So I did a null test to show people what the differences are. For this test I used the Jodi Good song "Where Did We Go Wrong?" that came as a demo with X2, as it's not a specially created file and is one that many people here might be familiar with.
 
I exported it with X3 using no dither with both the 64 bit double precision engine and the 32 bit engine to 64bit float files that I then nulled in Sound Forge. I then used SF's "statistics" feature to report the peak and RMS levels of the differences.
 
 
I decided to do the null test "wrong" once to illustrate how easy it is to screw things up and draw the wrong conclusions if you aren't careful. In this case, I left all of the FX enabled (knowing that at least some of them would create random differences between exports), nulled the files from the 64bit and 32bit engines and got the following results: 
 
32bit vs. 64bit engines with FX causing random differences between exports:
Left Channel Right Channel
Minimum sample value (dB) -26.421 -26.536
Maximum sample value (dB) -26.202 -25.950
RMS level (dB) -48.229 -48.289
 
Looks pretty bad right? But how much of that was due to the engines and how much was due to random differences that had nothing to do with the engine's bit depth? Well I exported twice using the 64bit engine (the only export option that changed was the file name, so any differences were due to some other difference between the exports) and nulled those files and got the following results:
 
64bit vs. 64bit with FX causing random differences between exports:
Left Channel Right Channel
Minimum sample value (dB) -27.302 -25.628
Maximum sample value (dB) -26.343 -26.088
RMS level (dB) -48.292 -48.400
 
As you can see these numbers, which were produced by randomly differing FX processing in each export, are all within a fraction of dB of the 32 vs. 64bit differences above.
 
 
Now let's see what happens when I do it a little more carefully. In this case I disabled track and bus FX on the export page and exported using the 64bit engine twice:
 
64bit vs. 64bit (no FX):
Left Channel Right Channel
Minimum sample value (dB) -Inf. -Inf.
Maximum sample value (dB) -Inf. -Inf.
RMS level (dB) -Inf. -Inf.
 
 
Everything nulls perfectly this time, so now we know that when we compare the 32 and 64bit engine exports, all of the differences will be due to the engines alone:
 
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
 
Now those numbers  might already seem ridiculously low and are surely inaudible, but wait, there's more - they are actually overstating the differences because in the real world everything is going to be output at 24bits or less. Let's see what happens when we reduce the bit depth to 24bit:
 
32bit vs. 64bit (no FX) reduced to 24bits:
Left Channel Right Channel
Minimum sample value (dB) -138.474 -138.474
Maximum sample value (dB) -138.474 -138.474
RMS level (dB) -Inf. -Inf.
 
The reason the RMS is now -infinity is that so very few of the differences survived truncation to 24bits that the RMS value doesn't even make it into the LSB of 24bit audio!
 

I can hear the difference between the 32bit and 64bit engines.  It's in the tail of the reverb or the end of the delay or the clarity on the toms low note.  The 64bit engine just gives a clarity to the lowest sounds in the mix.
 
Ben  

BenMMusTech
I can hear the difference between the 32bit and 64bit engines.  It's in the tail of the reverb or the end of the delay or the clarity on the toms low note.  The 64bit engine just gives a clarity to the lowest sounds in the mix.
 
Ben  

IMO, for classical or jazz, this might matter.  But for Rock/Pop/R&B.... A 70's Lexicon reverb tail sounds just fine to me.  When I hear a "crystal clear" recording, it just sounds sterile and, well... harsh to my ears. 
 
Even with a modern recording I like, that "harsh" quality makes it difficult to listen to repeatedly (It's never a problem with analog; I could play an album over and over again.  Of course I grew up listening to vinyl, so that may have just become my own personal taste).
 
Then again, "vintage" and "lo-fi" plugins are now the norm in most studios:  Recording everything crystal clear, then "dirtying it up" via the plugins.   
 
Make me wonder just how much of the 64-bit clarity is retained at the end of the day. 

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)).
 
Craig Anderton alluded to this situation in an article over on HC earlier this year:
 
http://www.harmonycentral...chniques/ba-p/34780908
 
Incidentally, Steinberg's VST implemented double precision with VST 2.4.

As I'm mixing down to 8 bit nowadays....
Nothing like a bit of marketing to bite you in the ass later.
Extremely interesting white paper, thank you.

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.
 

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

drewfx1
So I did a null test to show people what the differences are. For this test I used the Jodi Good song "Where Did We Go Wrong?" that came as a demo with X2, as it's not a specially created file and is one that many people here might be familiar with.
 
I exported it with X3 using no dither with both the 64 bit double precision engine and the 32 bit engine to 64bit float files that I then nulled in Sound Forge. I then used SF's "statistics" feature to report the peak and RMS levels of the differences.
 
 
I decided to do the null test "wrong" once to illustrate how easy it is to screw things up and draw the wrong conclusions if you aren't careful. In this case, I left all of the FX enabled (knowing that at least some of them would create random differences between exports), nulled the files from the 64bit and 32bit engines and got the following results: 
 
32bit vs. 64bit engines with FX causing random differences between exports:
Left Channel Right Channel
Minimum sample value (dB) -26.421 -26.536
Maximum sample value (dB) -26.202 -25.950
RMS level (dB) -48.229 -48.289
 
Looks pretty bad right? But how much of that was due to the engines and how much was due to random differences that had nothing to do with the engine's bit depth? Well I exported twice using the 64bit engine (the only export option that changed was the file name, so any differences were due to some other difference between the exports) and nulled those files and got the following results:
 
64bit vs. 64bit with FX causing random differences between exports:
Left Channel Right Channel
Minimum sample value (dB) -27.302 -25.628
Maximum sample value (dB) -26.343 -26.088
RMS level (dB) -48.292 -48.400
 
As you can see these numbers, which were produced by randomly differing FX processing in each export, are all within a fraction of dB of the 32 vs. 64bit differences above.
 
 
Now let's see what happens when I do it a little more carefully. In this case I disabled track and bus FX on the export page and exported using the 64bit engine twice:
 
64bit vs. 64bit (no FX):
Left Channel Right Channel
Minimum sample value (dB) -Inf. -Inf.
Maximum sample value (dB) -Inf. -Inf.
RMS level (dB) -Inf. -Inf.
 
 
Everything nulls perfectly this time, so now we know that when we compare the 32 and 64bit engine exports, all of the differences will be due to the engines alone:
 
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
 
Now those numbers  might already seem ridiculously low and are surely inaudible, but wait, there's more - they are actually overstating the differences because in the real world everything is going to be output at 24bits or less. Let's see what happens when we reduce the bit depth to 24bit:
 
32bit vs. 64bit (no FX) reduced to 24bits:
Left Channel Right Channel
Minimum sample value (dB) -138.474 -138.474
Maximum sample value (dB) -138.474 -138.474
RMS level (dB) -Inf. -Inf.
 
The reason the RMS is now -infinity is that so very few of the differences survived truncation to 24bits that the RMS value doesn't even make it into the LSB of 24bit audio!
 

Love when people put the time in and report facts.. thanks for this D... Now.. Let's wait for the remainder of those who are going to say "facts be damned.. I hear it..and my ears are better than your stupid null test" :)

 
Yes, thanks you a lot for this work , Drewfx1 !

guigz2000
Well, I think 64 bits should be a good thing on x64 OS.
Yes you won't hear any difference.
But, today CPU use 64 bits processors with 64bits registers. Using 64 bits engine should have an influence on the way data is retreived in memory and "might" speed up a bit data access, at the expanse of memory size. 64 bit processors access memory using 64 bits chunks and when storing lower bit nbr, there's one more operation to perform to get the needed value.

so...you won't hear a difference, but you'll just know that there must be one...