Loudness is the check most likely to surprise you, because it’s the only one on a WaveLens report where “passes every other check” and “sounds right” can genuinely disagree.
What BS.1770 actually measures
BS.1770 isn’t a peak meter and it isn’t RMS — it’s the ITU-R standard broadcasters actually use for delivery specs, and it works by applying a K-weighting filter (which de-emphasizes very low frequencies, roughly matching how the ear perceives loudness) before integrating the result over time. The output is a single number in LUFS (loudness units relative to full scale) that’s meant to correlate with perceived loudness far better than a raw amplitude measurement does.
wavelens runs this on both the reference and the DUT and compares the two integrated values against a tolerance.
$ wavelens analyze --ref reference.wav --dut device_under_test.wav --out report.html
wrote report.html (loudness: FAIL — integrated -14.2 LUFS vs -18.6 LUFS reference)
Why a normalization step is the usual suspect
The most common cause of a Loudness failure isn’t distortion or a bad encode — it’s a delivery-chain step that adjusted overall level on purpose. A loudness normalization pass, a broadcast chain applying makeup gain, or a platform-specific loudness target (streaming services each have their own) can all push a file’s integrated loudness outside your reference’s tolerance while leaving every other check clean.
That’s not necessarily a bug in your pipeline — sometimes it’s the pipeline doing exactly what it was told to do. The report just tells you it happened; deciding whether it should have happened is still a human call.
Where the check has blind spots
Loudness is a whole-file, integrated measurement — there’s no single “worst sample” the way there is for Bit-Exactness or Distortion, because the whole point is that it’s averaged over time. That has two consequences worth knowing:
- A file can pass Loudness and still have a problem in one section. A three-minute program with one badly clipped ten-second passage can still land close enough to the reference’s integrated loudness for the check to pass — the clipping would show up in Distortion instead, not here.
- A file can fail Loudness while sounding fine. If your reference and DUT differ by a deliberate, known gain offset — say, a broadcast delivery spec that intentionally targets a different LUFS than your internal reference — that’s a real, correct difference, and the fix is adjusting your comparison, not chasing a phantom bug.
Reading it alongside Level Fidelity
Loudness and Level Fidelity look related but answer different questions. Level Fidelity tracks amplitude/gain sample-by-sample against tolerance — it’s built to catch a mismatched gain stage or an unintended normalize as a local event. Loudness reports the integrated, perceptual result over the whole file. A file can fail one without the other: a brief gain glitch might trip Level Fidelity without moving the integrated LUFS enough to fail Loudness, and a deliberate whole-file loudness target change can fail Loudness while Level Fidelity — tracking relative shifts, not absolute targets — still passes.
If you’re triaging a report and only Loudness is marked, start by asking whether something in the chain was supposed to change overall level before you assume it’s a regression.
See it for yourself.
WaveLens compares a reference file against a processed copy and shows you exactly where they diverge — down to the sample — not just whether they still sound the same. One command, one report you can point at.