Hi.

I was wondering, are there any disadvantages to encoding a song from an audio CD "on the fly" to the format you want, as opposed to ripping temporary WAVs and then encoding them from there?

Thanks in advance for the help.

Tyler

the only downside from what i know is that if you do have suffient RAM, the encoding my be corrupted.

Encoding on the fly is a audio track sent to the RAM and then encoded into an mp3 while another wav file is being ripped. Thus encoding faster formats (mp3s) would be fine, but high density files (-8 FLAC) might have some issues.

That's what my 2 cents.

1) Some encoders are "2 pass" and require the audio to be fed to the encoder twice. This pretty much makes writing a temporary WAV file a requirement

2) Many encoders are going to be slower than your CD drive. This doesn't change the end-to-end encoding time, but it might take less of your time to be able to remove the CD and put the next one in. [edit: in fact, end-to-end encoding time will be shorter when encoding on the fly, assuming proper multithreading]

> downside from what i know is that if you do have suffient RAM, the encoding my be corrupted.

Typo for in-sufficient?

Windows operates a swap file, ram has nothing to do with the memory avaliable to Windows (and 640 MB is quite small in comparison to a swap file.

The only downside of on the fly encoding is that EAC, the best ripping software, can't do it.

That's not really an accurate description of how it works. What actually happens is that the ripping program reads the audio data from the cd and streams it directly into the encoder, using pipe input. The encoder then writes the file to disk, usually in rapid small chunks. It doesn't start reading the next track until the current one is finished. If you watch CDex in operation with the task manager while ripping a long track, you will see that it never comes close to using as much memory as the final file takes up.

Edit: while trying out the new musepack, I observed CDex:
20mb ram / 15mb vm while ripping
14mb ram / 11mb vm while doing nothing
One of the output files was over 20mb.

Not exactly true.

EAC rips directly to .ape if you use the Monkey's Audio dll, for instance. I'm pretty sure this is true when using the Lame dll also.

EDIT: I just tried it with the Lame 3.97b2 dll (happened to be the first one that I grabbed) and it wrote directly to mp3, except that it named the file .wav instead of .mp3...
and it didn't include a Lame header...
and it didn't...
IOW, it doesn't seem to work quite right with the version of EAC that I'm using (V0.95pb5).