FabFilter User Forum
"Double Precision" 64-bit floating point internal processing
We do use 64-bit internal processing where needed. For passing samples into the plug-in, and back to the host, 32-bit works well and there's no need to use 64-bit float samples. If there is a specific scenario where you run into the limitations of 32-bit float processing, please let us know and we'll consider it carefully.
Cheers,
Merely curious, does Pro Q3 in dynamic mode run internally at 64 float (double precision)?
Pro DS seems the only one that specifically states double precision in its specs/features.
Cheers.
In my daw I use 64 bit double precision engine does this cause problems of any kind (like rounding errors, audio degradation etc) with the fab filter plugins ? Should I use single 32 bits processing?
Hello, a real-time audio programmer with decades of experiences here. I'd like to voice my opinion on this. It is a bit misleading to use the term "32-bit depth" in connection with the single-precision float data type.
I will skip the theory about the internals of the float format. You can do a practical test in Visual C++ 2019 and see for yourself that the actual resolution of the 32-bit float for the normalized ranged [0.0, 1.0] is actually 6 digit. So there is no difference between e.g. 0.000001 and 0.0000005. It follows that the actual resolution is only a million possible values in that case, which is roughly 20 bits. So the resolution is actually worse than 24-bit integer.
And we all know that 20-bit depth is 4096(!) times lower resolution than 32-bit depth (it grows exponentially, not linearly -- each bit doubles the resolution).
So, in my humble opinion, there *is* a big reason to support double precision (64-bit floats) in plugins that do mixing and mastering processing (for VSTi there is no reason, though). And it's no wonder that Cubase does support 64-bit float internally.
Hi, epsilon for normalized float is 0.000000119209 which actually is 23 bit, as expected when dealing with a 23 bit mantissa. As stated FabFilter uses 64 bit precision internally (probably like any dev e.g. when dealing with filters, envelopes or such), 32 bit is only used the 2 times when passing buffers to the host/getting them from the host.
Cubase introduced 64 bit processing internally with v9.5. So all the versions before were a mess and of poor quality I guess!? And with 9.5 they've introduced it only for VST3, not VST2...
All the best, another real-time audio programmer with decades of experience :-)
Hah, forgot to add the sign bit, so you basically have double the discrete values which can be represented, which makes it 24 bit.
In theory, yes, single float has 24-bit resolution. So, again, it is grossly misleading to refer to that as "32-bit" resolution. I stand by that statement firmly.
(As a side note, in practice, with Visual C++ 2019 you will see that for the normalized 0.0..1.0 range, it is slightly less than 20 bit, actually.)
And no, 20bit or 24bit resolution is definitely not mess. But it is far far from perfect, either. Steinberg added double precision to the VST 2.x API more than a decade ago. Why, because it was not needed?
Finally, I thought we're talking top-notch mixing and mastering plugins here. Currently, when I use Cubase and iZotope plugins, I can run the entire chain in double float, which gives me 40-bit resolution. Why wouldn't I use it? Today's hardware has such excellent performance that there is no reason to use single-precision.
It's kind of shameful that you claim to provide top-notch EQ, while your output is barely 20-bit.
And, by the way, Cubase is far from being the only DAW that supports double float operation for VST plugins. There are many more. So please be a decent match for them and be a decent competition to iZotope, which is currently beating you on this front.
Sorry for adding another post -- there is no edit button. Another point regarding this is that the vast majority of floating-point values are an approximation. If your plugin does internal processing in double float and then converts to single float, and this goes back and forth, the errors of course accumulate.
With single precision the errors accumulate approximately 16 million times faster than with double precision and they are 16 million times more audible than on double precision.
Talking about "overkill" is needless with the state of today's hardware. But if you think it is an overkill, just use single precision, nobody's forcing you. I and others will continue using double precision to get 16 million times closer to perfection. ;)
I try to understand. Can we use the Fabfilter on our tracks with Cubase configured in 64 bit float? Yes or no ? Does that destroy the signal? It is better to leave Cubase in 32 bit float?
I prefer to keep the Fabfilter and stay at 32 bit float. I just can't do without it.
We have done extensive experiments with 64-bit processing and we concluded that it is just not necessary to use it as an audio format. You do need it internally in a plug-in for some types of processing. You don't need it when scaling the gain, or adding channels, which is exactly what the mixer in a host application does.
Keep in mind that the floating-point format is very different from a fixed-point format. It's true that you get no more than 23-24 bits of precision, which gives you a dynamic range of around 140 dB. (We never claim to have 32 bits of precision by the way.) That means that when your audio is at the 0 dB level, the tiniest detail that can be represented at the same time is at -140 dB, way beyond the threshold of human hearing which is around -90 dB at its best. But it gets even better, because when the overall volume gets lower, the precision scales with it so the precision actually increases.
With a fixed-point 16-bit format like a CD, you can force quantization noise during low-volume sections of a song (mostly with classical music which has a higher dynamic range), if you increase the volume enough so that loud sections will be far too loud. With floating-point, that doesn't happen because during soft sections, the precision increases and you don't get quantization noise.
Why does Cubase offer 64-bit processing? Because they can, and because people are asking for it. It is overkill, and we don't support it because we would need to have an entire separate chain of audio components for 64-bit audio in our plug-ins which would significantly increase our development, testing and support load. And we are convinced that you wouldn't hear the difference.
Cheers,
Hi!
I work in Reaper 64 FP mixing engine. I use Acustica Audio products (they are 64 FP) Airwindows (they are 64 FP) DMG, TBProAudio, the all are 64 FP.
Even latest Sonnox Inflator version are 64 FP.
Why should i go trancate to 32 only because of you didn't think we need 64 in FF plugins?
Q3 is no concurrent algo-eq to work with.
I can't set 32 FP mixing depth because Acustica's products work way better sonicly in 64 FP.
My point is - there is mass appeal for Fab-Filter plugins with double precision mixing depth.
Or you think people will claim you because of CPU usage? It's not bad even with ton's of 64 FP plugins. In Reaper I'm rarely seen CPU\ASIO Real-Time difference between 32\64 FP.
So that's not the deal-breaker.
When will this be implemented in all Fabfilter plugins, especially Pro-Q?
Truncating to 32-bit is still truncating, no matter how inauduble the noisefloor. You have a reputation for transparency in processing and this would be the final piece of the puzzle.Make it switchable if CPU use is an issue.
...Please? :)