Mono tracks showing wrong metering values

[AnAudioDude]

Solved, see bottom of question for answer.

When using a mono track the metering is way off, and becomes obvious if a limiter is applied to test this.

Example: The waveform of the clip doesn’t correlate with the channel or master metering, I discovered this issue when applying a limiter to a mono channel with some drums - I set the limiter ceiling to -1dbfs and pushed really far into it; the limiter says it’s hitting the -1dbfs ceiling, while nuendo’s meters tell me its pinned at -4dbfs, and it won’t move up from there no matter how hard I push.

I tried 6 different limiters, no change - so this is a nuendo issue.

Further; I asked nuendo to normalize the track to -6dbfs, when I exported it and opened it in RX11 it was at -9dbfs - this makes no sense and leaves me with a feeling that I can’t trust the tools I’m working with.

I made absolutely sure that it wasn’t user error on my part; the clip/event gains were at 0/default, only direct routing from channel to master, all faders at unity gain, nothing in the chain to distort the readings.

If I switch the offending mono tracks back to stereo however, they behave as expected and show correct values.

I asked support about this about 4 months ago and haven’t received a reply, I’m quite disappointed.

Anyone else encounter this?

Mono channel showing wrong metering:

Any help is greatly appreciated!

EDIT:

Not a bug.

Thanks, @MattiasNYC

Solution:

Change channel metering to “pre-panner” to see mono channels true dbfs value in their respective channel meters, the master fader will still show the effects of the pan-law, so now one can see both.

Tip: For batch exporting mono tracks, to ensure they adhere to channel levels without being affected by pan-law - select the events you need and choose File/Export/Selected events/Channel settings. This will bypass the master channel, and just export the selected events/clips directly from their corresponding channels.

Will leave this here so others can learn from my mistake.

[Reco29]

Seems like your panning law preferences have something to do with it. How did you set them?

[Dietz]

Please read up on the term “Pan Law”. I’m pretty sure that yours is set to -3 dB.

[MattiasNYC]

@AnAudioDude

Mono channel showing wrong metering:

Like the others said it’s likely just the pan law difference you’re seeing.

Route the mono track to a mono output bus and check again. Or switch metering to pre-panner.

[AnAudioDude]

Thanks for everyone’s input so far. I had the default pan law, equal power.

The pan law set to “0” did correct the behaviour. So I guess this is semi-solved, my only question then remains;

Doesn’t it seem like this throws off critical measurement for loudness features and normalization, etc?

When the pan law is set to 0, and normalize to -1dbfs it does actually render to -1dbfs.

If I have my pan law set to “equal power” which is the default, and I normalize a mono track to -1dbfs, it ends up rendering at -4dbfs when exported/bounced.

Isn’t this problematic - or am I just misunderstanding something fundamental here? Shouldn’t there be some sort of compensation happening?

You’re working and looking at the meters, making sure levels are correct, and then after normalizing and exporting you get other values than the ones you specifically asked Nuendo to set the targets to - then I’d wonder how this affects LUFS and everything down the line.

[MattiasNYC]

Yes, you are misunderstanding things.

Never change pan law to accommodate metering. Ever. That would be backwards.

You should set pan law according to how you would like panning to work. Everything else follows from that. My preference is equal power for various reasons.

Pan law is about how the audio engine deals with a single channel routed to a stereo path. If you pan that signal center do you want it ‘just copied’ to both left and right in the stereo path? If so the total energy is going to be bigger. If you want the total energy to be the same then each side of the stereo destination path have to be lower individually, so they sum together to the desired energy level. You see this reflected in post-panner metering.

Makes sense?

[AnAudioDude]

It is starting to make sense, yes. I appreciate the help and info.

I must admit that I can’t quite wrap my head around the fact though, that Nuendo will bounce a normalized file to a value based on pan-law instead of the actual normalization target, on a mono channel.

For any practical/real world use then; you just can’t use any other pan-law than “0” if you want to actually normalize mono tracks (for batch processing of sfx/foley/sampling etc).

In any case, I guess I have some learning to do.

Cheers for putting up with my questions, I’ll take this post down soon-ish as it’s not actually a bug.

[Dietz]

@AnAudioDude

I must admit that I can’t quite wrap my head around the fact though, that Nuendo will bounce a normalized file to a value based on pan-law instead of the actual normalization target, on a mono channel.

If you route it to a mono destination, a mono channel will bounce at its nominal level. If you route it to something else, the pan law comes into effect.

[AnAudioDude]

Thanks, this does make sense.

I have one final question.

Say you’re mixing a stereo short-movie, or just some music, there’s a blend of mono and stereo sources summing at the stereo master channel. Using the default pan-law (equal power) the individual mono tracks won’t show an accurate reading of their peak and RMS values, how do you deal with this?

Surely this is problematic for gain-staging, dynamics processing, and gauging loudness levels at the mixing stage?

Also, having a mono clip/event directly on a stereo track doesn’t cause any issues, it’s only when the mono channel feeds into a stereo channel - so why the discrepancy in metering - I’d assume there should be no difference since essentially the same thing is happening between L/R whether its a mono source on a stereo track, or a mono track feeding a stereo bus?

