Loudness Track vs. Audio Statistics Integrated Loudness

[ridgerider]

Hey everyone,

we're doing some loudness measuring and wanted to use Nuendo's loudness-tools as a reference. However we stumbled upon a difference metering readout when comparing the integrated loudness readouts from the loudness track (using a "Quick Analysis" over the exact time of my region) to the ctrl-rightclick-->audio-->statistics loudness information. (All mono files).
The differences are only in the magnitude of 0,1LU or so - but they don't appear to be simple rounding errors?! For example one integrated loudness measurement of a file would be -34.8LUFS in the loudness track and the same file's statistics would say -34,69LUFS.
Can someone explain how/why these differences occur? I know they are only small but a measurement should be a measurement? Does this have to do with integration time/gating?
Loudness Range readouts are off by around 3LUs - but they also skip around after the "Quick Analysis" is finished, so I don't know if one can trust the Loudness Track in this case?

Any help/information on what parameters are different between the two methods would be much appreciated. In the end I guess both readouts follow EBU R128 & ITU BS1770?!


Thanks,
Jan

(Things got really messy, when comparing the Nuendo readouts to the demo of RTW's Plugins. The measurements were (roughly - again about .1LU deviation) the same when comparing 5.1 loudness - but on the mono track RTW was suddenly 3LU louder? What's going on there? Any experiences? Could have been a wrong setting - can't verify at the moment, because trying to open the RTW plugin keeps crashing Nuendo today )

[MattiasNYC]

I don't have time to check now but a hunch says 'check duration of measurement'. In other words could it be that the length of the measured audio is slightly different depending on the method? If that's the case it would mean that the measurement would actually be accurate, it's just that you're not measuring exactly the same content (because of the different length).

[ridgerider]

Hey Lydiot,

I'm setting the loop in- and out- points (using the "p" shortcut) to exactly the desired region, which is also the region I am right clicking and analysing. At least on first sight that shouldn't result in a different measurement duration?

Thanks!

[Fredo]

*All* faders and settings @ 0dB?

Fredo

[ridgerider]

Fresh project, just drag-and-dropped the files in there!

[stingray]

It would seem the loudness track does not always precisely match the statistics, especially with regard to the loudness range, but IMO the integrated loudness values are always the same (barring the rounding of the values).

FYI, when analysing the same file, the loudness statistics of Nuendo closely match those of Wavelab. So it's probably true to say that Nuendo's statistics values are indeed accurate, and perhaps slightly more accurate than the loudness track / loudness meter values. But IMO the differences are very negligible indeed.

[MattiasNYC]

Hey Lydiot,

I'm setting the loop in- and out- points (using the "p" shortcut) to exactly the desired region, which is also the region I am right clicking and analysing. At least on first sight that shouldn't result in a different measurement duration?

Thanks!

Yes, I agree with you. My thinking was that perhaps Nuendo doesn't actually measure exactly the same duration using different methods, for some reason. Perhaps it could be some rounding/quantization error when placing in/out points, or something to do with delay-compensation, or what have you. Not sure it would result in a huge difference in value, but I fail to see how else it would occur. After all, the algorithm used should be official and virtually impossible to screw-up one would think.

I also think this is of significant concern. If hitting specific specs is what we need to do then the tools need to be accurate every single time.

[ridgerider]

So, maybe any comments from the Steinberg guys?
Unfortunately I don't have an e-mail contact at hand, otherwise I would just ask the developers for implementation differences in the loudness calculation between the two procedures…? Maybe they read it here?

Have a nice weekend!
Jan

[MattiasNYC]

What version are you running?

[ridgerider]

In this case it was a Nuendo 6.5.20 (32bit Win).

[MattiasNYC]

Now with Delay Compensation Constrained...

iZotope Insight (instantiated on the full-mix output):

Integrated (LUFS): -18.1
Momentary Max: -11.4
Loudness Range: 3.7
Peak: +1.3

Nuendo offline statistics:

Integrated: -18.09
Momentary Max: -12.39
Range: 3
Peak: +0.09

Nuendo Loudness Track Quick Analysis:

Integrated: -18.1
Momentary Max: N/A
Range: 3.3
Peak: +1.3

Nuendo Loudness Track Realtime Analysis:

Integrated: -18.1
Momentary Max: N/A
Range: 3.4
Peak: +1.3

[MattiasNYC]

Crap!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I did all the measurements above WITHOUT delay compensation constrained, and then when I thought I added a new post it turned out I did "edit post". So now all the prior measurements are 'gone'.

I don't have time to re-run them now, so you'll have to trust me when I say that the results were different for the values highlighted in red. Peak came in at negative 1.5 in all cases, and Range at about 3.4-3/5 or so. Integrated was slightly higher in all cases.

So I stand by the proposition that this has to do with timing and/or duration of measurement.

[stingray]

What audio material are you testing?

[MattiasNYC]

It's a full mix. Dialog, pfx, sfx, music. It's mixed "hotter" to be more in line with web content. I don't see how it makes a difference what content I'm testing with though.

[stingray]

I don't see how it makes a difference what content I'm testing with though.

I'd suggest it does. If you test individual audio events (no processing) you will get a different result since delay compensation has no effect.

[MattiasNYC]

I don't see how it makes a difference what content I'm testing with though.

I'd suggest it does. If you test individual audio events (no processing) you will get a different result since delay compensation has no effect.

That doesn't make any sense unless the audio engine is broken.

The processing I do all happens before the final stereo stream. Any effect or summing takes place first, and then you have the resulting stereo stream. The output that the stream is routed to is what I'm measuring, and I also recorded onto a track with that output as a source. All processing and delay compensation should have occurred before that.

If this was NOT the case you would have to always measure the mix twice: Once while working (for convenience), and once when the final mix file is rendered (i.e. offline), because the first measurement can't be trusted.

I recommend re-labeling this thread to [ISSUE] and that Fredo bumps this over to Steinberg so they can tell us what behavior to expect from the audio engine. This could be a potentially damaging issue.

[stingray]

I meant "delay compensation has no effect upon the results."

Sorry Lydiot, but I still I do not understand your test and the relevance of delay compensation with regard to possible differences between the loudness track and the statistics. Perhaps you could provide a precise step-by-step of what you did, I may have missed something which is obvious to you but not obvious to me. If you recorded the stereo stream onto a track then surely, if we're going to be strictly scientific, that is not the same as measuring the stereo stream itself?

I've tested here on a number of different single audio files (single audio events) and the results in the loudness track and the statistics match (except for the rounding of the values and loudness range differences). The only thing I don't understand is why the loudness range should be any different. However, IMO there is no difference between the loudness track and the audio statistics integrated loudness values (which was the original topic of this thread).

I should point out that the OP seemed to be testing single audio files too, and not the stereo stream of a mix. So IMHO it's not sure that your test provides a solution as to why ridgerider was seeing differences in the values (see the first post above).

[MattiasNYC]

I meant "delay compensation has no effect upon the results."

Except that it does. Like I said you'd have to trust me when I say it did. All of the numbers highlighted in red were different compared to running the project without it constrained. It actually seems fairly logical. If things are out of phase perhaps we get different summing which yields a different result, right? If I get time tonight I'll redo the test.

Sorry Lydiot, but I still I do not understand your test and the relevance of delay compensation with regard to possible differences between the loudness track and the statistics.

There logic is to entertain the idea that Nuendo does something behind the scenes to compensate for delays and it for some reason begins and/or ends measurement early and/or late - would that not possibly account for this small discrepancy?

But fair enough, delay compensation probably has bigger effects on phase which in turn has bigger effects on measurement. I'll do a test differently later.

Perhaps you could provide a precise step-by-step of what you did, I may have missed something which is obvious to you but not obvious to me. If you recorded the stereo stream onto a track then surely, if we're going to be strictly scientific, that is not the same as measuring the stereo stream itself?

Well, it gets messy because we're dealing with abstractions on many levels. But yeah, perhaps there's a difference somewhere, but my point is that there shouldn't be. If what you say is true then the signal I'm listening to is different from the one I'm recording. Would you trust a DAW that has such a flaw?

And just to be clear, my signal path is essentially individual tracks to groups (one 'type' of sound each, i.e. DLG, MUSIC, SFX, ADR etc) to outputs (Full Mix, Mix Minus Narration, etc). Control Room taps into relevant outputs (i.e. "Full Mix"). One audio track has as its input "Full Mix" output channel. Since no processing is done past the output of the "Full Mix" output channel it stands to reason that the file recorded to track, or during audio mixdown, should be the same as what Control Room is sending to my speakers.

I simply don't think that there's a problem there. I could be wrong of course.

I've tested here on a number of different single audio files (single audio events) and the results in the loudness track and the statistics match (except for the rounding of the values and loudness range differences). The only thing I don't understand is why the loudness range should be any different. However, IMO there is no difference between the loudness track and the audio statistics integrated loudness values (which was the original topic of this thread).

I just showed that there is a difference. We can debate whether or not the rounding significant in and by itself, but surely it means something, especially since we're seeing different values for "range", not to mention peak. It's a bit disconcerting that Nuendo statistics gives a lower value than online/quick analysis/iZotope insight.

I should point out that the OP seemed to be testing single audio files too, and not the stereo stream of a mix.

See above.

[Fredo]

I think the answer is simple. Rounding errors.
One measurement is happening real time.
For the sake of the argument, assume that the loudness is measured every second.
This means that every second a x-digit (don't know the specs) is added to the previous one, and then rounded to a number whcih has only one digit after the comma. The outcome of this measurement will be totally different than when you measure only once. As said, I don't know the specs, and I don't know how large the number strings are that are being used, but it seems "logical" to me that many small measurements added one after the other will provide different results than one single measurement. And the differences are still so subtle that I don't see any problem.

Fredo

[stingray]

Agree, any differences are very subtle. Here are some results for a single audio file. The only result that varies significantly is Nuendo's Quick Analysis Loudness Range. Nuendo's statistics correspond with Wavelab's global analysis. Note the two decimal places in Nuendo's statistics, and the Nuendo Quick Analysis integrated value which gets rounded down whereas the Wavelab integrated value gets rounded up. Other audio files tested in the same way gave similar results.

Nuendo Statistics
Integrated_Loudness_Value;-22.89 LUFS
Loudness_Range;8.66 LU
Max_True_Peak_Level;-7.54 dBTP
Max_Momentary_Loudness;-17.08 LUFS
Max_Short_Term_Loudness;-20.91 LUFS

Nuendo Loudness Track Quick Analysis
Integrated_Loudness_Value;-22.8 LUFS
Loudness_Range;8.3 LU
Max_True_Peak_Level;-7.5 dBTP
Max_Momentary_Loudness;-17.0 LUFS
Max_Short_Term_Loudness; N/A

Wavelab Global Analysis
Integrated_Loudness_Value;-22.9 LUFS
Loudness_Range;8.7 LU
Max_True_Peak_Level;-7.5412 dBTP
Max_Momentary_Loudness;-17.1 LUFS
Max_Short_Term_Loudness;-20.9 LUFS

[MattiasNYC]

I think the answer is simple. Rounding errors.
One measurement is happening real time.
For the sake of the argument, assume that the loudness is measured every second.
This means that every second a x-digit (don't know the specs) is added to the previous one, and then rounded to a number whcih has only one digit after the comma. The outcome of this measurement will be totally different than when you measure only once.

I don't understand the logic in the above Fredo. The whole point of the measurement is to create an average, so how can you "measure only once"?

The way I see it the difference would something like you reading numbers off of a string of paper. In one case you are staring straight down at a table, and I move the string of paper with the numbers on it past you. You see the numbers, do the math. In the other example the string just lies there, and you move your head and eyes to read the numbers and do the math. Same numbers, same order. Why would there be a difference?

And the differences are still so subtle that I don't see any problem.

Fredo

Depends on where the difference lie. I know that some companies run an analysis on deliverables and if peak is above a specific value you get stuff rejected. It doesn't matter to them if their specs say -8dBFS peak and you come in at -7.49 instead of -7.58, it's still over after having been rounded. The person doing the measurement is a "robot" and doesn't care about if there are any real world negative effects, he just cares about whether or not the number is correct.

So at least with one of my tests there was a big discrepancy with delay compensation constrained (which I agree is not a scenario most would use, but I'll try again today).

[MattiasNYC]

Agree, any differences are very subtle. Here are some results for a single audio file.

Could you please try again with a real mix?

Note the two decimal places in Nuendo's statistics, and the Nuendo Quick Analysis integrated value which gets rounded down whereas the Wavelab integrated value gets rounded up.

Well, we don't really know how things were rounded without seeing two numbers for the same parameters: One before rounding and another after.

[stingray]

Note the two decimal places in Nuendo's statistics, and the Nuendo Quick Analysis integrated value which gets rounded down whereas the Wavelab integrated value gets rounded up.

Well, we don't really know how things were rounded without seeing two numbers for the same parameters: One before rounding and another after.

A slight misunderstanding - I should have expressed this more clearly as follows:
It is only Nuendo's statistics which has two decimal places. Compared to the two decimal place Nuendo statistics integrated value, the Nuendo Quick Analysis integrated value seems to get rounded down whereas the Wavelab integrated value seems to get rounded to the nearest value.

Since the Nuendo statistics matches the Wavelab statistics very closely indeed, I would tend to have confidence in the accuracy of Nuendo's statistics results.

Agree, any differences are very subtle. Here are some results for a single audio file.

Could you please try again with a real mix?

If you've found differences between the output stream and the same stream recorded onto a track, this may mean that you are proving that there is a difference between the output stream and the exported file? You might run into problems if your mix contains effects and VSTi s which do not play back exactly the same each time.

When you recorded the mix onto a track did the mix null when you activated the recorded mix track's phase reverse switch? If they do not null then comparing the loudness between the two is void.

Just tried comparing a mix output stream and 32-bit imported mix track here and the results are still similar. There's a variation in the loudness range but there are no significant differences between the integrated and true peak values of the quick analysis and statistics results.

Could you please now try with a single file? I'd be curious to know what results you get.

[MattiasNYC]

If you've found differences between the output stream and the same stream recorded onto a track, this may mean that you are proving that there is a difference between the output stream and the exported file? You might run into problems if your mix contains effects and VSTi s which do not play back exactly the same each time.

That would only make sense if the measurements were between a different pass of playback versus recording. As far as I recall that wasn't the case. But I'll do it again.

When you recorded the mix onto a track did the mix null when you activated the recorded mix track's phase reverse switch? If they do not null then comparing the loudness between the two is void.

Well, yes, it would be void, but unless (as I said above) the two compared are from different "passes" of playback there's a real problem. The final stereo audio stream shouldn't change between output and writing file to disk. That would be terrible programming.

Could you please now try with a single file? I'd be curious to know what results you get.

Sure. I'll have time later today.