IPB

Welcome Guest ( Log In | Register )

LAME 3.97: different binaries produce differente results!, bizarre: different LAME 3.97 binaries produce differente results!
Adriano
post Oct 4 2006, 02:33
Post #1





Group: Members
Posts: 1
Joined: 4-October 06
Member No.: 35932



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
Go to the top of the page
+Quote Post
 
Start new topic
Replies
kjoonlee
post Oct 4 2006, 14:03
Post #2





Group: Members
Posts: 2526
Joined: 25-July 02
From: South Korea
Member No.: 2782



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.


--------------------
http://blacksun.ivyro.net/vorbis/vorbisfaq.htm
Go to the top of the page
+Quote Post
Gabriel
post Oct 4 2006, 14:50
Post #3


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



QUOTE (kjoonlee @ Oct 4 2006, 15:03) *
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.

QUOTE
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)
Go to the top of the page
+Quote Post
kwanbis
post Oct 4 2006, 19:17
Post #4





Group: Developer (Donating)
Posts: 2362
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (Gabriel @ Oct 4 2006, 13:50) *
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)

The question then, is, with what compiler options are the LAME devs using. I don't think i can hear any diference, but just to be safe. Or shouldn't we worry?


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd August 2014 - 03:55