32 Bit Floating point issue

Seems to me your best option will be to pre-process your 32 bit floating point source material into a good quality 24 bit file, with any hot transients brought down. I know it sucks to have that extra step, but any professional audio application will have to support 32 eventually so we can expect it in Fairlight some day.

Also, 16 bit audio is an ancient relic from the days of the TRS-80 and Commodore 64. After working with 24-96 or 24-192 for a while "CD quality" sounds like nails on a chalkboard, even with the best antialiasing. Although, all the work we put in to getting great audio is often destroyed when people pack it down to 128k MP3s or worse.

... So this 32-bit range is mostly for convenience when in the digital realm, but even when using these devices that can record to 32-bit files we're still left with reality. So unless you're literally recording spaceship rocket engine liftoffs or huge explosions nearby you're never ever going to need the range that even 24-bit fixed provides you with. It really only boils down to being able to be less careful with setting gain when recording and avoiding clipping...

Mattias, this is the paragraph that I was addressing in my post that tried to remind folks how easily audio can be clipped in reality due to the unexpected levels that sometimes are not accommodated by a sole operator. You can easily clip 24bit audio in practice without exceeding the maximum possible decibel range of 24bit audio due to where you’re starting your capture levels. Peace.

... So this 32-bit range is mostly for convenience when in the digital realm, but even when using these devices that can record to 32-bit files we're still left with reality. So unless you're literally recording spaceship rocket engine liftoffs or huge explosions nearby you're never ever going to need the range that even 24-bit fixed provides you with. It really only boils down to being able to be less careful with setting gain when recording and avoiding clipping...

Mattias, this is the paragraph that I was addressing in my post that tried to remind folks how easily audio can be clipped in reality due to the unexpected levels that sometimes are not accommodated by a sole operator. You can easily clip 24bit audio in practice without exceeding the maximum possible decibel range of 24bit audio due to where you’re starting your capture levels. Peace.

Yeah I know all that. That's why I wrote the last sentence you quoted.

And I was responding to this: "32 Bit Float allow to create huge volume adjustments not only during recording but also during any other workflow step". He'd tested lowering the level by 150, 130, 100 dB and so on. Yes, that's "huge", and it's something we also essentially never ever do in fixed point.

Re-read what I wrote.

OK.

Doesn't change what I wrote. With 32 bit float, I'm freed from certain constraints during filming.

Muck like shooting in RAW, I am freed from the need to set white balance before rolling, because I can simply change it in post without degradation.

It’s a great idea to use 32bit audio when you are not a dedicated audio recordist where it is completely possible you can fail to predict the best starting place for your recording and the maximum level of sound received in the recording.

Precisely.

For the last time: Nobody is disputing any of that...

I think the most universal compromise way to deal with 32 bit files is to normalize them in Reaper, Soundforge, Izotope RX, and export with preserved Timecode in same 32 bit float depth.
In this case you can work with file in Resolve and same time you keep your actual 32 bit source data untouched, so it may be useful for other apps, plugins or some future proof delivery options that may take advantage of 32 bit float extended dynamic range.

That's the plan for now then, I guess. Not sure I can stomach going back to premiere.

Go use the Zoom F6 and try it yourself. Its brand new technology, so any of your old ways and best practices dont apply anymore.

Until you actually use the zoom F6, any of you with a million years of experience have no idea what youre talking about. And yes I will say it bluntly like that.

I think most people in our industry embrace new technologies. However, they're just another "tool in the box" which can yield good results when used with a base knowledge & foundation in the area for which the "new technology" is applied...

It's the education and practical "experience" (which you crap on) that determines how well "new tech" impacts the final product... In the case of 32bit float - It won't save you from poor mic placement or other deficiencies in technique during acquisition (hence the knowledge & experience).

That said, healthy discussions over the "specs" and practical application is good thing - It's how we bounce ideas off each other, it's how we continue to grow... But.. To put it "bluntly", making a blanket statement sh*ting on many years of experience & the combined knowledge base here is simply counter productive... It's that toxicity which makes people less likely to help out in the future (just sayin - ).

For the last time: Nobody is disputing any of that...

But you aren’t convinced it’s important for Resolve to give it some priority.

