I’ve always wondered why a company like this, doesn’t answer these questions. We pay…We use…We guess, and look to each other to speculate answers. What ever happened to the days of comprehensive product information, and follow up, from the company.
My guess is that they do monitor these posts. Every now and again, they do reply but I’m sure there’s a lot of repeat posts and too many to respond to. There are also many conflicting requests and complaints so it behooves them to stay in the background and work from there. I personally think they’re doing a great job with this program. It’s just that what is great for some is a disappointment for others because we all have different needs and personalizations.
We the users are their beta testers and they provide the updates accordingly.
From Philippe, developer of Steinberg WaveLab:
The interest of 64 bit float is not about “headroom” / “dynamic range”…
pro:
no need to convert between 32 bit and 64 bit float: 64 bit is needed by some plugins for their internal computations. 64 bit then means: small performance gain and no precision lost between succeeding 64 bit plugins.
Better audio precision when mixing audio signals. I explain this at the end of this message.
If audio devices ever go beyond 24 bit precision, 64 bit float will be needed (because 32 bit float means, in fact, 24 bit precision)con:
requires more memory, which can mean a performance lost (more memory to move). But as soon as a sophisticated plugin is used, this one is likely to become the bottleneck, compared to the memory overhead. Therefore, this is a “relative con”.
64 bit CPU instructions are as fast as 32 bit instructions, because the CPUs are 64 bit today. But certain rare instructions are faster with 32 bit float, because the CPU can conjugate 2 of them while in the same time, only one 64 bit instruction is performed (SIMD).Now, an explanation about 32 bit float vs 64 bit float, for mixing.
While 32 bit float means in fact 24 bit precision, 64 bit float means in fact 48 bit precision. This means, far more precision.
I can illustrate this difference with elementary school maths (this is an analogy of what happens in reality).Let’s say samples can have only values 0, 1, 2, 3, 4, 5,…
Let’s start with a sample that has value “3”
An audio gain of “divide by 2”, is applied. We get the value “1.5”, but this value is not allowed hence must be rounded, eg. the new value becomes 1.
Later another gain “multiply by 2” is applied. The new sample becomes “2”.Consequence: we started from value “3” and ended up with value “2”, while the two gains should have cancelled each other.
When this kind of loss is performed multiple of times (complex mixing), then errors stack up.
The consequence is not dramatic, because some errors are (randomly) compensated by others (round-down / round-up), but this compensation actually means “digital fog” aka noise.64 bit float processing pushes the digital fog far from the 24 bit domain. Hence a cleaner result at the end of the audio chain.
The difference 32/64 is therefore about “audio definition”, if your ears can sensible enough. But that’s another topic!
Philippe
Ahhh! An explanation from the cellular level. 
Even though no one can hear a difference… Have a read here:
Then have a read on the whole thread, and the links provided:
I’m sorry, but Fredo’s post (increased calculation precision removing the need for up-sampling processors) is not accurate ; OTOH, Philippe’s answer is concise.
The best way I know how to clarify the 32 bit F.P. vs. 64 bit F.P. discussion is to look at the whole digital process from A/D conversion to processing (EQ compression, fx, mixing) to final product.
First let’s review digital processing to grasp the basics. Then address the inaccuracies of Fredo’s post. Lastly let’s look at the current plugin situation to reveal an unfortunate development:
All modern DAWs work essentially the same way: digital files are ‘captured’ from the converter (recording) or read from the drive (playback); these digital files or streams are then sent through whatever Digital Signal Processing (DSP) we deem necessary (including editing, EQ, Compression, FX, Level Adjustment, etc.), then combined or added together - i.e. mixed, then the ‘mix’ file is written back to the drive. That file might be burned to CD or other media, or sent to be mastered, or encoded into mp3, m4a or other formats to be uploaded to the Internet, etc.
So 3 basic steps: A/D conversion, Digital Signal Processing (mixing), creation of final format (wav file on a drive, CD burn, etc.). Of course we also have D/A conversion throughout (we have to hear what we’re doing to all those bits), but this is only relevant if we are using external analog gear during mixing or some other step in the production chain; it’s important to have a good D/A converter to make good mix decisions, but D/A conversion is an ephemeral process if we mix entirely ‘in the box’.
A modern A/D converter typically converts the incoming analog signal voltages to a digital integer number expressed by n bits (per sample) - usually 24 bits per sample. All other things being equal, the more bits available for the converter to express the voltage of each sample, the more accurate the translation from a given voltage level to its digital equivalent. The sample rate of an A/D converter dictates the upper limit of the frequency bandwidth (48 kHz sampling provides a 24 kHz bandwidth - minus whatever extra the Low Pass or decimation filter removes to prevent aliasing, based on the steepness & quality of the filter); The word length of an A/D converter defines the maximum achievable analog voltage to digital sample level accuracy (and, by extension, the codable dynamic range; the actual ‘dynamic range’ of a converter is limited by its noise floor, the quality of the analog circuitry before conversion, the stability of the clock and other factors). The easiest way to view this is from the Maximum Operating Level (MOL - digital maximum) down. Each bit expresses 6.02 dB. 16 bits is about 96 dB from MOL to the Least Significant Bit (LSB); 24 bits provides 144 dB from max to the LSB. This is where some can be confused: although there is a relationship between an A/D’s word length and dynamic range, it is more accurate to say that 24 bits provides more (smaller) steps for a more accurate translation from analog voltage to digital number. Thus a well constructed 24 bit A/D converter with low noise and stable clocking will more accurately express the incoming analog voltages than the same converter set to capture only 16 bits (all other aspects being equal).
- 1b)
What happens in a DAW is a different matter altogether. Any type of processing (from a simple gain change to compression to mixing , etc.) is only as accurate as the internal processing precision of the DAW (and the plugins used). Any processing expands the word-length of the digital stream, that expansion is limited by the internal calculation resolution of the DAW and any other DSP in the stream. A 32 bit floating point engine provides 24 bits (some sources say 25 bits) for the mantissa (integer) and 8 more bits for the exponent (an expression of how many zeros to add to the integer, and tied to how the integer is multiplied or divided). This allows for a huge range of numbers (which is why an ‘Over’ in a DAW doesn’t necessarily indicate clipping until it hits the ‘real world’), but the actual dynamic range never exceeds the precision of the mantissa! A 24 bit mantissa will never have more dynamic range than 144 dB (a 25 bit mantissa never more than 151 dB); though floating point can generate a huge range of numbers, numbers beyond the dynamic range you are operating within are swamped - ignored. But the 8 bit exponent does increase the calculation precision within the operating level, reducing rounding errors and thus digital distortions and artifacts from those errors. It is unlikely most people will detect these rounding errors with low track counts and minimal processing; but a mix with e.g. 100 tracks and 500 processors increases the possibility that the mix will start to sound a little grainy. And remember, even a fader is a processor.
Based on the above, consider a 64 bit floating point calculation precision (offering a mantissa of 48 bits and an exponent of 16 bits, or, per this post, double precision is implemented as 53 bits mantissa and 11 bits exponent - though it is discussing summing: Does 64-Bit Summing Sound Better?). Now you have a processing precision that encompasses 289 dB (mantissa of 48 bits) + double the accuracy in the 16 bit exponent (or 319 dB if the mantissa is 53 bits, + 11 bits for the exponent= 3 more than 32 bit F.P.). Processing is far more accurate and errors are pushed so far down that we will never hear them, even in the most demanding mixes. (Full disclosure: I don’t know if ‘Double Precision’ is always implemented as a 53 bit mantissa & 11 bit exponent in summing or in plugins, but either way it’s a much more accurate process; nor do I know if all DAWs limit the output of VST 2 plugins to 32 bits or if that is a Cubase limitation).
So in a 32 bit F.P. DAW, all calculations are limited by the 25 bit mantissa (an accuracy limit of 151 dB) and 8 exponent numbers, which expands the potential internal operating range and, to a lesser degree, the calculation precision. In a 64 bit F.P. DAW, the calculations are limited by the 48 bit or 53 bit mantissa (either 289 dB or 319 dB), plus the longer exponent, which both expands the potential operating range and the reduces the rounding errors further. Higher precision and significant reduction of rounding errors - in a demanding mix, eventually it will be a noticeable difference.
Of course if a VST 2 plugin (or a 32 bit VST 3 plugin) is inserted into a 64 bit F.P. stream, 32 bits are ignored entering and exiting that dsp step; a loss for sure, but the earlier and later 64 bit F.P. calculations are still more precise. And perhaps most critically, the DAW editing, gain adjustments & summing are done in 64 bit F.P.
I’m not making some big case that 64 bit F.P. sounds better (well maybe I am - I sometimes used Studio One Pro to mix & master stems bc of its 64 bit f.p. engine, and yes, I thought I heard a difference every time); it’s really about understanding when 64 bit f.p. makes a difference and when it doesn’t. If you have nothing but 32 bit f.p. plugins, it will reduce the potential accuracy, lopping off 32 bits every time the stream enters such a plugin; OTOH, if your 64 bit F.P. plugins sound like garbage, you’ll just have more accurate garbage! Besides, all of UAD’s plugins are 32 bit F.P. (except for the Massey MDW EQ) and most of them sound great - I wouldn’t stop using them bc I’m worried about more rounding errors! And some plugins do many calculations to each sample, so the internal precision of a plugin may be significant even if it outputs only 32 bits; the internal rounding errors are reduced. It’s important to know when, where and how internal precision is affected, but ultimately, if it sounds good, that’s what matters. Again, I’d advocate for 64 bit internal precision for the increased editing and summing precision, and not worry too much about the plugins unless you hear a difference.
Okay, so that’s my processing precision analysis. I know there are terms, explanations and possibly conclusions that some will disagree with. I only know what I know about the calculation methodology and limitations of DAWs and plugins (& I tried to stick to just that), and If I were to be totally precise and thorough, this post would be ten times longer; so if you do feel the need to offer corrections and/or clarifications, please be sure you know what you are talking about.
I do not buy Fredo’s argument that calculation precision has anything to do with over-sampling (over-sampling or up-sampling plugins multiply the sample rate of a digital audio stream before processing, then divide it back down to the original sample rate at output). Over-sampling is commonly used in plugins for a few reasons; in EQs, it is used to smooth out the high frequency curves and/or to increase accuracy and reduce ripple in Frequency Domain type EQs (typically Linear Phase). In non-linear plugins (compressors, tape emulators, etc.), over-sampling is used to push the non-linear distortion byproducts far beyond the Nyquist Frequency; this allows for a more gentle anti-imaging filter on the down-sample side, which often improve the sound of these processors; this is particularly beneficial with Distortion plugins & other plugins that add harmonics, especially when the harmonics are added in a dynamic manner - e.g. ‘circuit modeled’ plugins. Up-sampling can also be beneficial for non-linear processors since it provides the internal DSP more samples to work with (e.g. more accuracy for the ‘VCA’ component in a compressor to track level fluctuations, e.g. the Elysia Alpha Compressor). But these issues are unrelated to the internal processing precision as expressed in word length. Increased word length does not eliminate the need for or benefits of up-sampling in a processor - those are two different issues. Sample Rate = Bandwidth; if a DSP benefits by working with a higher bandwidth, increasing the internal calculation precision will not eliminate the benefit of up-sampling. There is no correlation or equivalence here. OTOH, higher internal calculation precision can still offer its own benefits in up-sampling DSPs if implemented properly (just the same as DSPs that don’t up-sample for processing); this has always been true for the same reason: more bits = less calculation errors.
Now, a look at the current DAW vs plugin situation: Ironically, certain plugin manufacturers used to boast that their plugins ran at ‘double-precision’ or 64 bit floating point, etc. That made sense for plugins that carried out more than one calculation, like the Ozone Mastering plugin. Brainworx used to tout 64 bit float internal precision as well. Unfortunately, when I installed Wavelab 9.5.25 on my system and looked at the plugin list, most of the newer iZotope and Brainworx plugins were listed as 32 bit internal precision, especially the VST3 ones! Ironically, there were numerous instances where the VST2 plugins reported 64 bit internal precision and their VST 3 counterparts reported only 32 bit internal precision; and Steinberg says VST 2 plugins can’t pass their 64 bits along the path (32 bits get truncated at the output) I tested this with the bit meter in Wavelab and found it to be true: a VST 2 plugin Wavelab reported to be 64 bit would only light up the 32 bit indicators; a 32 bit VST 3 plugin did the same; a VST3 plugin Wavelab reported to be 64 bit would light up the 64 bit indicators on the Bit Meter (make sure to set it to ‘true’ mode; ‘intuitive’ mode doe not accurately display the bit values).
That leaves me to wonder:
What is the point of releasing 32 bit VST3 plugins (when the same VST2 plugins have 64 bit internal precision) and:
a) only VST3 plugins can pass 64 bits back into the mixing path?
and
b) More VST based DAWs can operate at 64 bit internal resolution, now that Steinberg has joined Sonar, Studio One and others with a 64 bit engine?
Any thoughts on section 3 would be most appreciated! Or comments, corrections, etc on the rest…
1 Like