RonK: 64 bit Plug-ins and Summing

Good Morning Ron - bUmP
-Thanks in advance

-D

Scott:

Thanks for your reply - I think maybe I didn't (or can't) state my question thoroughly... I understand exactly what you're saying - My concern is what happens when audio processed in the engine exceeds the projects storage - This is specifically why Sonar can report +24db beyond full scale - Sonar (unlike Sound Forge for example) will report audio above 0 db. This is the result of processing in the current 32bit float engine but summing or bouncing to a 24 bit project - right? At least that is what everybody has so far reported to be the case. I've been following threads that are reporting clipping in frozen tracks and all already know about clipping in bus summing so we adjust levels - but 64 bits in a processing engine with multiple 64 bit plugins seems to be able to create a lot of data beyond the 144db limit of 24 bit - so... I'm trying to understand how that works without massive clipping - am I totally south here? thanks in advance

-D

The mixing engine will be 64 bit double on both 32 bit and 64 bit systems.

I'm assuming it will convert your files to 64 bit while inside Sonars system.

The main thing this will help is in headroom because now all of your summing will clip at a higher point on a 64 bit system. This also is supposed to increase sound quality to a certain extent.

High bit rates for plug-ins can help the sound quality too.

I'm not sure how hard this will tax the CPU but Cakewalk said something in the words of performance specs on 32 bit systems with the 64 bit engine being similar to performance specs on Sonar 4.

what is a ronk?

Exactly what I am asking -- 64 bit has a theoretical dynamic range of 384DB how will that 'head room' be handled when the processing returns to the 144db range of 24 bit or 96 db range of 16 bit?
-D

Good question. Actually this problem still existed with 32 bit fp (192DB). I'm assuming truncation, or maybe a dithering process.

ORIGINAL: DonM
Exactly what I am asking -- 64 bit has a theoretical dynamic range of 384DB how will that 'head room' be handled when the processing returns to the 144db range of 24 bit or 96 db range of 16 bit?
-D

Without answering your question -- Sonar 5's optional 64-bit mode uses 64-bit FLOATING POINT numbers, not integers. This gives it a range MUCH bigger than 384dB, if I am not mistaken. The old (6dB * number of bits) is for integers, not floating point numbers.

-lee-

The higher bit rate is used purely to bury artifacts. So long as the recorded clips are in good condition it makes absolutely no nevermind until your final mix.

ORIGINAL: DonM
Also, would freezing and bouncing end up too hot in this 64 to 24 world?

According to the new features of Sonar5 we will be able to export wav files at 32bit float. That may or may not have bounce and audio freeze implications - maybe yes, maybe no. I did a quick search but couldn't figure it out. Here's the Sonar5 feature link I'm sure you've seen:

http://www.cakewalk.com/Products/sonar/features.asp

ED: One more thing - IMO gain structuring is still important even when mixing in 32bit float, unless you're working 32bit float native data files since it's pretty hard to use all the headroom in there. Mostly you don't worry about it when at 32bit float. I do anyway. Some of the Voxengo plugins have a little 'overs' type meter to show you when something is too hot. Also I suppose you could sitck an instance of rms buddy in the FX area to see how hot you are in between plugs - or put a safety limiter in there somewhere.

Ahh... I read this thread with increasing stress until Prog jumped in. It will make my post much shorter. Many people said bits and pieces of the right stuff... but I can see why you are confused.

In a nutshell a 64bit floating point engine is not so much about headroom as it is resolution.

It's all about resolution and accuracy over the life of your audio stream as it travels from the hard disk through your plugins, volume and pan faders, through further buss effects and further gain changes and finally back out to your soundcard or to a new file on the drive.

Any change made to an audio file even as simple as a gain change and certainly as complicated as a plugin changes audio to some extent on the amplitude axis of resolution that the bitdepth describes.

So the more resolution you have on this axis the more accurate and natural your result will sound since the audio will not be as quantized (or rounded up and down) as it would be at a lower bit depth.

ALL processing introduces rounding errors into the audio data.

To exaggerate a bit(haha) to make a point consider the sound of a digital cell phone VS a nicely mixed CD. Part of the difference is the bit depth representation of the sound (among several other parts but lets ignore tham haha). So the more errors in your DAW's audio, the more it sounds like a cell phone , and the less it sounds like the original source. Obviously it will be nowhere as extreme as the aweful sound of a cell phone... but a little digital misrepresentation goes a LONG way to making sound less clear and true to it's origin.

In the end you must still handle your headroom responsibly since you can overload your converters or produce a lower bitdepth file with significant clipping.

cAPS

so... I'm trying to understand how that works without massive clipping - am I totally south here?

The feature list mentions support for 32bit float .wav files, so I assume that will at least partially address what you are talking about.

-S

This may not be helpful, but as I see it 64 bit simply means increased precision in calculations which, therefore, minimized the effects of data truncation when calculation results exceed the original wordlength (which they usually do). The more precision the clearer digital audio will sound in the end. It may all end up as a 16 or 24 bit wave, but the precision of all the calculations applied to the digital stream will determine the clarity of information that is there.

db

This gives much greater resolution than other formats, and allows for intermediate values that go way beyond 0 dB. This can be wonderful if you are dealing with processing transient peaks, or summing lots of channels.

Yes it gives much greater resolution.....stop there don't go any further in your statements because now you're talking Spinal Tap jiberish. Have you seen the movie Spinal Tap? For sampling there has to be limits set. 0dB is a limit. Due to floating point math it allows Sonar to calculate values that exceed 0 dB. Let me back up and explain the Spinal Tap analogy to you. The dB or decibel is a reference of 2 ratios. Therefore when you divide two numbers with the same units their units cancel out. Therefore the decibel is really a unitless number. When you're talking about the dB within the digital world they attach a unit measusement to it "FS".....or dBFS...decibel "Full Scale." Now there's a lot of numbers to represent between minus infinity and Full scale.....what's the ratio of 0/-inf.....ahhhh....it's infinity. Just like in my Spinal Tap analogy amps go from zero or NO SOUND to 10. Well the digital world goes from Zero NO Sound to 0dB Full Scale. If you want to think Sonar goes to 11, then go ahead and think that and we'll all have a good laugh behind your reasoning. How did you gain anything for transient peaks? Turn your volume down to 5 and you still have plenty of room for transient peaks don't you? Infact now you have volume levels 6 thru 10 for extra headroom for transient peaks. Just like 10 is Full scale on an amplifier 0dB is full scale in the digital world.

Yes Sonar can display on it's meters that you exceeded 0dBFS. What should happen when you see this is that Sonar should display a message for you saying, "Hey idiot you don't know how to mix and now you've exceeded the maximum number on my X-axis scale. Turn your entire mix level down to allow for those transients, so you're not going over the ceiling, because the outside devices don't have any numbers to represent these values. Like when you render your mix to your hard drive, and quite the same your soundcards D/A converter doesn't have a number for this also. SONAR does not go to 11.....the ceiling of the digital world did not magically get raised when Sonar added 64bit processing. There's just a hell of a lot more values to represent the numbers between -inf to 0dBFS, therefore your resolution has increased between these 2 points.

Well..... no.

I'm working on little article about this - it is likely to be something we'll want to add to the FAQ.

You are assuming 0dB is some sort of ceiling and that all digital representation of analog signals have to go from zero to full scale, where full scale is defined as 0dB.

In the analog world 0dB is simply a reference point for a particular voltage. Preamps and mixers specify how much higher they can handle (called headroom). For example, my Onyx mixer can handle inputs as hot as 21dB without clipping.

In the digital world, one dirty little secret is that there is no standard for converting signals. If you take the exact same input signal and apply it to two different interfaces, they will be similar, but not exactly the same. For example, if I run the same signal through my MOTU 24i/o interface and the firewire interface on my 1640 mixer, I get two different outputs, because the engineers have scaled the analog signal differently to fit it into the 24-bit space. (Aside: There's not really any such thing as a 24-bit converter. The best converters out there produce about 20 bits of actual data, formatted into a 24-bit word).

Digital clipping occurs when you truncate the sound because you are not able to represent the full signal.

When you add two or more 24-bit numbers together, for example, in mixing them, you are easily able to exceed what can be stored in 24-bits. In the current Sonar, the mix engine takes the original 24-bit data and stores it in a 32-bit format. (I'm not sure if it is floating point or not). Here's the important point -- it does NOT rescale the data as it does it, it just stores it. So you have a number which is now stored in a format that allows much larger numbers. As you add two of these together, you can end up with a "signal" (its just numbers) that goes way over "0dB". However, the number is still being processed with complete accuracy. The meters in Sonar represent that, and go over zero, just like the meters on an analog console. As long as you don't exceed the limits of the 32-bit value and rescale the number back down to what 24-bits can handle, you can have intermediate values that exceed 24-bits without any problem.

Again - digital data is not necessarily scaled such that zero dB equals full scale equals the max value.

A 24-bit value can store from 0 to something like 16,777,215.

Sonar 5 uses double precision 64-bit floating point (IEEE 754). This rocks. I designed and built a parallel supercomputer years ago that used this format. It is directly supported in the CPUs, often with hardware accelleration. There are instructions that transfer integers directly into this format. Such instructions do NOT rescale the data, they just transfer it straight across. For example, a "seven" in 24-bit data would be a 7.0000 in floating point format.

A 64-bit integer can store 2^64 values or 1.8446744073709551616 * 10 ^ 19.

A 64-bit dp fp can represent 1.7976931348623157 x 10 ^ 308 (Max Double). This is a much larger range.

The format of a 64-bit dp fp is:
Sign bit: 1
Exponent width: 11
Significand precision: 53

(0x000 and 0x7ff are reserved exponents
0x000 is used to represent zero and denormals
0x7ff is used to represent infinity and NaNs

The format is written with an implicit integer bit with value 1 unless the written exponent is all zeros. Thus only 52 bits of the fraction appear in the memory format.)

The key to note is that no matter what the range, a dp fp always has 53 bits to represent the data. This is always better than the 24-bit (20 actually) input.

Why is this good? Two reasons.

First, the extra range allows you to add number together (mix, or sum) and multiply numbers (amplify) without hitting any limits. As long as you rescale the numbers after you are all done, you will not have any loss of precision or any digital clipping.

Second, the extra bits allow much greater precision (finer granularity) on the processed data, which greatly reduces intermediate errors.

So, in this case -- the middle of the processing chain CAN go to 11 (12,13, 14...), as long as there is a step at the end which brings it back down to what the output D-A can handle.

-lee-

I admire your precision and articulation. This thread has become better than I could have dreamed.

Very interesting stuff.

Looks like CW need a new slogan for Sonar 5... I dunno, maybe "This version goes to 11+!"?

ORIGINAL: LaptopPop
The format is written with an implicit integer bit with value 1 unless the written exponent is all zeros. Thus only 52 bits of the fraction appear in the memory format.)

The key to note is that no matter what the range, a dp fp always has 53 bits to represent the data. This is always better than the 24-bit (20 actually) input.

Good post, but I just wanted to clarify. Yes, there are 53 bits to represent the resolution (or dynamic range) of the signal, but with the implicit bit the IEEE floating point spec will give 54 bits resolution for a 64 bit float: 52 bits for the fractional part of the mantissa, 1 sign bit and the implicit bit.

The 11 exponent bits are what give the number its huge range, the other bits give the number its resolution. A floating point number has a constant resolution over a very large range, while an integer number's resolution gets less and less the closer to 0 you get.

(and 32 bit float gives 25 bits worth of resolution: 23 bits for the fractional part of the mantissa, 1 sign bit and the implicit bit. And 8 exponent bits)

The implicit bit is what gives it that extra push over the edge

(these bits go to 2)