In-process BS.1770-4 measurement: how baken dropped ffmpeg loudnorm and got 15x faster

Headroom brings every track of a DJ library to one true peak ceiling. It needs two numbers per file: integrated loudness for the report and true peak for the gain decision. Until 3.5 it got both from ffmpeg -i file -af loudnorm=print_format=json -f null -, reading input_i and input_tp out of stderr. A user with a large library reported 10 to 20 minutes per 1000 tracks (#114) and pointed out that mp3rgain, a pure-Rust tool by the same author, analyses the same files in seconds. The first hypothesis was the decoder. It was wrong.

M3 MacBook Air (4 performance + 4 efficiency cores), Homebrew ffmpeg 9.0.1, mp3rgain 3.8.1, real tracks, one file at a time, wall-clock seconds.

Decoding is about 3% of the loudnorm figure. The filter itself is the rest, and it costs about 1.6 s per minute of audio whatever the codec: a WAV that decodes in 0.05 s still takes 7.3 s.

loudnorm is a normaliser, not a meter. Its true peak detection is a sample-peak search at 192 kHz, so it asks libavfilter for 192 kHz input and an aresample is inserted in front of it. Every sample, 4.35 times as many as the file has, then runs in double precision through the filter's complete gating, gain computation and limiting path. print_format=json only prints the measurement that fell out of that pass. When all you read is input_i and input_tp, you are paying for a normaliser whose output goes to -f null.

The bench above is one file at a time. These are the numbers a tester measured on their own library, and the ones measured again here under the same conditions after that report (#114, #129).

The first two rows are the ones that matter to a DJ: the same files on the same machine, about 14 minutes before and 20 seconds after. That is 42x, well beyond the 15x the one-file bench predicted. The desktop has 24 cores, and how each engine spreads across that many was not measured separately.

The Mac app rows are a different lesson. 1.0.2 linked the same baken-core as the CLI, but its lockfile still resolved mp3rgain 3.6.0, from before the true peak meter was restructured, so every file cost twice the CPU for identical numbers. The 257-file rows isolate that on one machine: 68.0 s on the old lock, 35.8 s on the new one, 33.8 s for the CLI. 1.0.3 ships the new lock. The tester's 1,036 files have not been timed on 1.0.3 yet.

Same files, old engine (loudnorm) against 3.6. Integrated loudness in LUFS, true peak in dBTP.

• Integrated loudness agrees within 0.06 LU (0.12 on the odd 16 kHz mono file).
• True peak is identical to 0.01 dB for every file at or below 0 dBTP. That is where the raise decision and the 0.05 dB dead zone live, so a library processed by 3.5 is not re-proposed by 3.6.
• Hard-clipped masters well above the ceiling (+1.5 dBTP and beyond) differ by 0.1 to 0.2 dB.

Both numbers are estimates of how far the reconstructed waveform reaches between samples. loudnorm's estimate is the sample peak after libswresample has resampled to 192 kHz with its default windowed sinc; the Annex 2 meter is a 4x polyphase FIR with a specified passband. On ordinary material the two agree to the last printed digit. Hard clipping is different: it puts energy right up to Nyquist, which is exactly where interpolation filters differ most, and the standard itself allows a 4x meter to under-read such signals by a few tenths of a dB. Neither is "the" true peak; both sit inside the tolerance the standard describes. For baken it does not matter: the files that differ are 1.5 to 4 dB above the ceiling and are lowered in 1.5 dB steps, and the step count was identical on every test file.

The meter was not the only thing that could send a file back. Up to 3.6.1 the gain rule did it on its own. A lowering is rounded up to a whole 1.5 dB step so the file stays under the ceiling, which leaves it up to one step below, and anything more than 1.0 dB below came back as a re-encode candidate on the next run. On the tester's library that was 7,700 of 24,000 tracks on the second run, and 80 of 253 (32%) in a small test, which is the arithmetic exactly. 3.7.0 waits for a full step before it touches a file again (#138): the tester's repeat run now proposes nothing, and nothing is re-encoded for gain at all.

• If all you need is I and true peak, loudnorm is the wrong filter. ebur128=peak=true measures the same I and true peak in a sixth of the time, at the file's native rate. Its summary prints one decimal; ebur128=metadata=1 followed by ametadata=mode=print gives full-precision per-frame values (take the last frame).
• If you control the binary, a decoder plus a BS.1770 implementation in-process is about 2.5x faster again and removes the stderr parsing. loudnorm's JSON arrives in the same stream as the ID3 dump, and GEOB/PRIV frames containing braces have broken brace matching before (#10).
• Once decoding is in-process, profile the true peak meter. In mp3rgain it was 68% of the analysis time, more than twice the whole decode, while BS.1770 loudness adds about 0.06 s per 10 minutes of audio. Four accumulators instead of one per phase, and a doubled history buffer instead of a wrapping ring, made it 2.1x faster with bit-identical output (mp3rgain#334, in 3.8.0).
• Check which analyzer you actually ship. Two workspaces that share a crate resolve its dependencies separately. The Mac app's lockfile stayed on mp3rgain 3.6.0 after the CLI had moved to 3.8.0, and nothing but a tester's stopwatch noticed the doubled CPU per file.
• Keep the ffmpeg path as the fallback. Pure-Rust decoders cover the common formats; ffmpeg opens everything.
• Do not chase the 0.1 dB on clipped masters. Different interpolators give different answers there, and both are inside the standard's tolerance.

Decode only, loudnorm, ebur128, and the 192 kHz evidence. The last line is baken 3.6.0 or later.

The full measurement log and the design are in issue #129, the implementation in PR #130, and the BS.1770 code in mp3rgain's bs1770.rs. Both projects are MIT.