I am trying to rerip all my MusicMatch (yuk) 160kbps MP3s with EAC/LAME 3.90.3 and --alt preset standard.

I have followed the detailed instructions on this and other sites to configure EAC and LAME and am getting rips that vary from 160 - 230 kbps which is a little wider range than I expected for --alt preset standard, does this sound right? Also am I correct in saying under "Compression Options" in EAC once I point to the LAME program and enter "--alt preset standard" (no spaces before or after the -- correct?) in the additional commands box that NO other menu options like joint stero, VBR vs. CBR kbps levels etc. matter at all. Basically entering "--alt preset standard" guarentees proper encoding...

I hope I have this setup right, if I am doing something wrong let me know before I begin the painful process of ripping 200-300 albums...

Thanks...

1) You cannot improve quality by re-encoding MP3 to MP3.

2) It seems that the parameters are OK.

Oh no, I am re-ripping from CD, not from my old 160 kbps MP3s.

I just wanted to make sure that

1) having a few 160-230 kbps MP3s from --alt preset standard was not unexpected (I thought 180 or so would be the low end, but it seems not to be... trust me the hard drive thanks me).

2) that once I entered "--alt preset standard" in the compression options menu that all the other DOZENS of menu settings for LAME under compression options no longer matter. i was worried not having the VBR/CBR, stero modes, quality of encoding options etc. properly set would affect me, but it appears --alt preset standard does all that.

i have configured EACs other menus such as drive options etc. as per the various tutorials.

If you have entered "--alt-preset standard" the codec will take it from there. It works for me. Happy Trails!

Sounds about right, depending on what types of music you are encoding.

Examples; Metal (eg., mostly "high energy") = ~230

Classical (eg., many "quiet" spots) = ~160

More examples:

Old reggae and dub (probably mono recordings) = ~130 kbps

Noisy electronic = ~200-230 kbps

that's exactly what i am seeing... for example i just ripped tori amos - under the pink and the quiet songs are in the 160-180 range while the more high energy, multiple instrument songs are well above 210... i didn't expect such a wide range but am very pleased the codec appears to be smart enough to manage my hard drive space, because until now I had only used CBR. i have 2 80GB drives and a 20GB iPod and decided enough is enough, I had to get rid of my 160 kbps CBR MusicMatch non-error checked MP3s and replace them with something *slightly* larger but much better sounding. MP3s are a must for me since I use streaming from my PC to Tivos, which don't support AAC or other formats.

its sad but true, louder songs require a higher bitrate, thats why some wavegain before encoding...

well small is better, but i like that the system is smart enough to use space when it needs to. if i need 230 to have mostly transparent sounding MP3s so be it... it should be offset by the 160 used in quieter songs i own.

the *only* painful thing about EAC/LAME is how long it is going to take to rerip all my CDs... the recording time is 4 TIMES longer than under MusicMatch, but it is obvious there is a reason for that.

i imagine the reripping process for me will take MONTHS.

It could go faster if you imaged the cds onto your harddrive and then mounted the images with "D-Tools" then set EAC to rip from the mounted image. You'd then go off the speed of the hard drive. It might go faster.

Later

While the idea of letting EAC/LAME process imaged CDs all at once, say overnight while I sleep is appealing... it sounds like the process will likely still require just as much hands on time... as it does take quite some time to image the AIFF/WAV files, and you still have to sit there swapping the CDs right? Where it the time savings... maybe I am missing something?

I just can't realistically keep the full AIFF/WAV versions of my CDs on my HD (I could in lets say 20-30 CD batches for future processing) as a "permanent" collection to use with future codecs like some do, I just don't have the space. It sure would be nice though...

some 120 GB (5200RPM HDD which I highly recommend for a music collection) can be bought for street prices well below 80€ ... and if you complain about lame's VBR preset encoding speed (on my AMD 3000, I get a max of 5.3x if I'm lucky), you should see FLAC ... lossless encoding for future transcoding at blinding speeds.

Maybe a slight investment in a new HDD would pay off for you in the end ...

Have you chosen "User defined encoder"? To be on the safe side you should do that, then EAC won't add any other options than those you type in the box. You need to add %s %d after --alt-preset standard, when using user defined encoder. There is a thread on this in the FAQ.

