The "float/fixed" debate and more digital myths

[muzines]

Having a delightful thread over on GS regarding dithering, specifically one guy who is annoyed that when importing 32-bit float files into Logic, Logic converts to 24-bit fixed files, without dithering, and he's convinced the audio sounds worse as a result (after all, 32-bit to 24-bit, you should always dither, which is his argument).

My understanding of 32-bit *float* files, is that, unlike regular 32-bit fixed point files, 32-bit float files *do not* contain 32-bits worth of audio data, they actually contain the regular 24-bit audio data, with (8-bits worth of) scaling values to let that 24-bit audio slide up and down the dynamic range - which is of course useful.

So a 32-bit float file does not contain any extra audio "precision" over a 24-bit fixed point one, and as, during Logic's import, no word length reduction is occurring when saving out the 32-float file to 24-fixed, so no dither is necessary - in short, the audio signal should be identical (assuming the audio is within a typical dynamic range scenario of course).

GS thread:
https://www.gearslutz.com/board/apple-l ... st14420490

Of course, you can find people saying similar - eg a nice post from Bob Ohlsson that 32-float files don't contain any more data than 24-fixed, but people with other "opinions" do things like this, where they say that dithering should be applied when going from 32-bit float to 24-bit fixed: https://www.sonicsciencelab.com/dithering/

So, I'm doing a quality check on my understanding - am I correct, or am I mistaken in this?

Come to my rescue, digital audio nerds!

[James Perrett]

So, I'm doing a quality check on my understanding - am I correct, or am I mistaken in this?

That's my understanding too - although as it is GS facts should never get in the way of a good argument

[muzines]

I think it's a general rule at GS that you can make up whatever "facts" best support your argument...

Thanks James.

[Folderol]

32bit float doesn't give you more precision than 24bit fixed, but it does give you greater range. Think of it like having a stepped amplifier/attenuator on the front end.

[Hugh Robjohns]

Yes Desmond. Your understanding is generally correct, assuming the source file audio lies withing the normal dynamic range.

However, if it happened to be a very quiet signal that was created within a floating-point domain, one that peaked at -40dBFS for example, it could be that the floating-point version would contain valid audio data below the fixed-point LSB (24th bit level), and it should therefore be dithered during the translation, as some word-length reduction would be occurring...

But if that was the case, you've probably got much bigger problems to deal with than a bit of theoretical truncation distortion!

Sadly, my experience on GS has not been good. There certainly are some extremely knowledgable and intelligent posters there -- industry gurus in many cases -- but they are totally overwhelmed by many who are not...

[muzines]

Thanks Hugh - yes, I'm aware that when you start to hit extremes, thing change a little bit, but I'm talking basically "normal" levels.

Someone else just verified Logic's handling of this by bouncing out a 32f file, reimporting it (Logic converting it to 24-fixed), then rebouncing out to 32f again, and comparing those two 32f files - they were bit identical. Basically, there is no "throwing away" of audio data, or loss of precision when importing 32f files to Logic, when it converts them to 24-fixed (likely for efficiency).

Anyway, thanks for the sanity check, just to make sure my understanding is sound (!).

[wireman]

Having a delightful thread over on GS regarding dithering, specifically one guy who is annoyed that when importing 32-bit float files into Logic, Logic converts to 24-bit fixed files, without dithering, and he's convinced the audio sounds worse as a result (after all, 32-bit to 24-bit, you should always dither, which is his argument).

I'm interested in this but don't use Logic so don't understand the question.

Does Logic import a 32-bit float file and operate on it in 32-bit floats internally (I assume so).
So where does the 24-bit fixed file come from, does it only have an option to save in 24 bits or is the imported file taken into some project folder and convered into a 24 bit file?

In either case it would be useful to understand what happens if the peak in the floating-point input file was say +20dB or -20dB.

[Folderol]

Having a delightful thread over on GS regarding dithering, specifically one guy who is annoyed that when importing 32-bit float files into Logic, Logic converts to 24-bit fixed files, without dithering, and he's convinced the audio sounds worse as a result (after all, 32-bit to 24-bit, you should always dither, which is his argument).

I'm interested in this but don't use Logic so don't understand the question.

Does Logic import a 32-bit float file and operate on it in 32-bit floats internally (I assume so).
So where does the 24-bit fixed file come from, does it only have an option to save in 24 bits or is the imported file taken into some project folder and convered into a 24 bit file?

In either case it would be useful to understand what happens if the peak in the floating-point input file was say +20dB or -20dB.

All the audio code I've worked with uses floats internally, and normalised to the range 0 to +- 1 (peak), converting any other format only at the entry and exit points (if/as requested). Some hardware can also send and receive audio as floats, in which case in no conversion is needed.

Actual AD/DA converters work at fixed discrete levels, hence fixed point of whatever resolution they are capable of.

[wireman]

Actual AD/DA converters work at fixed discrete levels, hence fixed point of whatever resolution they are capable of.

Where this is getting interesting is in the use of multiple converters to cover parts of the input range, something Sound Devices have picked up on.

[muzines]

Does Logic import a 32-bit float file and operate on it in 32-bit floats internally (I assume so).
So where does the 24-bit fixed file come from, does it only have an option to save in 24 bits or is the imported file taken into some project folder and convered into a 24 bit file?

When you import a 32-bit float file into Logic, Logic first converts it to a 24-bit fixed point file, and then uses that 24-bit file in the project from then on - Ie, it doesn't directly use the original 32-bit float file after the import process.

Logic's mixer is 32-float format by default, but does have a 64-bit high precision engine option if you want.

[Hugh Robjohns]

So on importing a floating-point file it basically just takes the mantissa and ignores the scalar, assuming it to be unity?

I can kind of see why given that all other local input sources will be fixed point... but given that the mix engine is floating point anyway it seems a rather backward step...

H

[Hugh Robjohns]

Where this is getting interesting is in the use of multiple converters to cover parts of the input range, something Sound Devices have picked up on.

Sound Devices weren't the first, and won't be the last... although they have engineered their version in a slightly different and ingenious way compared to others, and with some useful claimed benefits...

However, while the additional cost and complexity of this approach might be justified in applications handling unpredictably wide dynamic ranges -- so in digital microphones and location sound recorders, for example -- it is simply not required in the vast majority of everyday recording applications where the dynamic range is known, modest, and predictable, and routinely far less than the 120dB plus range that a modern delta-sigma fixed-point converter can provide very cheaply easily, and accurately.

[muzines]

So on importing a floating-point file it basically just takes the mantissa and ignores the scalar, assuming it to be unity?

I don't know on the internals of the behaviour offhand. It might ignore the scalar if it doesn't matter, but if it's significant, it may choose to do something differently (eg, scale down and dither, or perhaps even keep and use the 32f file in these circumstances.) - I don't know offhand without checking.

I can kind of see why given that all other local input sources will be fixed point... but given that the mix engine is floating point anyway it seems a rather backward step...

As I suggested on the thread, it's likely for performance reasons - there's not much point adding additional disk overhead to stream audio files with the 8 extra unused and unecessary bits, so converting down to 24-bit might be a lot more efficient to deal with, and the engine may be optimised heavily for it.

It's actually fairly recently that Logic allowed you to import and export 32-bit files (of any flavour) at all - up until LPX, the best you could do was freeze (which actually does save 32float files, as those frozen instrument channels might be well over 0dBFS), and use those directly. But there is a disk overhead with 32float files over 24.

[Folderol]

Actual AD/DA converters work at fixed discrete levels, hence fixed point of whatever resolution they are capable of.

Where this is getting interesting is in the use of multiple converters to cover parts of the input range, something Sound Devices have picked up on.

Which must require some mind-mumbingly precise silcon

[Kwackman]

Actual AD/DA converters work at fixed discrete levels, hence fixed point of whatever resolution they are capable of.

Where this is getting interesting is in the use of multiple converters to cover parts of the input range, something Sound Devices have picked up on.

Which must require some mind-mumbingly precise silcon

See the dialog box titled "Floating Free" in Hugh's review of the SD Mixpre-6
https://www.soundonsound.com/reviews/so ... ixpre-6-ii

[Folderol]

When you import a 32-bit float file into Logic, Logic first converts it to a 24-bit fixed point file, and then uses that 24-bit file in the project from then on - Ie, it doesn't directly use the original 32-bit float file after the import process.

Logic's mixer is 32-float format by default, but does have a 64-bit high precision engine option if you want.

Interesting.
These days, there isn't a lot of difference resource-wise between float and fixed point, but the conversion from one to the other is a serious bottleneck, so presumably they've done this to retain compatibility with their original file format and get rid of said bottleneck.

I've only worked with linux code, and know of just one person who seems to have done something similar (very much a cutting-edge guy). I've not looked at the code itself, but my understanding is the internal working resolution is 32bit fixed, which is just a bit shift away from 24bit

[merlyn]

I've always thought on audio data as integers. Two's complement signed integers.

A float takes the form :

s|eeeeeeee|mmmmmmmmmmmmmmmmmmmmmmm

1 sign bit, 8 exponent bits and 23 mantissa bits. That's turned back into a number as

+/- 2^(e-127) * (1+m)

There is then some conversion required to get a 24 bit two's complement signed integer -- it's not simply a case of dumping the exponent. But does it need dither?

Back in the days of16 bit recording dither was added to the input signal. Now with 24 bit the noise of the preamp dithers the signal and the last four bits are lost below the noise floor. I don't think even a super low level signal would need dithered when converted to 24 bit because it's in the dither, which will be ~4 bits high when scaled back to normality, normality being an exponent of 2^0 = 1 which is a value of 127 of the exponent bits.

