Hi,

I am going to rip + encode my complete CD collection. My CD-ROM drive can rip at 6x speed and I am using CDEx + LAME. I would like to encode on-the-fly as I have so many CDs to get done with.

From what I have read here, LAME 3.96 is faster and so uses less CPU than the previous versions. So it seems to be the right encoder for ripping at 6x speed on an AMD 2000 XP-M CPU, am I right?

What are the recommended for encoding to MP3 VBR on the fly at such a speed:

--preset standard

or

-- preset fast standard

'standard' is my desired quality, but I would consider reverting to medium if it it was necessary at that encoding speed with that CPU.

Thanks for any tips, Ernie.

I have a p4 2.8 HT, and --apfs encodes near 15x for me, so if speed and quality is what you want, then --apfs is good

AthlonXP 1.92GHz, here, and I generally get between 4x and 7x, using APE (don't know for APS or APFS, but surely faster!). Even with 3.90.3, it only gets down to 3x on really good stuff (The Digital Fox and Apostrophe have been all that bring it down to that so far).

I have a Philips Aurilium and KSC50 headphones, and while standard is transparent on that for about 2/3 of songs, the other 1/3 are annoyingly bad, being used to the real thing. I can't tell a bit of difference myself between 3.90.3 and 3.96.

But just start testing with some good old recordings or good remasters.

With a XP 2000+ (1.67GHz, IIRC), APE or APS aught to be fine, given a max of 6x read speeds.

IMO encoding on the fly is only going to waste ripping time. I believe that whilst your sat at the PC your time is best spent ripping, then when you're away from the PC you can then set your PC to encode all your wavs (unless HD space prevents you from doing this?).

EAC has the ability to batch process wavs like this (I'm not sure about CDex).

I'm encoding right now, browsing multiple forums, and only on a Athlon (classic) 700 (short story: my CDROM drive died today while ripping some Albert Collins). Starting programs takes forever, but using them doesn't.
Encoding as you rip removes a bottleneck, whether it is the CPU or the reader. Maybe on your system, you can't use it while encoding (I know that's the case on Durons), but if you can, there's no real reason not to.

This assumption is incorrect. While 3.96 is significantly faster than 3.90.3, both consume up to 95-100% of the CPU on my box.

Of course: if you ask the encoder to encode, it will encode as fast as possible, so it will use all available processor time.