EDIT: BTW, you haven't considered MPC? Smaller files, better quality and I think it encodes faster (?) If I were to store my music collection on HD for playing on my PC only, I would go for MPC...

BTW2: You like SAAB? (Best car in the world...)

But this would mean no secure ripping and hence no point in using EAC?
Instead I suggest ripping to wav during daytime (when you are awake to switch CD:s), and then batch encode everything during the night using RazorLame or some similar frontend.

actually i FLY Saabs for a living.

someone said this:

"Have you chosen "User defined encoder"? To be on the safe side you should do that, then EAC won't add any other options than those you type in the box. You need to add %s %d after --alt-preset standard, when using user defined encoder. There is a thread on this in the FAQ."

Now I have set the user difined encoder and pointed to the LAME.EXE (3.90.3) file on my Hard Drive. What does "add %s %d after --alt-preset standard" mean? Right now in the extra commands box I simply typed "--alt-preset standard" and nothing else. What should I have entered? Now I *am* confused...

but your not ripping the CD, it has already been ripped with some image mounting program; thus, bypassing the entire main reason to use EAC

It means the command line should be --alt-preset standard %s %d

Without this EAC won't pass to LAME the filenames of the input and output files.

The reason you need to use User Defined Encoder is because if you use LAME MP3 Encoder, EAC adds values to the front of your command line. For example, if you have the default bitrate 96 kBit/s and High Quality selected then it will add -h -b 96 before --alt-preset standard.

I don't think you need the %s %d when using external. I'm re ripping all of my CDs using --preset standard as the only parm in EAC, and the things are working fine. I'm using LAME 3.95.1 as the underlying engine.

dnimtz: you need it (%s %d) if you set user defined encoder on the external compression tab and let it point to lame....
the reasons why most of us want to set it to user defined instead of lame was already mentioned by saabcaptain (as we want to pass only the commands to lame we define & not mixing it up with other settings)

Yes, this is exactly it. If you choose LAME MP3 Encoder then EAC constructs the following command line for you:



So if you type --alt-preset standard in the Additional command line options box you will get, for example:



This is a valid command line, but has the unnecessary quality and bitrate switches. However, if you choose User Defined Encoder then EAC constructs the following command line only:



So with only -alt-preset standard in the Additional command line options box you will get :



Lame can't do anything with this because it has no file to operate on. Adding %s %d to the end of the Additional command line instructs EAC to replace those placeholders with the input and output filenames to give what we really want:



There... I think I've explained that one to death

OK...

I am *still* confused, perhaps I am dense. I am staring at the EAC interface right now and I want to confirm the following options...

Under the Menu, "EAC/Compression Options..." there are 5 tabs: "Waveform, External Compression, Offset, ID3 Tags, Lame DLL".

1) Under "Waveform" EVERYTHING IS GRAYED OUT.
2) Under "External Compression" the "Use external program for compression" is CHECKED, "Parameter passing scheme" is LAME MP3 ENCODER, "Program, including path, used for compression" shows THE LOCATION OF LAME 3.90.3 ON MY HARD DRIVE, "Additional command line options" is set to "--alt-preset standard" (IS THIS WRONG?????), "Bit rate" is VBR 192 kBit/s, "High Quality" is CHECKED, "ADD ID3 Tag and Delete WAV after compression" ARE CHECKED.
3) "Offset, ID3 Tags, Lame DLL" have NO modifications from default.

Is this right? As far as I understood having the location set correctly, having use external program for compression checked, and setting additonal command line options to --alt-preset standard ARE ALL I NEED and in fact basically OVERRIDE all the other menus and setup all the LAME stuff for me.

What am I doing wrong? What should be in the box saying "Additional command line options"...

OHHHHH... I think I get it !!!

I have "Paramter passing scheme" set to "LAME MP3 encoder" INSTEAD OF WHAT YOU ARE ALL SAYING I SHOULD HAVE IT SET TO, "User Defined Encoder".

OK... so that leaves 2 questions...

1) When I set it to "User Defined Encoder" instead of "LAME MP3 encoder" what EXACTLY do I have to enter in the box that says "Additional command line options" to enable --alt-preset standard?

2) What exactly was wrong with setting it to "LAME MP3 encoder" and entering --alt-preset standard in the "Additional command line options" box? Why do we have to set it to "User Defined Encoder"?

Thanks... I just want to make sure I am getting the best quality --alt-preset standard rips when I finally start this pretty big project.

Thanks so much... someone needs to take a program like EAC, bundle it with LAME 3.90.3 and have a menu options which is clickable and sets the whole thing up with --alt-preset standard and conservative, careful, and exact burning options... MAGICALLY.

Change Parameter Passing Scheme from "LAME MP3 Encoder" to "User Defined Encoder"

Change Additional command line options from "--alt-preset standard" to "--alt-preset standard %s %d" (without the quotes).

Please note, this is really not a big deal. What you have will work alright. If you rip to mp3 with your current settings, then change them and then rip again you will get very similar mp3 files. But they will not be identical. Whereas if you use the settings I have suggested, your output will be bit-identical to what you would get if you ripped to wav and then encoded using lame at a dos prompt.

and once I do this then NOTHING ELSE in the entire "Compression Options" menu matters correct? i get pure 100% --alt-preset standard rips and i am ready to go...

by the way... THANK YOU SO MUCH FOR HELPING ME... 300 CD's, iTunes, 2 Tivo's streaming MP3s, and a brand new iPod all thank you!

99.999% the way there...

As far as I am aware this is correct.

@phwip and magic75:
Why don't you read a little before spreading FUD?

Not to be mean, but the FAQ is meant to be read thoroughly.

From the FAQ: The truth about "User defined" VS. "LAME MP3 Encoder"

I have tested this with 3.90.3 and the parameter passing scheme does make a (very minor) difference to the file. For a start, the lame tag has the wrong bitrate written to it if you use LAME MP3 Encoder instead of User Defined Encoder. OK, not too big a deal, but it doesn't hurt to get it right. Not only that the music CRC is different.

I created a fake lame.exe - a little command line app that simply reports back what command line has been passed to it. With EAC 0.95 pb3 the following happens when LAME MP3 Encoder is selected:

firstly if High Quality is selected then -h is added to the beginning of the command line options, otherwise for Low Quality -f is added. After that the selected bitrate is added: if "Variable Bitrate XX kBit/s" is selected then "-v -b XX" goes on the command line. For "XX kBit/s" EAC just adds "-b XX". All this comes before any command line options supplied by the user.

I'm not entirely sure what LAME is doing with these parameters. I presume that because they appear before --alt-preset standard on the command line that they are intended to be overriden by that. The -h option that is added doesn't seem to make any difference. The -b XX option doesn't seem to be actually setting a minimal bitrate, but it does definitely change both the bitrate field from lame tag and the music crc from the lame tag. The change in crc indicates to me that the actual audio is different. Would you not think this?

I am aware the difference is minimal and probably irrelevant, but I did try and make that pretty clear:

saabcaptain had already been told to use User Defined Encoder (which BTW is fairly common advice on this board). Within that context he wasn't sure what to do with the %s %d, so I was trying to explain where they should go and why they are needed with User Defined Encoder. Hardly FUD.

No, since in the thread I pointed you to (did you even read it?) rohanc tested if the actual audio output would be the same. Guess what? It was.


Indeed, that is why I think it is adressed in the FAQ.
The conclussions there should be enough to stop thinking there is an actual, significant difference.
Continuing to ignore this conclussions, "just to be safe", is what I call FUD.

look guys, no big deal... as long as the "%s %d" add-on isn't hurting me, i am happy to have it in there and i have begun ripping with "--alt-preset standard %s %d" and it seems fine. as long as it doesn't make it worse i don't care, other than to say i am glad people are trying to help me when i ask these newbie questions.

as for the FAQ, to be honest i couldn't find one on this site until you just linked to it. i was able to find DOZENS of tutorials on how to configure EAC, but they focused on EAC settings unrelated to using LAME, leaving any talk of LAME to "use preset standard" with little extra info on proper configuration. thanks for the FAQ which i am not reading, but it seems I have EAC/LAME working with all your help.

thanks again...

Well this is getting very interesting. See to me the Music CRC from the lame tag should definitely not be different if the audio is the same. This is why I was sure there was more to it than just a wrong bitrate in the lame tag. Looking at the thread you quoted talks about the file MD5s being different, which of course they would be if any of the file including the lame tag is different. But the music CRC is just for the audio part of the file and doesn't include any tag frames, even the lame tag itself.

