drewfx1

Goddard
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

 
The point isn't that there aren't errors; it's that they aren't remotely audible.

 
Even if the rounding error (or quantization noise, if you will) might not be so significant as to be immediately audible when initially generated, it can still affect, and be affected by, any downstream processing to which the summed sample stream is subjected where further rounding occurs (such as another summation operation) or having noise gain (such as FX plug-ins through which the stream passes), so as to manifest more significantly towards audibility in the finally outputted 24-bit PCM stream.
 

drewfx1

Goddard
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).

RMS metering is as precise as any other metering if you understand exactly what it is telling you in a given application, which does indeed vary. But regardless, using different metering won't change the conclusion.

 
RMS measurement won't reveal peaks. And as already said, Sound Forge's RMS measurement (at least in SF 8.0 as was used for the differencing results reported in that old thread) was known to be rather buggy and unreliable:
 

Notable fixes/changes in version 9.0a
...
A bug has been fixed that caused the Statistics tool to report inaccurate RMS levels has been fixed.

http://dspcdn.sonycreativesoftware.com/releasenotes/soundforge90e_readme_enu.htm
 
Btw, in that same thread, the OP had reported a further test here:
 
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611251
 
 
and also, Ron K had previewed the AES presentation he was then about to give:
 
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611393
 

drewfx1

Goddard

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).

 
Go back and reread where I said where you quoted me a few lines above "The only potential difference is whether plugins get the higher bit depth at their input/output" and explain how that's different from what you just said. 

 
Ok, but while Sonar may not have any control over what/how (i.e., with what precision) a plug-in may process things internally, it does control what the plug-in processes, namely, whether the plug-in receives/returns a single precision fp stream or a double precision fp stream from/to the audio engine. That is, whether or not Sonar's DPE is enabled can influence the precision of the sample stream supplied by Sonar's audio engine as the input (i.e., "operand") to the plug-in for processing and also the precision at which the processed output stream is returned to Sonar's audio engine by the plug-in.
 

drewfx1

Goddard
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.

 
It's not disingenuous because Sonar doesn't determine what the recursive DSP FX is processing with internally. You are welcome to show some proof that this is incorrect if you disagree.
 
Mixing is essentially just summing and level changes with no recursion.

 
But whether or not the DPE is enabled in Sonar can determine what the recursive DSP FX processes.
 

drewfx1

Goddard

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.

 
And the key info from that test:

the RMS difference is -148db

 
Which means that most of those errors won't make it into 24bit output.
 
Which confirms my results.

 
As already noted, those reported RMS readings were rather liable to be unreliable. And in any case, both Ron K and Justin Frankel confirmed that single precision fp summing rounding errors do make it into the 24-bit PCM output.
 

drewfx1

Goddard

drewfx1
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

 
From your link (sic):

Because the hardware automatically scales and normalises every number, the errors due to truncation and rounding depend on the size of the number. If we regard these errors as a source of quantisation noise, then the noise floor is modulated by the size of the signal. 

 
Which once again confirms exactly what I said in the quote of mine that you are replying to here. When the MSB's in 24bit are zero (i.e. a lower signal level for a given sample), 32bit indeed has higher precision. 

 
That's "scaling" (in the exponent), not precision (in the significand/mantissa).  And in any case, sampled values constantly vary (unlike e.g. filter coefficient values). Consider what occurs precision-wise in the significand when the sample value becomes so small/large that the exponent has to change.
 
Anyway, such a discussion is only academic. The point of real practical interest here is that processing 24-bit PCM audio with single precision floats can lead to errors in the processed (summed) 24-bit PCM audio output of the audio engine which do not manifest when double precision is employed.
 

drewfx1

Goddard

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

 
How many times have I made the point that mixing doesn't cause this type of accumulation? You are of course welcome to prove otherwise. I've already shown the proof (which you keep questioning), but was confirmed by the null test you yourself linked to above.

 
Perhaps you missed this by Ron K in that same thread?:
 

That's 1 bit per multiply/summing stage. In other words, the more tracks and buses you have, the more these bit errors can accumulate and start to be come 2 bit errors, 4 bit errors, etc.

http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#614682
 

drewfx1

Goddard

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. 

 
I think you didn't understand. The RMS indeed nulls to infinity, but only when truncated to 24bit - because the result was less than the LSB of 24bit fixed point. It's exactly the same as an undithered recorded signal being cut off below the LSB. As I posted, it did not null to infinity before it was reduced to 24bit.

 
You are focusing on an unreliable RMS measurement. The poster there also reported that the normalized differences were audible.
 
