René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Audio lossyness between different CPU architectures","articleBody":"Recently I discovered a strange behavior with SAC.\r\n\r\n### Steps to reproduce:\r\n- Choose a `.wav` file to encode, the longer the more likely the problem will occur.\r\n- 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`).\r\n- Decode the encoded file on a *different CPU architecture (let's say aarch64/ARM).\r\n- Check the audio checksums with `ffmpeg -v error -i \u003cfile.wav\u003e -f streamhash -`\r\n- 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**.\r\n\r\nTested with aarch64 and x86-64, both with clang 16.0.6 and `clang++ -O3 -flto -march=native -s`\r\n\r\nAt least SAC encoding is architecture-dependent (different architectures will give different encoded SAC files - even the size).\r\n\r\nOn [Mega](https://mega.nz/folder/EjQw3YpC#X6kcyjiIpo0XrNWhe8DgRg), you can find the original WAV file, as well as the aarch64 and x86-64 SAC encoded files.","author":{"url":"https://github.com/T-3B","@type":"Person","name":"T-3B"},"datePublished":"2023-12-10T17:47:45.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":11},"url":"https://github.com/7/sac/issues/7"}