Also I noticed that the thread you linked to stated that all the mp3 files were the same size. Although my tests generated similarly sized files they were definitely not identical in size.

Why would I be getting different results to rohangc? Well out of interest I tried the same test with 3.90.2 and in that case the resulting mp3 files were indeed identical apart from 3 bytes, one of which is the lame tag bitrate and the other two are the crc of the lame tag itself, which of course would be different if the lame tag contains different data. The musics CRCs in the lame tag were identical.

So my test on 3.90.2 gives me exactly what you would expect from rohangc's tests, but with 3.90.3 the file sizes are different, and doing a hex compare in Beyond Compare shows the files are almost entirely different.

Try it yourself. Forget about EAC. Just encode a wav with --alt-preset standard and then with -b 224 --alt-preset standard.

I am using the modified 3.90.3 from rarewares that includes preset medium. I don't know if that makes any difference.

Interesting indeed...

Maybe John33 can clear this up, because I thought that using the modified 3.90.3 would be even "safer" because it accepts NOTHING BUT alt presets, IIRC...

AtaqueEG: I think you and Phwip are doing some crosstalk here.... even if so far & with recommended build of Lame the files are identical - Phwip has through the actually passed switches a good point.... as the --ap setting is added after what EAC adds to the cl-parameters it overrides them - it may make a difference on newer compiles (if -h still is the same as -q 2 and -q is not overridden by -ap anymore [Edit: checked right now -h still sets -q 2] it will make a difference on the resulting file (q2 vs q3)....

Edit -> quick test on FatBoy.wav with Lame 3.95.1 and user vs. lame EAC set ->
user defined pure --alt-preset extreme -> mp3 filesize 177 KB, EAC set to lame and --APE with High Quality taged mp3 filesize ->197 KB
And here are the Lame Tag Fields:



In my eyes that is a difference - but agreed not on the recommended version...
(& why it mentiones encoding method cbr on the LAME set is unclear to me... aeh wait... the 320 set in the bitrate field of EAC... sigh & as I cannot remember a possibility to deactivate that field using anything other then user defined is at least for me OoQ. ....)

I've just tested this with vanilla 3.90.3 and the files are identical apart from those 3 bytes, just like 3.90.2.

I also downloaded the most recent 3.90.3 modified as I had an older one, but the new one still produces completely different files.

So for 3.90.3 it is definitely an issue for modified only.

Interesting discovery indeed.

What could 3.90.3 modified be doing differently than it's "plain vanilla" sibling?

Just for kicks, could you test 3.95? (I'm on a different computer than my "encoding machine"?

AtaqueEG: see my above edited post for 3.95

Ok... to add to it... had forgotten that bitrate defines the min rate....
so with it set to 128 (the same that is used with a pure cli --APE)...
the resulting filesize is the same for user and lame... but the files are not identical (diff. in 383204 samples) and here is the lame tag reading for encoder pass set to Lame, High Quality taged and Bitrate set to 128



diffs only again for encoder: user & --APE %s %d



So - the only difference remaining is the change in -q in when EAC is allowed to meddle with the passed parameters... So my decision would be to be on the safe safe side always use user defined to pass the command line

OK, I've tested a number of combinations of High Quality, Low Quality and different bitrates for 3.95.1.

The good news is that only the lame tag ends up incorrect. (For me this is still enough of a reason to use User Defined Encoder and recommend it to other people, but that is perhaps a little off topic now).

Interestingly whereas with 3.90.3 it is the bitrate setting that changes the lame tag and the quality setting is ignored, with 3.95.1 it is the other way around. The bitrate (for those I tested) had no effect on the file at all. But the quality setting is written to the lame tag so if you select Low you get quality 74 (V2 and q6) and if you select High you get quality 78 (V2 and q2) whereas a straight --alt-preset standard compression gives quality 77 (V2 & q3). In all cases with 3.95.1 the actual audio part of the files seem to be identical.

Phwip: Oops... that is in contradiction to my experiences above... now I am puzzled why (the diff. is to much to be only in regards to the lame tag field, isn't it? - or maybe not... -q2 vs -q3 is unaudible for me - so an abx test for me wouldn't do any good... for me that would be going back to the dreaded waveform compare (wich I have no time for anyways %> )) but as the difference of -q is written to the lame tag field... I think we can agree on the fact that the actually passed command line is different (wich your faked exe already has shown)... so the safe side still is user defined if you want to be sure that lame only gets what you want it to

Yes, this is very puzzling. The Music CRCs from your lame tags are different which indicates the actual audio is different. On the tests I ran the Music CRCs all matched.

Hmm.. it's too late now. Better knock this on the head and come back to it at a more sensible time.

No, the real "safe side" is to use only recommended compiles.

Of course, both should behave the same way, but that is EAC's problem, and as tests by rohanc and phwip have shown, there are no AUDIBLE differences (only Lame Tag differences, which, to me, are unimportant) when using both settings and the recommended compile.

Too bad, since 3.95 looks somewhat promising in other fields.

Oh, it just ocurred to me that the ultimate way to determine which one of the two encodes with 3.95 is the correct one, since the filesizes are different is to test their gapless quality.

You know, encode two tracks that are supposed to play gapless (such as two tracks on a live CD) and load them up in foobar.
The correct size ones will play just as they do in the original CD.

That could be a major audible difference.

As for 3.90.3, it plays back flawlessly.

Well, as we have already determined, this will depend on whether or not you are using the 3.90.3 from john33's modified bundle from rarewares, or standard 3.90.3.

I appreciate that the modified version is not the recommended compile, but I think people are likely to expect the audio part of the file to be the same from both with EAC. john33 said here:



Using EAC with User Defined Encoder you get identical output from modified 3.90.3 as you do from standard 3.90.3. With LAME MP3 Encoder you don't:

User Def Encoder, 3.90.3 Standard compile: file size 4,026,081, lame tag music CRC 0734
LAME MP3 Encoder, 3.90.3 Standard compile: file size 4,026,081, lame tag music CRC 0734
User Def Encoder, 3.90.3 Modified compile: file size 4,026,081, lame tag music CRC 0734
LAME MP3 Encoder, 3.90.3 Modified compile: file size 3,945,229, lame tag music CRC 33A2

Actually, if you are using EAC to encode, you must use "--alt-preset standard %S %D". Do not omit the hyphen between alt and preset, and do not omit the %S %D.

Regards,
Madrigal

AFAIK, the only real differences between the standard and the modified compile is that
a) --alt-preset xxx, accepts xxx<80
b) --alt-preset medium is accepted
I think there is also some minor things, maybe somethings with the lame tag, don't remember exactly. Only John33 can answer...