Rounding error (bit loss) which occurs in (the significand of) the 32-bit fp number will still be present when that 32-bit fp number is converted to 24-bit integer/fixed. This was clearly shown in the reported 24-bit PCM output results of CW's testing for a simple gain alteration and summing operation, and also confirmed by Justin F's comparision test post. Converting to 24-bit won't make any difference, null-depth-wise, in the difference.
 
Maybe try using Diffmaker:
 
http://libinst.com/Audio%20DiffMaker.htm
 
Or maybe try chained instances of Sonar's Bitmeter plug-in, with the first instance set to "24" and the second set to "float". See:
 
http://forum.cakewalk.com/What-is-Bit-Meter-for-m956916.aspx#956957
 

drewfx1

Goddard

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.

 
Um, that's been exactly my point all along - as I've repeatedly said, there are indeed errors some of which will make it into 24bit output. But they aren't audible.

 
And my point is that noise/distortion due to rounding error which manifests when mixing 24-bit audio using single precision even if not initially audible may become audible (or cause undesirable effects) when further downstream mixing or DSP is performed on the rounding error-bearing data.
 
How many low bits of a 24-bit PCM sample need to be lost (incorrect) before it's audible? How much gain is required before a low bit rounding error becomes audible?
 
I've already pointed to Ron K's "1 bit per multiply/summing stage" remark above.
 
 
Wrt certain types of digital filters (as might be employed in various DSP FX plug-ins such as EQ and multiband compressors), see e.g. "noise gain" here:
 
http://electronotes.netfirms.com/EN209.pdf
 
Some DSP FX such as dynamic processors or FX with sidechain inputs may normalize or otherwise raise the level of an input in order to derive an internal reference level. See e.g. (towards the bottom, at "Anyway what is the bottom line (finally)?"):
 
http://www.gearslutz.com/board/6016102-post259.html
 
 
I could go on, but I think we've both pointed out our respective points.
 

drewfx1

Goddard
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.
 

 
Then we essentially agree. I have nothing against the use of 64bit double precision; I am just pointing out that there is no audible benefit in the real world. So people can stop worrying about it and instead worry about more important things.

 
Perhaps we inhabit different "real worlds" then, dunno. You seemed to temper your position in the course of an earlier thread on this topic:
 
http://forum.cakewalk.com/More-questions-about-64bit-recording-m2444701.aspx
 
Always good to keep an open mind...
 

drewfx1

Goddard
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).

An interesting question, but I suspect we would find that the mix engine is doing a relatively trivial number of calculations from a modern CPU's standpoint.

My takeaway then was that there was no performance impact due to the DPE, even on a 32-bit system, so good to go. If anything, it would appear from the marketing blobs that since then both CPU capability and Sonar's code for performing the kind of SIMD operation stuff involved in summing and other fp processing of audio has only improved, e.g.:
 
http://software.intel.com/en-us/articles/utilizing-intel-avx-with-cakewalk-sonar-x1
 
http://software.intel.com/sites/billboard/article/cakewalk-intel-and-windows-8-bring-high-performance-touch-enabled-mobile-workflows-musicians
 
although of course independent verification remains pending...

I'm not sure. This might be great groundwork for the 65 bit precision engine.

A ha so it affects the "low" end according to Ben,intriguing,as I should be able to hear a difference!
Bob

Goddard 
RMS measurement won't reveal peaks. And as already said, Sound Forge's RMS measurement (at least in SF 8.0 as was used for the differencing results reported in that old thread) was known to be rather buggy and unreliable:
 

Notable fixes/changes in version 9.0a
...
A bug has been fixed that caused the Statistics tool to report inaccurate RMS levels has been fixed.

http://dspcdn.sonycreativesoftware.com/releasenotes/soundforge90e_readme_enu.htm

Perhaps you missed that I posted the peak errors as well (SF lists them as Minimum and Maximum - there are two, because both the positive and negative peaks are posted):
 
32bit vs. 64bit (no FX):
Left Channel Right Channel
Minimum sample value (dB) -138.739 -136.175
Maximum sample value (dB) -138.943 -138.192
RMS level (dB) -164.395 -164.148
 
I used SF 9.0c, so the RMS values had been fixed.
 
 

Btw, in that same thread, the OP had reported a further test here:
 
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611251
 
 

Yes, and his result was a 1dB lower error level.
 

