Is 32 bit float better than 24bit?

I recorded a song with 32 bit instead of 24bit and it sounds so much clearer. Is this real? Or am I just hearing things. Does 32 bit sound much better than 24 bit? Or and will they ever make a 32 bit soundcard?

Just means you have more dynamic headroom. I’m sure we’ll see 32-bit interfaces in the future

Make no difference what so ever for recording and general work, your interface is no doubt 24bit so recording in 32fp will just result in the 32bit word being padded out. Of course Cubase works at 32bit fp throughout regardless of project bit depth setting, but that is a different matter, once you start to use any form of DSP whether a volume change or a convolution reverb then 32fp is of major advantage.

Where the difference can be noted is if you use any form of plugin on the input channels or take the input faders away from unity. Also any process within Cubase that results in a file been written to disk e.g Bounce, Offline processing will also utilise the project bit depth.

You will have no more “dynamic headroom” than using a project at 24bit on recording as that is a function of your A/D converter(soundcard)

Thx for info. So the plugins won´t sound better when added on the insert in 32bit float mode? So what is the point of 32bit mode. I find it strange that noone makes a 32bit soundcard at least Steinberg.

The 32 bit comes in when talking about masterbus/summing It is a final stage in the mixbus architecture.

Cubase does all internal processing in 32bit float.

Would like someone from Steiny to chime in, here, about this. As far as I understand, everything is internally converted in 32 bits float, even if your project audio files are in a different format. Fine. But this leaves two questions :

  • Is the conversion process taxing the responsiveness of the whole Cubase application (i.e. by adding a little more latency) ? And if so, wouldn’t it be better to leave the choice to the user to do all the internal audio processing at the same format as his project audio files (16, 24 bits…) ?

  • What’s the point for the 32 bits float format (aimed to give us more headroom, if I understand well), if you have to convert it again to 16 bits (or 24) at the export stage, with all the inherent problems levels wise, dithering, etc. ?

What I do is putting all my projects to 24 bits : I think it’s a good compromise between my audio interface resolution, S/N ratio, headroom and disk performance (both space and activity related). But I may be wrong, and this has got me thinking about it more than once, thus my two questions.

By the way, I still love what’s in my 16 bits CDs collection… :mrgreen:

Yes, but that latency is neglible. One core of my DAW is capable of converting approx 100 000 000 intgers to floating-point and back to integer in one second (and this is with scalar procsessing, no multimedia instructions used). So I would need hundreds of 96k tracks to have any significant processor load.

No. You always should have more bits involved in digital processing than in storing. Otherwise the rounding errors will quickly reduce your audio quality.

First point you already got: headroom. Second point: ability to process signal without loosing quality.

It’s not a compromise. 24 bits are more than your A/D converters are able to produce. They might claim to be 24-bit, but in reality they produce 21-23 bits of significant information.

Why? 24 bits are already close to the point where Johnson–Nyquist noise comes into play.

Hi, Jarno, and thanks for this. At last, a clear answer about all this…

Last question : according to what you said, I guess that the 24 bits audio files format choice is relevent, or I am wrong ? If I understand well, no need for 32 bits float audio files, as there is no significant latency added…

Thanks again.

Exactly. 24 bits is as much as we should EVER need. It gives 144dB of dynamic range. That’s 24 dB more than 120dB which is traditionally quoted as human ear’s dynamic range.

Thanks again, Jarno.

All the best ! :slight_smile:

One reason to use the 32bit file format would be when you pass your mix to the mastering engineer. This avoids the need to dither, which should be the very last step and therefore should be done at the mastering stage, not before when you export your mix.

Another reason would be offline processing, where you export a track for some external processing and then re-import the track again.

Excuse me, but I have to disagree. With 24 bits you have 144dB of dynamic range. Difference between lowest sound you can hear and the one that causes pain is approx 120dB. So you still have more than 20dB to play with in mastering/processing for. If your mastering engineer is going to squeeze dynamic range by more than 20dB, it sounds like Metallica, anyway. And if he/she has to boost some frequency band 20dB, the original mix is just crap.

Only places you need more than 24 bits are:

  • processing of audio (to minimize rounding errors from multiple processing stages to accumulate)
  • internal path of your DAW (only because it’s more confortable to have that extra headroom/accuracy instead of having to constantly think about gain staging)

I may point out again that having Cubase set to 32fp does have some advantages.

Please refer to my first post in this thread. If doing repetitive off line processing or other procedures that require Cubase to create new files on disk then using 32fp is the preferred setting.

Also if creating an intermediate file to use later in Cubase or another 32fp application it would be better to export at 32fp to avoid multiple conversions.

I actually agree with Roland here, and he has a good point. Common practice says we should avoid dithering as much as possible and keep files at their highest resolution until the end, which is the Mastering stage. Going from 32 bit into 24 bit “requires” dithering, as there is a reduction of bits where rounding errors are introduced. Whether you’ll hear a difference or not, that is where people differ in opinion. I personally like to have the peace of mind that I am working at the highest resolution all the way till the end. YMMV.

We had an interesting discussion about this a while back and the conclusion was that the UV22 offers shaped dither that should only be applied once at the very final stage. Although dither should be applied whenever the word length is changed it should be non shaped noise if you know that further bit reduction and dither is going to be applied at a later stage.

Split is right.

Any type of noise shaped dithering (i.e. UV22, POWr-3, MBIT+, etc) should only be applied as the very last step in the Mastering chain. But non-noiseshaped dithering (i.e Triangular) should always be applied any time bit reduction occurs. Seems like you and I agree on that.

That’s why I was saying that some people disagree with this and they find that, even at 24 bit, the resolution is high enough to void the merits of using non-noiseshaped dithering. This maybe true in some cases, like when working with a single (or few) stereo files. However, it could become a problem with a greater number of files. I think that dithering is a lesser evil than the effects of rounding errors due to truncation, and it actually increases the dynamic range. However, this doesn’t mean we should be care-free about applying it, since any type of processing degrades the quality of the files. The less we process, the better the quality.

Take care!

Work at 32 bit internally at all stages. Only dither down to 24bit and 16 bit at the mastering stage. I deliver mixes to mastering engineers in 32bit files. It just means with plug ins processing and all that, there is nothing to think about. You have virtually unlimited resolution for all practical purposes.

I would like to challenge anyone to have blind A/B test on hearing 0.0000126% distortion (rounding errors of 24-bit processing).

And I also have to remind you that 32-bit floating point doesn’t have more precision than 23-bit fixed-point (when using IEEE floating-point standard with 23-bit mantissa). It’s just gives you the precision within extreamly wide gain-range.