No, latest 64-bit version of 3.99.4 (20120125) from Rarewares has higher bitrates on the quieter track, as well, although not quite as much as the 32-bit version

Encodes done on same machine, but under Win7 64-bit, again from the command line, and I've included the bitrates from the previous test:

...

Those differences are entirely within what I would expect as the 64 bit compiles do not use the nasm code, although the VC10 numbers still differ more than I would expect. I'll compile using VC10 later and see what differences I get.

This post has been edited by john33: Jan 31 2012, 09:37

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

This track is neither particularly quiet, nor loud, but what is interesting is that the very quiet parts seem to attract a higher bit allocation with the Intel compile than with the VC10 compile. So, I'm guessing that with particularly quiet tracks, this accounts for the larger difference between the different compiles.

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

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.

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.

A question that has been asked many times. The short answer is that I don't believe anyone has claimed to hear any verifiable discernable differences and that is all that matters.

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

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.

QUOTE (john33 @ Jan 31 2012, 10:12)

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.

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.

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.

Here's some more data at different VBR quality levels with the fixed RareWares 32-bit compile of 3.99.4. Perhaps it's a little more real world than the 30 second Liszt piano solo (which is included), as all of these tracks are at least several minutes long. These bitrates are more consistent, although lvqcl's compile consistently comes out ahead. The Thelonious Monk track is also a piano solo piece. Interestingly, it shows probably the biggest difference between the two compiles after the Liszt sample.

(My apologies if this is too much data for the forums. It doesn't appear that I can attach a simple text log.) db1989: You can paste the log into a codebox (rather than between code tags) or upload it to our dedicated Uploads subforum. Editing according to the latter:

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.

In my environment, i686-w64-mingw32-gcc and cygwin gcc prints "53 52 53" (On the other hand, CL compiler of MSVC10 prints "53 53 53").The difference between ny and nyy is only whether calculated value (x / 100.0 * 100.0) is once stored to a double variable y or not.x86 architecture has fp register wider than double precision(64bit). Therefore, just a store/load can make such difference (introduced by rounding error).

Or, just use lrint() However, even if you use "proper rounding", it still remains the same that a simple load/store can change the value of floating point, at least on some architecture.My point was, how operations (such as load/store) are used/ordered is beyond control of a programmer who programs in high level language such as C, and also varies with compilers or optimization settings or something.

Very well-said. (not that we can require anyone to do an investigation - all of us LAME users are in debt to the devs as with anything open-source)But marked differences in bitrate are weirdly striking.

What I wonder: if you ran the differing-bitrate files through mp3packer, would they come out with the same bitrate? i.e., are there wasted bits that can be compressed out? Worth checking at least, unless someone with knowledge of the innards of LAME can say that this wouldn't be the case.I can run the respective files through mp3packer if anyone wants to send me the files.