Sorry this is turning into a sad battle. Let’s just let this go because we all respect that different people have different opinions and we’ve all stated our arguments and Peter calls the shots and has heard all of this.

I’m not going to contribute any more than I have and hope the thread doesn’t go thermonuclear as people become more entrenched and defensive rather than understanding and respectful.

I wasn't able to find a single IMDB credit for him.

I didn't say he works in film or television. I just said professional sound man. He records sound for a living. Clients hire him to record sound for their projects.

He's a professional photographer.
Not a professional soundman.

For the last time: Nobody is disputing any of that...

But you aren’t convinced it’s important for Resolve to give it some priority.

.

Becasue it's not a priority.
There are a lot more things that need to be changed first, to make it even a useful tool for any kind of audio editing and mixing.

For the last time: Nobody is disputing any of that...

But you aren’t convinced it’s important for Resolve to give it some priority.

I don't recall having said anything regarding priority.

.

Muck like shooting in RAW, I am freed from the need to set white balance before rolling, because I can simply change it in post without degradation.

And I disagree. Setting the white balance correctly, defines how you set everything else like, aperture, ND filters etc.

Wanted to throw in my hat here in asking for 32-Bit float support in Resolve. I own the MixPre-3 and would love to have it supported in the program.

Can we make sure this is implemented soon?

Please!

DaVinci Resolve 16.2 Codec improvements:
• Support for decoding 32 bit floating point audio.

Very good to see this addition. Thank you BMD!

Very happy this was added quickly!

Seems it really works well. But when you decrease volume on 32 bit audio file - visual representation of waveform always looks clipped. Not too pretty looking.

That’s not right of course. Maybe something to tidy up in the display, but hopefully the actual audio output doesn’t sound clipped!

Dmitry is right. Sort of a bummer.

I just made a video about this:

As you can see, when you decrease it, it still looks clipped. It definitely works (again, as outlined in my video), but the visual representation is potentially confusing.

I agree it’s misleading as you search for areas that need further adjustment. I’m sure this will be corrected shortly. I wonder if the normalize function also shows the same ‘clipped’ look or just when you manually adjust the levels.

Correct me if I'm missing something here.

Recently I've been recording into my macbook with a cheapo rode lav for some instructional videos.
I have the option for 24bit or 32bit float.
Adjusting the input level in system preferences, I can either have it on max where I have a nice apparent clear level (but it will potentially, occasionally clip), or I can dial it down a little bit where it won't.

I was under the impression that the louder the volume is above the noise floor, the better, especially if I am wanting to perform some compression or what have you.

Under these circumstances suppose I yell into the mic.
If I record at 24bit, it clips out occasionally at 0dBFS.
If I record at 32bit float I can recover the yelling parts in audition.

How is it that 32bit float is not desirable in this case or any case?
Is the reference point and noise floor the same or are they different?
It seems to me, the layman, that one option gives you extra range and one doesn't.
Can someone explain this?

Correct me if I'm missing something here.

Recently I've been recording into my macbook with a cheapo rode lav for some instructional videos.
I have the option for 24bit or 32bit float.

Are you sure that macbook really allow record to 32 bit float?

Anyway you need dual or triple stage A/D converter as well as dual or triple stage mic preamp to capture all dynamic range of the mic.
Just recording something to 32 bit float recorder line-in will not add any real dynamic range.

In MxPre3II you can just record at 32 bit and don't care about clipping anymore. You can bring back all hidden data in post.
In 32 bit all limiters, compressors, other tools and plug-ins will see all data above 0db and will bring it back to normal range.

Just remember, you can still overload the analogue stages of your A to D converter, so you will end up with a 32bit distorted signal.
Here's a link explaining 32bit float.

https://www.sounddevices.com/32-bit-float-files-explained/

I was under the impression that the louder the volume is above the noise floor, the better, especially if I am wanting to perform some compression or what have you.

That's not correct. You need to be sufficiently above the noise floor, but louder isn't automatically better.

If I record at 24bit, it clips out occasionally at 0dBFS.
If I record at 32bit float I can recover the yelling parts in audition.

