64 bit engine?

I'm grateful that CW found a quick workaround for those having problems with the X3C update and the Console Emulator buzz.  However, I have questions about turning off the 64 bit double precision engine.  What will be missed by turning it off?  Will it affect recording?  What about mixing?  I often switch back and forth between the two, and having this extra step in order to use the CE seems like a bit much unless there is no audible difference by doing so.  Will there be a patch for this anytime soon?  I want to stay up to date, but not until everything works at least as well as X3b, which is giving me no problems at all.  If anybody can shed light on this, I'd be grateful.

So, I'm guessing, the 64 bit double precision engine helps 64 bit plug ins run more smoothly?  I don't necessarily consider turning the 64 bit engine off a viable workaround if you have to take one step backwards to take one step forward.  Is my logic faulty, or am I just being too picky?  I suspect many have the same reservations.  I would really love it if someone from CW chimed in here.

Back when CW first came up with the 64bit internal engine, there was much talk/discussion/down right arguing about the benefits/lack of 64bit internally. And at the time I read more about the subject than I ever thought I needed. But it was very interesting.
 
The reason I am reluctant to explain in detail is because of my limited knowledge. Someone with better explaining skills than I have will jump in. Those guys who know the deal are really eager to teach others.
 
And when they see someone stumbling to explain, they usually come in and clear things up.  :)

bitflipper
Lynn, have you tried just turning the 64-bit engine off and listening?
 
Or, if you want to get scientific about it, export the full mix with and without the 64-bit engine enabled and do a blind ABX test.
 

Null test too?

You can try and do a null test too. Render a project in 32-bit mode, then rerender in 64-bit more. Take those two, load in to a new project. Invert one, and play back. Any differences will show on the meter as well as the level. So if you get digital silence, then no difference. If you get stuff down in the -140dB range, then way below audibility, and below the noise floor of any DAC. If you get levels of -30dB (you won't) then there's a problem.
 
Realistically not only is 64-bit unneeded headroom in pretty much any realistic project, it isn't all that helpful since most plugins aren't double precision. Your synths, FX, etc are probably mostly single precision, hence they are all rounding everything to 32-bit.
 
I'm not saying don't take double precision when you can get it but I would so not worry about it.

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.

Sycraft
You can try and do a null test too. Render a project in 32-bit mode, then rerender in 64-bit more. Take those two, load in to a new project. Invert one, and play back. Any differences will show on the meter as well as the level. So if you get digital silence, then no difference. If you get stuff down in the -140dB range, then way below audibility, and below the noise floor of any DAC. If you get levels of -30dB (you won't) then there's a problem.

 
You have to be careful here - if you have any random stuff going on, it won't null properly. So you need to turn off all dither and freeze any synths or FX doing random processing in your tracks. This might include anything with random modulation, synths with free running oscillators and such. The best way to test for this is to export using 64bit twice to verify that you get a perfect null that way first.
 
Also keep in mind that Sonar's meters only go to about -100 dBFS.
 

Realistically not only is 64-bit unneeded headroom in pretty much any realistic project, it isn't all that helpful since most plugins aren't double precision. Your synths, FX, etc are probably mostly single precision, hence they are all rounding everything to 32-bit.

 
In terms of headroom, 32 bit floating point is impossible to clip without intentionally trying very, very, very hard just to prove you can. In terms of precision, given competent programmers, plugins will do calculations at an appropriate bit depth internally regardless of Sonar's engine setting. Generally 64 bit double precision is appropriate mostly for recursive calculations (i.e. calculations that include a feedback loop where the errors might accumulate over thousands of iterations).

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!
 

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. 

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.

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" :)

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