nu774
commented
5 years ago That's normal, due to the nature of floating point math and architecture difference. Try the same with other lossy codecs such as MP3(LAME), Vorbis, Opus or something.
And hey, qaac is merely a front end to the Apple's encoder. Compiler option for qaac does in no way affect the AAC bitstream that is produced by Apple's encoder.
pzkpfw38t
Recently I built qaac from git cloned source with VS2017 Community for my music encoding use. I wanted to make sure I didin't fuck up something. I bit-compared (foobar2000's binary-comparator) the outputs from official binaries and my binaries. There are differences. I tested with Led Zeppelin's "How the West was Won" album 2018 edition. Something go wrong. Out of curiosity, I also bit-compared outputs from official x86 binary and official x86_64 binary. There are differences too. What compiler settings, which build settings in Visual Studio might cause this? (Floating point precision?) If there are specific settings to avoid this, I think we should put these in documentation. (btw differences occur in fdkaac x86 binary and x86_64 binary both built with VS2017 too. but in this case, I think 64 bit binary is just broken. )
Here is output from foobar2000's binary-comparator for "Dazed And Confused": `Differences found in compared tracks. Zero offset detected.
Comparing: "E:\x86\201. Dazed And Confused.m4a" "E:\x64\201. Dazed And Confused.m4a" Compared 67266612 samples. Differences found: 3114378 values, starting at 0:02.343787, peak: 0.011043 (-39.14 dBTP) at 22:09.987143, 2ch Channel difference peaks: 0.010922 (-39.23 dBTP) 0.011043 (-39.14 dBTP) File #1 peaks: 0.974373 (-0.23 dBTP) 1.000951 (+0.01 dBTP) File #2 peaks: 0.974373 (-0.23 dBTP) 1.000951 (+0.01 dBTP) Detected offset as 0 samples.
Total duration processed: 25:25.320 Time elapsed: 0:05.835 261.42x realtime`