How is it that 32bit float is not desirable in this case or any case?
Is the reference point and noise floor the same or are they different?
It seems to me, the layman, that one option gives you extra range and one doesn't.
Can someone explain this?

In addition to what Charles just said, that you can still clip the analog stage before the signal turns digital, Dmitry is basically hinting at another difference: There's a difference between how a digital signal is 'encoded' (for lack of a better word) and on the other hand how it is saved. I'm betting most interfaces that convert will do so to a maximum of 24 bits, and this is different from how your software then decides to save that signal. If you have the option of saving to 32 bit float, in most cases what will happen is that your interface converts to 24 bit fixed and your software will save that as 32 bit float. So you're not really gaining any headroom during conversion.

In other words;

You could still distort in the analog domain before conversion.
You could still clip when converting and not be able to recover that signal.
Even though you're storing at 32-bit float.

Best practice is to always stay away from peaks at 0dBFS.

And I reiterate what I mentioned in another thread: I honestly dread the day that I begin seeing clipped audio that I have to lower in Pro Tools or Nuendo and that becomes the new norm. It'll be more work for me (certainly with no more compensation to go with it) and the potential for accidentally pressing play and getting a bunch of 0dBFS signals blasting over my speakers / headphones.

I understand the convenience of this recording format, but like I said, I think there's more to consider within the larger context.

+1

Mattias, not disagreeing with your recommendation but I would think the argument that your software is converting to 24bit fixed and saving that as 32bit float must be incorrect or your software in question isn’t taking advantage of the 32bit float capabilities. Not that I know what’s happening, but it’s fraudulent software if it’s not recording different values for the exponent depending on the loudness received from the analog-to-digital circuits which are recorded data 32bit float. My reading of what Sound Devices dies is that the exponent varies if needed to preserve the full dynamic range available to it. Otherwise there is no point beyond marketing.

I didn’t write the code so I can’t tell you it definitely varies the exponent as needed but anything else seems implausible or they wouldn’t be able to demonstrate ‘saving’ audio that would otherwise be clipped in 24bit fixed.

DaVinci Resolve will write 32bit audio, presumably they write 32bit float with variable exponent, but I suppose it could mean 32bit binary (sorry haven’t looked in the manual to see if that is made clear) which may well be enough information to handle any loudness range we would likely require on Earth above what 24bit binary can do.

Rick,

Before I get to my reply - if my memory serves me the post I was responding to was actually an original post in a new thread, created by Ben Helweg. That thread had nothing to do with the device(s) we were talking about specifically in this thread that convert to 32-bit float. I'm talking about this one:

viewtopic.php?p=626949#p626949

Hopefully with that context what I wrote is more clear.

Mattias, not disagreeing with your recommendation but I would think the argument that your software is converting to 24bit fixed

I don't think the software is doing that, I think it's the hardware that delivers whatever it is capable of via drivers to the software. And most converters aren't capable of converting to 32-bits, either float or fixed. So the output of the converter is going to be at most 24-bit fixed in most cases.

and saving that as 32bit float must be incorrect or your software in question isn’t taking advantage of the 32bit float capabilities. Not that I know what’s happening, but it’s fraudulent software if it’s not recording different values for the exponent depending on the loudness received from the analog-to-digital circuits which are recorded data 32bit float. My reading of what Sound Devices dies is that the exponent varies if needed to preserve the full dynamic range available to it. Otherwise there is no point beyond marketing.

Yes, but the Sound Devices is a.. well.. device, not a software interfacing with a device.

Once a signal has been converted to one fixed point value I don't really see how you can extrapolate what is no longer there. So if the converter outputs a 24-bit fixed signal there is then nothing the software can do to gain anything back, and that includes storing it as 32-bit float. It's essentially going to be the same 24-bit signal (clipped or not) stored within that 32-bit float file.

The reason a software could still save 32-bit float despite not receiving that from a converter is that for a long time most DAWs operated at 32-bit float internally when doing summing. So stored 24-bit fixed files would be converted on-the-fly to 32-bit float, get processed, and then get converted back to 24-bit fixed for output to the converter again so we could hear it. So since the internal working size is 32-bit float it actually makes some sense to allow for files to be stored as 32-bit float as well. You could for example imagine a case where you process files and you want to interchange them with another person using a different computer. By storing that processed file as a float file you retain whatever it is and lose nothing from conversion (not saying any "loss" is of significance either though). But this would most often still be a 24-bit input file, processed and stored in 32-bit float 'temporarily', and then in the end get output in fixed format again.

