Checksums between LAME and Fre:ac encoded MP3

[ShamanZeno92]

When I calculate the SHA256 checksum on files made by LAME 3.100 and those made by Fre:ac 1.1.7 using the same bitrate settings, and having both the tags deleted, the results are not identical. I've tried changing some of the encoding parameters in the GUI to see if adjusting anything there would generate the same results, but it hasn't so far, unless the right combination of settings hasn't yet been figured out. Turning off SuperFast changes the resulting checksum, but it's still not identical to those encoded with LAME 3.100. I'm puzzled as why there's a difference. What might be causing this?

[enzo1982]

That's expected.

LAME uses mostly floating point math and that can produce slightly different results depending on which optimizations are applied. Different compilers make use of different optimizations and can thus create binaries that produce different results.

For example, a calculation like a * k + b * k could be optimized by a compiler to the mathematically equivalent (a + b) * k, but that will in many cases change the resulting value very slightly due to limited precision of intermediate results.

Similarly, it makes a difference which instruction set extensions are used by the compiler. Classic x87 floating point math will usually produce slightly different results from modern SSE math due to different internal precision.

It can also make a difference whether 32 bit or 64 bit binaries are used, as 64 bit mode allows the compiler to make use of newer instructions set extensions by default. For example, the 32 and 64 compiles of LAME 3.100 available from RareWares produce different MP3 files, even though the same compiler (ICL 19) has been used.

The LAME library used by fre:ac (on Windows) is compiled with TDM-GCC 9.2.0 using the -O3 optimization level and makes use of SSE optimizations added by TMKK, the author of X Lossless Decoder, available here.

To have a chance to produce MP3s with the same SHA-256 checksums using fre:ac and command line LAME, you would need a LAME binary built from the same sources using the same compiler with identical optimization options.

[ShamanZeno92]

Thanks for explaining this. That makes perfect sense.