ripping MP3's?

Depends on the settings you're comparing and equipment, but yeah it can make a huge difference.

I assume you're using the LAME encoder if your speed is slow? If you're using the presets, add the "fast" tag. "--alt-preset fast standard (or extreme)". High bitrate FhG encoders can sound very well as well (though most give a significant edge to LAME, especially if size is factored in), but it tends to be much faster. In either, you reach a point where you may be high enough up the bitrate ladder, but then again I don't find an encoding time difference between say 192 and 320.

There are also newer codecs like Ogg and AAC that may encode much faster with similar quality. My QT/iTunes AAC encodes at 4X-8X of LAME (~4/8 depending if "fast" tag is used). If compatibility with a specific portable is not a concern you should also give these a try. 192/224 iTunes AAC (and likely q6/q7 Ogg) is very comparable to -aps/-apx LAME, and will encode very very fast.

Re: ripping MP3's?

As you state, you want the best quality that you can get, so to achieve that, it obviously takes longer to rip. Using a ripping software like EAC to achieve acuracy, when it's ripping from CD to wav, it'll take several passes to make sure there are no errors in the outputed wav file. If your CDs are in relatively good condition, then you might no need such rigorous checking and can change your settings to gear EAC more towards speed as opposed to accuracy.

Stick with 192 kbps. Mp3s encoded at 192kbps sound great on my Nomad Zen, but Mp3s encoded at 128kbps don't sound as sharp and dynamic.

First, before AIM9x can yell... the search function is indeed active and working...

Second, I myself use EAC and FLAC, but that's going to a 120GB hard drive. For portbale use, you're usually limited to MP3/WMA (except for the new Rio's, which can also do Vorbis and FLAC), so for MP3, LAME 3.90.3 --alt-preset-standard is probably your best bet. As blessingx said, you can add the fast tag if the encode time is really unbearable. There is a noticeable difference in quality, but try both out; you likely won't care in a portable setting.

Also, just out of curosity, what CPU/speed do you have, and how much/fast RAM? I've got an Athlon XP 2000+ with 512MB of DDR333, and it takes me, on average, a little over a minute to encode one song in LAME 3.90.3 --aps Ah yes, in comparison, with Ogg Vorbis (OggEncGT3B1), at -q6, it takes about 40 seconds to encode those same songs. And did I mention they're 1-2MB smaller than the MP3's, and sound the same or better?

(-:Stephonovich:-)

With EAC and Lame, on my 1700+ with 768MB RAM I usually get 4x overall speed (48 minute disc takes about 12 minutes to rip and encode to 192kbps MP3). Fast enough for me.

Umkay. Not too much difference, I see. The amount of RAM doesn't have too much to do with it after a certain point (256MB or so, methinks), though. Also, the version of LAME you're using can matter. 3.90.3 is the supposed best sounding version; compiled by some people at Hydrogen Audio. This can also kick up encode times.

(-:Stephonovich:-)

When I was using a 550MHz Celeron machine I used to rip six or eight CDs to wav using EAC and then encode using RazorLame as a front end to LAME. I had a CD-ROM and a CD-R/W in that machine and could use both devices to rip at the same time. So I'd rip CDs for maybe 30 minutes and then let them encode overnight. If I let EAC do all the work serially it would take about double the length of the CD to get everything done. On a slower machine, assuming you have the disk space, doing the ripping and encoding as two separate steps is definitely the way to go.

Now that I have a dual 2.8GHz machine, there's no point in doing the batch encoding. I tell EAC to launch four encoding threads and it has the first track encoded long before the second track has finished ripping.

Just to keep the time comparisons going... using iTunes on a dual 450 RISC machine, at 224 AAC (with error correction on and the ripping & encoding done as a single step) about 3.5 minutes per album.

Question regarding LAME encoding:

I always encode at alt--preset standard.
I saw someone post about adding a "fast" tag. What exactly will this do? Will it speed up the encoding? By what percentage and at what detriment to sound quality?

Thanks
Gregg

The fast tag doubles the encoding speed on my machine. It always comes with the "potential slight quality loss" warning. Since it's only "potential" and not even assumed, I use it whenever encoding -aps or -apx (it's not an option for -api). I haven't found any difference in tests. Also if you have multiple processors there's the "--multi" tag. Another plus is the "--vcomment" tag that writes your settings in the comment field. That's pretty useful. Generally I use "--alt-preset fast extreme --vcomment".

Aw c'mon... isn't this comparing apples to oranges?!?!?! (pun strongly intended) :

3.5 minutes per ALBUM?! Dang, I knew Macs were faster at multimedia stuff, but not that fast... Ah well. The Athlon FX 64 proved it's worth, giving the G5 a well deserved butt-whooping. Once again, PC's regain their rightful place on the throne.

Anyhoo... EAC is mainly what slows me down, as the fastest I've ever had it ripping is about 5x on a perfect CD. I'm using a 24x/12x/4x CD burner, due to the fact that I know the offsets for it. So even if a CD is perfect, with no scratches, I'm looking at ~15 minutes for a rip of a (700MB) CD.

Really? Maybe I had something screwed up when I tested. The -fast tag seemed worse (quality wise) to me. Perhaps I'll have to do re-test tonight...

I had a PIII 550MHz, and even ripping one CD bogged it down. Of course, that was with 64MB of RAM, too. Encoding an album on that usually took me, oh, about 30-45 minutes. I remember reading one time about the author of Blade (older MP3 encoder, which was at one point, the best in quality for >=192 KBPS. Below that, it sucked. Badly) saying that on a PII 266 box, he'd leave it running all night to encode one album. Now that's dedication

Finally, I just did a --apfs and --aps test; I couldn't tell the difference. I must have had something messed up big time. Either that or I had the compile optimized only for --aps. However, the --apfs one was about .5MB smaller than the --aps. So presumably more information is being thrown away, if you're the type to worry about that. (like the -k tag... why anyone would worry about 18KHz sounds is beyond me...)

(-:Stephonovich:-)