Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: different mp3 files from same command line (Read 3213 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

different mp3 files from same command line

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.
God kills a kitten every time you encode with CBR 320

different mp3 files from same command line

Reply #1 –
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.

different mp3 files from same command line

Reply #2 –
Quote
Originally posted by timcupery
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.

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

different mp3 files from same command line

Reply #3 –
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...
God kills a kitten every time you encode with CBR 320

different mp3 files from same command line

Reply #4 –
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.