There was 1 unique stdout blob collected all successful configurations agreed on this stdout blob: pass
So, it worked. Yeah, I’m surprised too. That result means that all the configurations (20 total) produce an audio waveform in which no individual PCM sample deviates from the reference wave by more than 1. Since I had to choose some configuration to generate the reference sample, I used Linux / x86_32 / gcc 2.95.3.
BTW, this is the general Python algorithm I am using to compare the waves. It takes a full minute, give or take a second, to compare 2 33MB samples:
I replaced abs() with a branch to check if the diff is < -1 or > 1, but that didn’t improve speed measurably. I think the constant unpacking might have something to do with it. Better solutions welcome. (By comparison, performing a comparison using ‘cmp’ of 2 identical files that have the same size as the test above, living on a network share, takes less than 2 seconds.)
For a 10-second sample of a .m4a stereo AAC file (882,000 samples), these are the number of PCM samples that deviated by 1 (first number), and by more than 1 (second number). You will notice that no samples deviated by more than 1, which was my hypothesis at the start, and the basis on which I devised this plan:
Mac OS X / PPC / gcc 4.0.1 432691, 0 Linux / x86_32 / icc 238, 0 Linux / x86_32 / gcc 2.95.3 0, 0 Linux / PPC / gcc 4.0.4 Linux / PPC / gcc 4.1.2 Linux / PPC / gcc 4.2.4 Linux / PPC / gcc 4.3.2 Linux / PPC / gcc svn 432701, 0 Linux / x86_64 / gcc 4.0.4 Linux / x86_64 / gcc 4.1.2 Linux / x86_64 / gcc 4.2.4 Linux / x86_64 / gcc 4.3.2 Linux / x86_64 / gcc svn 248, 0 Linux / x86_32 / gcc 3.4.6 Linux / x86_32 / gcc 4.0.4 Linux / x86_32 / gcc 4.1.2 Linux / x86_32 / gcc 4.2.4 Linux / x86_32 / gcc 4.3.2 Linux / x86_32 / gcc svn 237, 0 Mac OS X / x86_64 / gcc 4.0.1 244, 0
I have thrown RealAudio Cooker and 28.8 samples at this, and both work. I am still testing this against some more audio samples to ensure that this idea holds water.