Topic: 32Bit Float recording - The Technical view

[Rairun]

I do disagree with the wording here-

[snip..] The more digital attenuation you add, the more of the signal you "submerge" into dithering/quantisation noise waters.

Once digitized, the noisefloor becomes fixed relative to the rest of the signal.  We can alter level digitally and the noise-floor shifts along with the signal. If we amplify a lot so that low level signals become perceivable, the noise floor is amplified along with the signal and can also become perceivable.  The boat rises along with the tide, both are being raised or lowered by the same amount.  The signal "submerging" into noise (into analog thermal or dither noise in a properly designed ADC rather than into quantization noise) all happens upon or prior to the digitization process.

The noise floor won't shift along with the signal, though! I mean, it will do so if you are talking about the noise that has been digitised, as long as it still fits in the bits available. If the noise floor of the recording is -90 dBFS and you lower it by -10 dB, then yes, the new noise floor will be -100 dBFS because this still fits in the 24-bit file. But as you reach the lower end of the 24-bit format's dynamic range, the audio data that is just immediately above it will drown in dither or quantisation noise (if the device or software doesn't apply dither when saving the file).

Another way to think of this: you've recorded a show with a high dynamic range, and you peaked at -1 dBFS. The quietest songs are around -45 dBFS. The recording's noise floor (venue noise, preamp noise, whatever analogue noise was created) sits at around -60dBFS, which is audible if you crank up the volume for the quiet parts. Now, if you attenuate this by -80 dB, save the file to 24-bit, open it again and amplify it by 80dB, you will have increased the noise floor in relation to the quiet music because the dither or quantisation noise that was applied when you saved the file will have drowned the original noise floor! This is why audio editors default to working at 32-bit float - because then you can attenuate it and amplify it by however much you want without introducing more noise/artifacts. Then, when you've got your ideal levels set, you can export to 24 or 16 bit.

[Rairun]

Just to add to my last point:

If you open an audio file in Audacity and use the silence command on it, you can amplify it infinitely without hearing any noise because Audacity works in 32-bit float. Now, if you export this silent file to 16-bit and 24-bit files and then reopen the files in Audacity you will find:

- You can normalise the dithering noise added by Audacity to 0 dBFS by adding +71.224 dB to the 16-bit file.

- You can normalise the dithering noise added by Audacity to 0 dBFS by adding +118.474 dB to the 24-bit file.

This is by using the best quality 'Shaped' dither under Preferences > Quality.

My point was that any attenuation you do digitally on a 16 or 24-bit file, if it is actually saved to the file instead of a temporary 32-bit float one, is not a lossless operation. If the device (or software) applies attenuation after the conversion, you are losing data. The only lossless operations that you can save to 16 or 24-bit files are simple ones like copying, moving, splicing, deleting, etc. As soon as you manipulate the actual sound waves with EQ, compression, amplification, and so on, you're not getting the exact same data back by doing the inverse operation.

[Ozpeter]

Wow.  Lots to absorb there.  Could any of this account for why 32 bit float recorders seem to peak at +15dB so that it has to be attenuated in post?  (By that I mean that when you record into them at almost analog clipping level, the file is recorded to +15dB instead of 0dB as one might logically expect?)

[Gutbucket]

Totally agreed on the last two posts.

The noise floor won't shift along with the signal, though! I mean, it will do so if you are talking about the noise that has been digitised, as long as it still fits in the bits available.

^ That's it. I was referring to the initial digitization through the ADC only, not any additional subsequent processing.

Yes, if performing some subsequent operation other than simple ones like copying, moving, splicing, deleting, etc. then both the operation space in which the calculations are performed and the saved output format must accommodate the potential increase in wordsize.  One might get away with digitally amplifying or attenuating after the ADC in a recorder which uses a larger internal operation space and still save all meaningful audio data within 24bits by truncating empty zeros at the top or random bits at the bottom, but there's nothing that keeps the user from overdoing it and exceeding the limits "meaningful audio data".  Technically its not bit-perfect even if it still contains all meaningful audio data.

Simple take away is that if a recorder is going to allow the user to digitally amplify/attenuate, or perform any other non-simple operation after digitization, it should use a larger calculation space AND save to 32-bit-floating-point.  Otherwise, best not to provide those functions on the recorder.

But if not allowing for those operations, the dynamic bottle neck of any of these recorders remains their analog circuitry and not the 24bit file format.  All the clever tricks being used to increase dynamic range such as analog gain ranging ahead of a single ADC or multiple analog paths through multiple ADCs or whatever could still be applied to usefully increase real world dynamic range while writing a standard 24bit file.

Thanks for the engaged discussion!


I just wish that whatever shenanigans are going on under the hood had been applied to improving 24bits recorders without muddying the waters with the whole 32-bit float output file thing.  24bits is fully capable of accommodating that with all the niceties that folks now tend to associate with "32-bit" such as no level setting in these kinds of small all in one recorders.  I don't really care what those shenanigans are, as long as the output is as identical to the input as possible, which is the metric that counts.

[Gutbucket]

Wow.  Lots to absorb there.  Could any of this account for why 32 bit float recorders seem to peak at +15dB so that it has to be attenuated in post?  (By that I mean that when you record into them at almost analog clipping level, the file is recorded to +15dB instead of 0dB as one might logically expect?)

Only reason I can think of is that the signal level captured in the raw recorded file is no longer being effectively normalized upon capture by the user setting an appropriate input gain.  Because of that initial playback levels prior to making any level adjustment afterward will tend to be much lower than they used to be.  Increasing level in the output file by 15dB may just be some compensate for that.  15dB being somewhat arbitrarily decided upon as being about right, but the specific amount not really mattering.  Keeps folks unfamiliar with the new 32-bit-float ways from thinking "man this is really low in level unless I amplify it", and also makes direct playback without making a level adjustment more reasonable.

But that's just my guess.

[Ozpeter]

And one more thing - I've been saying that here for years - in the M2 for instance (dual converter device) there are options to normalise to a copy of the file, to normalise during replay, and to export to 16 or 24 bit.  Am I right in thinking that these features will be work more accurately and losslessly if the stored recording is 32 bit float rather than 24 bit?  There are also broadly similar things possible with the single ADC H2essential - mixing its tracks, normalising, exporting.  Then again, a DAW can do that stuff with a 24 bit file but in a 32 bit float processing environment.  But maybe with the files in 32 bit float at the outset, it makes the internal processing (using low grade processors probably) more efficient?

[morst]

Am I right in thinking that these features will be work more accurately and losslessly if the stored recording is 32 bit float rather than 24 bit? 

The mantissa is gonna be 24 data bits either way, but having a wider dynamic range on the container could pick up actual signal rather than blankness for a bit or three while it's shifting.


Just wondering if anyone can create a short file to be used as a dual-ADC obstacle course?
Ideally it would be music, but if speech, birdcalls, electronic sounds, or thunderclaps are more telling, then let's use the most difficult source to track, in order to reveal issues and/or differences between implementations!?
#ADCobstacleCourse

[adrianb]

Curtis Judd has just released a video titled “32-bit Float Recorder Myths You Should Know About”.

I suspect that is in response to some of the discussion here and elsewhere.

[Ozpeter]

Curtis Judd has just released a video titled “32-bit Float Recorder Myths You Should Know About”.

I suspect that is in response to some of the discussion here and elsewhere.

I saw that - I think it is intended as another contribution to the general "merits of 32 bit float" debate - but indeed he did briefly mention the dual / single ADC subject. 

The key issue there, for me anyway, is that there is a bucket load of info about how dual ADC 32 bit float is implemented.  (Well, apart from the exact way the output of the two devices are merged which may vary between devices, and there are some who can hear and/display resulting artifacts.) 

But single ADC 32 bit float remains a mystery, by which I mean, sure it can be simply 24 bits written to 32 bit float resulting in no real audible difference, or it may be something potentially better than that if well implemented, like a kind of analog compression / digital expansion thing which seems quite plausible.  But we don't know for sure, or even at all.  And given that it's being used for marketing, and given that it's messing with our audio data, someone (presumably in a vendor company) should at least give a summary of what is going on, and why it's good.

[Rairun]

But single ADC 32 bit float remains a mystery, by which I mean, sure it can be simply 24 bits written to 32 bit float resulting in no real audible difference, or it may be something potentially better than that if well implemented, like a kind of analog compression / digital expansion thing which seems quite plausible.  But we don't know for sure, or even at all.  And given that it's being used for marketing, and given that it's messing with our audio data, someone (presumably in a vendor company) should at least give a summary of what is going on, and why it's good.

Yeah, it would be good to how they implement this!

I've long understood the theoretical principles of this, but something that I hadn't fully figured out until recently was the actual bottleneck of the gear I used. When I used to tape with CA-11s>STC-9000>Zoom H1, I disliked the amount of noise I got during quiet passages when I had set the gain for other much louder parts. My interest in 32-bit float devices - and my eventual purchase of the Zoom F3 - was due to that.

But it was only after running some tests with the Zoom H1 and Zoom F3 side by side that I understood not only their practical limitations, but the microphones' as well. I made a post about it that was a bit too long, but essentially, I found that as long I was adding around 20dB of clean gain to the CA-11's output (either with the STC-9000 alone or a combination between the STC-9000 and the Zoom H1's internal gain - the Zoom H1 only provides 13dB of fairly clean gain and gets worse from there), the Zoom H1 and the Zoom F3 performed exactly the same. With the CA-11s, EIN maxed out at around -118.5 dB, no matter how much more gain you threw at it, because at that point the microphone's own noise floor became the bottleneck.

In short, if you are using a pair of CA-11s with a Zoom H1, you get no benefit from using any more gain than +20 dB. So if that gives you enough headroom, you will get no performance benefit from pairing the CA-11s with the Zoom F3 instead. I'd say that for about 70% of the shows I attend, I get more than enough headroom with the CA-11s +20 dB into the Zoom H1. At the loudest show I've ever recorded (Mogwai), I used +12 dB and peaked at -4 dBFS. This means that if I had used the Zoom F3 then, the noise floor of my recording would have been around 8 dB quieter than it turned out to be.

Note that +20 dB gain paired with the CA-11s is not a very strong signal! If you're recording a singer-songwriter, you might be peaking at -30 dBFS or even less, i.e. a lot of headroom and an end result as good as if you were using the best multi-ranging ADC device around.

Now, of course, this calculation changes entirely when you're using different mics - both sensitivity and self-noise specs would affect the ideal amount of gain you'd need to get the least amount of noise as possible. What I suspect these budget devices are doing is simply giving the user fewer options to optimise for the internal mics (maybe compromising a little bit on the quiet/clipping ends to strike an acceptable balance). For those of us using external mics, though, I can't see how that's a good thing.

[Ozpeter]

I woke up this morning devising new tests of all this stuff that I could carry out using devices I have.  Will I bother?  We'll see...

When you mention how they may be optimizing these devices for internal mics, well, that's partly my (often repeated, sorry) view of the Zoom M2 (and M3) - as they have no inputs, Zoom must know that they have no way of blaming anyone else for bad outcomes, assuming they are correctly placed.  So they must be optimising the setup of the preamp and dual ADCs (claimed in marketing to be derived from F series devices) with a mic that isn't a load of crap, otherwise if it was, there's no point in the device at all.  And in my simple tests online, it's not an embarrassment.

[Gutbucket]

tl;dr- If its a closed system that can only record through built-in mics, it really doesn't need a dual ADC.. even if its output is 32-bit files.


If it's a closed system, meaning no external input other than the built-in mics, it should be relatively easy for manufacturer's to get away with providing no level controls at all, including gross mic/line and fine gain adjustments, because the manufacturer can just adjust things however is needed to match the output parameters of the internal microphones they are using to the inout parameters of the ADC they are using. ..AND since the dynamic range of any of the built-in mics they are likely to use is going to be less than 100dB, they would have no problem at all saving that output as a 24bit file. A 32-bit-floating-point file option would be fine as well if that helps them sell more recorders, but wouldn't provide any higher quality.  Same for dual ADCs.

Dual ADCs or other strategies along with writing 32-bit files is only technically helpful if the recorder has external inputs that need to accommodate gear with output parameters that are unknown to the manufacturer.  Even though the dynamic range of any one of those "unknown input sources" could be accommodated without using such strategies if it's output parameters were known to the manufacturer, accommodating a sufficiently wide range of "unknown inputs" requires either manual input gain setting by the user or increased dynamic range via dual ADCs or some other strategy.  But even with multiple ADCs, gross input gain in the form of mic/line input sensitivity still needs to be set manually by the user.

[Ozpeter]

I see what you mean but the M2 (and I think the M3 but its MS setup makes things slightly more complex) quotes a max SPL of 135dB in the specs - which must include the mics, and all the way through to the 32 bit float output.  As memory serves me, 24 bit would handle up to 144dB (?) so on the face of it, 24 bits would cover that ear damaging input.  Just. 

But as I think I've mentioned here - or elsewhere, oops - the M2 does some pretty efficient (faster than realtime) normalizing and converting onboard, and can even play back normalized on phones without prior conversion, so maybe 32 bit float helps a bit with that processing, in theory if not in practice.

(But would the ADC handle 135dB input at its analog stage without fear of clipping that front end of the ADC?  Thus needing one with lowered input to accept high levels, while the other does the quieter stuff maybe with even raised gain right before the conversion stage of the chip?  I have a horrible feeling that in my dotage I am sending this discussion round in circles...)

[TheJez]

But as I think I've mentioned here - or elsewhere, oops - the M2 does some pretty efficient (faster than realtime) normalizing and converting onboard, and can even play back normalized on phones without prior conversion, so maybe 32 bit float helps a bit with that processing, in theory if not in practice.

I guess I'm missing the point here... Normalizing is one of the easiest operations one can do on audio. It doesn't matter nowadays if the processor is doing integer or floating point arrithmatic, both will be very fast, and maybe even outsourced to an onboard DSP. By far the biggest bottleneck is reading/writing the input/output samples to the slow SD card, not the calculations. Back in the days, microprocessors typically only had integer arrithmatic on board, meaning that floating point calculations were emulated by integer software algorithms, which made them slow. Fortunately those days are over.