Topic: 32Bit Float recording - The Technical view

[Dan33185]

Just bought a 32 bit recorder for this first time, and had a question. If I'm recording at 32-Bit, and then downsample to 24 or 16-Bit for distribution, will that introduce clipping because of the limitations of those 2 bitrates?

[commongrounder]

If you are planning to use the recording as-is with no other processing, then all you need to do is perform a level normalization to set the peak level to maximum 0dbFS, and add dither if truncating to 16-bit. If you are performing any EQ or other processing, do that before you do the above. BTW, this is not downsampling, which is changing the sampling *rate* (frequency). Rather you are changing the sample bit *depth*.

[voltronic]

If you are planning to use the recording as-is with no other processing, then all you need to do is perform a level normalization to set the peak level to maximum 0dbFS, and add dither if truncating to 16-bit. If you are performing any EQ or other processing, do that before you do the above. BTW, this is not downsampling, which is changing the sampling *rate* (frequency). Rather you are changing the sample bit *depth*.

Just my 2 cents: I always set max level to somewhere below 0dBFS because you run the risk of inter-sample peaks clipping. If you are using software that measures "true" peak level then it is set up to detect these.

The term for lowering the bit depth is decimation.

My favorite tool for any jobs of this type is iZotope RX, FWIW.

[Gutbucket]

Correction to Voltronic, the word you are looking for is "truncation" (discarding excess bits), not "decimation" (which is a step in sampling/resampling)

If I'm recording at 32-Bit, and then downsample to 24 or 16-Bit for distribution, will that introduce clipping because of the limitations of those 2 bitrates?

As commongrounder mentions, what you describe is not resampling, but a truncation of bit-length or bit-depth.  That is to say, a lopping off and discarding of the least-significant bits. 

Doing that can introduce clipping (or noise), but won't if you do it correctly.  In essence you are moving the content from a very sloppy fitting larger "container" to a better fitting smaller one.  So yes, you need to make sure it fits.. AND is positioned correctly inside the new container.

As covered in many of the discussions here at TS about "32-bit float recording", not only will all of the live music recordings we make already fit comfortably within 24bits, anything that can possibly be recorded successfully by any of the 32-bit recorders folks are currently using will also fit in a 24-bit "container".  The musical content itself and everything we want to hear will always fit within 24bits. 

However, because 32bit recording (or more accurately, the auto-switching ADCs schemes used in "32-bit recorders") delays the need for proper level setting until after the recording has been made, that musical content is likely to be shifted way up down in level, so its level needs to be adjusted prior to listening and/or conversion to a 24 or 16bit file format. Normalizing is the "doing the level setting afterward" part.  There is no need to try and push it as close as possible to the limit by normalizing the highest peak all the way to 0dBfs. It's safer to normalize to a little less.  The exact value doesn't matter.  -1dB or -0.5dB is fine. 

The next step after normalizing is the bit-reduction truncation.  Whenever bit-reduction is performed it is always best practice to add a bit of dither (random noise) at a level just a tiny bit louder than the truncation value.  Doing so essentially "smooths the sharp edge of the cut" eliminating quantization error.  Even though that error is very low in level and probably not audible at all in a music recording, if made loud enough to be heard, quantization error noise sounds terrible, so a tiny bit of very low level random "hiss" (dither noise) is preferable.  It may not be absolutely necessary to dither when reducing bit-length from 32-bit floating point to 24-bit fixed, in the same way that its not technically necessary to do so when reducing to 16-bit, but it is still best practice.  So.. always dither whenever reducing bit-length. Its easy enough to do the right thing (usually by just checking a box to apply it).  Don't worry about fancy noise shaped dither. Standard "triangular dither" (TPDF) is fine.. and is preferable if further processing might be done.

[Ozpeter]

I'll throw in that normalisation is sometimes a built in function with 32 bit float devices (eg the Zoom H1 XLR, Zoom M2 & M3).  I doubt whether anyone has yet tested the matter but I wonder whether normalising within the device is any better or worse than normalising outside the device (which does usually have the advantage of the user being able to select the maximum level).  I guess I could test myself to see whether an in-device normalisation actually does the job to (say) -1dB rather than 0dB or thereabouts.

[Gutbucket]

^ Would be cool if they included an internal function that would both normalize the 32bit float file AND produce a 24bit file from that on the recorder itself, streamlining post work where desirable.  Sound Devices should be able to do that easily since the MixPre IIs already have the capability of supporting internal mixdown to a new file, I believe.

[Dan33185]

