MP3 encoding is largely a CPU bound process. Faster CPUs or parallel CPUs will directly speed up your encoding times. However, your CD-ROM has to produce data fast enough to feed that faster encoder. With grip, watch the two thermometer guages for ripping and encoding. If ripping is fast and encoding is slow, then faster CPUs will help you. If the encoder is winning, then you need a faster CD-ROM. Also, keep in mind that lame CBR is about twice as fast as lame VBR.

If your goal is to have the fastest possible MP3 encoding system, get the fastest dual-processor machine you can afford and get a Plextor CD-ROM drive. You can tell grip how many CPUs you've got and it runs that many copies of lame in parallel. Cool stuff.

Grip is really fantastic. The only gripe I have with it is that it doesn't know anything about ID3v2 tags (only ID3v1.1 which has 30-character fixed-length fields which chop off long song titles). However, grip stores the full track information in the MySQL database. You could theoretically hack together a Perl script to read the database and add ID3v2 tags to all your files. The only issue is if you move the files around, they can get out-of-sync with the database.

DDJ is a nice toy, particularly the BPM-o-matic hack, but it needs a whole lot of work before I'd use it on a regular basis. To play music on my Linux box, I've been using FreeAmp, which will scan all your MP3s and build its own database. Still, if you've got an EMPEG, the EMPEG's playlist management stuff is dramatically better than FreeAmp or DDJ. These days, I just have my EMPEG hooked to the home stereo in the next room while working in my office. The only minus with this setup is that I occasionally want to run to the other room to read the track information. I can live with it. :)