drewfx1
Goddard
Might as well revive this thread, rather than start a new one.
Alongside Cakewalk's posted video of Ron Kuper's 2006 AES presentation (linked in post #19 above) explaining why double precision floating point math is beneficial (if not critical) when mixing 24-bit PCM audio, Cakewalk also published a whitepaper by Ron Kuper which gave some additional info on the subject:
http://mixonline.com/online_extras/Cakewlk%20Wht%20Paper.pdf
In this whitepaper, respective code examples are given of single and double float mixing of 3x 24-bit samples and the outputted results are compared. This corresponds to what Ron Kuper was describing in the AES presentation video.
Basically, when mixing 24-bit audio, a 32-bit single precision engine lacks sufficient precision, such that errors can arise in the mixed audio even when mixing only a few streams. While such errors might not be easily audible, they do occur nonetheless and can accumulate and propagate downstream (for example, when further DSP operations are performed on the mixed audio) so as to become more audible. On the other hand, use of a 64-bit double precision engine simply avoids such errors occurring (which would explain why the Cakewalk developers chose to implement a double precision engine back when (in Sonar 5)).
What the white paper actually says:
What this simple program shows is if X is a 24-bit PCM sample, and the math is done using 32-bit floating point, an inaccuracy is introduced due to summation. In this case the least significant bit is lost. If the gain adjustments are more dramatic, or more gain stages are used, then more bits can be lost.
This is true, but you're supposed to infer here - as all the people who don't understand the math and want so badly to believe in this stuff usually do - that since there are errors, they, gasp, must be audible. But note that they don't actually say that. You might want to consider how many bits you can lose before it might be even close to being audible.
Nowhere was it ever asserted or left to inference that such LSB-wise errors in 24-bit PCM audio data are audible in themselves.
What the whitepaper also actually says (preceding the portion you quoted above):
An IEEE 64-bit float has 52 bits of mantissa plus a sign bit, giving 53 bits of precision when doing calculations. This amount of precision means audio fidelity is maintained even with dramatic gain staging within processing elements, and also means more accurate processing for recursive DSP such as IIR filtering.
Double precision mixing is especially important when processing 24-bit PCM audio data.
In Cakewalk's AES presentation video, after presenting the test program results, Ron Kuper says (at 3:55):
Now maybe one bit doesn't matter, uh, but folks who've installed Sonar 5 and turned on the engine say it sounds great, you know, and I'm not a golden ears, it's like, subjective, but I believe the math that backs it up, and people are hearing a difference, so I think just on the basis of the math alone this is a pretty significant result, uh, that, if you're going to be processing 24-bits into a DAW, you need to mix using doubles, otherwise you're gonna lose, you're gonna lose a lot of bits on the bottom.
Now, it's fine to dismiss the DPE as being unnecessary on the basis that nobody can hear such low bit errors. But don't flatter yourself, you're hardly the first pushing that position. Search the archived posts from the cakewalk.audio newsgroup from back when and you'll find plenty of company.
But asserting that low bit errors in 24-bit PCM audio are way below what is audible simply neglects to take into consideration what anyone who's worked with DSP well knows, and why fixed integer DSP chips have long had extended-precision registers and accumulators and why floating point DSP chips have continually moved toward greater precision. Namely, that precision does matter because with DSP what goes around can often come around (a whole lot of times).
It's interesting to note that your so-called "null test" had FX disabled, and thus biased the testing against revealing errors which manifest more significantly if not audibly due to recursive DSP (for example, by running a delicate condenser-mic'ed vocal passage or acoustic instrument track through an IIR reverb FX plug-in).
drewfx1
Goddard
Craig Anderton alluded to this situation in an article over on HC earlier this year:
http://www.harmonycentral...chniques/ba-p/34780908
As far as I can see, this is all Craig says about it there:
But your sequencer’s audio engine needs far greater resolution.
.
.
.
Today’s sequencers use 32-bit floating point and higher resolutions, but many earlier sequencers did not.
Um, where does he say 32bit isn't good enough?
Um, how about in the paragraph
which you snipped out?:
Recording resolutions higher than 24 bits are fictional, due to the limitations of A/D technology. But your sequencer’s audio engine needs far greater resolution.
This is because a 24-bit piece of audio might sound fine by itself. But when you apply a change to the signal (level, normalization, EQ, anything), multiplying or dividing that 24-bit data will likely produce a result that can’t be expressed with only 24 bits. Unless there’s enough resolution to handle these calculations, roundoffs occur—and they’re cumulative, which can possibly lead to an unpleasant sort of “fuzziness.” As a result, your audio engine’s resolution should always be considerably higher than that of your recording resolution.
Now, I don't want to infer anything from "unpleasant sort of fuzziness" as to whether that implies audibility, or even guess at what Craig meant by "far greater" or "considerably higher." Although surely, 32-bit single precision float is only equivalent in resolution (significand/mantissa digit-wise) to fixed integer 24-bit, not "far greater" or "considerably higher"?
But again, I certainly don't want to infer anything, so in the interest of precision, perhaps Craig would care to elaborate on precisely what he meant in his HC article?
drewfx1It's very simple. We can go through the math, but for people who aren't interested in going through the math (or doing controlled null tests), the answer is this:
Yes there are errors, but they accumulate quite slowly - to the extent that often relatively few of them even make it into 24bit output, much less at an audible level.
So you say, repeatedly, here and in other posts. While conveniently omitting any consideration of whether such errors may propagate through subsequent DSP operations and gain alteration so as to manifest toward audibility at the bigger end. Not that possible error manifestation due to error propagation via downstream DSP would show up when null testing the mix engine's output as you did with FX disabled anyway.
Now, I must admit that I hadn't paid much attention to your earlier so-called "null test" post before, once I'd noticed that you'd disabled all FX when exporting. But just now looking at your "null test" post again, your testing methodology does raise one question:
What exactly was being nulled?
I'm travelling right now and can't load up that same X2 demo project which you employed for your "null test", but IIRC, that demo project had an already-mixed down track soloed (with some FX (in the Pro Channel?) on it, sort of like the mixdown was being "mastered"?).
Now, if my recollection about that demo project is correct, then I wonder if, besides disabling all FX, did you also bother to disable track and bus mute/solo when exporting? There's absolutely no mention of that in your post above that I can see, so what should one infer from that?
Otherwise, seems only that soloed mixdown track would have been exported, without any gain alteration or mixing (or FX processing) actually being performed in the mix engine during the export, but merely the copying of only the (already rendered) mixdown track to the export destination files followed by nulling of the thusly exported files. If so, that could certainly account for the lack of any significant difference between the exported files when nulled against each other.