Bug: Audio Clip Normalize

The order of applying normalization to a clip is wrong to my normal way of operating.

The place where normalization is occurring includes ALL of the signal processing in the VST chain.

Normalizing audio should occur just at the raw file level before further processing.

This has caused quite a round of headaches where I've applied processing to individual clips and then find that I need to normalize the audio differently. I have to turn off all of the processing first, then normalize.

It also means that I cannot split a clip with audio processing and renormalize it if needed in any sensible way. It becomes arduous.

Edits: to the title to be more concise.

Which normalise method are you referring to? Timeline, Export Audio Files, or Deliver presets?

The Timeline Normalise function is not destructive and is simply Clip Gain and used to conform to the specified target level. Timeline Normalisation is identical to manually adjusting Clip Gain via the “Volume” slider in the Inspector or the Clip Gain line on the Audio Clip itself.

Timeline for individual audio clips.

For most clips, a single pass of normalize should be sufficient to get into the ballpark and I've had success with that.

The issue is where I may have missed a mark on a group of clips and find later that an adjustment is needed and I've already got audio processing (VST's) involved on the individual clips.

The normalize function does not work with the VST's enabled.

I then have to go around both elbows to do what should've been a simple adjustment.

Normalizing audio should occur just at the raw file level before further processing.

Would this not be the result if you did the Normalization before you do anything else?

The normal course is to normalize audio clips to some standard before proceeding with other audio functions.

In the course of my own effort, or it is that I have inherited a project from someone else, or by some other scenario, I may find the need to re-normalize some of or all clips to some standard level for the sake of convenience.

Normalizing audio involves the file at the raw level for the particular clip within the constraints of what is showing on the timeline for the clip.

This should be EASY. For anyone coming from another DAW, this is what is expected.

The fact that VST's added to an audio clip affects the outcome of this procedure is fundamentally wrong. It appears that the normalize function is taking into account any VST's in the clip signal chain. If there are compressor's or other level altering processing in the VST chain it affects the outcome of the normalization for the clip. For each clip where there are audio VST plugins added, I have to turn them all off and then subsequently reenable them.

I'm asking for normalization to be at raw or file level within the constraints of the clip. As it is, the process flow is a reproducible bug with undesired outcome.

If you want normalization to work on a file before any fx already added to the clip or track, then this would have to be a switchable option.
I don't consider this a bug at all. It is normal practice to either normalize before doing anything else, or do a final normalize at the end.
In the 30 years of using Pro Tools, and now Fairlight, I have never used normalization on raw tracks. I balance them using Clip Gain by matching waveform amplitude by eye, before doing anything else. The only time I use normalization in Resolve is in the render to bring the final mix up to -14 LUFS for You Tube.

If you want normalization to work on a file before any fx already added to the clip or track, then this would have to be a switchable option.
I don't consider this a bug at all.

I'm not in agreement. Clip gain normalization should "read" and "affect" things at that point only, clip gain only, and not to be including the VST chain with it. This is the entire point of my posting here.

It is normal practice to either normalize before doing anything else, or do a final normalize at the end.

I would certainly agree on that first part. The final normalize is a separate purpose and procedure which I was hoping in general to keep out of the conversation.

In the 30 years of using Pro Tools, and now Fairlight, I have never used normalization on raw tracks. I balance them using Clip Gain by matching waveform amplitude by eye, before doing anything else.

With what I'm looking at, it is easier to hit a ballpark with normalization and go from there.

I'll repeat my particular point again: Clip gain normalization should read and affect things at that point only, the actual clip gain itself, and to not include the VST chain with the adjustment in a loop back. If this gain were adjusted at the output of the chain that would be one thing (and would not be clip gain anymore) it might be useful for someone (not me), but it is that the actual clip gain is adjusted back at the input coming from the file/clip and the "read" is including the VST in a loop, and results in a confounding of the purpose.

Clip gain affects the actual clip gain, if you have no VSTs. That part is working quite wonderfully well. If you add a gain altering VST chain it compromises the clip gain result which is getting adjusted depending on the gain changes in the VST chain. The result is an error. It is not a desirable result at all. It is confounded and useless.

Procedure aside, this is an error.

Normalizing audio involves the file at the raw level for the particular clip within the constraints of what is showing on the timeline for the clip.

That's what you might want.

And if you do that Normalization first, that's what you'll have.

But if someone wants the Normalization to include the other processing, what would they do if this Request was granted?

The level affecting the audio coming in is what is changed. It does not necessarily change in a meaningful manner at the output of the clip processing chain with the normalization working as it is.

I see where some people may want the output of the clip processing normalized. That is not what the algorithm in question is supposed to be doing, and it is not, at least not effectively for that purpose.

Purely input normalization is simply that only, and is what the algorithm is supposed to affect, and by logical nature, only what is input is to be assessed and affected.

If folks want clip processing output normalization, that is something else.

I do not want clip processing output normalization. That is also not what is implemented.

I want input normalization to be working to industry standard, please.