Normalization occurs directly on audio clips. That is useful for almost ready audio, however for guitar di it is not that very useful since change the gain also very much change the sound of ampsims. So this is a feature request for output normalization that takes the insert effects in to the calculations.
I don’t want to interfere with your feature request but, if you’re already getting the sound you want from your amp sim, why would you want to normalise the event(s)?
There are two reasons in MY work flow that would benefit from the output normalization feature.
Getting the faders on the mixer in sweet-spot. Now I often get them too low or too high for working with hardware controllers. It is fixed with a plugin that do only gain.
A LUFS normalization would make compression of two difference plugin chains easer. Without volume compensation it is easy to fool your self and pick the loudest. Let the computer do a fair setting and let the ears do judgement.
Can you explain how this should work? Because as you correctly wrote, normalization works on an audio event (it has to, else it isn’t normalization). With the insert effect, you don’t have an audio event, your processing audio in real time. So you would need to render the audio first with the insert effects, and then normalize it. This is what you already can do now. And you wouldn’t need the ampsims anymore because it is already rendered…
Aren’t there gain staging plugins, where you insert one before the effects and the other one after them? Then they will be able to show you the level difference, possibly also in RMS, LUFS, or whatever.
It uses output instead of clips/event. It will of course do a rendering similar to a freeze with effects on some different time selection methods. Whole track, selection, markers or what ever. We have a volume curve (input too), maybe a output-volume curve so it can be different on different sections so it also can me manipulated by users. Eg the output normalization generate the curve.
That doesn’t really work. You cannot use the output of a plugin for normalization. Normalization only works on a whole audio file/event. Everything else is volume automation/gain riding.
What is wrong with simply rendering the track with the amp sim insert included and then do a normalization on the new, resulting track? Which the also already offers volume curves (with clip gain/automation etc).
So I’ve done some research I have to correct myself. There are actually algorithms that try to target a specific loudness in realtime. This is mostly used in broadcast for live streaming etc. and the audio is analyzed using a rolling average over a time span of several seconds to minutes, the longer the better for the prevention of artifacts (This is essentially automatic volume automation ie amplitude modulation and as such produces distortion).
But as a realtime process cannot see into the future, this process may of course produce erroneous level “corrections”. I don’t think it is useful in the context of a DAW…
I think it is a good thing to have some argument about it. Often there is something similar that can be used or why it is a bad idea. And there are people that think all normalization is just wrong in all cases. But this feature is not about getting cubase to something it can not do, it is about work flow. I hoped for someone would say, YES here is my macro that already do this, but NO. The suggestions is more or less what I do today when I need it. But it double tracks and generate load for something that is just a gain change that should be done with a single key-press without any side effects.
After comping and riding a track I always adjust the track’s pregain to a max level of around -18db using a VU meter for monitoring. It’s more or less a ballpark region that I use as a starting point. When I add inserts I make sure to keep this level by adjusting an insert’s output level or by a volume plugin if necessary.
If you are looking for “one click alternatives” then you will always be left with an additional plugin in your chain. In these cases I can recommend mvmeter. It’s free and it will apply gain reduction with a single click (e.g. -18db in standard vu meter mode). This approach requires a known “before” level if you want to keep a track’s level in the same ballpark area.
Another way to do it is to use ABLM2 which works differently. It will measure before / after insert levels based on loudness and lets you AB the inserts in between matched by loudness without any necessary preparations. You could leave it there afterwards, too.
These are just practical approaches for the time being. I am not opposed at all towards various feature requests asking for more gain control options within the insert chain!
Sure but it seems to me that in this case it is less arguing about the feature request and more trying to understand what the actual FR actually is actually about. Maybe I am dumb, but I am still not sure I fully understand it from the descriptions…
Level normalization is not what you want to use in your case.
That’s how it’s supposed to work. The idea behind it was to bring an audio file or a clip to a defined (normalized) peak level, just with applying gain.
Well, why do you want to normalize that clip? That’s one question here.
So it isn’t level normalization then. It would be a dynamical process. There are tools available.
This a feature request, it is about change (adding) the functionality.
You are quote the answer. Plugins are not linear. It will be very differnt result depending on where your nomalization point is. Normalization point? - #3 by cubace
It would be dynamic process in the same way as input clip normalization, the only difference is where the gain is applied.
It is a feature request for output level normalization. And not necessary for a clip.
Why don’t share the knowledge abot the tools instead?
The reason normalization works so well on an audio file/clip is that the data is static. If you were to perform a similar operation that includes live plugins, the reference data is not static anymore. Consider for example if you had a tremolo effect inserted that is free running. Each time your proposed normalization process would analyze the data there is a real risk it would record wildly different results.