A question about the 64bit engine

As long as it's been available I've always left the 64-bit engine checked. I figured the greater the calculation accuracy, the better. But I'm wonder now what difference this really makes. If you are recording at 24-bit and rendering (bouncing/exporting) at 24-bit, what does this increased accuracy actually give you? Whether you're processing at 32-bit or 64-bit, doesn't all this extra "accuracy" get truncated when rendering to 24-bit?

I know that when applying any digital processing to an audio file you increase the word length and, therefore, theoretically the increased bit accuracy of the engine will provide more calculation headroom. But if you're truncating to the 24th bit during final rendering, what benefit does the 64-bit engine actually give you compared to 32-bit?

For a simple minded example, lets say we render all our audio files to 5-bits, so our audio file starts out with a value of say 50.00. Now we apply some processing to the audio file that results in a calculation of 50.00 x 3.12345. If our calculation engine is 8 bits, this gives us enough head room to be fully accurate with a resultant value of 156.1725. If our calculation engine is 6 bits, the result is truncated to a value of 156.17. Final exporting of our file will truncate to 5 bits, which would be 156.1. In this case, what is the value of the extra .0025 accuracy provided by the 8-bit engine if in the end this all gets truncated down to 156.1? In this case our 8-bit engine offers no advantages over our 6-bit engine.

If we extrapolate this example to 64-bit versus 32-bit engine processing and rendering to 24-bit, it logically appears to me that unless one is actually rendering to 64-bit, that all this extra calculation accuracy is just a waste of processing power.

Am I looking at this all wrong?

Best regards,

DB

one thing is the resoulution of individual audio clips and the other ist the "pool" in which you mix them ... sonar foer example always makes volume fades in 64 bit because they are smoother and also you might be right that the difference between a 32 and a 64 mix engine is probably almost neglectable - but the more "space" you have in the summing engine the less you will ever clip - even when summing a lot of clips that could for coincidence all have peaks at the same time (resluting in evemntual clipping)
so the more tracks you use and the hotter you record and mix them the more a 64e´ngine keeps it on the safe side...
clipping would resulzt in a damage at the peak of the signal resulting in audible degenenartion - summing "clip-free" in a very high resolution environment and THEN downascaling to a lower resolution will affect the signal on the opposite side - at the lsb (least significant bit) so the information lost in that process is a very low level information that will mostly be not audible at all...

cheers

ORIGINAL: CJaysMusic

Your getting floating and fixed rates confused. 64 and 32 are floating and 24 and 16 are fixed. You can get the benefits of the 64 float engine in a 16 and 24 bit file
Cj

Hey CJ,

What benefits? I understand the benefits of floating point. The question is whether or not there are benefits of using 64-bit floating point versus 32-bit floating point when rendering down to a 24-bit file. Seems to me that regardless of the floating point, the extra accuracy of 64-bit over 32-bit will be lost when truncating down to 24.

Again, I'm no expert...just trying to gain some clarity.

Best regards,

DB

Let's say you're mixing a series of pristine 24-bit tracks together -- tracks that actually take advantage of 24 bits. During mixing, you have plenty of automation all over the place, etc... and if you use plugins that can handle 64-bit audio, all the better... Now, if you have the 64-bit engine engaged for mixing, think about the headroom (and footroom) that is available to you to get the most pristine possible mix and retain the integrity of the original audio sources and processing, at each stage... from channel to plugin (if it accepts it) to bus, etc...

In a "lesser" mixer, all sorts of compromises are made at every gain/plugin/bus stage in the path. Keep in mind that summing is taking place all over the place, so more audio data is lost than one might think, even in a 32-bit engine. When it is all summed up (and re-summed, and processed, and bussed, and re-summed), right before the final output, you theoretically have a cleaner, more transparent mix, with a potentially higher level of integrity if you are using Sonar's 64-bit engine. Then, when that is truncated/dithered down to 24 bits (or whatever target you have) you should theoretically still have a cleaner, more transparent mix with better integrity throughout the whole dynamic range.

Also, think "GIGO" -- Garbage In, Garbage Out. While the data is in there, you don't want the engine messing with your audio streams, right? The 64-bit engine ensures that minimal junk happens to your audio... so you can just worry about the quality of the stuff you feed it.

Now, that's all in theory, but in practice, I have NOT experienced MUCH of a real-world benefit, say compared to Cubase/Nuendo's mix engine (which is only 32-bit). HOWEVER, it's nice to know that my Sonar mixes are technically (and/or theoretically) more pristine and have more integrity. For a while, I tried to fool myself into thinking I had the ears to really tell the difference in my "normal" projects, but it was only in extreme circumstances that I could begin to notice a difference.

What I've found is that the limiting factor is really the other gear you have in your signal path. If you have crappy ADDA converters, monitors, mics, preamps, room acoustics, etc., etc., etc., 64-bit vs 32-bit audio should be the least of your worries. Your signal path is only as good as its weakest link. And the final piece of "hardware" in your mixing path is your ears. :) So in the end, it all boils down to a human being anyway. Maybe that's the weakest link for most people right there.

[EDIT: Also, I should mention that I think technique and skill obviously play a massive -- perhaps THE singularly massive -- role here too. If someone doesn't have the skills to record/mix/produce/master well in 32-bit, then does a 64-bit engine really matter? Heck, they'd be better served worrying about learning the ropes first. :) Like you, I enjoy and cherish some recordings that were recorded and mixed on something far more primitive than Sonar, and I still marvel at the beauty of the recordings and engineering skill that went into them. Again, the human factor. ]

Once I upgraded my basic i/o path to some quite decent hardware and treated my environments, in the end, I feel like 64-bit audio engine does have SOME merit, but only barely, for my personal uses. In the end, since there are so many other factors that matter more, I've concluded it's mostly about marketing. It's good marketing for Cakewalk, and it's good marketing for me to tell clients. There's a little psychological biasing you can get from it. :) Good? Yes. Use it? Yes. Argue about it with Steinberg folks? No. Not worth the time. ;)

ORIGINAL: dbmusic

ORIGINAL: CJaysMusic

Your getting floating and fixed rates confused. 64 and 32 are floating and 24 and 16 are fixed. You can get the benefits of the 64 float engine in a 16 and 24 bit file
Cj

Hey CJ,

What benefits? I understand the benefits of floating point. The question is whether or not there are benefits of using 64-bit floating point versus 32-bit floating point when rendering down to a 24-bit file. Seems to me that regardless of the floating point, the extra accuracy of 64-bit over 32-bit will be lost when truncating down to 24.

Again, I'm no expert...just trying to gain some clarity.

Best regards,

DB

ORIGINAL: eratu

Let's say you're mixing a series of pristine 24-bit tracks together -- tracks that actually take advantage of 24 bits. During mixing, you have plenty of automation all over the place, etc... and if you use plugins that can handle 64-bit audio, all the better... Now, if you have the 64-bit engine engaged for mixing, think about the headroom (and footroom) that is available to you to get the most pristine possible mix and retain the integrity of the original audio sources and processing, at each stage... from channel to plugin (if it accepts it) to bus, etc...

In a "lesser" mixer, all sorts of compromises are made at every gain/plugin/bus stage in the path. Keep in mind that summing is taking place all over the place, so more audio data is lost than one might think, even in a 32-bit engine. When it is all summed up (and re-summed, and processed, and bussed, and re-summed), right before the final output, you theoretically have a cleaner, more transparent mix, with a potentially higher level of integrity if you are using Sonar's 64-bit engine. Then, when that is truncated/dithered down to 24 bits (or whatever target you have) you should theoretically still have a cleaner, more transparent mix with better integrity throughout the whole dynamic range.

Also, think "GIGO" -- Garbage In, Garbage Out. While the data is in there, you don't want the engine messing with your audio streams, right? The 64-bit engine ensures that minimal junk happens to your audio... so you can just worry about the quality of the stuff you feed it.

Now, that's all in theory, but in practice, I have NOT experienced MUCH of a real-world benefit, say compared to Cubase/Nuendo's mix engine (which is only 32-bit). HOWEVER, it's nice to know that my Sonar mixes are technically (and/or theoretically) more pristine and have more integrity. For a while, I tried to fool myself into thinking I had the ears to really tell the difference in my "normal" projects, but it was only in extreme circumstances that I could begin to notice a difference.

What I've found is that the limiting factor is really the other gear you have in your signal path. If you have crappy ADDA converters, monitors, mics, preamps, room acoustics, etc., etc., etc., 64-bit vs 32-bit audio should be the least of your worries. Your signal path is only as good as its weakest link. And the final piece of "hardware" in your mixing path is your ears. :) So in the end, it all boils down to a human being anyway. Maybe that's the weakest link for most people right there.

[EDIT: Also, I should mention that I think technique and skill obviously play a massive -- perhaps THE singularly massive -- role here too. If someone doesn't have the skills to record/mix/produce/master well in 32-bit, then does a 64-bit engine really matter? Heck, they'd be better served worrying about learning the ropes first. :) Like you, I enjoy and cherish some recordings that were recorded and mixed on something far more primitive than Sonar, and I still marvel at the beauty of the recordings and engineering skill that went into them. Again, the human factor. ]

Once I upgraded my basic i/o path to some quite decent hardware and treated my environments, in the end, I feel like 64-bit audio engine does have SOME merit, but only barely, for my personal uses. In the end, since there are so many other factors that matter more, I've concluded it's mostly about marketing. It's good marketing for Cakewalk, and it's good marketing for me to tell clients. There's a little psychological biasing you can get from it. :) Good? Yes. Use it? Yes. Argue about it with Steinberg folks? No. Not worth the time. ;)

Guess I'm just not getting it here. I do understand that within the 64-bit mixing engine you get more accuracy and theoretically more "pristine"audio. But isn't all this "pristine" information you are getting with 64-bit calculations being truncated at the 24-bit rendering?

I know this is all esoteric and won't matter one hoot in what people actually hear from my mixes. In reality I'm much more concerned with proper gain staging through my analog chains to keep the noise floor as low as possible. But still...I do wonder.

Watch the Ron Kuper videos from AES 2005: http://www.cakewalk.com/Events/AES2005.asp . Look at the stuff under "Ron Kuper Delivers Seminar on Benefits of 64-bit Computing for Digital Audio Applications"

He gives a demonstration of how easy it is to introduce errors into the lowest bits of a 24-bit file using just a couple of operations when summing with a 32-bit engine. Considering audio may go through thousands of calculations in a complex mix it seems logical to believe that compounding error would affect more than the LSB. Also, Bob Katz in Mastering Audio talks about why he believes 32-bit summing is not good enough for digital audio software.

Hi dbmusic,

I think what the others have missed so far is that when you record at 24 bit and use the 32 bit mix engine, then your resolution (not to be confused with absolute range) is actually 25 bits.

This is because a 32 bit float uses a 24 bit mantissa and 8 bit exponent. It is the mantissa that gives you resolution and due to some truncation of the absolute range (part of the IEEE floating point spec.) we gain one extra bit of resolution to get 25 bits (using the implied bit). You do not need many calculations before the errors due to rounding start encroaching on our 24 bit resolution and in fact not too much needs to be done with FX etc. before you will lose several bits.

Also, if you take advantage of 24 bit when recording to keep your peaks at around -10 dB or so (to easily prevent any digital overs) then you soon get to the stage where your error free resolution could be reduced to be around the 16 bits of a standard CD.

Using 64 bit floats effectively removes this error build up as far as 24 bit output is concerned by using an incredible resolution (IIRC 53 bits effective mantissa) so the errors will never affect us when we reduce to 24 bit output. While 64 bit could be argued to be overkill there is no floating point spec. with intermediate resolution so that is what we use. I believe earlier systems used (and perhaps still do) a 48 bit fixed point approach. This requires custom maths though, and while it is more than adequate it is not worthwhile to even consider nowadays as we have efficient 64 bit floats easily available.

ORIGINAL: Mr. Ease

ORIGINAL: dbmusic