Dither de-correlates quantisation distortion from the signal. The ear is more tolerant of noise than distortion.

An undithered image:



Dithering saves the image from technical catastrophe :

[DC-Choppah]

I've always thought on audio data as integers. Two's complement signed integers.

A float takes the form :

s|eeeeeeee|mmmmmmmmmmmmmmmmmmmmmmm

1 sign bit, 8 exponent bits and 23 mantissa bits. That's turned back into a number as

+/- 2^(e-127) * (1+m)

There is then some conversion required to get a 24 bit two's complement signed integer -- it's not simply a case of dumping the exponent. But does it need dither?

Back in the days of16 bit recording dither was added to the input signal. Now with 24 bit the noise of the preamp dithers the signal and the last four bits are lost below the noise floor. I don't think even a super low level signal would need dithered when converted to 24 bit because it's in the dither, which will be ~4 bits high when scaled back to normality, normality being an exponent of 2^0 = 1 which is a value of 127 of the exponent bits.

Dither de-correlates quantisation distortion from the signal. The ear is more tolerant of noise than distortion.

An undithered image:



Dithering saves the image from technical catastrophe :

[Rich Hanson]

I've always thought on audio data as integers. Two's complement signed integers.

A float takes the form :

s|eeeeeeee|mmmmmmmmmmmmmmmmmmmmmmm

1 sign bit, 8 exponent bits and 23 mantissa bits. That's turned back into a number as

+/- 2^(e-127) * (1+m)

There is then some conversion required to get a 24 bit two's complement signed integer -- it's not simply a case of dumping the exponent.

If you work through the maths, as long as the exponent is 127 (which would be equivalent to the normal 24 bit range) then throwing away the exponent is exactly what you are doing. The sign bit and the mantissa are still making up a two's complement number.

Obviously this only holds true for that situation, and higher exponent values for example could lead to clipping.

[merlyn]

It would make things easier if that was the case. As far as I can make out that is not the case. Dumping the exponent and appending the sign bit gives a number that's not in two's complement.

There is an IEEE 754 converter here :

https://www.h-schmidt.net/FloatConverter/IEEE754.html

[Rich Hanson]

I stand corrected, I'm well out of date

[Folderol]

I stand corrected, I'm well out of date

I have to be corrected so often that I find it more comfortable to sit

[merlyn]

@Rich Thanks for your input. This is how myths get busted!

The idea that 32 bit float contains unaltered 24 bit audio data scaled by an eight bit exponent is ... a myth. I don't know where this originated but it's all around the internet -- I've never seen it explained any other way.

It may have been put together to reassure neurotic musicians who want to dither 24 bit audio ... twice.

What I said above about an exponent of 2^0 = 1 is wrong. With an exponent of 1 the numbers that can be represented are +1 to +2 and -1 to -2. That isn't a lot of use for audio.

The two's complement integers must be converted to a float between -1 and +1.

As far as I can see this doesn't introduce errors. Take 1 as an integer. To convert it to a float between 0 and 1 you would divide by 2^23 and that can be done exactly in a float with an exponent 0f 2^-23.

1 > 1/(2^23) = 2^-23
2 > 2/(2^23) = 1/(2^22) = 2^-22
3 > 3/(2^23) (also exact)
4 > 4/(2^23) = 2^-21

... and so on. This means the exponent is being used all the time.

The principle that no information is being lost or gained holds, but the details are more involved than the myth suggests.

[Hugh Robjohns]

...the details are more involved than the myth suggests.

Isn't that always the way?

[muzines]

The idea that 32 bit float contains unaltered 24 bit audio data scaled by an eight bit exponent is ... a myth.

I'm not sure if you were referring to me or not, but I'll say if it wasn't clear is that I didn't think that was the case. When I say that 32-floating audio format contains 24-bit audio data, it doesn't mean I think it's a naive mapping of 24-bits of fixed point stuck in the lower bits of the floating point number - but I can see that it can be interpreted (incorrectly) as that's what's going on.

One thing I do say is that float numbers are "mathsy" and not at all intuitive to "regular" folk compared to fixed point files which are reasonably straighforward, and the times when I've looked into it just makes me realise that the full details are over rather over my head and I have needed to get into it deeply enough for a complete understanding. I understand just enough of it to be useful (and not *too* dangerous!)

I don't know where this originated but it's all around the internet -- I've never seen it explained any other way.

Indeed. Like many things about digital audio, often they are explained by people who don't know the full details, because the full details have complexities that are problematic to explain to us more naive folk.

The two's complement integers must be converted to a float between -1 and +1.

Indeed.

The principle that no information is being lost or gained holds, but the details are more involved than the myth suggests.

Yes.

Also, I vaguely recall (but don't have the full details offhand) something about the floating range when you get high up is that the resolution isn't quite linear like integers - the gaps between numbers on the scale get bigger as you go. Maybe you can explain that to us laymen...