dwasifar's daily gripe

I’ve spent today playing with the new Ubuntu 9.10.  Every release has something new to adapt to, and this one is no exception.  The two things that stand out for me as problems are  1) Installing kubuntu-desktop over standard Ubuntu no longer plays nice, and  2) My longtime CD ripper of choice, Grip, is no longer in the repositories.  I’m still figuring out what to do about the first thing, but I found a solution to the second.

A little poking around on the forums revealed that Grip was removed from play at the request of the maintainer, which probably means it’s not being maintained any more.  This left me two choices: either install Grip from an old package intended for a previous version of Ubuntu, or find something else that’s being actively maintained.  Since the first choice leaves me depending on an abandoned package that will never have any updates, I decided to try to find something new.

There are plenty of rippers available for Linux, many of them in the Ubuntu repositories, but the particular charm of Grip was its extended configurability.  You could control the various encoders to a high degree of precision, because Grip let you configure the actual command options that were sent to plugins or external encoders, as if you were encoding manually from the command line, and specify filenames and directory behavior with template strings and variables representing things like track number, track name, album name, and so forth.  Here’s what I mean:

From this you can see that I use Grip with the lame encoder, with the setting –preset extreme (very high quality VBR encoding), and you can also see how the save paths work.

Ubuntu’s default ripper right now is RhythmBox.  Before that it was Sound Juicer, which is still in the repos.  RhythmBox is a full featured media management app, and is complete overkill if you just want to rip CDs.  Sound Juicer doesn’t give you much configuration flexibility, and is known for its difficulty in configuration if you try to go outside the preset options.  I tried a couple of other rippers, like Ripoff, but I found the same issue there too; if they use lame, they don’t give you the option to take advantage of its options.  Typically there’s one slider for “quality” and that’s it.  The other option is to go to a commandline interface, but that’s counterintuitive for ripping CDs.

So on the advice of an Ubuntu Forum post, I tried RipperX, also in the repos, and found it to be acceptable with a minor tweak.

RipperX has the ability to configure filenames and directories, not with as much granularity as Grip, but enough to do what I need it to: /Artist/Album/[tracknum] [artist] – [trackname].mp3.  And it has almost enough configurability in encoding parameters:

What this doesn’t tell you is that the bitrate you choose here becomes the minimum bitrate if you click the VBR box.  Some people seem to have been screwed up by that; they click 320k and check Variable Bitrate and wind up with big files that are all 320k.  I tried it with the settings you see here and I got files that were almost the same quality as the ones produced by Grip; a test track ripped in RipperX came out to 9.8MB at an average bitrate of 147, compared to 10.3MB and average bitrate of 153 for Grip’s version of the file.  This is pretty good, but not quite good enough; I didn’t want to sacrifice any quality at all, so here’s where the tweak comes in.

In the home directory, RipperX creates a hidden file, .ripperXrc, containing your config settings.  Get everything besides the encoding options the way you want it, then edit this file.  The line you’re looking for begins with Encoder::fullCommand and in my case it was this:

Encoder::fullCommand = lame -b 128 --nohist -v -h -p -V 0

If you compare these settings to lame’s helpfile, you can see that RipperX’s configurator doesn’t do a very good job of building this string.  -v by itself is the equivalent of -V 4 (variable bitrate, quality setting 4) and is redundant because of -V 0 later in the string.  But it doesn’t matter, because we’re replacing it anyway:

Encoder::fullCommand = lame --nohist --preset extreme

This duplicates the setting I had in Grip.  Running RipperX with this change produced mp3 files identical to those from Grip.  You may, of course, use any settings you like here, even –preset insane if you are really intense about quality and don’t care a fig about file size.  Or you can just forget about editing this file, use RipperX’s configurator, and accept the options it offers, which are pretty good – better than Sound Juicer’s or Ripoff’s.  But if you do choose to edit .ripperXrc in this way, you must include the --nohist option in lame’s parameters.  When run from command line, lame puts up a little active display using console characters – the “histogram” – showing its progress.  RipperX gets confused if it gets the histogram from lame behind the scenes.  Tracks will still rip successfully, but the progress bar jumps around and doesn’t display accurate values.  Using --nohist prevents this problem.

If you plan to edit the file on your own, make sure it is the last thing you do; further configuration changes from within RipperX will overwrite your edit.