Warblefly
"The EBU R.128 algorithm measures in 400ms blocks" seems wrong, ffmpeg doc states otherwise
In https://github.com/Warblefly/TrackBoundaries/blob/f68458558b1119890e0f96a356181fe50786cf1a/cue_playlist.py#L101-L106, 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.
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…