EDIT: Stupid answer from me , now I understand what you are asking about... Sorry... probably one of my most stupid posts ever...

I have read that thread thorougly and I don't think I am spreading FUD:

To me this is valid reason enough to suggest using user defined "just to be on the safe side". The original question was whether other options mattered at all when using --alt-preset standard, and obviously according to Volcano's summary there is one instance when it does, i.e when setting bitrate to 320 kbps. And when using --alt-preset <bitrate> the bitrate setting always matters. Sure, the question was about aps but maybe someday he wants to use --alt-preset <bitrate> and then maybe think if using "Lame MP3 encoder" works with -aps it will work with --alt-preset <bitrate> as well? To me at least, it seem like a good idea to recommend "user defined" as a safer choice, even though it doesn't necessarily make a difference in all cases. But thats just my opion.

Sorry - my views on that are not an audiophile approach but a technical one...
(just catch the passed commandline from EAC - it IS different)
And from a technical Point of View a difference in command line is all you need to advice on User Defined... or at least to let that information be contained in other advices... as used encoder and final file is of no matter in such a approach as I do... Cause I believe that one must always have the feeling to "know what he is doing" (even if that is based on false information - in my memory there hasn't been any one day were I haven't learned something new and therefore had to change my "known facts") ... and spreading the information that it makes no difference may lead to urban myths if it is not also given with the information of the differences in using those two methods...
And binding one to only recommended is - well - a good base and newbies entry point, but not a concept that should lead to ignorance...
And for me a "know what you are doing" approach is only given if I must not fear that one program (in this case EAC) is meddling with the things I want to pass on to another program (the encoder) - as only then I can be sure that it really does what i wanted it to do
Don't see it as a religious war - but I don't like important information to be lost or ignored due to something so minor the fact that for strict recommendations it makes no difference (when on the technical side there is one) :peace: