32 bit float is, quality wise, the same as 24 bit integer. The added 8 bit is used as the exponent which is what makes the dynamic range super high but the SNR is still -144 dB, the same as 24 bit integer.
1 Like
Well, to be consistent, if my internal processing precision is set to 64 bit float and if the storage problem doesnât matter anymore, wouldnât it make more sense to set the Record File Format to 64 bit float?
And for more precision and audio quality, what would be the best ratio to establish concerning the sample rate for a 32 or 64 format despite the fact that in the end, all this audio will be converted to 24 bits or 16 bits depending on the needs?
Many plugins implement both 32-bit and 64-bit code paths, because the VST plugin API allows you to do one or both.
This might be true for 32-bit fixed-point values, as used by DSP chips from the distant past, but this is not true for 32-bit floating point.
There are also other problems than signal-to-noise in plugin processing. Read below.
So much mistaken math in this thread.
First: a â32-bitâ floating point number has 24 bits worth of precision. (It has a 23-bit mantissa, but gets one extra bit âfor freeâ because of the specifics of the encoding.)
24 bits of precision, buts the quantization noise floor at about -146 dB.
Using 32-bit floating point precision in Cubase (or any other system) will give you quantization noise thatâs at -146 dB, and youâll probably want to add dither to get it to -143 dB but better sounding.
Second: -146 dB quantization noise is still quite imperceptible, because you need to be playing at full scale to get to that point. If your signal is less than full scale, the quantization noise will also lower itself â this is what the âfloating pointâ is all about. I measured my near-field Genelecs to about 112 dB SPL before distorting out (if I remember correctly â this was long ago â I donât run them that hot, ever, because I like my ears) so the quantization noise would be below 0 dB even at max â and ears mask signals, so you canât even hear a +20 dB signal when the room is blasting at 110 dB, much less a -36 dB signal, which you can never hear, almost definitionally.
A 64-bit floating-point number, which many VST plugins can process with these days, gives you 52+1 bits of precision, so a little over 320 dB of headroom above quantization noise at full scale. Thatâs ludicrous overkill, if all youâre thinking about is quantization noise.
However, in signal processing, something called ârecursive filtersâ (âIIR filtersâ) are very, very common. Almost all EQ, anti-aliasing, and even compressor responses are implemented using IIR. Recursive filters, especially for frequencies that are low compared to sampling frequency, and up accumulating error in an exponential manner.
Thus, itâs actually very very hard to design an EQ/filter that is stable at 20 Hz (or even 100 Hz) when using 32-bit floating point, but itâs quite doable at 64-bit floating point. Back when VST only did 32-bit, many plugins would internally convert to 64 bit just to be able to run stable filters, and then convert back.
Constant conversion back and forth may eventually degrade the signal, in theory, but in practice youâd need so many plugins that you couldnât plug in enough screens just to fit the name of all of them for that to matter. But thereâs some CPU load involved in the conversion, and the built-in Cubase filters/EQ will certainly work better in 64-bit than in 32-bit.
So, if you ever have a plugin that suddenly goes silent or clicky when you crank frequency low or feedback high, it might be that youâre running into the numerical stability limits of 32-bit floating point values, and if the plugin also supports 64-bit processing, changing your project to 64-bit may fix it.
Btw: Whatâs often done in practice, is add a small noise signal around -120 dB, so 20 dB above the quantization noise floor, to prevent the plugin from reaching the denormal/numerically unstable state. This noise signal could theoretically be amplified by downstream plugins, too, so it may be that your signal chain becomes quieter when you switch to 64-bit processing, where the same kind of signal only needs to be at -300 dB to serve.
1 Like
Not really, as the conversion from the stored 32bit float only needs to be done once and not with every plugin.
Also, using the industry standard 24 bit integer as a the starting point, 32 bit float will use 33% more storage space while moving to 64 bit float as project setting you will use 100% more storage space on top of that for no reason, as 32 bit float is already enough to avoid clipping.
As i wrote in my next post, I corrected myself. SNR for 32 bit float is about the same 24 bit
This is not entirely true. How hot you run your monitors is just a matter of how much you turn your volume knob and thus how much amplification you are doing. There is a difference between the dBFS used in the digital world and the SPL you get from your monitors.
To get the full benefits of the 144dB SNR from 24 bit, in theory all you need is to make sure the signal is hitting 0dBFS before AD conversion. Now this is only in theory as there are other factors that comes into the equation and practically even the best converters will not give you more than 120âish dB SNR.
Thanks, that makes good sense to me.
So what you are saying is that the signal remains at its original bit depth after exiting a plugin ?
On another Topic I got told :
(expand the quote so see my original statement)
Here @KHS seems to be on the same opinion that the signal is converted to the internal 32 or 64 bit FP for the whole signal chain.
What is the definitive answer ?
Is the signal actually converted to Cubase internal bit depth in between plugins and processing, or is the internal bit depth only used during mathematical operations and the actual signal always stays to its original bit depth when the processing has been done ?
Thank you for the link.
Very clear as an explanation.
64 bit float, why not use itâŚ
The definitive answer is: The audio stream is converted to 32 or 64 bit float format as soon as it enters the signal chain. And it stays there for the whole signal chain.
In the [Studio] > [Studio Setup] > [Audio System] > [Advanced Options] panel you can choose between 32 bit or 64 bit float processing. This setting affects the entire signal chain.
Let us assume that you have selected 32 bit float processing, and you have imported a 16 bit WAV file into a Cubase track.
Now put a bit meter into an insert slot. For this test I recommend the free âBitterâ by Stillwell Audio. When you play the file, Bitter will show that only 16 bits are used in the audio stream. In reality, however, the audio stream is already in the 32 bit float audio format.
A 32 floating point number consists of a 24 bit significand and an 8 bit exponent. (The significand is sometimes called mantissa, but this is not correct.)
Because we have not applied any processing to the audio stream so far, the bit meter shows that only 16 bits of the fp number are used. But note that this is not a stream of 16 bit integers; it is a stream of 32 bit floats in which only 16 bits of the significand are nonzero. These are just the bits that came from the integer numbers. The remaining bits of the significand are zero. The bits of the exponent are also zero. This results in a neutral multiplier because 2^0 = 1.
Now let us apply some processing. We can simply use the gain fader for this. Put another instance of Bitter into the track, but this time post fader.
When the fader is in neutral position (0 dB, meaning gain = 1.0), there is still no change. Only the original 16 bits of the significand are used. Now move the fader slighty. The gain value changes (e.g. to 0.9948 or 1.7493), and now Bitter shows that all 32 bit of the fp number must be used for the audio stream.
If you change your processing precision to 64 bits you will get similar results: As soon as you move the fader away from its neutral position, the sparse fp audio stream will change from 16 used bits to 64 used bits. But the audio stream is always in floating point format.
As long as only 16 bits of the significand are used and the exponent is zero, the fp audio stream is fully equivalent to a 16 bit integer data stream. This means it can be truncated to 16 bit integers without loss of precision, i.e. without the need for dithering.
As soon as processing is applied, all bits of the fp number are used. You cannot truncate to 16 or 24 bits without loss of data. The bits that represent very low signal levels will be lost.
In order to minimize the damage caused by loss of precision, you can apply dither noise before truncating. Dither noise prevents unpleasant truncation distortion. On the other hand it will raise the noise level a bit, but this trade is beneficial.
Dithering is important when you go to from fp to 16 bit integer format or even lower. In case of a 24 bit integer target format the difference will most likely be inaudible. I would still recommend dithering because it is so simple to do. But donât worry if you have forgotten to dither in this case.
2 Likes
Thank you very much for this detailed post !
This clearly answers my question, especially with the Bitter plugin trick.
I have experimented and saw that the bit depth will indeed increase to the internal 32 or 64 bit as soon as it goes through any processing or summing, and stays like that for the whole chain. (I understand it is already even without processing, but isnât visually displayed on the Bitter plugin because of the floating point, as you explained in your post)
I run Cubase at 64 bit float internal, and have noticed that some processing do not make use of the full range. For example Transpose and AudioWarp go to 32 bit, while Steinberg plugins go to 64 bit, and gain faders go to 48.
If you believe that the innards of the plug-in are part of the âsignal chain,â you cannot guarantee this.
When Cubase says â32-bitâ or â64-bitâ mode, then all Cubase processing and buffer-forwarding happens in that format, but source files may obviously have a different format, and plugins may do something different on the inside.
Some plugin may not support 64-bit VST processing, so it has to convert to 32-bit to send it to the plugin, and then back out to 64-bit once it comes out of the plugin.
Which then gets to the question: If I chain two plugins, neither of which implements 64-bit processing, and Cubase is in 64-bit mode, will Cubase convert the output from the first plugin to 64-bit, only to immediately convert it back to 32-bit again for inputting it to the next plugin? I kind-of doubt that it would matter in practice, but itâs a question we donât have the answer to, and which would be very hard to answer without reading the Cubase source code directly.
(Maybe some special plugin could be written that could detect this, if one was really curiousâŚ)
Well just do the experiment with the Bitter plugin.
Waves plugins always expect 32bit float, although they processes the signal internally at 64bit double precision.
Waves therefore always convert any incoming signal to 32bit float first.
( Last i checked was 2 years ago, could have changed)
That is a lot of back and forth.
I donât use any Waves plugins anymore, Steinberg plugins have become so good over the years that I can do without them.
In my experience 64bit dp, gives me slightly better performance. But again it depends on what plugins are used, and IMHO worth to experiment with.
âIf you believe that the innards of the plug-in are part of the âsignal chain,â you cannot guarantee this.â
Your comment is correct. With âsignal chainâ I meant the positions before and after an audio processor.
What happens inside a plugin is a different matter. Many 32-bit plugins will increase calculation precision to 64 bit or even 80 bits. This is necessary in cases where many calculations must be performed over and over again in order to obtain the result. Without increased precision tiny errors would add up and make a difference.
Once the final result has been obtained, precision can be brought back to 32 bits.
Audio plugins may not only increase calculation precision temporarily. In certain cases they will also upsample the audio signal internally by a factor of 2, 4, 8 or more. Saturation plugins may do this in order to reduce aliasing. The final result will be brought back to the original sample rate before it is output.
For the signal chain (between the plugins), 32-bit precision is absolutely sufficient. So why do Cubase and other DAWs (e.g. REAPER) offer 64-bit processing?
The answer is that internal 64-bit processing has almost become standard for plugins by today. And more and more plugins also offer full 64-bit processing, meaning that they also input/output 64-bit fp numbers.
If we use plugins with full 64-bit processing, and also set Cubase to 64-bit processing, the entire signal path becomes much simpler. There is no need to convert floating point numbers between 32 and 64 bits of precision. The 64-bit setting may actually require less processing power than the 32-bit setting.
If you use third-party plugins, you can open the VST Plug-in Manager. There is an option to show only plugins that offer full 64-bit processing. If all (or most) of your plugins offer full 64-bit processing, the 64-bit processing option in Cubase does make sense.
If all (or most) of your plugins offer full 64-bit processing, the 64-bit processing option in Cubase does make sense.
All Cubase stock audio plugins are 64 bit float, not all 3rd party plugins, also in the case of VSTi none of the stock plugins, other Steinberg plugins (GA6, HAL 6, The Grand) and 3rd party VSTi are only 64 bit float, the list is empty.
Two questions: 1) Are VSTi affected or supported by the Processing Presicion option? 2) going back to the question at the beginning of the thread, does using 64 bit float in such a context affect Cubaseâs performance or has a significant impact on its performance?
Under the hood, there is very little difference between a VST instrument, and a VST effect. Whatever holds for one, usually holds for the other.
There is a small effect in performance, but itâs unclear which direction the effect will have in each case! On the one hand, 64-bit means more bytes in each buffer, meaning the L1 cache will see higher pressure, meaning large sweeping processes may run slower. On the other hand, 32-bit may mean that plugins that prefer 64-bit, have to convert to 64 bit on the way in, and then back to 32 bit on the way out.
Both of these effects are small, and whether you can actually tell a difference, depends very much on the particular project size and specific plugins/instruments used.
I generally donât top out my workstation, so I havenât had a problem with 64-bit.
Except for that one NI instrument that just wonât play right because it uses more CPU than my poor 1950X Threadripper can supply ⌠(Straylight, I think? Or Pharlight?) 64/32 bit doesnât make a difference, there.
Thanks all for this post very helpful , Below could also help users make there mind up
I am having problems with High Track counts and HALion 7 , I am new ish to Cubase 12 , while testing best settings I found 32bit was a game changer with Kontak7 and HALion 7 ⌠check this thread
As I am running an M2 Mac , I am now wondering if there are any problems running Cubase in 32bit mod ?
I have 96Gb ram and Cubase 12 seems to be happy accessing all of that even in 32bit