FabFilter

Hear me out, before you start writing something about overkill.

There is no longer any excuse today in a pro audio plugin to still only support single-precision float. Why? Consider these points:

* The resolution of 32-bit float is NOT 32-bit, but only ~20-bit. Yes, in the normalized range 0..1, the smallest resolvable step is 0.000001.

* In contrast, the resolution of 64-bit float is ~53-bit. That is 8,589,934,592 times higher resolution compared to single float.

* 53-bit quality is not an overkill. Not at all. In the 20-bit quality you currently provide, repeated processing accumulates and amplifies the imprecision errors inherent in IEEE 754 single-precision float.

* The increased CPU load is only by ~3%. Negligible, but if anyone still minds it, they can switch their DAW to single precision.

* VST2 has supported double float for decades now.

* Your main competitor iZotope has supported double float input/output in VST2 for years.

* If you internally already use 64bit processing, the cost of implementing it on the input and output is negligible. In fact, you already do a redundant conversion from single to double and back. You only need to skip that conversion.

Again, if you claim your very expensive plugins are meant for pro audio, it is quite embarrassing you force the input and output to ~20bit resolution.

Hi,

The 32-bit float format has 23 bits of mantissa, plus an implicit 1, so effectively 24 bits of precision. It's important to note that a floating-point format provides much better resolution than traditional fixed-point formats like 16-bit or 24-bit PCM. For example, if a signal is around -12 dB, it's never above +/- 0.25 so in this case 32-bit float provides the resolution of 26-bit PCM.

I think we all agree that 24 bits PCM is more than enough for a final master -- you could even argue that 16 bits PCM (the CD format) is good enough as a final output if the level is normalized/mastered correctly. But with PCM, if you use lower level signals, you get much less precision: in the example above with a -12 dB signal, you get only 14 bits of effective precision with a 16-bit format. That's why, if you use fixed-point PCM, you want at least 24 bit for your intermediate formats.

32-bit floating-point provides 24 bits of precision *and* also provides that precision for smaller signals. The repeated processing that you refer to just doesn't accumulate to errors that become significant in the context of DAW processing. (It does accumulate with some kinds of internal processing in which case we use 64-bit.)

It's also not true that the increased CPU load is just 3%: with SSE parallel processing, 64-bit lets you only do two operations at the same time, while 32-bit allows four operations. So it completely depends on the processing and how well it is optimized.

We could provide 64-bit I/O for all our plug-ins but that requires a completely different signal path if you want to also offer the increased efficiency that 32-bit gives you. That doubles our internal testing efforts so it's not as simple as it sounds.

I hope this explains our current thinking!

Cheers,

It's funny in audio how often people want things merely because they are possible instead of focussing on things that add value.

I would ask the OP: What actual, concrete problems is the fact that FabFilter plugins run at 32 bit floating point precision causing for your music?

I already know the answer: None. None whatsoever. Professionals have created millions of hit songs and audio for movies and TV shows using FabFilter plugins. The 32 bit floating point precision hasn't held any of those professionals back in any way, ever.

My honest suggestion, not meant to sound passive aggressive: spending:

Stop wasting your time and energy on pointless over-optimization. Stop looking for problems where there are none. Use that time and energy instead to create good audio. The tools that are at your disposal are more than sufficient.

If there are things missing from FabFilter plugins, it certainly isn't higher floating point precision.

I don't think anyone but you would want the FabFilter team to use their limited resources on stuff like this, if those resources could instead be invested in building features that actually make a difference. Nothing comes for free in software engineering, everything is always a trade-off.