LAME: different compilers producing significantly different bitstreams, Split from “LAME 3.99 is out” Options

[Alex B]

The new 32-bit lame.exe seems to work fine for me on XP Pro SP3 (I have an AMD Phenom II CPU that supports SSE2), but it produces entirely different output than LAME 3.99.3 from the previous "main" bundle. I did not expect that. As far as I can see, the change log does not indicate any further "quality tweaking".

In some cases 3.99.4 seems to produce significantly smaller VBR bitrates than 3.99.3. I tested the settings -V1, -V5 and -V8. When the source tracks were quiet and uncompressed (classical, ambient, etc) the bit rates were 3-12% smaller than before. When the source tracks were loud and compressed (hard rock, metal, etc) the bitrates were about the same as before (or just very slightly smaller).

This post has been edited by Alex B: Jan 28 2012, 16:08

[Pretentiousman]

Is it possible for an executable from one compiler to produce a difference in quality or sound than another executable from different compiler? It seems that a difference in bitrate is possible. I am curious. I am no programmer btw.

This post has been edited by Pretentiousman: Jan 31 2012, 18:00

[JJZolx]

Is it possible for an executable from one compiler to produce a difference in quality or sound than another executable from different compiler? It seems that a difference in bitrate is possible.

Which, IMO, is no less concerning than if they produced differences in sound quality.

The short answer is that I don't believe anyone has claimed to hear any verifiable discernable differences and that is all that matters.

It's not all that matters.

The whole point of a lossy codec using VBR is to produce the lowest possible bitrate at a given SQ level. Perhaps it's naïve, but I would expect all compiles on all platforms to produce the same encoding results.

This post has been edited by JJZolx: Jan 31 2012, 18:19

[lvqcl]

Perhaps it's naïve, but I would expect all compiles on all platforms to produce the same encoding results.

LAME uses floating point calculations, so it is highly unlikely.

[apodtele]

Perhaps it's naïve, but I would expect all compiles on all platforms to produce the same encoding results.

LAME uses floating point calculations, so it is highly unlikely.

Please... Given the same CPU, floating point calculations are quite deterministic.

The whole story smells like LAME is too careless about floating overflows and underflows.

[C.R.Helmrich]

Please... Given the same CPU, floating point calculations are quite deterministic.

I wish... well, yes, maybe the calculations are deterministic, but the order of calculations (which can vary between compilers according to optimization algorithms) can have a significant influence on the result. But of course the observations discussed here are extreme.

Chris

[apodtele]

Order is defined by precedence and compiler rarely dares to go against left-to-right as specified by the C standard.
I still bet on undeflows of the type that 3.99.4 was trying to paper over with max(x, epsilon). This type of bugfixing is dangerous.

This post has been edited by db1989: Feb 7 2012, 14:43

Reason for edit: removing unnecessary full quote of above post

[saratoga]

Perhaps it's naïve, but I would expect all compiles on all platforms to produce the same encoding results.

LAME uses floating point calculations, so it is highly unlikely.

Please... Given the same CPU, floating point calculations are quite deterministic.

Given the same CPU and the same binary, they usually are. But across different platforms or different compilers, they are not.

Order is defined by precedence and compiler rarely dares to go against left-to-right as specified by the C standard.

Its not that simple:

http://msdn.microsoft.com/en-us/library/aa...7(v=vs.71).aspx

c specifies operator precedence, but that does not strictly define order, only how a statement is parsed. Compilers still (often quite aggressively) reorder floating point calculations depending on the optimization level and compiler flags. You can of course disable this, but the performance penalty can be quite large, particularly with vector extensions.

When talking about different instructions sets, pretty much all bets are off. Operations can be done at different precision and in different order.