LUFS correct is not good audio: two gates, one of them a human

The number was right

The audio policy document of the video factory describes one concrete case: the V2.2 sine audio bed measured exactly on target, and a person still found it “too synthetic, too loud”.

The ffmpeg documentation describes its loudnorm filter as “EBU R128 loudness normalization.” That kind of filter takes a mix to a number. What the case shows is that reaching the number does not answer whether it sounds good.

What the code says

A comment in audio_gate.py says “LUFS in range is NECESSARY, never sufficient”. The module keeps two separate verdicts:

• TECHNICAL_AUDIO_PASS, computed by the machine. The technical_verdict function adds a failure reason, for example, when integrated loudness was not measured.
• HUMAN_AUDIO_PASS, which starts false. gate_state returns HUMAN_AUDIO_PASS as False, with human_audio_state set to PENDING and human_audio_pass_by set to None.

The only way to change it is human_pass, and that function raises a ValueError unless it receives the name of the person who listened, and another unless it receives the audio variant that was heard. A generator has nothing to hand it: it takes someone with a name.

The documented policy adds one exception: the human gate is not required for a truly silent piece (audio_kind: "none").

Validating before ffmpeg

The same module validates every audio event before it reaches a filter string. A comment gives the reason: a NaN, inf, negative or absurd number “must never become adelay=nan|nan or volume=infdB”. The _finite helper rejects booleans and non-finite numbers.

The lesson

When the target is perception, the metric is a safety floor, not a quality score. Keep the machine verdict and the human verdict in separate fields so one can never stand in for the other.

The message of a related commit says levels “are reported but are NOT an acceptance”: they are reported, and they accept nothing.

If you want to see more of how we build these gates, follow the blog.