Repeated processing/render operations can potentially lead to an accumulation of quantization noise which results in an audible difference between 24 and 16 bit.
This problem is rare, but it’s good practice to avoid it by giving yourself more dynamic range by using 24 instead of 16.
Actually not quite. Yes, some data is lost during encoding. However, also some data might get lost during decoding, ie. importing an MP3 into Cubase, thus converting it into a PCM file. And decoding to 24bit or even 32bit float (MP3s are using 32bit float) might yield a better result than 16bit, depending on the source material. But this is probably not noticable in most cases for most people, so I advised @alin89c to just go ahead with 16bit.
If you convert audio from one bit resolution to another is that still called quantization noise?
Anyway, in order to circumnavigate such issues I recommend to use the same bit resolution as the one the audio engine is running on, ie. either 32bit float or 64bit float.
Any files that you create for usage in the production (or even for sending to another studio or mastering engineer) ought to be saved in floating point format. This way you avoid any signal degradation.
It should be noted though that quantization noise is not white noise, nor does it necessarily sound like it. Since the distortion is correlated with the signal it sounds like the signal is distorting which is very different from white noise. That is why we dither signals.
So I think that part is just wrong.
That isn’t correct, or at least the way you were wording it isn’t.
The headroom in processing comes from the audio engine and how it operates. In Cubendo it’s 32- or 64-bit float. Absolutely massive headroom. You could load an 8-bit file and still have enormous headroom for all signals within the DAW.
The bit depth of the recorded audio translates to possible dynamic range of that signal, the difference between peak and noise floor. I don’t think we would call it “headroom”.
If we’re using the term “headroom” when recording then I would take that to mean the difference between the peak of the recorded signal and 0dBFS (@ 16 or 24 bit fixed). But that is slightly different.
I don’t think that’s really true. If memory serves me correctly the 32-bit float file contains two chunks, one of which is for the signal that originated as fixed point. That means the 24-bit file is effectively the same resolution “within” the 32-bit float file.
So unless the A-D conversion allows for 32-bit float with an actual and true dynamic range larger than 144dB there is nothing to gain in terms of resolution. It would still convert to a 24-bit dynamic range signal and save that “within” 32-bit float.
(The “fraction” or “mantissa” is where the 24-bit signal would go. The exponent would be used to ‘float’ the signal/fraction and give the total dynamic range.)
When the conversion is to a lower resolution, yes.
Yes, you’re correct at normal audio levels. In other words, under normal circumstances, the advantage to 32 bit float file format in your project settings can be considered to be the headroom, not the dynamic range.
There is no AD conversion when you create a file digitally (DOP, Bounce Selection, Render-inPlace, Audio Mixdown, Convert Sample Rate/Bit Resolution). We were only talking about this part, not the recording (analog to digital domain).
You are not gaining resolution by recording at 32-bit float compared to 24-bit fixed. The 24-bit signal itself, i.e. the sound we captured one way or another, isn’t described with any more detail in 32-bit float because it lives entirely within that mantissa, within the “fraction”. It does not “extend” and become a “larger” signal. Instead the signal is scaled up and down by the exponent.
Ah, sorry.
It’s the other way around. You can potentially lose resolution with 32 bit float, depending on the amplitude.
Explain.
That’s the fundamental difference between integer and floating point formats. The incremental amplitude difference between adjacent values never varies with integer. With floating point, it depends on the exponent.
Yeah, but only in levels where 24 bit integer can’t go in the first place.
Yes, that’s what I said above. But the point remains: the primary advantage to 32 bit float over 24 bit integer is headroom, not quantization noise.
I think we agree. A lot of people would probably look at the signal path as having a much wider dynamic range, and because of that the headroom before clipping (or getting into trouble) is larger. In other words they too are not talking about quantization noise but the absence of clipping.
I think the quality differences when importing an MP3 into Cubase at different resolutions are not worth worrying about. Even high-bitrate Mp3 is a highly compromised format. 16 bit PCM will capture the recording fine, as long as you make sure the signal peaks are not too low.
However, choosing the word length to use for audio files in Cubase is a different question.
As disk space is cheap, I’ve started storing audio files at 32 bit float. Cubase does not dither when it freezes a track or renders in place to 16 or 24 bit (or at least I think so - I’m happy to be corrected).
So, why not use 32 bit float where dither is not required (the concept does not exist) and remove any quantization distortion? According to Hugh Robjohns of Sound on Sound, quantization distortion can just about be audible even with undithered 24 bit PCM if there are rapid fades in and out.
The latest generation of audio recorders store data at 32 bit float to remove the need to adjust gain of signals into the AD converters, so over time I think 32 bit floating point will become a common format for recordings and DAW audio files.
Using 32 bit float as the project file format is a fine idea. But, just so nobody gets the wrong idea, using 32 bit float as the audio interface format makes no difference to gain adjustment. You’ll still need to adjust the gain to avoid clipping the same way you’ve always done with integer. It’s just a different file format to be used for the output of the A/D converter.
That’s interesting, Glenn.
I didn’t think it was possible to clip the converters themselves given the headroom of 32 bit float above 0dBFS. Obviously any pre-amp circuitry could be driven into clipping, but I don’t think that’s what you meant.
If you look at the Sound Devices converters they are set up to not clip. I can’t recall how they did that but that’s basically the main selling point.
I’m just saying 32 bit float devices don’t eliminate the possibility of irretrievably clipping your audio. Adding 32 bit float support to the digital side doesn’t change the basic physics. The analog part of the converter still has a finite voltage range. Send 10V P-P through it and it will clip. I have to be careful with my 32 bit float Rode, just like any other A/D converter.
