Using 32bit Float Point

[reneo]

Nice discussion, but his files are still clipped...

You can try a decliner plugin. RX3 from iZotope contains an aax-declipper-plugin.

[dr_daw]

Originally Posted by JFreak

We need a new scale

+1 dBfp (floating point) :P

[DonaldM]

Originally Posted by reneo

Nice discussion, but his files are still clipped...

You can try a decliner plugin. RX3 from iZotope contains an aax-declipper-plugin.

thanks.. But it is helpful to understand exactly how this all is supposed to work.

[DonaldM]

I found this video that explains it nicely with a good demo. Shows exactly how 24bit just won't work.

So, here's what I'm wondering. Say I get a clipped audio track from someone and its 24bit, and they did it in Pro Tools. Could they re-export the clipped track as 32bit and send to me and then I can fix it as shown here by importing it as 32bit? Or, is it the case that if originally recorded as 24bit, you're sunk? From the video, it looks like he exported the same track, once as 32bit, and once as 24.

Seems like that if someone sends a track that is clipped and they have the option to export at 32bit, then having them re-export it at that would allow you to fix the problem more easily. Am I right in thinking about it that way?

[Darryl Ramm]

[QUOTE=DonaldM;2165540
Seems like that if someone sends a track that is clipped and they have the option to export at 32bit, then having them re-export it at that would allow you to fix the problem more easily. Am I right in thinking about it that way?[/QUOTE]


We've been over this same question multiple times. so final try... If somebody sent you a file that was clipped on input that data is gone/the signal is damaged forever. Having them just convert the output file to 32 bit float will not help *at all*. And would be the same as you can do yourself to their fixed point file, won't make any difference.

The above is what I am assuming happened here, but If they did not clip on input but rather got things too hot during mixing or plugin processing and wrote out a clipped output... then yes you may be able to fix things by having them write out a 32 bit float file instead and then have you deal with pulling down the levels. (but we don't really know what you have, what was done to it, and with what exact daw/audio engine.). If they monkeyed with the recording in a DAW like that them you can always just get them to remix/reprocess things less hot or just give you their entire session/all media files.

Either way you probably want to slap hard whoever gave you the file.

Tools like iZotope RX just try to repair the sound, it is impossible for them to actually recover the missing/clipped data. They can do well, through to sounding awful. Can you fix the problem at the source should always be the first question. The next is to grab a RX demo and see if it can do a good enough job for you or not. And in this case are you willing to pay for iZotope RX plugins? there are also their plugins that can do this YMMV.

Mmmm, did I mention slapping somebody? OK, yes I did.

[mesaone]

Just reading through, I noticed someone asked why DAWs don't show >0 dBFS metering.

Pro Tools actually does show levels above 0 dBFS. Check the peak readout below the meter. You can push it pretty far. Here's an image where I've taken pink noise and boosted it to +120 dBFS (running to a bus, with the monitoring system turned off). Of course this is only possible when the boosting is done in the mixer, in this case pink noise rendered to 0 dBFS with two Blue Cat Gain plug-ins in series with the knobs set to +60 dB.

Some metering plugs max out at 0, +6, or +10 dBFS. But the Pro Tools meters and HOFA 4UMeter can read anything I put through it.

[JFreak]

Well at least for now, we need metering that can show us what happens at the DA converter. Whatever happens within the mixer is another story.

[JFreak]

That familiar -1 ... +1 is just a representation of a signal that we assume being kind of a sine wave that is centered to zero.

In reality, digital fixed-point signal goes from minus infinity to Full Scale, with the absolute maximum at 0dBFS going down as far as the bit resolution permits. With 16bit signal the all-zero signal is roughly -96dBFS and with 24bit signal the all-zero signal is roughly -144dBFS, and so on.

That signal is later on represented around the zero to connect us with the analog domain.

[Top Jimmy]

Originally Posted by kdarbyshirebryant

Linear PCM integer coding of audio (usually) uses two's complement binary notation for sample values. 2^16 gives 65536 different values, thus 16 bit audio samples are represented between the range -32768 (negative full scale) and +32767 (positive full scale) with zero representing zero!. The most significant bit is used as the sign bit ie. positive of negative leaving 15 bits to code the value. 24 bit linear integer PCM coding is similar, 1 sign bit, 23 value bits. -8388608 (negative full scale) to +8388607 (positive full scale).

So if you put two and two together. 16-bit PCM encodes 16-bit peak to peak, but silence to full-scale is only 15-bit. Even though we often use simple math and say we have 96dB of SNR, the truth is we only have about 93dB peak to quantization error.

[JFreak]

Originally Posted by Top Jimmy

So if you put two and two together. 16-bit PCM encodes 16-bit peak to peak, but silence to full-scale is only 15-bit. Even though we often use simple math and say we have 96dB of SNR, the truth is we only have about 93dB peak to quantization error.

It is not so. PCM is all about minus infinity between 0dBFS which means all samples =1 is 0dBFS and whatever bit depth you use determines how many minus dBFS you have below the absolute when you have all-zeros sample.

16bit = 96dB
24db = 144dB

This is fixed-point only.