Podcast / Apple
−16 LUFS ± 1
−30−8 LUFS
Apple asks for roughly −16 dB LKFS within one decibel. LKFS and LUFS are the same scale for this purpose.
Podcast and voice mastering
Measure gated, K-weighted integrated loudness and estimated true peak. If the file misses your preset, normalize it, encode a 192 kbps CBR MP3 and measure the encoded output again — all inside the browser.
Ready.
Where the presets sit
Integrated loudness for spoken word lives in a narrow stretch of the whole LUFS range. These are the bands the presets aim at.
−16 LUFS ± 1
−30−8 LUFS
Apple asks for roughly −16 dB LKFS within one decibel. LKFS and LUFS are the same scale for this purpose.
−16 LUFS, −2 dBTP
−30−8 LUFS
Spotify's podcast ad requirements ask for −16 LUFS integrated within 1.5 dB and true peak under −2 dBTP.
−15 to −18 LUFS
−30−8 LUFS
Storytel asks for −15 to −18 LUFS with no peak above −0.3 and a noise floor under −80. Their document writes all three in “LUFS”, which is a unit slip for the last two; the preset aims at the middle of the window and holds true peak under −0.3 dBTP, which is stricter than a sample-peak reading of the same number.
−19 LUFS ± 1
−30−8 LUFS
A quieter target used where a single mono voice is delivered to a platform that normalizes further down.
−1 dBTP by default
−60 dBTP
Headroom for the codec. Inter-sample peaks are estimated at four times the source rate, not at sample resolution.
Limits stated up front
Apple's podcast audio requirements ask audio to average around −16 dB LKFS, within one decibel, with true peak no higher than −1 dBFS. LUFS and LKFS are equivalent scales for this purpose; the measurement here follows the gated, K-weighted method specified by ITU-R BS.1770.
This browser tool measures inter-sample peaks at four times the source rate, through the polyphase filter BS.1770-4 specifies rather than a spline. It clears every true-peak case in EBU Tech 3341 that applies to a stereo meter — but it runs in a browser tab and nobody has certified it, so treat the table as evidence, not as a badge.
The exported MP3 keeps an extra half-decibel limiter margin and is rechecked after encoding.
Measured, not asserted
Every meter in this corner of the internet says it is accurate. Here is ours against the published compliance cases in EBU Tech 3341, Table 1, with the number it produced for each — including the ones where it sits at the edge of the tolerance.
| Case | Test signal | Metric | Allowed | We measure | Off by | Result |
|---|---|---|---|---|---|---|
| 1 | Stereo 1 kHz sine, −23.0 dBFS, 20 s | I | −23.0 ±0.1 | −23.04 | −0.04 | Pass |
| 2 | As #1 at −33.0 dBFS | I | −33.0 ±0.1 | −33.04 | −0.04 | Pass |
| 3 | 10 s −36, 60 s −23, 10 s −36 dBFS | I | −23.0 ±0.1 | −23.06 | −0.06 | Pass |
| 4 | 10 s −72, 10 s −36, 60 s −23, 10 s −36, 10 s −72 dBFS | I | −23.0 ±0.1 | −23.06 | −0.06 | Pass |
| 5 | 20 s −26, 20.1 s −20, 20 s −26 dBFS | I | −23.0 ±0.1 | −23.02 | −0.02 | Pass |
| 15 | Sine fs/4, amplitude 0.50, phase 0° | True peak | −6.0 +0.2/−0.4 | −6.02 | −0.02 | Pass |
| 16 | Sine fs/4, amplitude 0.50, phase 45° | True peak | −6.0 +0.2/−0.4 | −6.19 | −0.19 | Pass |
| 17 | Sine fs/6, amplitude 0.50, phase 60° | True peak | −6.0 +0.2/−0.4 | −6.09 | −0.09 | Pass |
| 18 | Sine fs/8, amplitude 0.50, phase 67.5° | True peak | −6.0 +0.2/−0.4 | −6.06 | −0.06 | Pass |
| 19 | Sine fs/4, amplitude 1.41, phase 45° | True peak | +3.0 +0.2/−0.4 | +2.82 | −0.18 | Pass |
| 20 | fs/4 period inserted in fs/6, decimated at offset 0 | True peak | 0.0 +0.2/−0.4 | −0.13 | −0.13 | Pass |
| 21 | As #20, offset 1 | True peak | 0.0 +0.2/−0.4 | −0.12 | −0.12 | Pass |
| 22 | As #20, offset 2 | True peak | 0.0 +0.2/−0.4 | −0.14 | −0.14 | Pass |
| 23 | As #20, offset 3 | True peak | 0.0 +0.2/−0.4 | −0.12 | −0.12 | Pass |
Fourteen of fourteen inside tolerance. Every reading is slightly low rather than slightly high, between 0.02 and 0.19, which is the expected behaviour of four-times oversampling and of a gated measurement that includes its own filter warm-up — and it is the safe direction, because reading high never certifies a file that is actually over a limit.
Case 6 is a 5.0-channel signal. This meter handles mono and stereo, which is what spoken word is, so there is nothing to run rather than something that fails. Cases 7 and 8 are authentic programme material — they exist only as the EBU’s own audio files, and those sit behind a wall that refuses every client we have. Cases 9 to 14 test momentary and short-term metering; this engine reports integrated loudness and true peak and does not implement either, so they do not apply.
A conformance claim that quietly drops the cases it would fail is worth less than no claim, so the three exclusions are named here rather than left out of the count.
The EBU publishes a WAV set and it is unreachable from here. Table 1 defines each signal exactly — waveform, frequency as a fraction of the sample rate, amplitude, phase, durations and tolerance — so the suite synthesizes them from that text. You can check the synthesis against the standard line by line, which a downloaded binary would not let you do.
The suite is not decoration: the interpolator this meter used until 31 August 2026 fails cases 16 and 19 by about 1.1 dB. It is what found that, and it runs on every change.
Different job
Straight answers
Apple asks for about −16 LKFS, within one decibel, with true peak no higher than −1 dBFS, and Spotify's podcast ad requirements ask for −16 LUFS within 1.5 dB with true peak under −2 dBTP. The Podcast / Apple preset here aims at −16 LUFS; Storytel, spoken-word mono and voice-over have presets of their own.
RMS is a plain average of the signal's power. LUFS is measured through a filter that approximates how loud speech sounds and is gated so silence does not drag the figure down, as ITU-R BS.1770 specifies. ACX judges audiobooks in RMS; podcasts and streaming use LUFS.
True peak is the highest level the waveform reaches between samples once it is reconstructed, which can sit above every sample value. This meter estimates it at four times the source rate, and the exported MP3 keeps an extra half-decibel margin and is measured again after encoding.
No. Measurement, normalization and MP3 encoding all run inside this browser tab, and nothing is sent anywhere.