drewfx1
Goddard
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.
Yes. It's indeed useful for recursive IIR filtering, but the mix engine doesn't do this sort of thing.
But FX plug-ins (such as convolution and recursive FX) get their input from the mix engine and provide their output to the mix engine.
Moreover, when the dpe is enabled, any plug-ins which also implement 64-bit dp processing internally will receive and output 64-bit fp streams, e.g.:
Written with sound quality and ease of use a priority, all of our plugins are 64-bit internal processing. If your host is VST 2.4 capable, we’ll accept and pass on 64-bit double-precision audio streams. If you have a host that is only 32-bit capable, we’ll still give you as much precision as possible.
http://www.stillwellaudio.com/plugins/stillwell-audio-plugins/ drewfx1
Goddard
Double precision mixing is especially important when processing 24-bit PCM audio data.
For mixing? No, not at all.
Well, fortunately for you the dpe can be disabled in Sonar if so desired. Otoh, some other DAWs such as Reaper only mix in 64-bit dp with no option available to use single precision.
drewfx1
Goddard
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.
"It's like, subjective" 
This is classic. He's deliberately avoiding saying whether he can hear it or not - "I'm not a golden ears!". Then he says "you're gonna lose a lot of bits". Gee, I wonder why he, or anyone from CW won't ever just say it's audible? Why must they always dance around it? Hmmm.
Well, Ron K's no longer with CW, but here's what he'd originally said here in the forum way back when:
http://forum.cakewalk.com/RonK-64-bit-Plugins-and-Summing-m594294-p3.aspx#599327 Although I'd hoped someone from CW would chime in on this thread (and possibly provide a link to the "clearly audible" test to which Ron K referred above), they're no doubt beavering away on X3d. But, anyway, it wasn't only CW who were finding that single precision processing of 24-bit PCM lost bits on the low end:
http://forum.cockos.com/showpost.php?p=116056&postcount=35 No dancing there, I'd say. Nor here either:
http://www.gearslutz.com/board/q-justin-frankel-designer-reaper/118481-reaper-64-bit-engine.html drewfx1
Goddard
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.
I don't flatter myself. Valuing logic and evidence over belief in one's own "golden ears" precludes that.
You're a bit late to the party:
http://forum.cakewalk.com/RonK-64-bit-Plugins-and-Summing-m594294.aspx drewfx1
Goddard
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).
Once again, there are indeed areas where recursive processing (involving thousands of operations) makes higher precision processing necessary. The mix engine just isn't one of them, because there is no recursive processing and not enough operations otherwise.
You never use any FX plug-ins when mixing/mastering?
drewfx1
Goddard
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).
"So called"? Um, it was a null test. Period. My advice? If you want to have a technical discussion, lose this sort of nonsense. It's not gonna help you.
Tell you what. Don't insinuate that I've improperly paraphrased something, or snip out text when quoting something I've cited and then ask where it says what I've stated it alludes to, and we won't have any more nonsense in this thread.
Yes, you called it a null test, but I'm not so sure it really was a
mixing test.
Note that even when mixing with a 64-bit dpe, there will still be rounding errors in the lowest bit(s) which will be evident, e.g.
http://forum.cockos.com/showpost.php?p=626771&postcount=8 Instead of going by RMS metering of the difference in Sound Forge (RMS metering is not really precise and SF's metering used to be rather buggy), try putting it through Sonar's included Bitmeter plug-in or Schwa's free Bitter bitscope plug-in (available from above-linked Stillwell site).
drewfx1
Anyway....
THE MIX ENGINE HAS NO EFFECT ON WHAT BIT DEPTH PLUGINS ARE PROCESSING INTERNALLY WITH. The only potential difference is whether plugins get the higher bit depth at their input/output, not what they process with internally. Sonar has no control over what/how a plugin processes things internally and plugins already generally process at whatever bit depth is necessary (possibly down to the individual operation level).
No, Sonar's mix (audio) engine, when in dpe mode, passes/accepts 64-bit fp sample streams to/from any plug-ins which accept/output such (or otherwise, converts to/from 32-bit fp, this conversion presumably being done in the abstraction layer).
drewfx1
As stated, disabling FX is necessary because the FX contained considerable random processing as shown when I exported twice using the 64bit engine and they didn't remotely null. Now I indeed could have gone through and disabled each plugin individually to discover which ones contained random processing and only disabled those containing random processing, but it's not like the results were even close...
Yes, some FX (and softsynth) plug-ins can throw off a mix engine null test and render its results unreliable/invalid, e.g.
http://www.gearslutz.com/board/music-computers/88771-64-bit-mix-engine-hype-aka-sonar-6-a.html (as said, this party started long ago)
My point was that it's disingenuous to acknowledge that higher precision is necessary when performing recursive DSP but then exclude any recursive DSP FX plug-ins from your testing and assert that higher precision doesn't matter for mixing.
drewfx1
You are of course welcome to do a "proper" (in your eyes) null test and post the results yourself. 
It's already been done:
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#610928 It didn't null completely.
drewfx1
Goddard
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"?
It depends. The lower the exponent is set, the higher the comparable resolution of floating point. It's only "equivalent" for samples that are near full scale. And if we consider that adding one bit doubles the resolution...
No it doesn't depend. 32-bit floating point and 24-bit fixed/integer are equivalent in resolution/precision:
http://www.bores.com/cour...tro/chips/6_precis.htm drewfx1
Goddard
drewfx1
It'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.
I think you will find that, as I conveniently did in the part you quoted here, I always say something like "the errors accumulate quite slowly". Or does "propagate" mean something different than "accumulate" to you here?
In DSP, rounding error may also accumulate/propagate quite rapidly (exponentially even):
http://www.dspguide.com/ch4/4.htm drewfx1
Goddard
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.
What should someone infer? I was hoping someone might infer at least a basic level of competence on my part.
The results should not null to infinity. There should be a discernable difference in the low bits at least. Not saying it would necessarily be audible (at least, not without considerable gain boosting) but it should show up in a bitscope/bitmeter.
drewfx1
I suggest you do your own null test (making sure you have absolutely no random processing going on so that the only difference is indeed the engine) and post your results.
As noted above, it's already been done, back when. Didn't null completely. Was the difference audible? Hardly. But that's not really the point.
Now, just to be clear, I've never asserted that rounding errors when mixing (summing) in Sonar with single precision are necessarily audible, nor that Sonar's double precision engine sounds better than or even different from its single precision engine. If anything, I've always played the skeptic around here (and in this forum's earlier incarnations and the ng) as you may have noticed, never the "placebophile", and I've even been known on occasion to call into question what I've perceived as mere marketing hype.
But if I'm going to be mixing or mastering using any plug-ins which can handle 64-bit streams, particularly any convolution or recursive DSP FX (like say, EQ or reverb), well then, I'd prefer to mix with the dpe enabled.
Btw, while that CW whitepaper also discussed performance aspects when the dpe was used, I'd intentionally refrained from pointing to that in my earlier post as I wasn't sure whether those aspects still remained valid for more current systems, and in any case, the results reported in that whitepaper were based on CW's own internal benchmarking and test projects and I tend to view such results with skepticism unless they can be independently verified (my hidden agenda
).