Hi!
I have just startet using EAC(V0.95 prebeta 5) and LAME(v3.96.1), and i got two questions.

First, I have ben using Musicmatch 8.1 until now, and is realy EAC better? I have ben ripping at 224kbps. I have anly ripped one cd with EAC, and what I noticed was that with my other files the 224kbps was steady at that rate all the time, while the one from EAC varied all the time.... and it is MUCH slower then Musicmatch....

And the other q, is it posible for the EAC to make sub dirrectories? Cuz' I want it to be like this c:mp3\BandName\Album\file.mp3

EAC is not better ... is more secure ... it uses a ripping method where it rips twice all sectors, so it can be sure what it was ripped is OK ... it is slower, but safer ...

If your drive supports C2 error reporting (and you trust it), you can use it instead of reading twice.
This is both safer and as fast as Musicmatch, but maybe not as safe as reading twice.

EAC can also workaround audio caching in drive, making it even slower,
but then it can report errors which would be hidden from read twice mode.

There is also Burst mode available for those who value maximum speed over security.
You can also use Test & Copy mode comparing MD5 of ripped data. (more than twice as slow, because of seeking and such...)

In other words, what the guys are trying to tell you is this:

• EAC is secure. It makes sure that the CD is ripped as accurately as possible. Hence, you won't have any pops or blips in your rips. This makes EAC a better ripper in terms of accuracy than MusicMatch. Since EAC double-checks everything, it is slow.
• If your drive supports C2 and is relaible (which it rarely is), you can use C2 error correction, which makes it faster.
• If you really want fast rips, you can use the burst mode, which is not guaranteed for accuracy. But if you want to rip your CDs just once and be sure that you have the most accurate rips possible, don't do this. This defeats the entire point of using EAC. You might as well stick to MusicMatch.
• You seem to be a real newbie. So, why don't you set up EAC the safe and easy way?
• LAME 3.96.1 is not the recommended version. For best results, use LAME 3.90.3 available in the downloads section in these very forums.

Hope this helped, bye.

(slightly off topic, but I couldn't resist)

I know that I'm by far not the first one to claim so, but as long as everybody keeps feeding themselves and each other this v3.90.3 recommendation, no one is ever going to be benefiting from the improvements of v3.96.1. The sheer argument "stick with v3.90.3, since it's the recommended and most widely used and tested version" is self-fulfulling, unoriginal and contraproductive.

Gabriel, I'd appreciate it if you could shed some authoritative light on this.

Edit: fixed quote.

Edit 2: I also know that the whole 3.90.3 vs 3.96 matter has been discussed abundantly in the sticky - hence I know that I'm by far not the first -, but it keeps striking me with how much perseveration people keep advocating v3.90.3. That's why I think a comprehensive round-up by one of the LAME developers would be nice. Don't mean to rake over old ashes at all.

@Nozaki
Hi - Have You already seen the recommended Lame settings? - When using Lame 3.96.1 this new Lame settings overview may be of interest too.
I (and many others i guess too) would recommend You the check out once the Lame 'Presets' with variable bitrate modes (VBR), because they give You a better quality/space ratio.
Another (quite personal) point is, don't care about ripping time. You rip and encode it once and will listen to it serval times or even for years.


Yes this is possible. See the 'EAC Options' (F9):
On the 'Filename' card set the '%A\%C\%N - %T' for 'Naming scheme'.
On the 'Driectories' card set 'C:\MP3' for 'Use this direcotry'.



Now i also have a question: What codec is using Musicmatch 8.1? Any dubious FhG codec running by default in a half-hearted fast mode?

1. I updated the LAME Versions thread and added a recommendation for 3.96.1 for low to mid-bitrate VBR.

2. 3.90.3 is just the HA.org recommendation. LAME developers - of course - will always recommend using the latest release.

3. I personally believe that for transparent archival 3.90.3 (--alt-preset standard) is still the sanest choice, since it has been tested by thousands of ears on thousands of samples (and the number of reported problems is incredibly small). It's the oppinion of HA's moderation that the advantages of 3.96.1 are too minor to justify replacing 3.90.3 as HA.org's recommended version.
Of course we encourage all interested users to do their own testing and decide for themselves if the advantages of using 3.96.1 outweight the peace of mind of using 3.90.3.

maybe it can't be compared so directly ... but it shouldn't it mean something, that 3.90.3 was LAST on the first listening test, while 3.96 was SECOND on the last one? or i'm missing something?

You're missing some important facts:
1. LAME 3.90.3 used ABR in the first test, LAME 3.96 used VBR in the second one. (See the note about low to mid bitrate VBR modes)
2. Results from one bitrate can't be extrapolated to another one so easily.

well thanx, this has truly helped me