Plug-in engines not seen as 64 bit FP - Output bit depth is 32bit

It happens to you that that Cubase does not see plugins like Fabfilter, Izotope, Bx as 64bit FP? In fact by measuring the 64 bit FP file output bit depth through/after the plug-in this is reduced to 32. Obviously the rendered 64Fp format file has 32 (measured) bit depth - if there aren’t in addition other channels using Cubase summing engine (set to 64Fp) and assumed that on the final bus there is none of these plugins that “work” (reduces) in Cub to 32 bit.
Plug in like Acustica and other and others does not have this issue
Cubase 12 latest, 13 gives the same problem?

That is a limitation of the specific plugins. Not all plugins support 64-bit data paths. Most from PSP Audioware do, but I don’t think any I’ve tried from Waves, iZotope, IK, or NI do. So that will be a limitation on the plugins that only support 32-bit data in/out. (I’ve used a free plugin called Bitter to check this out for various of my plugins.)

Thanks for your reply. Yes, I’ve used Bitter too. I am aware of the data path, but I wanted to ensure it was not connected to my Cubase installation. Anyway, most of all succited plugins are 64 FP internally but, obviously, as we noticed, they have a 32 bit data path and I am wondering why. The result is that the 64FP rendered file is actually 32 bit depth. You have to put, for example, a Studio Eq or another 64-bit plugin at the end of the chain to achieve 64-bit depth again, but it is really a poor workaround and, actually, you have not a true 64 FP file.

Do you ask that question to the developers of the plugins, too?

No, My first thought was that plugins was reporting erroneously to Cubase the data path, but I will ask in the future to plugins developers. In the meantime would be cool if someone from Steinberg would let us know his opinion as developer.

What are the benefits of the 64 vs 32 bit output, if the internal processing is still done 64 bit?

Just in case you didn’t know: the information about whether a plugin supports 64bit I/O is also indicated in Plugin Manager: Display Options → Show Plug-ins That Support 64-Bit Float Processing.
VST Plug-in Manager Toolbar (steinberg.help)

Surprisingly, this feature hasn’t been widely adopted yet. Out of my arsenal of plugins, only Voxengo and Steinberg natives support 64bit I/O.

When the data paths in/out of a plugin are 32-bit, and you’re going into it with 64-bit data, there is a loss of resolution going into the plugin, and, if the internal 64-bit calculations of that plugin would create more resolution, there is also a loss of resolution on the way out, so the next plugin in line will only get 32-bit data even if it would be able to use 64-bit data.

By contrast, if every plugin had 64-bit data paths, and you’re using the 64-bit audio engine inside Cubase, any extra resolution that emerged from calculations along the way, up to 64 bits, would be maintained at each step in the audio path.

It could be the difference would be subtle, or something you might not hear at all. The concern, though, would be that, if you’re doing a lot of calculations via summing and processing through many steps in the overall audio chain, at some point there may actually be an audibly different result.

I think I also recall reading somewhere that there may be some extra overhead in switching resolutions between steps when using 64-bit CPUs, which naturally have 64-bit data paths and do 64-bit calculations.

I was thinking there would be no good way to test the audible difference consideration, but perhaps one way to do it would be if you try a project using only plugins with 64-bit data paths, then do separate mixes, with the only difference being that one sets the Cubase audio engine to 64-bits while the other sets it at 32-bits. I’d guess there wouldn’t be much audible difference in simple projects, but, as the processing got more complex, perhaps some difference might start to creep in.

One bottom line here is that, whether an end result has a full 64-bits of data or only 32-bits of data at any given step of the way, including the final stage, will depend on whether the plugin just before that step had 64-bit, or only 32-bit, data paths. Of course, the end result in terms of a final mix is likely to be reduced further – 16-bits for CD quality or 24-bits for other formats – but it is whether those results might be compromised by bit reduction along the way that is in question.

These are all good points.

Something to consider: 32 bits give you 194 dB of SNR/resolution, WAY above and beyond the noise floor of D/A converters, let alone any ambient noise in the playback environment.

So you’re already operating with a ton of resolution headroom at 32 bit, and with floating point math, you won’t even have to worry about poor gain staging reducing your bit depth.

I can’t imagine a scenario where the extra 193 dB of SNR/resolution you’d get by going full 64 bit across your data path would make a perceptible difference, so I just wouldn’t worry about this.

Perhaps. But the question is whether lots of operations (i.e. over the course of individual signal chains for elements in a mix and the summing of those elements) might result in an audible difference at the end of all those calculations (i.e. the final mix, or within stems of submixes).

To give an extremely simplified, but perhaps conceptually relevant example, let’s take one simple multiplication, one using the four decimal place version of the original number that is essentially being squared in this multiplication, and the other reducing the resolution to two decimal places.

I’ll use 0.1234 for this example. The actual result of multiplying this number by itself is 0.01522756, so that would be the full resolution result.

