In practice, DAW audio engines and plugins process audio in widely varying - often extreme - ways. Yes, in abstract, a single truncation might not affect much. But multiply the lack of precision across a hundred tracks in an electroacoustic sound design project, each with multiple plugins (perhaps being converted between 32-bit and 64-bit processing). Multiply the lack of precision in and out of multiple components of each processing chain. You can imagine that in certain situations, the sheer number of calculations and the way the processors are used could amplify rounding errors significantly and cause deviations further and further from “accurate.”
Whether you would like the resultant sounds better or not is a matter of preference. You could arguably prefer the 32-bit-processed results. But the 64-bit processing capabilities built into Cubase and WaveLab allow our work to be more precise. Plus, it just makes sense to keep 64-bit plugin processing in 64-bit rather than convert back and forth needlessly.
Dallon426 and vinark, I agree with Raphie. This isn’t about hearing an increased dynamic range above a noise floor due to 64-bit processing. It’s about maintaining higher precision at more points along the processing path.
And what do you think rounding errors cause? (Distortion) Noise! And I meant dynamic range in the sense of usable range above the noise floor.
Still this update is meant for streamlining the audio processing not improved audio quality as stated by Fredo.
Yep, this is a good summary, PG and Fredo summed it up nicely from a accuracy and streaming processes perspective.
people confuse wordlenght, bitdept, samperate
True, on the audible side of things I would not claim that there is no difference.
Just that I in my room with my speakers dont hear anything conclusive, it feels better but that could easily be something I want to hear.
If anyone can show empirically (in a reasonable setup outside of bizarre edge cases) an audible difference (or even a measurable difference above -120dB) then I will eat my hat.
There would be no sound difference cause cubase 9 was also 64 bit engine it’s the down sampling that the new setting does .and it will probably lower cpu usage cause the mixer will do less calculations…fredo explains it well
Hey, guys, I actually think that you both could be right! There are two distinct things which have to be distinguished:
whether a plugin uses 64-bit floating point in (a part of) its internal processing and
whether the same plugin accepts 64-bit samples on its input/output.
Cubase knows and reports the latter (64-bit floating point I/O compatibility), however, in no way it can look inside of the plugin, which is the first aspect. It seems that Waves are not the only vendor who applies 64-bit processing only on necessary places but who does not allow 64-bit I/O since the rest of their audio chain is actually 32-bit. Another example is MeldaProduction: I had a discussion with Vojtech on this topic over at KVR Audio (New 64-bit Cubase 9.5 engine and Melda - MeldaProduction Forum - KVR Audio).
Yes you are right, those are 2 different things. My understanding from Steinberg was that all VST3 x64 plugins support double precission and communicate on 64bit wordlength by definition as it’s part of the standard. Hence VST3 plugins do not show in the capable list at all. But I might have understood this wrong.
Both VST3 x64 as well as VST2 x64 plugins (and applications in general) use 64-bit instructions for memory addressing - which is a pure IT matter, nothing to do with the sample depth. Generally speaking, x64 application/plugin can process 32-bit audio samples as well as 64-bit audio samples. Likewise, even x32 application/plugin could process 32-bit audio samples as well as 64-bit samples. But there is yet another thing and this is the interface between a host and a plugin which is given by the VST standard. VST2 was prepared only for 32-bit samples I/O between a host and a plugin. Therefore, while a VST2 plugin actually can utilize 64-bit floating point processing internally (since for some DSP tasks the precision really matters), for the output to DAW it has to convert the 64-bit samples back into 32-bit samples (even if it is a VST2 x64 plugin). On the other hand, a VST3 plugin has the option to accept 64-bit samples on its input and output. But the 64-bit floating point I/O is optional, not mandatory in the VST3 standard. A plugin vendor has to enable this capability.
In my opinion, 64-bit floating point audio engine implemented on the host side (DAW) could bring theoretical benefits if the signal path is completely 64-bit from start to end. However, if your plugins do not accept 64-bit samples on their I/O then the DAW has to perform multiple 32<->64 conversions on each plugin boundary and, consequently, the whole point of the 64-bit DAW engine fades away.
There are two distinct things which have to be distinguished: