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: lame.exe vs lame_enc.dll (Read 6788 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lame.exe vs lame_enc.dll

Hi all.

In the course of setting up CDex for --preset standard encoding, I've been very surprised not to get the exact same output from lame.exe and lame_enc.dll.

Of course I know CDex does not cleanly support presets.
I used both the standard DLL + matching settings (br min/max=32/320, quality=alt-preset-standard, VBR quality=2) and john33's ini modified DLL (thanks John).
Both DLLs give me the same output file, byte for byte.

But this is different from what "lame.exe --preset standard" gives me.
Size is the same and content is roughly identical, but some bytes are changed here and there throughout the file.
Specifically, 0x60 (dll output) is changed to 0x64 (exe output).
Plus an extra change in the file header.

Every encoding was done from the same original wave file (NOT from a CD!).
I used Rarewares' 3.97b2 binaries (also tried 3.97b).

Anyone observed the same behavior?
Is this a known discrepancy between lame.exe and lame_enc.dll?

lame.exe vs lame_enc.dll

Reply #1 –
Maybe it's just the version info in the header that's different.  That could be normal.

lame.exe vs lame_enc.dll

Reply #2 –
I tried Audiograbber 1.83 & LAME 3.97b2 dll (from rarewares) with these GUI settings: Variable Bitrate, Method: New, Quality 2, Joint Stereo, Normal

and the command line exe version with -V2 --vbr-new.

foo_bitcompare says this:
Quote
INFO (foo_bitcompare) : Comparing:
INFO (foo_bitcompare) : location: "file://E:\Test\The Beatles - Twist And Shout_dll.mp3" (0)
INFO (foo_bitcompare) : location: "file://E:\Test\The Beatles - Twist And Shout_exe.mp3" (0)
INFO (foo_bitcompare) : No differences in decoded data found.
INFO (foo_bitcompare) : Finished successfully.

so the audio content is identical.

(this particular sample is available here: http://www.hydrogenaudio.org/forums/index....howtopic=41248)


EDIT

I noticed that you didn't use --vbr-new. Here is the result with the old VBR method:

Quote
INFO (foo_bitcompare) : Comparing:
INFO (foo_bitcompare) : location: "file://E:\Test\The Beatles - Twist And Shout_dll (AG -V2).mp3" (0)
INFO (foo_bitcompare) : location: "file://E:\Test\The Beatles - Twist And Shout_exe (--preset standard).mp3" (0)
INFO (foo_bitcompare) : No differences in decoded data found.
INFO (foo_bitcompare) : Finished successfully.

lame.exe vs lame_enc.dll

Reply #3 –
Right, the audio content is identical, but the binary files are different.
I'd expect the same version of the same program to produce the exact same output...

lame.exe vs lame_enc.dll

Reply #4 –
It is a different program, the encoder version is the same. A different program may write different headers. The audio data seems to be identical.

EDIT

I tried also CDex with your settings. The decoded output was identical:

Quote
INFO (foo_bitcompare) : Comparing:
INFO (foo_bitcompare) : location: "file://E:\Test\The Beatles - Twist And Shout_exe (--preset standard).mp3" (0)
INFO (foo_bitcompare) : location: "file://E:\E:\Test\The Beatles - Twist And Shout_dll (CDex).mp3" (0)
INFO (foo_bitcompare) : No differences in decoded data found.
INFO (foo_bitcompare) : Finished successfully.

lame.exe vs lame_enc.dll

Reply #5 –
I agree with you Alex, don't loose your time trying to prove anything.
You totally missed the point of this topic.

lame.exe vs lame_enc.dll

Reply #6 –
I just wished someone here could have a look at this and say "hey, bit xyz is changed in every frame, lame.exe|lame_enc.dll gets it wrong".
Or give another real explanation.
I KNOW the audio content is identical, one bit changed can't be caused by a different encoding algorithm or anything.

lame.exe vs lame_enc.dll

Reply #7 –
have you tried using lame_enc.dll with some other program and get the same differences?
(to be sure its not just cdex doing it  )
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune
 

lame.exe vs lame_enc.dll

Reply #8 –
gameplaya15143> Yes I did. Audiograbber and CDex give consistent results. But read this...

OK, back to this old thing.

Silly me, I realized I was encoding with the "original" flag set for lame.exe, and unset for lame_enc.dll.
I did check flags before, but didn't expect this information to be stored in EVERY frame (which leads to a LOT more differences than what you'd expect from such a flag). And lame.exe sets it by default, which was not obvious to me.
Never got the meaning of this flag anyway...

With the original flag set on both encodings, the differences are reduced to only two 16 bits words, located in the first frame -- the so-called LAME tag, or mp3 tag.
I've read a little about the LAME tag format (http://gabriel.mp3-tech.org/mp3infotag.html), and theses 2 words happen to be the replay gain and the checksum.
The checksum change obiously is a consequence of the different replay gain info.
The replay gain info is only computed by lame.exe, and zeroed by lame_enc.dll.

So in the end this is the only difference between files generated by lame.exe and lame_enc.dll.
lame.exe defaults to --replaygain-fast, while lame_enc.dll defaults to --noreplaygain.
The replay gain information is not used by all players, but foobar2000 does for one.
So people who rely on replay gain for playback probably shouldn't use lame_enc.dll at all!

lame.exe vs lame_enc.dll

Reply #9 –
Personally, I disable LAME's automatic ReplayGain addition as I never use it and, even if I did, I don't believe that foobar2000 recognises LAME's method of storage. But at least you found your solution!

lame.exe vs lame_enc.dll

Reply #10 –
Yeah, I'll sleep better now.