and also, Ron K had previewed the AES presentation he was then about to give:
 
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611393
 

 

The verdict is that using 32-bit floats to mix 24-bit data introduces at most 6dB of error more than 25% of the time.

 
Are you asserting that "at most 6dB" is a problem?
 

Ok, but while Sonar may not have any control over what/how (i.e., with what precision) a plug-in may process things internally, it does control what the plug-in processes, namely, whether the plug-in receives/returns a single precision fp stream or a double precision fp stream from/to the audio engine. That is, whether or not Sonar's DPE is enabled can influence the precision of the sample stream supplied by Sonar's audio engine as the input (i.e., "operand") to the plug-in for processing and also the precision at which the processed output stream is returned to Sonar's audio engine by the plug-in.

 
This is a bad argument, as it only applies in borderline cases that don't exist in the real world. If the errors from using Sonar's single precision mix engine are far from audible (as they are), you need to do huge amounts of additional processing using 32bit single precision to get audible errors. But the audible errors are then not really from the mix engine, but from the additional processing. It's an argument that the additional processing should be done with more precision.
 
Do you understand how to calculate the effect of adding, say, a -140dB RMS error to a -120dB RMS error? If not, we can go through it, but the increase in error level of adding something 20dB lower is much less than many people might think. Basically, if you have two similar sources of error, you can completely ignore the lower level one if it's far enough below the higher level one.
 

But whether or not the DPE is enabled in Sonar can determine what the recursive DSP FX processes.

 
What makes you think that that matters? The DSP adds additional errors to what it gets or it doesn't.
 

As already noted, those reported RMS readings were rather liable to be unreliable. And in any case, both Ron K and Justin Frankel confirmed that single precision fp summing rounding errors do make it into the 24-bit PCM output.

 
I've repeatedly said that some errors will indeed make it into the 24bit output. The point is that they aren't remotely audible. 
 

drewfx1

Goddard

drewfx1
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

 
From your link (sic):

Because the hardware automatically scales and normalises every number, the errors due to truncation and rounding depend on the size of the number. If we regard these errors as a source of quantisation noise, then the noise floor is modulated by the size of the signal. 

 
Which once again confirms exactly what I said in the quote of mine that you are replying to here. When the MSB's in 24bit are zero (i.e. a lower signal level for a given sample), 32bit indeed has higher precision. 

 
That's "scaling" (in the exponent), not precision (in the significand/mantissa).  And in any case, sampled values constantly vary (unlike e.g. filter coefficient values). Consider what occurs precision-wise in the significand when the sample value becomes so small/large that the exponent has to change.

 
No it's the same. An intrinsic property of floating point numbers is that the numbers have less/more precision compared to fixed point depending on the exponent.
 
For instance, in 24 bit fixed point if the 3 MSB's at the top are all zero (i.e. a lower signal level), you only have 21 bits of precision left for your actual data; in floating point the MSB is an implied value of 1 (except for subnormals), so you are always using every bit of precision (for all non-subnormal values) and the exponent scales it up or down. To put it another way, with fixed point the level of quantization error relative to the signal increases for lower level signals whereas with floating point it stays the same.
 

Anyway, such a discussion is only academic. The point of real practical interest here is that processing 24-bit PCM audio with single precision floats can lead to errors in the processed (summed) 24-bit PCM audio output of the audio engine which do not manifest when double precision is employed.

 
I would say that the "practical" point is not whether the errors exist, but whether they are audible. If the errors are present, but never audible I would call that academic. 
 

drewfx1
How many times have I made the point that mixing doesn't cause this type of accumulation? You are of course welcome to prove otherwise. I've already shown the proof (which you keep questioning), but was confirmed by the null test you yourself linked to above.

 
Perhaps you missed this by Ron K in that same thread?:
 

That's 1 bit per multiply/summing stage. In other words, the more tracks and buses you have, the more these bit errors can accumulate and start to be come 2 bit errors, 4 bit errors, etc.

http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#614682

 
This is indeed true. But don't confuse peak errors with RMS, which much more closely represents what we hear. If you test, you will find that the RMS error increases far more slowly than the peak error levels.
 
And you also need to consider that the true peak is dependent on the sample level not dBFS - so you only get the maximum peak if you happen to be unlucky enough to have a maximum calculation error occur on a sample near that is near full scale. This is unbelievably rare in the real world, and becomes increasingly rare as you do more calculations. 
 