But let’s say we try this operation with four decimal digits at the input and output stages (and I’ll assume rounding, as opposed to truncation). Here we get 0.0152 as the result.

If we now try this with only 2 decimal digits of resolution at input and output, we are multiplying 0.12 by itself, which would actually give 0.0144, but ends up with 0.01 when reduced to 2 decimal places.

So we have a difference of 0.052 between the results. If the final output (“mixdown” equivalent) is only 2 decimal places, the 4-places chain ends up giving 0.02 due to rounding, while the 2 places chain gives 0.01. The full resolution result rounded to 2 decimal places would be 0.02, so the 4-place math gives the desired result, while the 2-place math does not. If this were some sort of audio operation, the difference here would likely be significant.

As I indicated, this is an extremely simplistic example, but what might happen over the course of an entire signal chain with a load of mathematical operations that are continually being rounded (or truncated) between steps?

For whatever it’s worth, I don’t actually worry about this stuff in that I’ll use whatever plugins feel most appropriate in any given scenario, and, though I do use PSP Audioware plugins, which, by and large (there are only a few exceptions), support 64-bit data paths a fair amount, I also uses Waves, Arturia, and a few other brands that only support 32-bit data paths quite a bit. The one place I tend to be a bit more sensitive to this than elsewhere (and still not always) is in my mix bus, which will end up dictating the input to my master bus. So, for example, if I want an SSL-type bus compressor, I might choose the PSP version (BussPressor) over the Waves version.

Conceptually, you are correct, and such errors can accumulate indeed, especially if you have highly iterative algorithms.

In practice (specifically, regarding the audio processing example discussed here), the safety margin of 16 bits (~100 dB) will prevent any such errors from accumulating to the point where they would impact the audible resolution/SNR (also, that’s where the mantissa and exponent of floating-point math helpfully come in, so that such errors due to gain differences are minimized).

Having written signal processing algorithms using both fixed-point and floating-point math, I’d love to hear about any edge cases somebody has come across where such error accumulation results in audible differences!

But in the end, you got it right by not worrying about this :slight_smile: And all else being the same, using a 64 bit data path sure can’t hurt anything either!

You are mixing integer and floating point formats. That is not valid. 32bit integer might have 192dB dynamic range, 32bit float has an excess of 1500dB.
The advantage of 32bit float is not the amount of bits added compared to 24 bit integer but the fact that there is practically no upper limit for a signal anymore, ie. unlimited headroom. It is not possible to clip a floating point signal.

Philippe had a pretty good description on the difference between 32bit float and 64bit float:

The question is: Can actually anybody, or better a significant amount of people hear the difference?

One could run a test. Same project, one time run it completely on 32bit float, the other time run it completely on 64bit float. Play out the results in a blind listening test to different people.

You could take the same test one step further - in order to gain insight how prejudice has an effect: do the same as before but advertise the 32bit mix as the 64bit mix to the listeners and vice versa.

I wouldn’t care much about “a significant amount of people” in the test scenario. More about whether I could hear the difference, and also people who had better ears than me (and so might hear things I might miss).

One key in this test would need to be that all plugins in the test supported 64-bit data paths, though. Because even one plugin with only 32-bit data paths would compromise the test – how much would likely depend where in the signal flow it sat, as well as on the type of calculations that plugin was making.

But, at least for now, it could only be a scientific exercise since so many of the plugins most of us use don’t support 64-bit data paths, thus requiring us to compromise on our plugin selection to even try the test. For example, even though I’ve got pretty much all the PSP Audioware plugins, and there are only a few of those that don’t support 64-bit data paths, I’ve never done an entire mix using only their plugins. For one thing, they don’t have plugins to cover some of the functionality I use commonly. But, beyond that, I’m much more of an “I’ll know it when I hear it” sort when choosing plugins and presets as starting points than an “I know what I want and how to get it” type. And my picking one plugin over another with the same or similar function is frequently one of trying multiple plugins and presets to see which gets me closest to something I like, then tweaking from there.

However, if all the Cubase plugins do support 64-bit data paths, and there are people out there who limit their plugin use to those, maybe it wouldn’t be so tough for someone like that to stage a test.

My personal expectations are that the results would be subtle, sort of like comparing an “in the box” mix to one using outboard processing when similar signal flow is set up with hardware versus plugins. And preferences would almost certainly be subjective as to which was preferred on any given song/mix.

My own starting to use 96 kHz for my projects when my system could handle it started with similar experiments in mastering my own recordings back when I was limited to a lower sample rate at the mix level, and so I was only switching to 96k for mastering. While the difference may have been somewhat subtle, there were differences I could hear – maybe along the lines of “more like analog” – and I preferred the 96k versions, despite having started with probably a 64-bit/44.1 kHz mix and ending up with a 16-bit/44.1 kHz mix. I probably was using mostly or all PSP plugins in my mastering chain at that point.