In each case bit depth will determine at what point information will get truncated off the result of a calculation. What I'm not seeing is the usefulness of truncating at the 64th bit versus the 32nd bit in the mixing process when everything is truncated to the 24th bit in rendering.

DB

This is the point of my post here. With a 32 bit float you are not truncating the 32nd bit, you are truncating (or more accurately, rounding) the 25th bit as that is the resolution of the mantissa. These errors can build up quite quickly as I said before, particularly if you record "cool" in 24 bit by say 10 dB.

Ok, in my feeble attempt to understand this I think I'm starting to get my head around it. I think my key misconception is in the definition of "errors". I was looking at errors as any set of resultant calculation numbers that exceeded the mantissa and would thereby be truncated. I was looking at the truncated result as the "error". I didn't think that errors were actually incorrect calculations...only digits that extended beyond the boundaries set by the bit accuracy and, therefore, subject to truncation.

So, if you consider that in 32-bit accuracy a calculation may not only exceed the 25 digit mantissa (which would get truncated), but the calculation itself may result in incorrect numbers (errors) extending below the mantissa, now you have errors imparted into your 24-bit rendering.

From this vantage it's easy to see that using a 64-bit mixing engine (with a 53-bit mantissa) will significantly reduce the impact of calculation errors on the final rendering as very few of those errors are likely to extend into the 24-bit rendering.

Whew! Thanks to all for indulging me.

Best regards,

DB

I always found "odd" (my poor joke) with this whole computer and music thing.. yep cards are 24 bit conversion wise.. while from programming background stuff is normally in multiples of 8 or 16..

FWIW, the noise-floor of (good) electronics is currently too high to take full advantage of 24Bit audio resolution.

Nor is this likely to change significantly as many converters now manage to get near to the theoretical limits of electronics operated at room temperature. Unless we start using liquid nitrogen cooled converters we will never see any where near the theoretical 144 dB range of 24 bit converters.

And for some perspected:
A noise-floor of -117dB or better is pretty darn quiet.
To take full advantage of this, the rest of your front end has to be pristine (including the background noise in your studio space).

I know that you all love the tech side of this but to me and I think the OP would benefit by simply stating it sounds 20 to 40 % better.

are well past their sell by date

By how much, would you say?

The short answer is, the 64-bit engine will have less intermediary rounding 'errors' than the 32-bit engine when doing floating point math. In complex calculations this rounding can really add up - in a very undesirable way This would apply mostly to the summing "amps" as stated by many above. It would also apply to plugins that are 64-bit aware.
-Dan

You do not need many calculations before the errors due to rounding start encroaching on our 24 bit resolution

I'm not disputing this point, but I am curious. Isn't the real issue the ultimate affect the processing resolution has on the final product, which in most cases (these days, anyway) will be 16-bit CD tracks or even the lesser effective resolution of MP3? By the time we get to that, there'd have to be a great deal more rounding error to affect things that many bits to the left, would it not?

Also, an earlier post asserted that 64-bit gave better protection against clipping. I don't believe that is so, but I don't know quite enough about DSP to state that with confidence. Can anyone confirm this one way or the other?

John,

Just to be sure we're talking about the same thing ... I'm suggesting that it makes little sense that 32-bit floating point would have a significantly greater potential for clipping than 64-bit. I'm not comparing floating point to fixed, which obviously is a different situation.

Here's my reasoning. 32-bit floating point can represent astronomically huge quantities (the highest order 8 or so decimal digits being accurate). 64-bit floating allows astronomically "huger" quantities and more digits of accuracy (15 or so, if memory serves). But the the order of maximum magnitude of 32-bit floating is already so large, clipping should become a non-issue. To be more scientifically precise, we're talking gazillions vs. bazillions. It's only when we convert back to fixed point that the clipping comes into the picture. Coming to fixed point from 32-bit floating vs. 64-bit floating shouldn't be a factor.

At least this is what my intuition tells me. Once again, I'm not saying you're wrong, especially if you can demonstrate the behavior. But if I'm wrong, then I'm clearly misunderstanding something fundemental about how all this stuff works under the covers.