And as noted earlier, I got a peak error of -136.175 dBFS in my tests (which became -138.474 dBFS when truncated to 24bits). But the dBFS peak value will vary much more from test to test than the RMS value for the reason I stated above - the errors are relative to the sample itself, not dBFS, so the peak dBFS error in any given test will depend on levels of the samples where you happened to get a peak calculation error.
 

 

drewfx1
I think you didn't understand. The RMS indeed nulls to infinity, but only when truncated to 24bit - because the result was less than the LSB of 24bit fixed point. It's exactly the same as an undithered recorded signal being cut off below the LSB. As I posted, it did not null to infinity before it was reduced to 24bit.

 
You are focusing on an unreliable RMS measurement.

 
As stated above, my RMS measurements were from a version of SF that had corrected that error.
 
And I find it very telling that you just assume that my numbers must be wrong.
 

The poster there also reported that the normalized differences were audible.
 
Rounding error (bit loss) which occurs in (the significand of) the 32-bit fp number will still be present when that 32-bit fp number is converted to 24-bit integer/fixed. This was clearly shown in the reported 24-bit PCM output results of CW's testing for a simple gain alteration and summing operation, and also confirmed by Justin F's comparision test post. Converting to 24-bit won't make any difference, null-depth-wise, in the difference.

 
SF reports the numbers in the bit depth of the project. You can't represent a number below -144.494 dBFS in 24bit, so SF reports -infinity. The point is that the RMS error level is below the level of 24bit's LSB.
 
Note that I got an RMS error of -164.148 dBFS RMS before truncation. Since this indicates that an overwhelming number of errors are below -144.494 dBFS and will thus get truncated, you will get an even lower RMS error level after truncation if we bother to calculate it and express it at a higher bit depth.
 

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.
 

drewfx1  
Um, that's been exactly my point all along - as I've repeatedly said, there are indeed errors some of which will make it into 24bit output. But they aren't audible.

 
And my point is that noise/distortion due to rounding error which manifests when mixing 24-bit audio using single precision even if not initially audible may become audible (or cause undesirable effects) when further downstream mixing or DSP is performed on the rounding error-bearing data.

 
As noted above, it will be downstream errors that are audible, not the ones from the mix engine.
 

How many low bits of a 24-bit PCM sample need to be lost (incorrect) before it's audible? How much gain is required before a low bit rounding error becomes audible?

 
Ignoring masking, if your playback level puts the errors at a level that is below your absolute threshold of hearing, they are obviously inaudible.
 
When we consider masking from background noise in the listening environment, analog circuit noise, dither, quantization noise, noise in the signal and the signal itself, they are much further from being audible.
 
If you do a null test and listen to the difference signal, you will find that you have to add many tens of dB's of gain to hear anything, even without your signal there to mask it. 
 
I strongly suggest you do such a test to see for yourself.
 

 
Wrt certain types of digital filters (as might be employed in various DSP FX plug-ins such as EQ and multiband compressors), see e.g. "noise gain" here:
 
http://electronotes.netfirms.com/EN209.pdf
 
Some DSP FX such as dynamic processors or FX with sidechain inputs may normalize or otherwise raise the level of an input in order to derive an internal reference level. See e.g. (towards the bottom, at "Anyway what is the bottom line (finally)?"):
 
http://www.gearslutz.com/board/6016102-post259.html

 
I afraid I don't have time to read every link you post. I suggest that in the future you quote the relevant parts in addition to providing the links for people not inclined to follow every link.
 
Regardless, I fully understand and have repeatedly stated that higher precision is desirable/necessary for certain forms of processing involving thousands of calculations (or more), but this doesn't apply to the mix engine. 
 
Changing the reference level in floating point doesn't make the errors any more of a problem (perhaps it adds a few additional calculations, but they have essentially no effect on the error level).
 

 
Perhaps we inhabit different "real worlds" then, dunno. You seemed to temper your position in the course of an earlier thread on this topic:
 
http://forum.cakewalk.com/More-questions-about-64bit-recording-m2444701.aspx
 

 
I'm not sure what you mean here. My positions have not changed since those posts.
 

Man... I cannot wait for the 128-bit machines to hit the streets so I can finally be rid of these grotesque computational errors... ewww.

Here's an analogy I've used sometimes as to errors that happen at extremely low levels.
 
If a bus is going down the street right outside your window while you're recording a vocal, it will introduce unwanted sounds. If a bus is going down the street two blocks over, it may or may not introduce unwanted sounds because it will be much lower in level. If a bus goes down the street 500 miles away, it really won't make any difference to your vocals although the bus does exist and does make noise.
 
