"The EBU R.128 algorithm measures in 400ms blocks" seems wrong, ffmpeg doc states otherwise

[Moonbase59]

In

TrackBoundaries/cue_playlist.py

Lines 101 to 106 in f684585

	# The EBU R.128 algorithm measures in 400ms blocks. Therefore, it marks 0.4s as the
	# start of the track, even if its audio begins at 0.0s. So, we must subtract 400ms
	# from the given time, then use either that time, or 0.0s (if the result is negative)
	# as our track starting point.
	# We then take it back by a further 0.2s for safety -- NOT YET
	cueTime = max(0, ebuCueTime-0.4)

, you state

The EBU R.128 algorithm measures in 400ms blocks

but the ffmpeg docs say

By default, it logs a message at a frequency of 10Hz

which is 100 ms. So I think

cueTime = max(0, ebuCueTime-0.4)

should actually be

cueTime = max(0, ebuCueTime-0.1)

If I do a quick test in the terminal, it actually lists it in 10 Hz intervals:

ffmpeg -hide_banner -i test-5-15-5-15-5s.mp3 -vn -af ebur128=target=-18 -f null null

[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.0999792  TARGET:-18 LUFS    M:-120.7 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.199979   TARGET:-18 LUFS    M:-120.7 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.299979   TARGET:-18 LUFS    M:-120.7 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.399979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.499979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.599979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.699979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.799979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.899979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU
[Parsed_ebur128_0 @ 0x561b6c14b880] t: 0.999979   TARGET:-18 LUFS    M:-163.5 S:-120.7     I: -70.0 LUFS       LRA:   0.0 LU

I’m on Linux Mint 21.3 and used the default ffmpeg version 4.4.2-0ubuntu0.22.04.1 to test this. Hopefully the intervals don’t/didn’t change between versions or platforms!

Thanks for sharing all this—it is really well thought out and useful! I don’t use it, but it gives valuable insight into Liquidsoap and ffmpeg filter chain inner workings.

I only wish we could grab ffmpeg textual output easily within Liquidsoap and thus eliminate the need for external dependencies for some simpler things like finding start/end cue points, and rewrite that in Liquidsoap. Then again, some pre-processing makes sense, like for replaygain and possibly cue/fading points, since these can be costly in terms of CPU/memory usage.

[Moonbase59]

I stand corrected:

Momentary loudness: every 100 ms, a range of 400 ms of audio is measured.

So it’s intervals of 100 ms that it shows, but actually measures a 400 ms interval.

I still wonder how it can give data for 100, 200, 300 ms when it needs at least 400 ms. It surely won’t measure forward? Maybe I need to study the ffmpeg code…