Whats with this 32-bit float and no clipping jibber jabber?

[SouthSIDE Glen]

I've heard something sporaically mentioned on this board, and now I've actually read the following in the Cubase4 manual (bottom of page 75):

"With 32-bit float recording, you don't risk clipping (digital distortion) in the recorded file."​

Could somebody who truely understands thiis stuff tell me what they actually mean by that? Anybody can clip in 32-bit float anytime they want to (not that they should want to )

G.

 

[mshilarious]

Not if you turn down the master fader. That is, IF your chain (including all your plugs) are passing 32 bit float between themselves, you can be a little sloppy going through, at least if the plugs themselves don't freak out with a high input level. That might not be true with a lot of the analog modeling plugs, they might have an input level control, but they will probably model the analog input control rather than simply doing a digital gain change.

Some time ago I did the test, with 5 plugs doing 12dB cuts, then making it up in the master section, and the opposite as well. It nulls with the original file.

 

[nononsense!]

You can always let something clip. What they mean is that the 'chance' that it clips is decreased, because it has a higher cliplevel in comparison to the already used 24 bit resolution.

 

[tarnationsauce2]

I am not sure how they do it, but if you "clip" a 32-bit float file, it will actually go over 0 and not truncate the part that would have went over 0.

For example a strong snare hit goes over the top line, out of view. If you apply a destructive amplitude reduction to the file, you will see that the part that went over the top is not clipped. It will be rounded and look as it should. In the DAW it will not sound clipped either, as long as you turn down the track's level or the master fader.

My guess is that digital 0 is not the "real" digital 0. it's probably 24-bit digital 0.

Yeah, the laws of binary audio still apply, with enough input or gain it will eventually clip the waveform.

 

[theblackBay]

What Mr sense said.

it is the internal Bit depth resolution, so that there is in theory the extra "depth" for "shaping" thus the less inclined for the actual signal to clip to the full 24bits.

you will see some plug-ins espouse the internal 48bit depth, the plug-in has the added bit depth when the signal enters the plug-in to stop this internal clipping.

aaah i'm horrible at math so i'm rambling.
the math pans out though and 32bit is technically different.

 

[kubeek]

The key is in the float point.
Lets say your wave is sine in 32bit, and the peak value is 1, written like 1/2*2^32.
Now lets get rid of bits, and imagine 32bitStaticPoint like you have 32 decimal places to write your numbers, asuming the numbers are in format 0.xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx, so you can have numbers 0.0-1.0
When your number is 1 and you multiply it by 10, you get digital distortion.

32bitFP means you use for example 4 places to define the position of the point, and the rest 28 for the number.
So the number is like 1x10^0. When you multiply it by 10, you get 1x10^1, which holds the precision, and distortion occurs only with very big or small numbers where you don't have enoug place to store the exponents.

Is it more clear?

So you can clip it (inside the box) anytime you want, but you have to add few thousands dB of gain.

 

[SouthSIDE Glen]

IF your chain (including all your plugs) are passing 32 bit float between themselves, you can be a little sloppy going through, at least if the plugs themselves don't freak out with a high input level.

You can always let something clip. What they mean is that the 'chance' that it clips is decreased, because it has a higher cliplevel in comparison to the already used 24 bit resolution.

That much I already understand (or maybe not? ); that with FP precision, there is higer resolution up near 0dBFS, and therefore when riding up near 0dBFS, incidental clipping may be somewhat reduced. But all it takes is an increase in gain of one dBFS and even 32FP will be pushed over the edge into clipping.

But the statements Iv'e heard and read (but have never seen explained) are far more definitive than that. The Steinberg manual doesn't say that the risk of clipping is reduced, it says "you don't risk clipping"; i.e. that there is NO RISK WHATSOEVER of clipping if one records using 32FP. Thi is, of course, nonsense, which I have heard repeated many times on this forum and elsewhere.

Is this just a bad translation from German in the Steinberg manual, or is there some other principle they are espousing that I am misinterpreting myself?

G.

 

[Sonixx]

here's the deal in layman's terms...

16 and 24bit is integer and can handle 2^16 or 2^24 respectively. depending, a multiplication or division can cause an overflow (clipping) or underflow (Zero) so precautions need to be taken to prevent this.

32 bit floating point is a 24 bit mantissa and 8 bit exponent which can handle about -e35 to +e35 there abouts. with floating point the math is scalable and one generally does not need to worry with "running out out of bits" as with integer math.

now with double precision math that you hear about, this is a much finer grained math (more precise) so multiplications and divisions result in much less round off i.e. the "value" of a bit is much smaller.

yes, clipping is basically a non-issue with floating point unless one is doing some really strange math that puts one at the extremes or has a calc that is divergent.

 

[SouthSIDE Glen]

with floating point the math is scalable and one generally does not need to worry with "running out out of bits" as with integer math.

But this is where the misunderstand lies, I think. You still have an integral (and real-life in the converter) wall at 0dBFS that's going to clip off whatever you have going on "above that" sooner or later.

OK, so I think I see where the problem is with that Cubase startement. They say there is no clipping "in the recorded file" if the file ins in 32FP format. True enough in the the math holds. But fairly irrelevant in the big picture.

G.

 

[Sonixx]

But this is where the misunderstand lies, I think. You still have an integral (and real-life in the converter) wall at 0dBFS that's going to clip off whatever you have going on "above that" sooner or later.

OK, so I think I see where the problem is with that Cubase startement. They say there is no clipping "in the recorded file" if the file ins in 32FP format. True enough in the the math holds. But fairly irrelevant in the big picture.

G.

no, with FP 0db has no meaning wrt to the math like it does with integer math. with FP, there is a trade off with only 24 bits of resolution but it does not "clip". the trade off is rounding error. this can be significantly accommodated with double precision math.

an example in 32FP is a division by .2 and then to multiply by 5. you won't get back what you started with. but in 64bit FP you will.

 

[kubeek]

I think that they mean that you have to try really hard to make something clip in 32FP.
For example in Cubase SX you can only add +20dB (= x10) in one step using Gain, so you would have to do it 38 times to get to the clipping region.
Would someone ever do something like that?

 

[pipelineaudio]

I know a little of how the floating point system works in reaper. But Im not very good at math.

IIRC correctly its got a mantissa of 52 bits, a sign bit, and an 11 bit exponent

If I'm doing this right that spells a 12,328 db dynamic range...pretty hard to clip *internally*.

You still would have to turn it down before sending it out to a real world converter, so there's an over indicator where the rubber meets the road.

 

[Sonixx]

I know a little of how the floating point system works in reaper. But Im not very good at math.

IIRC correctly its got a mantissa of 52 bits, a sign bit, and an 11 bit exponent

If I'm doing this right that spells a 12,328 db dynamic range...pretty hard to clip *internally*.

You still would have to turn it down before sending it out to a real world converter, so there's an over indicator where the rubber meets the road.

this is a totally different issue. now the conversion is to 16bit or 24bit integer where 0db is basically all bits on. internally, there is scaling so 0db has a meaning relative so when converted to 16bit or 24bit integer the conversion is correct.

as far as the 52 bit mantissa, this is for 64 bit FP (double precision). 32FP is 24 bit mantissa and 8 bit exponent.

 

[xstatic]

I think the Steinberg manual is referencing that the internal algorithm itself will not clip. What it does in real life down the road when it is inserted somewhere with an actual limit (like the master bus) then you will have distortion. The distortion however does not reside on the recorded file, but in the summed output. I think Steinberg could have worded it better, but I do not think they meant this to hold true on input, but more in the internal processing. It's kind of how you can let channels go well over 0 without hearing anything bad in your DAW but the master can't.

 

[pipelineaudio]

we did some tests in reaper of taking 32 identical -12dBFS sine waves, then turning each channel up till they were lighting the channel overs at +25

Then we turned down the master output till the peak read -12dBFS...the file rendered nulled with the original -12dBFS sine wave. To me that showed what the point was with what before I had just called 'numbers magic" into the practical realm.

 

[Sonixx]

What it does in real life down the road when it is inserted somewhere with an actual limit (like the master bus) then you will have distortion.

not as long as all math is FP. the only time you'll have problems is over 0DB and converting to 16bit or 24 bit integer... when outputting either a limiter or the DAC will set the top value.

 

[pipelineaudio]

How would this 32 bit floating point file represent a waveform accurately over (I think) +/- 750dB ?

 

[Sonixx]

How would this 32 bit floating point file represent a waveform accurately over (I think) +/- 750dB ?

what's 750db?

 

[SouthSIDE Glen]

I think the Steinberg manual is referencing that the internal algorithm itself will not clip. What it does in real life down the road when it is inserted somewhere with an actual limit (like the master bus) then you will have distortion. The distortion however does not reside on the recorded file, but in the summed output. I think Steinberg could have worded it better, but I do not think they meant this to hold true on input, but more in the internal processing. It's kind of how you can let channels go well over 0 without hearing anything bad in your DAW but the master can't.

Yeah, I think this is where it's at. Steinberg uses the phrase "in the recorded file" (they happen to be talking about recording at that time.)

OK I do understand the no clipping thing now, in that they mean that *locally* or *in the internal math* there is no clipping.

But it remains kinda meaningless in the big picture - and by big picture I mean in the context of overall gain structure. Pushing a 32FP signal past 0dBFS, while it may be mathematically possible, will still ultimately result in clipping and/or analog distortion in the rest of the chain.

Overall, this sounds in flavor to me a LOT like when the manuals for digital recorders recommend recording digital as hot as possible without clipping (in integral math.) It sounds like a good idea on a local scale, but when considered as part of the overall signal chain, it's not really all that wise.

G.

 

[pipelineaudio]

what's 750db?

If Im doing the math right, a 32 bit float has 1 sign bit, 23 bit mantissa and a 8 bit exponent, this could represent 8,388,607 to the 255th power

This works out to 1541dB, which I think signed would be +/-750dB

there are only so many numbers a given bit depth can represent, only so far an exponent can take you

There has to be a level at some point after which it becomes impossible to represent