Since the OP was talking about a consumer device, and we have to take into account the tremendous amounts of converters out there for anything from phones to TVs to laptops to professional converters, it most likely was a converter that output a 24-bit fixed point signal. That is a different thing from how a software then decides to store it.

Looking at it from a different perspective:

- I've seen very few converters over the past 20 years advertising 32-bit conversion, either fixed or float, and surely they would have if they were capable of it... and

- I've seen the ability to store audio files at 32-bit float for at least a decade or two, and that thus wouldn't have been possible without either a) the previous point being wrong, or b) the gist of what I'm saying being true.

PS: Sorry for all the words...

Thanks for those remarks. I wasn’t quite appreciating the context. Appreciate your patience.

n/p, I think we're in agreement.

URL not allowed so Google on "Over/Under in 32-Bit Float" and check Sound Devices article.
Quite clear you can mistreat the gain (i.e. forget it) and normalize with lossless result in (32 bit float supported) DAW's
Understood this topic covered the analogue part before A/D step but I guess with most common mics + recorders supporting 32 bit float today, this is a non-issue.
Using myself a Zoom F6 (always set in 32 bit 192kHz float) and 2 Line Audio Design CM4 mics with amazing results...I never bother the gain (always set 2 o'clock, i.e. +20dB in-between -60 & +60dB) and do normalizing afterwards in DaVinci Resolve Studio Fairlight module.

This is still not working. I exported it to ProTools and my sound engineer said the files were clipped and unable to pull down. What gives?

This is still not working. I exported it to ProTools and my sound engineer said the files were clipped and unable to pull down. What gives?

May need to be a bit more specific in terms of export parameters and what import parameters he chose.

Got an AAF to share for us to check?

This is still not working. I exported it to ProTools and my sound engineer said the files were clipped and unable to pull down. What gives?

May need to be a bit more specific in terms of export parameters and what import parameters he chose.

Got an AAF to share for us to check?

It's just on the track I recorded at 32 but there's MANY tracks for the entire short film. I don't know if it makes sense to send all of that over?

This is still not working. I exported it to ProTools and my sound engineer said the files were clipped and unable to pull down. What gives?

May need to be a bit more specific in terms of export parameters and what import parameters he chose.

Got an AAF to share for us to check?

It's just on the track I recorded at 32 but there's MANY tracks for the entire short film. I don't know if it makes sense to send all of that over?

If it's just the one track then maybe do a save-as and get rid of everything but the track with 32-bit float audio and then;

1. Export that as an AAF, share AFF with us, and let us know the settings used
2. Share that Resolve project with audio so we can check...

that way the file size will be small and we can test it (I'm on Nuendo this week as far as I know, but if it opens there it should probably open in PT... and if it opens in Nuendo I can re-save for you and hopefully that'll open for your sound guy).

Also, a thought occurred to me - does AAF actually allow for 32-bit float files? And even if it does, did the sound engineer choose to 'link' to source media rather than copy/conform it to a different format, for example .wav files at 24-bit fixed?

This is still not working. I exported it to ProTools and my sound engineer said the files were clipped and unable to pull down. What gives?

Protools should work:
https://www.sounddevices.com/32-bit-float-applications/
Protools 2019.12 32-bit float WAV Import - Yes. Waveform displays and outputs appear to be 24-bit, Outputs will clip if signal is > 0dBFS

.AIFF can handle only 32-bit PCM files, but not 32-bit float files. Use .WAV

I would like to record audio on the zoom f6 using 32 bit audio, but we have to edit in 24 bit.

I was hoping I could dual record 24 and 32 bit in the zoom f6 and have 32bit as a backup which is possible BUT then there is no limiter available for 24 bit.

So I was thinking: is it possible to record in 32 bit and find a reliable way to transcode the files to 24 bit later on?

We are syncing audio and video via timecode using tentacle sync studio.