I've been using lame recently to convert some favorite cds to mp3 for use over the summer... I was given a discman-type portable cd player that can handle mp3 discs, and it'll be nice to only bring 10 cd's to the Yosemite high country and still have 100+ albums worth of my favorite music. I'm encoding at --alt-preset cbr 128, this isn't for archival purposes or anything. I'm looking forward to the day when ogg or mpc receives good portable support, and then I'll think more about archiving. Anyway, I can rip wav files and send them to lamedrop, or set up EAC to run lame.exe as an external encoder, or use john33's cdex with the lame dll and --alt-preset support. However, each of these methods creates a different file. I test this by decoding the mp3 files back to wav (always using the same decoding method), and then using the "compare files" option on eac. It doesn't surprise me that CDex, using the lame dll, puts out a slightly different mp3 file for --alt-preset cbr 128 than does lame.exe. However, it seems strange that lame.exe will put out differing wav files depending on whether I call it up using EAC or Lamedrop. I've got all my options configured in EAC so that it should be just sending the same commandline that lamedrop does.

for the record, this issue isn't one of burning importance. I can't hear a difference between the files from CDex lame dll, EAC-called lame.exe, or Lamedrop-called lame.exe. But it would still be cool to know what's up here.

Just to mention: John33's CDex uses daily DLL, compiled with VC6. And, if you use Mitiok's binaries, they are compiled with ICL. That may be a reason of part od the differences.

Regards;

Roberto.

Maybe you thought of this, but try to call lame.exe as a user defined encoder, putting the parameters you use for lamedrop into the custom parameters box and adding %s %d at the end for source and destination... I belive EAC will add some parameters to the line otherwise depending on the settings, I think the "high quality" radio button will add a -h to the command line if selected for instance.

If the resulting .mp3s still differ then, I'm out of ideas

Yeah, "User Defined Encoder" would probably do the trick. But from what I know, --alt-preset is supposed to include the "high quality" switch anyway, and the 128kbps that I selected from the dropdown menu should be overridden by the --alt-preset cbr 128 command. I'll try that...

Hi Tim. I don't know whether you already tried this or not, but your description of how you verified the difference in the encoded file made me wonder...

Are you certain the difference is in the ENcoding, or could it be that the inconsistency arises from the DEcoding process? To check this, you could try using a HEX editor to compare the MP3 files you've generated without decoding them at all. Or you could simply generate an MD5 sum for each of the MP3 files. If the MD5 sums are identical, the generated MP3s are identical; if the MD5 sums are different, then there was some difference in the encoded audio. A free MD5 program can be found here: http://homepages.ihug.co.nz/~floydian/md5/

Hope this helps.
- M.