VST 2.4 double floats

[Izhaki]

Hi Andrew,

So I’ve been into these sorts of debates loads. As someone who is teaching this and even has a small related publication, I hope I know a thing or two and would actually love you to prove me wrong. So I’m happy to keep this discussion going until we are both satisfied.

So lets start with the basics, floating point numbers have a dynamic range from 2^128 to 2^-128, and 20 Log (10, 2^128 / 2^-127) = 5100 dB [1], and not 150 dB which is the figure you have stated. I am guessing what you meant to say was precision not dynamic range. So lets agree that a 32-bit float has somewhere from 24 to 25 bits of precision [2] (it depends on how you count the sign bit and the leading 1 which can never be zero so doesn’t really count as a full bit).

You are correct about a precision of 25 bits (23 Mantissa + 1 sign + 1 implied bit). Now I think we disagree on the definition of dynamic range, which is clearly a thing to not agree about.

If you compare floating point to fixed point you can say that floating point has a larger dynamic range (much higher and lower values can be represented). Indeed, articles on float vs fixed often use ‘dynamic range’ for the exponent and ‘precision’ for the mantissa. But if we talk about floating numbers representing audio, then we have to take into account that although we can represent very big and small values, the audio itself is confined to a much smaller precision, within a hugh range. This precision, in audio terms, equals to the actual dynamic range of the system.

It is true that the range of numbers provided by floating point can be bigger than 150 dB apart. If we speak in strict dBFS terms then yes - one sample can be 0 dBFS while another -700 dBFS (0 dBFS stand for the biggest number float can represent). But when you mix these two samples together your result is limited to 25 ‘meaningful’ bits (ie, bits that carry a calculation based sequence of 0s and 1s) - the 8 bit exponent just scales them into a range of numbers.

If you consider a delay line, where each echo is 6dB lower than the previous (imagined in binary - the mantissa will stay the same, but the exponent will go 1 down with each echo). The wet signal will actually dive more than 150 dB in level within the delay. But when mixed with the dry signal, you cannot have the result extending 25 bits below the peak. The peak of the dry signal sets the top, and anything 25 bits below it will have to either be rounded or lost. In technical terms, if you mix/sum these two binary samples:

1 0000 0000 0000 0000 0000 0000 (all of these 25 bits are the mantissa)
0. 0000 0000 0000 0000 0000 0000 0000 0000 1 (you can get such a number with the exponent)

There is simply not enough bits in the mantissa to represent the result and you’ll end up with the first number instead - your low level signal is lost. The two samples ARE more than 150 dB apart, but their sum isn’t!

You can give a similar example with a fader - if 1.0f is divided by 3, the result is limited to a 25 bit precision. This practically means rounding errors (distortion) at -150dB.

Although we can be a meter away from a 130 dBSPL source and we will clearly hear it (some would say too clear), as 120 dBSPL is the threshold of pain we say our ears has 120 dB of dynamic range. In the same way I believe there’s no point of talking about huge dynamic range if any processing of a sample results in a precision limit of 25 bits (150 dB).

Another argument would be the mathematical view - there is nothing in Nyquist’s theorem that relates to dynamic range (and some people say that scientifically speaking digital audio has unlimited dynamic range). But we clearly get (rounding/truncating/quantisation) distortion at some level and that level defines the noise level in our signal-to-noise ratio which is then assigned to the dynamic range of the system. This level is -150 dB from peak signal in float (regardless of how high or low that peak is, ie -300 dBFS or -1000 dBFS).

(And by the way, I can say with next to certainty that your 5100dB calculation is wrong; on the most basic level it could work for 1 bit mantissa, but you have a 25 meaningful bits in addition to the 8 bit exponent. I also think your calculation will work with a decimal floating point, but the floating point is binary - but I might be speaking rubbish. I did this calculation with Nika Aldrich something like 7 years ago, and if I remember correctly two different calculations yielded something around 1600 dB; I’ll have to dig in my email box to see if I still have it and what exactly was going on there.)

