Audio lossyness between different CPU architectures

[T-3B]

Recently I discovered a strange behavior with SAC.

Steps to reproduce:

• Choose a .wav file to encode, the longer the more likely the problem will occur.
• Encode a file on a specific CPU architecture (let's say x86-64). Any settings are fine (so for simplicity I chose the fastest - e.g. no argument given to sac).
• Decode the encoded file on a *different CPU architecture (let's say aarch64/ARM).
• Check the audio checksums with ffmpeg -v error -i <file.wav> -f streamhash -
• You will see that the decoded .wav does not match the input one (while if you used the same CPU architecture for both encoding and decoding they would match). You can also listen to the decoded file, warning: loud electronic noise.

Tested with aarch64 and x86-64, both with clang 16.0.6 and clang++ -O3 -flto -march=native -s

At least SAC encoding is architecture-dependent (different architectures will give different encoded SAC files - even the size).

On Mega, you can find the original WAV file, as well as the aarch64 and x86-64 SAC encoded files.

[sergeevabc]

@T-3B, which SAC version do you use? Github has 0.5.1, EncodeSu has 0.6.3.

[T-3B]

@sergeevabc I compiled myself the master branch (with a very few extras in my fork).
I also made some releases there with LTO and PGO and different CPU architectures (aarch64 and x86_64).
So it is 0.6.3.

[T-3B]

Oh, I forgot about that one: #2

Apparently not only because of different CPU architecture, but different OS too.

[sergeevabc]

Hmm, where can I get the binary of version 0.6.7 with “a small fix”?

[inschrift-spruch-raum]

At first, I thought this issue was useless. Until I encountered a similar problem myself.

I am maintaining a SAC version of the zig-build-system. I found that no matter how I tested it, my compiled version deviated from the version provided in the releases, and the two versions were incompatible with each other.

I originally thought that I had made some destructive modifications.

However, when I used the original repository code + some necessary modifications,

I was convinced that the issue did indeed exist.

[inschrift-spruch-raum]

I have already uploaded my most simplified modifications and compilation results to substantiate that my claims are not baseless.

https://archive.org/details/sac_20250426

https://archive.org/details/sac-test

@slmdev @sergeevabc @T-3B

[inschrift-spruch-raum]

I seem to have some clues. When I was compiling, it showed that there was a conflict between the macro used by MD5 and the compiled file

[sergeevabc]

https://archive.org/details/sac_20250426

Alas, it does not work on Windows 7 x64.

[inschrift-spruch-raum]

This is caused by the system version. GetSystemTimePreciseAsFileTime() is a call supported only on Windows 8 and above. Since my system is Windows 11, the compiler might have assumed its existence by default.

You can try compiling it yourself with Zig.

[slmdev]

Sac only supports full lossless support with the same binary. Big-endian is not supported.
AVX2 is usually not compatible with the normal compile for example.

If you know compiler switches which improve compatibility between different code paths or uarchs - let me know

[biblicabeebli]

From GCC docs, a quick search for "floating" yields two things:

Even if rounding is well-implemented, changing order could conceivably introduce some difference, and it looks like there is an optimization level difference between x86 and ARM.

-fschedule-insns

    If supported for the target machine, attempt to reorder instructions to eliminate execution stalls due to required data being unavailable. This helps machines that have slow floating point or memory load instructions by allowing other instructions to be issued until the result of the load or floating-point instruction is required.

    Conventionally enabled at optimization levels -O2 and -O3. However, many targets override this behavior. For example, on x86, it is disabled at all levels, while on AArch64, it is enabled only at -O3.

I won't pretend to know what this one affects, but looks relevant:

-ffp-contract=style

    -ffp-contract=off disables floating-point expression contraction. -ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them. -ffp-contract=on enables floating-point expression contraction if allowed by the language standard. This is implemented for C and C++, where it enables contraction within one expression, but not across different statements.

    The default is -ffp-contract=off for C in a standards compliant mode (-std=c11 or similar), -ffp-contract=fast otherwise.

That looks like it for enforcing safety. There's a whole section about breaking safety, but the header is literally The following options control compiler behavior regarding floating-point arithmetic. These options trade off between speed and correctness. All must be specifically enabled.

x86 options exist for forcing manual precision handling (-mpc32 -mpc64 -mpc80), but I think you have to pair it with -m80387 or -mhard-float and/or -mfpmath=387 for that to apply universally. At that point you are specifying which historical x86 floating point extension set to target. (It says SSE is the default. 80387 is the original x87 FPU.) So maybe you can use these to force one ISA choice in the generated instructions and test whether an ISA can be at fault on a single CPU, and also have two x86-to-x86 uarch implementation comparisons to check for differences? eeehn? maybe?