# Different Normalize Algorithms - Peak and RMS.... edit: Bring Wavelabs Loudness Meta Normalizer into Cubase!!

I’m trying to adjust all my own samples to be of equal RMS so as to quickly be able swap them in and out, for instance a snare sample - I have variations of the same snare sample printed with different levels of compression for instance. Sounds with equal RMS mostly seem to sum better as well.

Having normalize with an RMS algo would speed thing up very nicely.

What you are asking is a normalize function that acts like a limiter. I guess it wouldn’t be normalizing anymore and the limiter wouldn’t know how much gain reduction to apply so you would have to adjust it manually anyways for each sample.
Normalizing only looks at the peak and raise the volume of the clip to whatever setpoint you select.

Yeah, I get what you are asking but once your peaks reach 0db you cant raise the RMS more without limiting or else it will clip.

Normalizing doesn’t have to be to 0db, it could be -6db.

Obviously it can be to whatever value you set it to be, but if you raise the RMS of your snare to -6db i guarantee you that the peak will be way above 0db and thus clipping unless you limit or soft clipping it.

I adjust peaks to -6db, then RMS from there.

If you set your peaks to -6db then the RMS is what it is. If you change the RMS by just turning volume up or down you will also change the peaks by same amounts.

Hmm, not sure if what I’m suggesting is getting across. When your normalize multiple events, it normalizes all the peaks to -6db. Some those events might be -12db, some might be, -3db, 0db - it will normalize all of these to -6db.

I want to do this based off RMS data, not peaks. If you have a snare sample for example, and you’ve taken this sample and EQ’d and compressed it a number of ways thus creating 10 new samples from the 1 original snare sample - your peaks will no longer be relevant, and if you normalize them to -6db, you will here that even though the peaks are -6db, they appear to be much much louder than the original sample or compared to some of the other processed variations because the RMS has changed. So, peak normalizing is no longer useful here.

It matters because if your RMS of those same events are like -24db, -15db and -10db with the peaks at -6, -3 and 0 then you wanna normalize the RMS to lets say -10db, then you will need to raise volume by 14db on the lowest sample and that will bring the peak from -6db to 8db and thus clipping.
Just because you have compressed your snare samples doesn’t mean the peaks doesn’t matter, it actually still matter as much as it did without compression. Specially because compression doesn’t deal with the whole transient and will let the whatever number of ms you select with attack knob through.

What I’m saying is that it makes no sense to normalize by volume using RMS value. For that you will use limiter of soft clipper.

wavelab - meta normalizer

Seems to be working fine doing it by hand… other than taking a long ass time.

One would just have to know how much headroom they have, to avoid clipping. But evening out samples based off peak, does not work - try it! As soon as one sample is shifted in frequency content from the next, their peak values are no longer relevant in terms of how loud they are as perceived by human hearing.

I guess my feature request is to bring Meta Normalizer in Cubase!

I never said they are relevant to the human hearing, I’m saying they are absolutely relevant to avoid clipping. Doesn’t matter how much you process them or how much the frequency is shifted, they still need to be below 0db to avoid clipping.

Yes of coarse, but what does clipping have to do with my suggestion? My intent was to never RMS multiple events to be 0db, and if my starting point is -6db peak, any work I do altering the RMS in this context of creating even sounding samples, is very rarely going to create a new 6.01db peak.

My action here is using a -6db peak as a starting reference point, then leveling RMS around that reference point. Clipping isn’t really a concern.