Speaking of really low-level signals, I find dithering very interesting because it seems to be right on the borderline of the perceptible. I've done several classical music projects involving solo acoustic instruments; some people could reliably identify dithered and non-dithered material, while others couldn't tell the difference.

lawp
so the dpe is/was just marketing hype?

As I've said before...when the 64-bit engine was introduced, the world of audio engines was quite different and it was a major step forward.
 
As an analogy, at one point stereo was a huge deal and there was a major marketing push about how much better it was than mono, which it was. However these days, you won't see a lot of marketing based around stereo reproduction because the world has caught up to it.
 
Please note this is my personal opinion and does not speak for Cakewalk.

The issue with console emulator buzz when the 64 bit engine was on has been fixed. It was actually caused due to a stereo mono mismatch with the plugin and SONAR.
This issue ironically was caused by a workaround in X3C for the line 6 PodFarm bug (problem when switching it to mono and then stereo). That workaround has now been removed from X3D and I have notified Line6 again. A fix for that issue will have to come from them now.

Unless someone can demonstrate that it's ever even borderline audible through some objective testing, I would say that there was some marketing going on.
 
But I think most of the hype part actually comes not from marketing, but from the odd (to me) psychology of people who want so very, very badly to believe they can hear something - despite any and all evidence to the contrary - just so they can click on a button and make it go away.
 
 
Personally, I would prefer if CW would just say something like, "turning on 64bit double precision essentially ensures that any mathematical errors that normally occur as a result of processing in the mix engine will never make it to your output audio" and leave it at that.

Well have X3C now, next week we will have X3D.
That is one letter more, and "D" sounds better than "C".
Which is the main reason why I will be installing this patch (finally I will be able to put my cucumber back into my pants).

Anderton

drewfx1
Unless someone can demonstrate that it's ever even borderline audible through some objective testing, I would say that there was some marketing going on.

It depends upon what you compare it to. When compared to a 16-bit fixed audio engine, you don't have to do too much DSP to hear an obvious, audible difference. With a 24-bit fixed engine, you have to work a lot harder to create a project where you can hear a difference. It is possible, but the project wouldn't have much relationship to real-world projects...unless your music consists of solo acoustic instruments recorded in isolation with noiseless mics, then bounced multiple times through precision reverbs and played back at really loud levels

 
Well, here we were comparing calculations done using 32 bit single precision floating point to 64 bit double precision floating point.
 
In terms of marketing, I too remember the days when we avoided at all costs any processing that wasn't absolutely necessary out of fear of audible damage from calculations being done at lower bit depths. And I agree that when CW introduced the 64 bit engine, we were not far removed from those days.
 
Personally, as I've expressed in various ways, I find some of CW's historical wording regarding the 64bit engine, shall we say, "unfortunate". But as a long time enthusiastic user of CW products, I put this in context of a company I otherwise have great respect for. 
 
I put equal (or more) blame on individuals' inclination to ignore basic questions of context: "There are errors? OK, how loud are they under typical conditions?" 
 
And no one ever seems to ask under what conditions a given problem is minimized or exacerbated. 
 
For some reason when it comes to audio, people want to believe that any artifact must be audible under all conditions if they just listen for it, but the real world just doesn't work that way. And intelligent people who profess themselves to be "skeptics" will sometimes readily accept all claims from one side without any even trivial doubt, but will demand endless proof that the other side has dotted every "i" and crossed every "t" without ever providing any contrary evidence of their own.
 
 
I agree that one could create a laboratory project with the express intent of making 32bit errors audible, but for real world usage I've never seen a shred of objective evidence that it's even close to making a difference. 
 
Mathematically, the size of the errors relative to the signal is dependent on the bit depth the calculations are done with, the number of calculations performed, and how they accumulate based on the nature of the calculations being done. With 32 bit floating point you are starting at a point far from ever being audible, and in mixing I will assert that the errors are typically distributed fairly randomly. Therefore you need to do lots and lots of calculations before the errors could accumulate enough to be worth worrying about. 
 
The math part is not really open to debate. But I would be quite interested in someone presenting objective evidence suggesting that the number of calculations under the 32bit mix engine is sufficient to make the errors audible, or that when mixing real world signals the errors might accumulate unusually rapidly to the point of being a problem.
 

