About LUFS measurement

Development
1

I am writing a LUFS meter. From ITU-R BS.1770-5 and this thread and I have got a basic understanding of how to do this.

Notice that the pre-filters are:

Pre-filter (high pass)
cutOffFrequency = 37.5 Hz
Q = 0.5

RLB (high shelf)
crossOverFrequency = 1500 Hz
gain = 4.0 dB

I know how to create those filters under higher samplerates, e.g., 96kHz. However, if the samplerate is 96kHz, does it make sense to add one additional steep low-pass filter at(or slightly above) 24kHz? I have tried several open-source/commercial products but it seems that none of them is doing so. Is there a reason for that?

2
1 Like
3

I have already watched the video. According the the video and all existing documentations, it seems that even at 96kHz we don’t need any downsampling or a low-pass filter (though the original standard doesn’t mention much about anything other than 48kHz). However, it indicates that anything above 24kHz would also contribute to the loudness. which doesn’t make sense to me.

It should be noted that while this algorithm has been shown to be effective for use on audio programmes that are typical of broadcast content, the algorithm is not, in general, suitable for use to estimate the subjective loudness of pure tones.

Perhaps the standard doesn’t care about samplerates larger than 48kHz. And how to deal with high samplerates is not well-defined.

4

The reason they are not doing that is possibly because it is not part of the standard. These meters are ‘compliant’ if they pass the tests
.
You question if it ‘should’ be.

And you might be right.
This is a perceptual model and one could argue that frequencies beyond our perception should not attribute to the value.
Note that for the true peak metering, 48 kHz is assumed and oversampling requirements are more relaxed at higher sample rates.

1 Like
5

Thanks for the reply. Anyway, I will add one lowpass and document it in the manual. Let’s see whether some users would complain about it.

6

The purpose of a standard like LUFS is compliance between different meters. If you start thinking outside-the-box and “improve” the filter beyond that, you’re no longer implementing LUFS. There are test libraries you can use to validate specific Momentary, Short-term, Integrated, LRA measurements throughout test files to confirm your compliance.

See TECH 3341 and TECH 3342 in particular.

1 Like
7

Thanks for the reference. It seems that I am doing my own way of loudness measurement :grinning: I will go with that because I want to provide a loudness comparison before/after the effect instead of a precise LUFS value.

1 Like
8

To provide a more accurate estimation of the filter parameters, I have run scipy.minimize and the result is given as:

  • a high-pass filter at 38.13713296248405 Hz with Q = 0.500242812458813
  • a high-shelf filter at 1500.6868667368922 Hz with Gain = +3.9993623475151354 dB and Q = 0.7096433028107384
  • an additional gain = 0.04474275026925389 dB

I know it is a bit overkill :grin: just in case someone needs it.

9

K-weighting (used by LUFS) is already a very lossy approximation of fletcher-Munson equal loudness contours at a fixed reference level. Hyper optimizing for the k-weighting filter isn’t going to improve actual perceptual accuracy. If that’s your goal you could try to approximate those curves instead.

1 Like
10

That’s a good point! I will definitely look into this.

11

If you want a compliant meter, I’d say you would have to write a test suite for the test signals provided. If they pass (within margin) then your meter is compliant.
The test files are 48 kHz, so anything you do beyond that is not going to influence the test for compliancy.

2 Likes