Ok, so I use Reaper these days for mastering, if I do all my EQ in that, and then normalize to something around 0 or below before I render it from Reaper in to a 16 or 24-Bit file, I should be ok at that point is what I'm understanding.

[Gutbucket]

 

[rocksuitcase]

If you are planning to use the recording as-is with no other processing, then all you need to do is perform a level normalization to set the peak level to maximum 0dbFS, and add dither if truncating to 16-bit. If you are performing any EQ or other processing, do that before you do the above. BTW, this is not downsampling, which is changing the sampling *rate* (frequency). Rather you are changing the sample bit *depth*.

Just my 2 cents: I always set max level to somewhere below 0dBFS because you run the risk of inter-sample peaks clipping. If you are using software that measures "true" peak level then it is set up to detect these.

My input: Ever since I read voltronic say this some years ago, I started normalizing to -.2dBFS

[commongrounder]

Darn! I go away for a few hours and miss a bunch of great discussion! I always appreciate gutbucket’s well worded explanations of the technical aspects of our craft/hobby. Thank you. Indeed, I never actually normalize right up to 0dbFS because of the mentioned inter-sample clipping possibility. I have the normalize function in my Wavelab setup dialed to -0.2dbFS. I should have made that note in my post.
Dithering of 32-bit float to 24-bit fixed is an interesting subject to me. I have chosen not to dither in this situation because the audio content inside the 32-bit float container is already very close to 24-bit in depth. Going to 16-bit will truncate a significant portion of the low level content so dithering is appropriate here. I’d be interested to hear other opinions about this (admittedly obscure) subject.

[Dan33185]

Sorry to bombard this thread with questions...just received my new toy today and am exploring the menu options. Most are pretty self explanatory, but I am unsure on which Sample Rate to use? 44.1, 48 or 96?

[grawk]

48.  There's no chance your mics are more resolving than that.  If you eventually want to do something like recording bats, and slowing them down to listen to, and you get ahold of some appropriate mics, 96 will help.

[Gutbucket]

[snip] Dithering of 32-bit float to 24-bit fixed is an interesting subject to me. I have chosen not to dither in this situation because the audio content inside the 32-bit float container is already very close to 24-bit in depth. Going to 16-bit will truncate a significant portion of the low level content so dithering is appropriate here. I’d be interested to hear other opinions about this (admittedly obscure) subject.

Thanks for the kind words.  Is it really necessary? No. Not at all. I'm not making the argument that it is. Only that its easier to just always dither and not bother oneself further about when it is or isn't necessary.

It is almost totally assured there is nothing but random noise down there at the 24bit truncation point, because after normalization the meaningful audio data isn't close to that cutoff point.  That's the whole point of the music fitting comfortably within 24bits - we aren't loosing any useful information by down-sizing into the 24bit container.  And.. if there was meaningful audio data down there, say some sort of still audible reverb tail decaying past the truncation point (which could never actually be heard except with a super quiet recording along with an impractically large amount of amplification - its never going to happen in a live music recording), the random noise that the reverb tail was decaying into would probably serve the same purpose as dither noise in eliminating quantization-error.   So yeah, in reality there is no need to add a couple dB of additional noise down there with the application of dither. 

My reasoning is more about just getting into the good habit of always dithering when reducing bit length, because its never the wrong thing to do, rather than making a special exception to that just because it doesn't really matter in this particular case.

[Gutbucket]

48.  There's no chance your mics are more resolving than that.  If you eventually want to do something like recording bats, and slowing them down to listen to, and you get ahold of some appropriate mics, 96 will help.

I'm with grawk on this too. Some will argue that higher sampling rates are beneficial for post processing, to which I say ok then use the oversampling function that is built-into most modern post processing effects and crank it up to 8X or whatever your computer resources can handle comfortably.  There is actually a good argument for not recording a bunch of ultrasonic content (which recording at 48 automatically achieves), or actively filtering out any ultrasonic content that's already present in material that was recorded at a higher sampling rate, prior to applying post processing with oversampling.

Fun to record bats and bugs and slow that down into audibility though.  Always exceptions in certain cases.

[Ozpeter]

The M2 does have the facility to normalise and export to lower bitrates all in the recorder.  It can also normalise on the fly during playback.  I would lay money that the H1 XLR will work the same way.  I have probably posted this before but here is a crude test I did recording 'silence' at night in the garden, normalising it in the device, and the recording low level speech for comparison.  I do recommend listening to all of it and noting the explanation that shows as it plays, without which completely the wrong impression might be given, but it's less than 2 minutes long.

https://youtu.be/Fb1r11dYpUY?si=5SyqVQzpWx5ZWwr6