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 )
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).
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?
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.
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.
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?
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.
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.
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.
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).
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.
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.
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 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 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.
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.
)