Again to draw a comparison to dithering, I did a mastering seminar where I reduced the signal level dramatically and did comparisons with and without dithering. The difference was totally obvious, but only because the signal level was so low you could really hear what was happening with those least significant bits. People couldn't tell the difference at "normal" listening levels.
 
However, I always wondered if after people heard what dithering did to multiple low-level examples, it would train their ears sufficiently so they could learn to recognize the difference at normal listening levels. The ability of the ear to "learn" extremely subtle gradations would explain why some people hear very subtle audio cues while others don't.

If the dither/quantization_error at a normal listening level is below the absolute threshold of hearing, or is sufficiently masked by background noise and the audio itself, it will be inaudible. This is commonly the case for 16 bit audio, but you can certainly find (or create) conditions where it is audible.
 
In borderline cases, my understanding is that listeners being trained on what to listen for can make a very significant difference. And that, aside from hearing loss, training or "knowing how to listen" is the primary difference between different individuals ability to hear things or not - i.e. aside from hearing loss, it's not based on anyone having naturally superior hearing or anything like that. So it wouldn't surprise me if, as you suggest, some people have learned to hear details that escape others of us, but are still within the physiological limits of our hearing.
 
But I would also assert that it's often not all that difficult to differentiate between "conceivably borderline" cases and "below the physiological limits of human hearing" cases for listening levels that don't cause permanent hearing damage in the short period of time before you blow your speakers.

D K
 ^^^ Game, Set, Match ^^^ - That is.. for anyone whose primary concern is about performing,capturing, mixing and presenting...music

 
Seeing as how you feel compelled for some reason to keep score here, why don't you instead tell us all about how much improvement your heard in your Tango 24 after shelling out for that BLA mod?
 
Btw, we'll be expecting objective proof...

Anderton

lawp
so the dpe is/was just marketing hype?

 
As I've said before...when the 64-bit engine was introduced, the world of audio engines was quite different and it was a major step forward.
 
Please note this is my personal opinion and does not speak for Cakewalk.

Craig, with all respect (and I've been enjoying your writings since Polyphony and Device days), "double precision" DAW audio engines had already been around for some time before Sonar's DPE. SAW used 64-bit processing (running native on PC), and Digi used 48-bit/56-bit DSP chips for PT TDM (with 24-bit paths between chips?) giving effective double precision (or at least, the necessary extended precision for accumulation when mixing 24-bit audio).
 
Iirc, CPA/Sonar's audio engine was built on DirectX and used single precision floats for processing. And iirc, even when Sonar was re-coded into a 64-bit application (Sonar 4?), it still processed using floats until Sonar 5 finally came out with the DPE.
 
Hopefully Noel will correct me if I'm wrong here, but seems to me that it was not until Intel and AMD's provision of streaming SIMD (SSE) functionality enhancement in their processors (supplanting the need to rely upon the x87 FPU), along with the move away from a DirectX foundation that it became performantly practical to natively implement higher precision processing in Sonar (as well as in plug-ins such as those running under VST which was revised for doubles around that time also).
 
That said, a 64-bit DAW with a 64-bit DPE was a pretty nifty trick back then (and still is).
 
But yeah, a DAW with a DPE is no longer a novelty. Even have one running on some i-devices now!
 
Otoh, some DAW developers still flatly reject double-precision, such as this one (who btw does know Jack):
 

64 bit processing is a completely bogus sales/marketing tactic. No (let me repeat that, no) double blind test has ever shown any difference to audio processing with 64 bits over 32. Synthesis is slightly different, but plugins are free to do whatever they want internally, and simply convert 32 bit for input and output. The same is true of any other processing. Certainly nothing that Ardour itself does to the signal would benefit from 64 bit processing. If you think that Reaper (or any other system) "sounds better" because of 64 bits, you need to setup a properly structured double blind test. I almost guarantee that your belief will be gone by the end of the test.

https://community.ardour.org/node/5812
 
Hey, remind you of any recent forum threads around here?

Wow. A lot of fantastic stuff here. 24 bits 32 bits 64 bits...
Hard to argue that 64 bits is not better in theory. There might conceivably be situations where it would make a difference. Anyone arguing for 64 bits for that reason ready to argue against 128 bits? 256 bits? 1024 bits? Computers  may be able to chug those out without a glitch, if not now then surely in the audio world of the future.
Or are we all going to accept that, short of an infinitely large internal representation, there is no reliable way to protect ourselves from the possibility of audible errors in an infinitely long or recursive processing chain.