[quote]Ok, now lets turn to a real world signal being recorded. Even with the best acoustic environment, with the best mics, and the best converters you still have to deal with (unless you want to record at near absolute zero kelvin) Johnson Nyquist Noise, which is at the level of -124 dB at 100 kHz [3], which is around 21 bits, so already our single precision float is going great guns, not a problem thus far as you have a 3 or 4 bits of natural dither from actual thermal hiss. Our ears are also victims of physics, so the same thermal issues apply. In other words there is a limit to the dynamic range of human hearing that a single precision float also handles.

Now processing audio is a different matter, as I already pointed out, internally to an algorithm you may need to use double precision numbers, and if you really want to you could dither back to there (although it is non trivial) to single precision, but when passing information between devices single precision is fine.[/quote]

Yes the best Mic’s SNR is 110 dB, our ears are 120 dB dynamic range, the best ADC is 122-124 dB dynamic range… But whether you are using Pro Tools or Logic or any other system that uses float to represent samples, nearly every mathematical function on a sample value (let it be gain or mixing of samples) generates rounding distortion at -150 dB. And you are processing all over the shop if you’re mixing, for example.

So this is nothing to care about if all you do is apply gain as the resultant distortion will end up below the 24 or 16 integer bits the audio is going to end up at. But it is the accumulation of this distortion, and the distortion of a distortion of a distortion that can get into ‘the audible range’.

Now how exactly getting 32 bits, going double precision inside a plugin, then bit-reducing back to 32 bit is any better than having 64 bit throughout? When going from 64 to 32 you either get rounding distortion or dither noise, both will be around -150 dB. On a double precision system your noise floor is at -325 dB (54 bits) and that’s where your rounding distortion or dither will be added to.

I do completely agree that “when passing information between devices single precision is fine”, but it is as fine as a 44.1kHz 20 bit Integer audio - if no processing is being done, that’s all you’ll need. There is no point whatsoever using floats if all you do is passing information. So we really are talking about the processing side of float, not its passing qualities.

Next up, processing overhead. With an intel CPU you can do four single precision floating point operations at once, vs 2 double precision, so already your processing power is halved if you use doubles. Then, if all your numbers are doubles, you halve how many numbers you can store in the inner most cache. With Analog Devices and Texas Instruments chips you have a similar situation, double precision computations take twice as long as single precision ones.

OK, I’m neither a great expert nor an authority on that, but to my knowledge the 64 bit Intel chips within our DAWs place float number into double registers anyway - there’s virtually no difference if you’re using float or double (only true for 64 bit machines). Am I wrong?

It is much easier to just search and replace “float” with “double” in your code and be done with it, but this is wasteful and lazy. If you can’t figure out where a float is needed and where a double is needed you are best off sticking with double, even horrible dsp deformities like a direct form 1 biquad work ok (well you still can’t modulate them) with double precision numbers, but please don’t brag about being lazy and by putting something on your web page saying “all 64-bit signal path”, since that says to me “I’m not smart enough to work out how to do things properly so I’m just going to waste your cpu and memory and try and convince you it’s in your benefit”.

OK, I promise you I’m not going to do this. But from a pure digital audio point of view, it is more correct to go double precision and then dither back to 32 bit than to leave the rounding distortion you get from single precision signal path. I don’t think you should refer to people who do this as not smart enough, particularly as some of them work for respectable companies like NEVE.

Having said all that, I do see where you are coming from, and to be frank, I would probably give others the same advise as yours - just stick to single precision. I’m not even getting into the business of if you already going double precision you might just as well oversample in your plugin. Some people take the practical view (you can’t hear rounding distortion or low level aliasing, and a 3dB boost on an EQ will have much more effect on your audio), other takes the digital-audio-purist view (do whatever is needed to ensure the best audio quality).

But really, back to what this thread has started with - if VST provides a double precision signal path, why not support it? It just nulls our discussion altogether - you don’t have to go double and then single, you just get the double to begin with.