There is a feature I would really like (and need) to be implemented in Cubase/Nuendo.
I have noticed, that when exporting an audio file from let´s say a 44 kHz project to an audio file of 96 kHz…
I obtain a file that is technically at 96 kHz.
This file only contains frequency content of up to 22 kHz
so this wouldn´t be REAL HD.
Cubase projects (as any other DAWs nowadays) can only work at ONE sample rate.
Well, many of us do want to create HD mixes (from 88.2 kHz upwards), which forces us to create a project at that frequency. This has obviously a higher CPU impact than working at 44.1 kHz. As a consequence, we can use less VST instruments. As FREEZING and RENDER IN PLACE are made at the frequency of the project (of course), there would be no gain in quality at the moment of rendering.
BUT: If I could export my instrument tracks at real 96 kHz, I could …
create a completely independent project for productions at 44 kHz, with maximum amount of VST instruments, then exporting audio at 96 kHz, and then …
create a new project for mixing, which actually contains and processes 96kHz audio.
Why would I want this?
It´s about CPU Usage at the moment of production and later on, in the mix.
If I work producing at 44.1 kHz, but exporting at 96 kHz (with frequencies up to 48 kHz), I will have more CPU power for more instruments.
As I mix with audio files, there is virtually no CPU impact when playing back these audio files, therefore I would have almost all CPU power for FX and automation.
This functionality would benefit everyone producing music with VSTi for HD, especially with not so powerful computers.
Let me know, what you think, "below in the comments "
I don’t think what you are after is possible. If a project runs at 44kHz then there can’t be any content above 22kHz whatever you do. It has to run at a higher sample rate.
His suggestion is to run the project at 44/48 , but to “automatically” switch it to 88/96 on export. The host has to notify all the plugins of the new SR for that, but it should be doable from the VST3 API if I understand it correctly.
While that should theoretically work (afaik Reaper can do that), there is a t least one thing to consider, and that is what you will hear when playing back the project at base SR is not necessarily identical to an export at a higher SR. Some plugins behave differently at different sample rates, a sample based instrument with samples recorded at 48 would need to upsample (but will not have any frequencies in the upper octave that way), other plugins would maybe not upsample compared to base SR, some reverb algorithms are known to sound different at different sample rates. Whether that is noticeable I can’t say, just something to consider.
Personally I would also question the premise that “more is better” (more instruments, more frequencies) ;). In a mix, I would lowpass most of the signals anyway because I consider frequencies above the human hearing as useless HF noise that might even do more harm than help. Just as I hipass unnecessary low frequency content…. But that is just my opinion, if anyone wants to do that, please do.
I would suggest just getting a more powerful computer so you are sure that the signal you hear is identical to the rendered signal…
There are many plugins on the market that oversample incoming signal then apply eq etc., almost all the uad does this, many pa, voxengo, and others have oversample settings. Applying filters in higher SR helps, it’s not just about existence of signal above SR/2.
Every plugin is told what the sample rate of the project is, when it is instantiated.
If Cubase was to suddenly feed data at a different sample rate to the plugins, then they would sound all wrong.
Thus, the correct way to “generate 96 kHz output from 44 kHz project,” is to render at 44 kHz (which the plugins expect,) and then upsample with a good rate converter algorithm.
This may still have some benefit, for example for hardware where the 96 kHz playback rate makes their reconstruction filters sound better.
If you want to actually generate sound at 96 kHz, you have to change the project sample rate to 96 kHz.
This is pretty easy, in Project Settings; just make sure to answer “no” to the questions about whether you want to convert the audio files, and whether you want to use sample position for events.
Then render out at 96 kHz.
If your project is too heavy to monitor at 96 kHz, then you need to convert back after rendering. (Or do the conversion/render on a copy.)
Note that, if you render with a project/sample rate setting you haven’t actually monitored, you may be surprised. Some plugins have bugs (or “design intent,”) where they sound different at different sample rates, because they don’t do the appropriate conversion of parameters when the rate changes, or their S-to-Z-transform function is dodgy, or they use fixed tuning values for internal algorithms, or whatever.
I can see more than one motivation for this suggestion:
Me for example, I am not necessarily someone of the “More is better” category, but I certainly do prefer for example have a separate track for every different sound. This helps avoiding automations in EQs for example. And as my projects contain a lot of sounds designed especially for it, of course I occasionally have a lot of tracks, in which a sound appears only once in a project. (Yes, I use mixing groups later , and nowadays a plugin goes into Sleep mode, when not generating audio… ).
Unfortunately, some plugins on the market are not perfectly optimized CPU wise. This might be seen as a general tendency, as more powerful computer are released every year. I remember CamelAudio Alchemy for example, when it came out, I couldn´t have more than 2 instances of it in a project, because of the CPU impact. On a major scale, this applies even more to complex NI REAKTOR ensembles, to have a more recent example. This also influences the choice of plugins I use in my productions, which actually should not be the case to be honest…
So for me it would be very useful, especially because I would be able to use CPU heavy plugins at 44 kHz, but to be able to later mix their audios at 96 kHz.
I didn´t know that REAPER was capable of doing so, but if REAPER can, why not CUBASE/NUENDO. I do not pretend to change DAW (well, actually I just changed to Nuendo, but I still have my Cubase licence).
Also, an export at a higher sample rate will use more CPU power than at 44 kHz, and would therefore (in occasions) impossible to be done in Realtime, but I would be more than happy to wait (like it were a batch process) for Cubase to “magically change project settings” and export then at a higher sample rate. The benefit of exporting a project in NON REALTIME is not only to be able to export more quickly, but also, that you can export even slower than playback speed, which is actually a very smart thing, as it gives the computer enough time to process adequately the audio.
(As a side comment…, imagine, you are working on a powerful computer, then the computer doesn´t start anymore, but you have the possibility to transfer your project to a secondary (not so powerful) computer for mix. This is one of the reason I never considered ProTools for my productions (although a lot has happened in the last years…))
I’m not sure this assumption is wholly accurate. If the project sample rate only is sent to plugins at instantiation, then changing the project sample rate after inserting a number of plugins, would result in a sample rate mismatch. At least until the plugins are re-instantiated (by reloading the project e.g.). But this is not the case, so Cubase has to have the capability to inform the plugin of a sample rate change. Thus, the feature request should technically be doable.
“Re-instantiation” might not be quite the right word – the plugin needs to be suspended and re-configured. Plugins that use sample-rate dependent source data (convolution kernels, etc) may need to re-load data from disk. Filters that are tuned to some particular frequency suddenly need to use a totally different set of coefficients.
The host could totally do it – after all, I can easily change the sample rate in Cubase. But the end result for the user could be totally confusing, because what they export, is not what they’re auditing in the tool, and when it sounds different, the user may complain about the host, when it’s really some plugin design “feature.” It’s easy enough to change the project sample rate, and that leads to predictable results, so I understand this choice.
@jwatte I think we are in agreement, but just to be clear, I do not support the proposed feature for reasons you mentioned and others. I was just trying to say it should be technically possible.
I’m not sure there is a lack of love. I just don’t really understand what it would accomplish. Let me try to describe the value proposition and you can correct me where I am wrong.
For audio recording, there isn’t much advantage to recording above 48K x 24-bit. It takes a lot of CPU power to process higher sample rates and most people would rather have the flexibility of many more tracks rather than spending potentially $8000 for a system powerful enough to work efficiently at 96K. So this is really not about recorded audio. That knocks out a lot of potential interest.
It is about working in MIDI to VSTis (and their related processing effects) all in the box, The proposal is to allow a framework where the artist could work in “draft mode” (my term) for the first 95% of the project. That should give very high quality results, but in the final rendering one might like to render at 96K for the best possible quality.
It is great that you put the word “DRAFT” into the conversation. Because…until it is not rendered as a final product/final mix, it is a draft. So up to this point, there is no need to work at “overly-high” frequencies. It becomes relevant when rendered to audio.
You have put myself into thinking, what I am trying to accomplish, and maybe that is one of the misunderstood aspects.
It´s not about the customer, it´s about ME as a musician and a producer. I want to feel a special pride, when it comes to my music, because it represents a lot of what I am. It is not just another record…at least for me.
Maybe I am seeing this from the wrong angle. Maybe it´s just an industry hype, maybe I give to much importance to detail, or to the negative implications when converting audio files, or the lack of precision when working with a lower sample frequency and/or bit rate, that I feel the desire to get (in terms of sonic quality) the most out of it.
I am completely aware …
that consumers won´t be able (in the vast majority) to tell a difference betweem 44 and 96 kHz, most of them cannot even tell if it´s a WAV or mp3 (and I am not critizing nobody for it)
a bad (or lets say, no so good) song will remain so, although you produce it at 384 kHz.
Am I making my money making music? No. Is it a hobby? No, it´s much more than that. So it deserves as much attention as it can get. I think this is “only logical” (LLAP).
So, I don´t feel bad if this won´t be implemented, nor will I start Steinberg bashing…it would just be nice.
This is an age old debate. But if there really is no difference, why do some interfaces allow sampling at 192K. I assume some of the high end VSTis have sample libraries produced at 96K or even higher.
It seems to me that for simple recording without significant processing, the case for 48K or even CD standard being all that is ever needed is strong. But at 48K, the curves are approximations – in other words, they contain a certain amount of error even if it can’t be discerned except by a few people using the best equipment. However, we all know that these curves (waves) are manipulated dozens or hundreds of ways in modern productions. And each step can amplify those errors. It seems to me that is the case for 96K or higher. And that can just as easily apply to MIDI rendering.
OTOH, with audio recording, if you start with 44.1K or 48K audio source, up-sampling to 96K is going to add those errors from the very beginning of the pipeline, so I can’t see that being fruitful. But if one is working with VSTis that are capable of emitting original material at 96K quality, that’s a much stronger case, even if the last step of the rendering drops it all back down to 44.1.
If there is some validity in this reasoning, it seems to me that Steinberg really should think about offering the so-called “draft mode” and a final mode that runs slower by working at a very high resolution.
Even if people don’t think the case is particularly strong today, it seems likely that sample libraries and synths are going to continue to work at higher and higher resolution, so Steinberg should begin positioning for that.
That a common misconception, but not true. digital audio does not have curves, it has samples. Those discrete samples will be converted back to a continuous analogue signal by the reconstruction filter - in theory perfectly up to the nyquist frequency (half the sample rate), in practice of course imperfectly due to the limitations of our physical world and the engineering (there is no such thing as a perfect DAC)
Any differences that people can hear between sample rates ( personally I can’t, but I believe some people can, if trained, although it is hard to prove scientifically) are most likely caused by the implementation of the reconstruction filters in the converters and not by some “inherently imperfect curves” of lower sample rates.
The real and absolutely valid reason for working in higher sample rates in the DAW imho is aliasing. Any non-linear process in digital audio can create aliasing, and if the aliasing becomes too loud, it will audibly impact the sound. This depends very much on the plugin and the incoming signal (level, frequency distribution). Developers can take different measures to prevent aliasing, one of them is oversampling the plugin when it runs on lower sample rates.
If you have plugins that do alias in critical amounts (compressors, saturation, distortion), running at 96k can help minimize the aliasing. It also can create its own intermodulation distortion under some circumstances if there is too much high frequency content, which is why some people do actually low cut the octave above ~22KHz.
There is also the case of naive digital equalizers having more “analog-like” curves because the frequency- and phasewarping (“cramping”) that happens near nyquist is shifted one octave higher in the inaudible range.
In the end, it all is very much a case of “it depends”. I am very much convinced that someone who knows his tools and the pitfalls of digital audio can make a better sound at 44.1Khz that someone who doesn’t at 96Khz (actually this is valid for analogue audio, too )
I think this is mainly a semantic, rather than a substantive, argument. There is no such thing as a process that converts from a natural wave to discrete data points and then “perfectly” back to the original wave. There is only the question of whether that round trip is “close enough”.
And maybe at 44.1 or 48 it is close enough. Certainly that is the case for distribution on MP3, AM radio, cell phone or cheap earbuds.
But rather than arguing about that type of “close enough”, I believe the issue is that these errors (and aliasing is another type of error) can be cumulative as more and more processing is added to the chain. For the work I do (mainly live recordings), I don’t think I would ever gain anything by going beyond 48K, but others might.
It would be very interesting to have this feature available, because without that capability, we can’t easily do an A/B test to find out if there are some cases where it makes a clear difference.
That’s not actually true, if you consider phase. The closer you get to Nyquist, the less well your signal phase is represented, and when you’re quite close to Nyquist, the signal actually needs to have many periods to be perfectly reconstructed by a filter.
And while our ears can’t hear absolute phase, they can hear relative phase.
So, if you care about phase smear, especially about transients that are short lived, there can be some small audible difference with higher sample frequency. And, more importantly, the less-than-perfect actual-filters have more margin for error, so even in cases where “theoretically” you wouldn’t hear a difference, in practice, it is possible.
That being said – repeatable listening tests again and again show that 48 kHz/20 bits is perfectly suitable for delivering any finished, mixed product, phase smear and all. It’s what happens before then, when a little bit of headroom is convenient.
Anyway, for those who want to “listen at 48 kHz, but then render at 96 kHz,” what is the actual proposal?
Do you really want to render something that you haven’t listened to, knowing that plugins do change sound (subtly, or sometimes dramatically) with project sample rate? That just makes no sense to me.
So, it seems like the five clicks needed to change project sample rate before render (“project settings → sample rate → OK → don’t screw it up → don’t screw it up”) aren’t a big problem.
"
.