Hello all,

Up to now I've been using Easy CD-DA Extractor 6.2 (with LAME 3.93), encoding @ 192. Ripping process was fast enough for me (7x average with a Hitachi DVD-Rom GD-2500), but I heard that LAME 3.93 is a bad version.

Which had me look for better : I was advised EAC 0.95 prebeta 4 + LAME 3.90.3.

My problem is that it seems to be slower... It does rip at a 7x average just like EZ CD-DA Extractor, but then it has to stop between each track and start up a DOS window for Lame.exe, which then encodes the ripped WAV at approx 5.5x...

Is there any way to have EAC encode to mp3 "on-the-fly", ripping directly to mp3 just like EZ CD-DA Extractor does ? I think the latter uses the LAME dll to rip that way, so can I use the LAME dll with EAC to achieve the same thing ?

Thanks in advance for any help, and sorry if this question is "lame" I did read the FAQ and a lot of posts without finding any info...

EAC rips to wave as an intermeditary step.

Lauching the dos box should not slow down the ripping process at all.

Yes, EAC can encode on the fly.

EAC isn't very clear about things like this, though. It'd be harder to make it more confusing.

Put the lame_dll in the eac directory, disable the use of the external encoder. And in the 'waveform' section, chose the mp3 encoder & the preset you want. And set the .mp3 extension and check the boxes.

An alternative would be to make an image of the cd and then mount that with a virtual cd program, and then rip from that. That way you can use external encoders without the cd starting & stopping.

Or, you could just rip to WAV and then encode from that. EAC, Lame command line, or LameDrop.

Personally, I'm rather fond of LameDrop, except that it has some limitations in tagging. (Be nice if the author would add an option to prompt the user for the tags for each file dragged onto it.)

Also, I think LameDrop only works with the older 3.90.3 version and not the newer versions of LAME (since it's compiled in, rather than using a DLL.)

I used the Lame DLL with EAC for a good portion off my rips. It works well and eliminates the intermediate WAV file. However, you don't have as much control over the compression options. This really isn't much of a problem if you use the Lame presets.

But I switched back to external compression (using Ogg) because you can set EAC up to compress and rip at the same time. Go to the "EAC Options" then "Tools" tab and enable the "queue compression in background" option. Most likely you should choose 1 thread. This allows the extractor to continue reading the CD while the previous track is being compressed.

You may find that the lame dll is even slower than using the "start external compressor cued in the background" option in EAC.

If ripping several albums at once, you might want to try opening the compression que control center ctrl-q and check make all compression tasks sleep. When you are ready to take a break, uncheck the box and let the computer do all the compression tasks while you are not there waiting. The ripping, which requires frewuent attention to change disks, also goes faster this way.

This is cool and I got it to work. But now there is a tab for other Lame options that appear and no way to get rid of it. Does anyone know if selecting a preset overides these options or are they tagged onto the command line even if you select a preset?

BTW, it is really slow too...

Thank you all for your input.

I have just tried the Lame dll thing. It's pretty nice, but it doesn't support the alt-preset insane ! I set it to 320 kbps joint stereo 44.1 khz, which seemed to give the same result, only the file was 1 frame shorter...

The interest of the dll for me was getting rid of the intermediate wav file, to cut my hd some slack... But i might just go back to the exe and queue up the compression jobs (thanks to those of you who suggested it).

First of all, I would like to apologize for bumping into this old thread...

But I was trying to use the on-the-fly feature of EAC via lame_enc.dll for the first time. I managed to set it up and it works. The "problem" is that this is not on-the-fly ripping! EAC rips the track first, then it says it is compressing, when the indicator comes to 50%. If you check the folder you are ripping to at the time of compression, you can see, there is a hidden wav.temp file. So it is basically the same as if one would use the lame.exe with EAC and with the option 'do not show console at encode'...

Anyone ever used REAL on-the-fly encoding with EAC?

Sorry, I'm not sure if I understand you correctly.
Do you mean something like encoding an half-ripped track or something the like by 'on the fly'?

I don't know about using the dll and/or non-user defined encoder,
but if you use the exe and user defined encoder it does complete the rip of the track first,
then starts encoding and keeps on ripping the next track.
So it's ripping and encoding (altough external) at the same time.
That is as much 'on the fly' as I can imagine since it's most likely not possible to encode half-ripped wavs.

With on-the-fly I meant the kind of ripping CDex does. With no wav being written to the drive! So it's basically ripping to memory and encoding directly.
I conclude from your post, that EAC is uncapable of such operation. As you said... if you let EAC to rip the next track, while it is still encoding the previous one is the nearest to real on-the-fly ripping EAC can get.

Thanks for the answer(s).

I'm pretty certain that EAC uses the Monkey's Audio dll on the fly. A temporary wave is written but the compressed .ape file finishes just as the track finishes ripping.

Ah, now I know what you mean, but I don't know if it is possible or not.

I never tried CDex, so I have no Idea how it works.
Are you sure that CDex isn't creating any temp-file too?
Does it start the encoding process instantly after it startet ripping?
If it starts encoding after the first track is ripped it likely creates a temp-file too.

Edit: So it may be encoder-dependant?
If it acts like greynol describes it, it may be possible to rip to the memory too.

@Hollunder: CDex certainly does it on-the-fly. It makes no temp files. The mp3 is directly made from the CDA. I don't know why, but this feature seems to be very important to me... I kinda feel better.
Because of this, CDex was my ripper of choice for many years now. But yesterday something happened and all at the sudden, I wanted a change. So I tried EAC and Easy CD-DA Extractor... I like EAC being secure and all, but I kinda miss the on-the-fly ripping.
I have also made a comparisson between these 3 rippers (with 5 different CDs). These are my conclusions: EAC at all modes (secure, paranoid, sychronized, burst) and Easy CD-DA Extractor produce bit-for-bit exact same wav files, whereas wavs that CDex produces are different all the time.
So, I just can't go back to CDex after learning this... Also, Easy CD-DA Extractor is not for free. And EAC doesn't do on-the-fly... So I'm desperate.

EDIT: My drive is LITE-ON DVDRW SOHW-1613S AS06, if anyone is interrested...

At least with EAC 0.95pb4 and using the lame_enc.dll, EAC only rips on-the-fly in secure mode - in burst mode, it appears to create a temp WAV file (although I'm not exactly sure what it's doing as it creates both a ".TMPWAV" and an .mp3 file at the same time...). I don't know about paranoid and sync modes as I've never used them.

The CBR modes ("128 kBits/s, 44,100 Hz, Stereo" etc.) don't seem to be affected by the parameters under the "LAME DLL" tab, nor do the Presets - it's when you select one of the "Minimum xx VBR" modes that the additional settings come into play. Also, while I can't verify this right at the moment, I'm pretty sure that even if you select one of the Presets, EAC sets its own minimum bitrate, and I seem to recall this changing between pb4 and pb5.

Edit: In burst mode, it does indeed rip to a temp WAV file and then encode with LAME - it just creates the files simultaneously. Note that this actually ends up being fairly slow (well, depending on the speed of your drive and CPU) as it can only rip one track at a time before it has to stop and wait for LAME to compress.

One of my drives is a LITE-ON DVDRW SOHW-1693S (but it does a rather bad job at ripping)
But I think that this doesn't depend on the drive but on the applications/settings.

I would go with EAC, either secure mode or burst mode with test & copy(faster) (you can of course use T&C at secure mode too) and maybe accurate rip with both. And I would use 'user defined encoder' too.
This way you can be sure to get your discs at the drive as intended.

I read that dbpoweramp is getting a secure mode similar to EACs but I don't know details on this.

I would consult the wiki on EAC for detailed informations and links to guides (maybe there's some info on 'on the fly ripping' but I don't think so).

Well, but that's only relevant if you care about really exact copys and proper error correction, if not you could just use burst mode or one of the possibly faster rippers out there.

@mixminus1: Thank you!!!
I was indeed using the burst mode in EAC. Then I tried the secure mode... It actually ripps on-the-fly now!
From now on, I only use EAC!

I wouldn't worry about LAME settings... presets are from 3.97 on all set up properly. There is no need for any custom settings!

@Hollunder: Thank you for your suggestions! I am using the secure mode, since my computer is not fast enough to encode on-the-fly any faster than ripping goes with this mode. I'll probably add the AcurateRip function as well... Thanks to mixminus1, ripping is on-the-fly now!