LAME 3.97: different binaries produce differente results!, bizarre: different LAME 3.97 binaries produce differente results! Options

[Adriano]

Hi.

I was VERY surprised to find out that different binaries for LAME 3.97, namely Rarewaves [1] and Mitiok [2], produce differente results, i.e, different mp3 files.

[1] http://www.rarewares.org/dancer/dancer.php?f=109
[2] http://mitiok.maresweb.org/dancer/dancer.php?f=3

Maybe that has something to do with "Recompiled to include mp2 decoding which was omitted, in error, in the original compile", which relates to Rarewaves link? Well, anyway it's not how it was supposed to be. I am currently using Mitiok binary, which is smaller and seems to be slightly faster.

Any clarification is very welcome.

Regards,
Adriano


Only to exemplify...

Mitiok:

CODE

LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav
to Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav.mp3
Encoding as 44.1 kHz VBR(q=2) single-ch MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
2846/2846 (100%)| 0:03/ 0:03| 0:04/ 0:04| 18.884x| 0:00
32 [ 6] *
40 [ 0]
48 [ 0]
56 [ 11] *
64 [ 63] ****
80 [ 697] **************************************
96 [1264] ********************************************************************
112 [ 551] ******************************
128 [ 162] *********
160 [ 90] *****
192 [ 2] *
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps mono % long switch short %
98.1 100.0 91.4 3.3 5.3
Writing LAME Tag...done
ReplayGain: -3.4dB

vs. Rarewaves:

CODE

LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav
to Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav.mp3
Encoding as 44.1 kHz VBR(q=2) single-ch MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
2846/2846 (100%)| 0:03/ 0:03| 0:03/ 0:03| 18.656x| 0:00
32 [ 6] *
40 [ 0]
48 [ 0]
56 [ 10] *
64 [ 60] ****
80 [ 696] **************************************
96 [1272] ********************************************************************
112 [ 549] ******************************
128 [ 163] *********
160 [ 87] *****
192 [ 3] *
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps mono % long switch short %
98.1 100.0 91.4 3.3 5.3
Writing LAME Tag...done
ReplayGain: -3.4dB

This post has been edited by db1989: Sep 8 2011, 15:39

Reason for edit: adding codeboxes

[kjoonlee]

Because it happens all the time with floating-point calculations and nobody is complaining, usually?

Look at the real results. 3703 vs. 3691 192kbps frames.

[Gabriel]

Look at the real results. 3703 vs. 3691 192kbps frames.

Remember that because fo the bit reservoir, using a 192kbps frame does not mean that you are using the full space of such a frame. It's a matter of combination between the current bit allocation and previous bit allocations.
You can try comparing decoded samples from both versions, it's quite likely that there will not be that many different samples.

Why should be normal?

It's because of different floating point calculations reordering dony by compilers, which are producing slightly different results. Floating point only has a limited precision, and there is often some approximations in the result compared to the theorical formal result.
You could also try disabling some vectorial computations , it's likely that the result will also differ (--noasm mmx/3dnow/sse)