You should forward this post to Steinberg. I think they missed it. We now get glorious precision and accuracy and transparency via the new 64-bit floating point mix engine.
You are totaly missing the point.
Any critical process is executed within double precision (64bit). That was so within the old engine, and is still so in the new.
Plugins handling critical processes also upsample to double precision.
Old VST2 standard was 32bit in- and out.
VST 3 is 64bit in- and out.
Making the engine full double precision eliminates the need for upsampling and truncating before and after each insert slot and from each channel to bus/bus/output. So since the plugins are (or can be) 64bit nowadays, there is no reason at all for “converting” before and after the inster slots.
So what happens is that by having a 64 bit engine from start to end, a lot of unnessesairy processing is removed from the audio engine.
Does this make a difference in sound quality: Nope. Only under exotic laboratory conditions you would be able to expose the “gain in quality”.
It does simplify the piping/processing and programming throughout the audio engine?
But indeed, the majority of people still thinks that “more is better”, so even for that reason alone, the change is justified.
On the list of things that should have been fixed or improved way earlier I’m not going to find 64-bit processing.
In case it wasn’t clear: I don’t mind a 64-bit engine, but don’t spend time and money moving towards a 64-bit engine while releasing such buggy software as Nuendo 8.
So you think that Steinberg development is a bunch of boyscouts that jump on anything that supposily is urgent at the current time?
There are two developers who are constantly working on the audio engine to keep it up to date, to keep it on par with all un-announced changes in OS’s, to avoid spagetti-code, and to improve the functionality of the Audio engine. So the 64 bit audio engine is the result of work that has been planned and executed years and months before any of the issues you are talking about came to surface. That is their work, nothing else. And they shouldn’t be ashamed to commit their improvements/developments to the latest release, just because it could give some people the weird idea that they have spend their time on something less important than the important things du jour.
Here’s what the creator of Wavelab had to say on the subject, from an unrelated discussion: https://www.steinberg.net/forums/viewtopic.php?f=244&t=125236#p686179
The CPU performance boost that VST3 plugins can get from full 64 bit processing is likely the main reason why the Steinberg engineers chose to work on this. This is something that will benefit pretty much every Cubendo user to some extent. Like Fredo said (and everyone ignored) it’s not just about the minuscule improvement in transparency, which is what this thread was originally about.
The description on the Cubase 9.5 page is just the marketing team doing its job. They simply say that it’s more transparent, but they’re intentionally vague about how much difference it makes. That’s the easiest way to sell the feature to people who may not know much about audio, and make them try it.
One thing that some Nuendo users seem to constantly forget is that Steinberg isn’t a one man show, they have almost 100 people working on both Cubase and Nuendo and just because they introduced one feature you think you wont need, that doesn’t mean that no work is being done on bug fixes and other features and improvements.
On-topic, because it responds directly to the Steinberg employee/moderator’s thread topic. So it’s not “hijacking” and won’t be deleted, right?
Fredo, I’ve read your words in this thread several times, but I didn’t see where you explained why you are apparently contradicting Steinberg’s prose regarding the 64-bit engine. Apologies if I’m missing that … could you address that again please? As I see it, there is a discrepancy between what you write and what Steinberg on its website does:
You write in your thread title and the OP of this thread, “more bits is not better”, and you also write a few posts up:
“Nope, 64-bit doesn’t make a difference in sound quality”.
But Steinberg writes (https://www.steinberg.net/en/products/cubase/what_is_new_in_cubase_95.html ):
… the 64-bit engine will “take your sounds to new heights”
“Get your mixing down the line — with the new pristine 64-bit floating-point mixing engine you will no longer need to compromise when it comes to quality, precision and realism. The advanced audio engine calculates your summing, mixing and effects processing with double-precision accuracy, performing each task with the utmost level of detail, dynamics and transparency”.
Those seemingly contradictory group of statements is what is confusing me. I’m interested in buying Cubase 9.5 (with the brand new 64-bit engine), but as there is the possibility of taking a CPU hit compared to a 32-bit engine, I need to be sure I understand what is actually being sold. (If it helps you to know, I am not an engineer or professional. Though I’ve been buying Steinberg software and hardware for 10-15 years, I’m just a self/internet-taught home hobbyist. So I understand it’s very possible you have explained all this, just in a way too complicated for me to understand, and if so, I apologize for this post).
(BTW, my post of last night saying roughly the same thing seems to have disappeared without a trace, I could have sworn I hit send. I’m sure even a Steinberg moderator wouldn’t delete a post without noting so, so I guess it’s my error somehow. It was a big long one also, probably unecessarily so, the silver lining of it’s have gone missing is I probably communicated the same idea in less words!)
There are different things at play; first of all the “more bits = better”.
Technically, on paper and in laboratory tets, the 64-bit engine will indeed show an improvement in quality.
In real life however, it won’t make a difference. Unless you set up some exotic test that does +90dB in volume/processing/lower 90dB/processing/ + 90dB, etc …
An analogy …A 32bit calculator has 192 digits after the comma, a 64 calculator has 384 digits after the comma. That doesn’t change a single thing for adding and substracting numbers. (which is exatly what a audio engine does, adding and substracting)
It does make a difference for multiplying & deviding numbers … But that is not part of the engine, we are talking plugins & processes now.
Critical processes already use double precision (64bit)
The “old” engine was 32 bit from start to end. So whenever a process was executed in double precision, the output of the engine needed to be “upgraded” to 64 bit, and after the process being truncated to 32bit again. There might be a tad of precision-loss in that process.
With a 64bit engine, no need for converting from 32 bit to 64 bit anymore. So we go from “might be” a precision-loss to absolutely no precision loss.
Now that most of the third party developers have comitted to VST3, the in- and output of any plugin now is 64 bit.
So going in- and out of the engine doesn’t need any converting anymore (same as above)
In short, the additional advantages (say, the side-effects) of the engine-upgrade to 64bit bring more benefits and improvements than the precision that is gained within the engine itself.
It is very difficult to explain something complicated in a non-complicated way, and there is also no point in trying to explain these nuances to the public.
Hope this explains it a bit. (pun intended)
Thank you, Fredo. I’m am checking my plugins to see which are 64-bit (they almost all are VST3).
I asked in another thread, but perhaps it’s ok to ask here also …? I was wondering why there is a toggle to 32-bit engine in Cubase 9.5. Does its presence suggest there are circumstances where the 32-bit engine may be a better choice?
Thank you -
64bit all over does require a bit more memory and memory management from your computer.
So if your machine can’t handle it, you can switch back to the old 32bit.
I was not aware that they left the switch in, I thought it only was for betatesting purposes.
(I focus more on Nuendo, so I am not really up-to-date with Cubase details)
Anyway … that gives you a chance to compare a 64bit mix and a 32-bit mix.
Render both out in 48/24 and flip phase to hear what the differences are.
Not expecting to hear any from what you’ve posted, and others.
Thanks again for the explanation.
I’m pretty sure for many of us this is going to be the hot subject for some time. One which will never truly be put to bed.
That well-known engineer should stay by his tape-machine and analog desk… FACEPALM (we need a new emoticon)!
As long as we are talking about stuff that ends up on CD or DVD, I agree with this statement.
88.2 to 44.1 kHz is a simple dvising by two. It results in pretty even numbers.
96kHz to 44.1 is a much more complicated computation, which will leave much more artifacts after conversion.
So, yes …
The problem with these studies is it looks at the best possible scenario, a full 16 bit signal which is only in the peaks. Typically, on a 16 bit audio recording, your averaging around 11-13 bits or less. Bumping up to 24 bits brings that average to over 16 bits and NOW you have nice clear audio. 24 bit has smaller steps in between dynamics also so rounding errors are more subtle.
Also, you don’t need a Mic that records 192kHz. The reasoning of using higher sampling rates is not so you can HEAR 192 kHz, it’s so the filtering os so far beyond the human hearing range that it doesn’t effect what you are hearing.
And I still like the photo analogy. It’s a picture of an Apple yes but at higher resolution, you can see the various markings on the skin, details in the shadow etc. Higher quality audio produces a much better audio image of the recording. It’s still a snare drum, but I can hear the subtle overtones of the drum, the rattling of the snares against the bottom head and subtle nuances that unexperienced listeners don’t notice or don’t care about.
That’s not how it works though. You’re thinking about it the wrong way.
First of all we’re not taking an entire signal and representing it with a sample, multiple samples become the signal during reconstruction. So really the one sample just represents one amplitude at one moment in time.
Secondly, I really think you’re looking at numerical values in an odd way. “Resolution” isn’t determined by how many digits you “fill” or “use” but by the lowest possible value. Consider the size of errors from quantization in these two examples:
Available range for both: 00000 to 99999
Input 1: 12345.6
Output 1: 1234**6**
Error 1: 0.4
Input 2: 012.3456
Output 2: 0001**2**
Error 2: -0.3456
Error in all cases = -0.499… to +0.5
Lastly: read up on sigma-delta (or “delta-sigma”) conversion on Wikipedia or elsewhere. The converted analog signal ends up a a 1-bit stream that gives us an average level that is then decimated into a 16- or 24-bit word representing an average during an oversampled period of time.
Unless you are going to spend years studying DSP I don’t think any of us are qualified to give an opinion, to be honest. Suffice to say - after years of looking at this I have reached the conclusion that 24 bit 44.1 khz at most 48khz is sufficient taking account of nyquist . most adults cant here above 15 kHz. There are some studies showing higher sample rates like 192 can be preferred for some genres of music - but the sample size is small (pun intended lol) . Then there’s this :
Here is the issue. At maximum levels with too much compression , most of your audio will be between 16 and 12 bits so lets say average of 14 bits, and that’s probably generous for most types of music. At full 16 bit, the numbers pan out. But you are rarely hitting a full 16 bit signal. Your average is probably closer to 10 bits.
on a 24 bit signal, you ar getting a consistently higher resolution on average, most likely 16 bit an above for a good part of the signal.
You still don’t understand how it works.
I just read that interesting thing about bits…
It is kind of true, yes… But only because it mainly talks about music applications, where in fact, with absolutely no dynamic in the final mix, there is little difference between 32float and 24 bits. (even 16, indeed)