It’d surely be very impractical to always sum mono channels to their own dedicated mono-out, apart from the stereo sources, just to read the mono channels correctly when making a stereo mix.

Going by what the measurements and bounces tell me, I would then just always have to factor in that a mono channel is -3dbfs louder than actually displayed.

On the picture I supplied where I’m pushing in to the limiter, the channel meter won’t budge over -4 even when feeding it massive levels - the dynamics get squashed, as intended, but it feels really strange that the max peak measurement won’t show its actual value.

[Dietz]

Don’t overcomplicate things. That’s the beauty and the idea behind Pan Laws: If you stem-export your mix to a chosen format (e.g. stereo), the resulting mix of the exported files will be exactly like the one you heard (apart from any mix bus processing, of course). If you have stereo and un-panned mono tracks, this wouldn’t be the case.

[AnAudioDude]

Switching the metering to “pre-panner” sorted this out immediately, this is exactly what I was looking for.

I can actually see what I’m doing now as any given selected mono channel displays the true value of the waveform in dbfs, in the respective channel meter.

Thank you!

Now if only there was a way to configure the right-hand side meter to display the channel metering when events are selected, and the master when unselected, that would be cool.

But I’m getting greedy now, my problem is solved.

[MattiasNYC]

@AnAudioDude

Say you’re mixing a stereo short-movie, or just some music, there’s a blend of mono and stereo sources summing at the stereo master channel. Using the default pan-law (equal power) the individual mono tracks won’t show an accurate reading of their peak and RMS values, how do you deal with this?

Surely this is problematic for gain-staging, dynamics processing, and gauging loudness levels at the mixing stage?

I know you switched metering to pre-panner, but it’s worth commenting on the above:

If we are talking about post then I would say you should maybe take another look at your workflow and reconsider what is actually important. For me for example “gain-staging” is certainly something I consider, but I also end up exporting stems, so what I really care about is what the mixes, submixes and stems come out as.

My template is set up with that in mind. I simply set up a separate output bus with no output assigned and with a meter on it and then send all dialog tracks to that output bus. The only thing it does is show level of all dialog tracks. I have another meter for my M&E stem, and one meter for my master. I have all three up when editing and submixing and also when doing the final mix. I can instantly see where the dialog is and where the M&E is, and the mix of course. And I couldn’t care less about individual track meters. The only time I use track meters is when I ‘navigate’ and need to see where something is.

To me, since I’m only really ultimately concerned with what I’m delivering to clients showing levels later in the signal chain is more useful. Gain-staging at the plugin stage is a non-issue for me. My room is calibrated so that loud sounds loud, and in addition if I’m working on TV my template includes dynamics processing already set with the intended -24LUFS target in mind (plus or minus a few LU). What the track meters show is simply a non-issue for me working this way.

@AnAudioDude

Also, having a mono clip/event directly on a stereo track doesn’t cause any issues, it’s only when the mono channel feeds into a stereo channel - so why the discrepancy in metering - I’d assume there should be no difference since essentially the same thing is happening between L/R whether its a mono source on a stereo track, or a mono track feeding a stereo bus?

If I understand the above correctly I’m guessing that a mono source on a stereo track is likely adjusted earlier in the signal chain and therefore won’t show up on the meter.

That would make sense to me.

[AnAudioDude]

Different strokes for different folks I suppose, but cheers!

There are a number of reasons I personally like to see accurate meter readings;

• The incoming signal/event could be clipping at the channel level, but that won’t be displayed on a bus or master-output if it’s a centered mono channel even when soloed. If it’s clipping, but going to a stereo bus and one bases their peak reading off of it, it’ll look like it has 3db of headroom (even on the individual channel, if post-panner metering is on). Easy to work around, yes, but nice to have quick visual cues for efficiency even though it’s easily mitigated.

• I generally want to see the channel values for safety “on the way in” as I do a lot of editing with clip/event gain for dialogue and general prep, especially FX - once I’m happy with the event levels I move on down the chain, and I don’t pay much attention to the individual channel meters, as you point out.

• I’m making a “foley” sample pack for a sound library. I need to normalize about 400 events for export. Over 40 tracks, each containing roughly 10 individual variations for every track. As you might imagine, for batch exports like this it is crucial that the individual channel meters represent the final output, so that the normalization value can be trusted. I was worried that normalization didn’t work correctly before, due to lack of knowledge about how pan-law affects metering, giving me the wrong impression.

• For music, it’s nice to see how much of the peaks I’m taking off when saturating individual channels with outboard gear, especially if I’m going for a precise, controlled reduction in dynamics.

• It’s just generally a handy, basic, diagnostics tool that can help confirm mix choices before branching a mix out to buses/submixes.

I’m not at all married to the channel meters, I’m just glad to know that the software works as intended, haha! They were confusing the hell out of me when limiting, and using direct offline processing by showing me “incorrect” readings though - leading me to doubt the software.

In any case, thanks again for the assistance. It is very much appreciated, and I now have a newfound confidence in my favourite DAW.