cliffr
Na, Cubase has been 64 bit for a while now.
I only know beacuse I was thinking of adding it to my tool kit a while back so checked that first.

You misunderstood what I was saying.  Certainly Cubase runs as a 64-bit application.  But the internal data stream for sound is, I believe, still 32-bit only.  You do not get a choice between 32 and 64 as you get in SONAR.  Now, I could be wrong about that because I've just recently acquired Cubase and am still reading a massive amount of documentation, but that's my understanding so far.

My OP question was a reaction to the fact that you don't have meters in the signal flow at the input of the summing busses and so you don't know what your head room is.

I think we've established that headroom at the summing busses is mostly irrelevant, at least on a purely technical level, because we're still in floating-point land there. 
 
What's more significant is that most of us don't have meters at the hardware output. Instead we rely on software that can report overs and interpolate where the signal will actually peak when reconstructed.
 
Even when provided, such information may not be accurate. Software cannot differentiate between an over and a legitimate sample value of 0dB, so it assumes that N consecutive samples at 0dB constitutes an over, with the value of N being up to the developer's/manufacturer's discretion. Consequently, hundreds of overs may not be reported. 
 
Whether you're working in integer or float, 16, 32, 48 or 64 bits, the best strategy is and always has been to just leave some frickin' headroom. The common practice of pushing peaks right up to -0.3dB or higher is totally unnecessary. 

As I have already said one can very easily keep well clear of any limits of the digital system. What is even better about the K System approach is that for your final mix to finally end up at the reference level eg K-14 the buses are actually below that. The buses might be sitting down at K-17 for example because it is when they finally add up on the masterbuss the final mix comes back up to K-14. So our buses are sitting at an rms value of say -17 which means 17 dB of headroom above that for peaks. Pretty decent amount of headroom. Even a powerful transient might reach 12 dB above the rms value meaning the loudest peaks on my buses are only making up to -5dB at the most.
 
You don't actually have to monitor buss levels at all in fact. You only really need to monitor the final stereo buss level. Because you will never really go over your chosen ref level (on your masterbus) which is keeping the buses slightly below that.
 
You just turn up the monitor level now in your room to either 85 dB SPL or higher. The reason why people overload their tracks and buses is that they are keeping their monitor volume down too far and hence they are pushing everything so hard in order to hear the music. K System is about ref levels within your DAW AND monitor volume settings. I have a SPL meter permanently setup in my control room and it is very good to have it there. It tells you a lot about what is going on.
 
Even in 16 bit system if you choose a K-20 ref level and that is even lower, you still have 70 dB of dynamic range underneath at your disposal. At 24 bit this goes up to 120 dB below -20dB! No reason to be peaking anywhere up near 0dB FS is there!

It's hardly pedantic if a point is made that renders the original question moot.

Careful gain staging and metering = no internal clipping. Simple as that really. On any DAW. I have never clipped the AUX inputs in PT in my life. Why is that I wonder. And yet the tutorial the OP refers to internal clipping on the AUX buses. Ever wonder why it happened in the first place? Metering is not a workaround, it is a necessity.
 
You can walk along the road and fall into a hole and then you will need a lot of enery and effort to get out of it, or you can look ahead and just walk around it.
 
Mike I do respect your deep interest in these things and it often uncovers things we did not know and that is always a good thing. But for those of us who are being paid to pump out mixes every day that sort of stuff is the very last thing on our minds. There is just no time to think about it.
 
 

yorolpal
Yea...it's kinda like wanting to have a detailed understanding of quantum "membrane" theory before you go to Starbucks for fear you'll drive into another universe on the way there. Or is it?? :-)

You jest, but it's no laughing matter. I've done exactly that, except it wasn't Starbucks, it was Guitar Center.

Hey everyone! :-)
 
Thank you for being so open minded about my posting.
 
I want you all to know that I value everyone who has taken part in this thread and that I am always eager to discover and learn stuff from you.
 
It is really helpful, for me, to be able to bounce ideas around with people that are so well experienced.
 
Thank you all very much!
 
all the best,
mike

Jim Roseberry
When it comes at virtually no CPU load, I'll take the extra resolution... and never give summing accuracy another thought.   

But you see this is the beauty of it - someone who's concerned that there might be a CPU hit under load can just do the reasonable thing and leave 64bit turned off because there's no real world impact on summing accuracy, and then they never have to give the potential of an adverse CPU impact another thought! 

Hardly a new topic, Pro Fools have been in a dither over this for years and not much has really changed. For example:
 
http://repforums.prosoundweb.com/index.php/topic,6955.0.html
 
http://duc.avid.com/showthread.php?t=320440
 
There are actually valid architectural reasons why the choice of math impementation can differ very significantly between processes to be executed using a general-purpose CPU and processes to be executed using specialized DSP chips or a GPU or an FPGA, e.g.:
 
http://www.mpi-inf.mpg.de/~strzodka/projects/double/
 
Anyway, even though Sonar's audio engine has been able to employ 64-bit double precision floating point on 32- and 64-bit systems since at least Sonar 5 iirc (Ron Kuper days?), there are still places where audio data streams need to be converted bit-depth-wise and between fixed/integer and floating-point representations, so rather than fixating only on a mix engine's precision it is also rather important whether these necessary conversion operations are optimized for the hardware employed. See for example:
 
http://software.intel.com/en-us/articles/utilizing-intel-avx-with-cakewalk-sonar-x1
 
http://www.tomshardware.com/reviews/fx-8150-zambezi-bulldozer-990fx,3043-5.html
 
http://software.intel.com/sites/billboard/article/cakewalk-intel-and-windows-8-bring-high-performance-touch-enabled-mobile-workflows-musicians
 
Btw, for plug-in experimentation outside a DAW's mix engine, the freeware VSThost is available in both 64-bit double precision and 32-bit floating point versions:
 
http://www.hermannseib.com/english/vsthost.htm
 
Finally, what one hears may have nothing to do with a DAW's internal precision and everything to do with its dithering (or, in the case of the original SAW DAW software, lack of any dithering at all-- just do a search for Bob Lentini and Bob Katz and dithering and truncation).