Van de zes streamingdiensten waarvan de omgang met luidheid het vaakst wordt besproken, publiceert er precies één een normalisatiedoel dat je kunt citeren. Spotify publiceert −14 LUFS integrated, met een true-peak-plafond van −1 dBTP, aangescherpt tot −2 dBTP als de master luider is dan −14 LUFS. Apple Music, YouTube Music, Amazon Music, TIDAL en Deezer publiceren helemaal geen normalisatiedoel. Elk cijfer dat je voor die vijf hebt gezien, is gerapporteerd, niet gepubliceerd — en dat verschil telt op het moment dat iemand er een berekening mee maakt van hoeveel gainreductie zijn master krijgt.
Het ene gepubliceerde cijfer uit de streamingwereld
Spotify's eigen pagina over luidheidsnormalisatie noemt het doel −14 LUFS integrated. Ze noemt het true-peak-plafond −1 dBTP, en −2 dBTP voor masters die luider dan −14 LUFS worden aangeleverd. Die drie getallen zijn de enige normalisatiespecificaties van een streamingdienst in dit artikel die van de dienst zelf komen.
Dat is een smallere feitelijke basis dan het meeste masteringadvies suggereert. Het is ook genoeg om mee te werken, want het mechanisme is overal hetzelfde, ook waar het doel niet gepubliceerd is: meet de integrated loudness, vergelijk die met een doel, pas gain toe bij het afspelen.
De vijf diensten die niets publiceren
Apple Music, YouTube Music, Amazon Music, TIDAL en Deezer publiceren geen normalisatiedoel. De cijfers die voor hen circuleren zijn, in de enige eerlijke formulering die beschikbaar is:
Breed gerapporteerd, niet gepubliceerd door de dienst: Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15.
Die staan met opzet apart, en de regel die erbij hoort is streng: bereken er geen gainwaarde uit. “Jouw master staat op −8, Apple zit op −16, dus Apple trekt je 8 dB omlaag” is rekenwerk op een getal dat het bedrijf in kwestie nooit heeft bevestigd, met een algoritme waarvan het de parameters evenmin ooit heeft bevestigd. De aftrekking is netjes; de uitkomst is ongefundeerd.
Dit is geen muggenzifterij over bronnen. Het is de praktische reden waarom zoveel luidheidsadvies zichzelf tegenspreekt: twee schrijvers pakken twee verschillende gerapporteerde waarden voor dezelfde dienst, doen allebei de aftrekking, en presenteren allebei een zelfverzekerd getal.
−23, −16, −18: drie cijfers die niet uitwisselbaar zijn
Drie andere getallen circuleren alsof het alternatieve streamingdoelen zijn. Dat zijn ze niet.
- EBU R 128 schrijft −23 LUFS voor. R 128 is een aanbeveling voor omroep. Het is geen streamingdoel en was nooit als zodanig bedoeld. Het citeren in een discussie over streaminglevering is een categoriefout, geen strengere norm.
- AES TD1008 geeft −16 LUFS voor muziek. Dit is het op streaming gerichte cijfer waar mensen meestal naar grijpen als ze AES aanhalen.
- Het cijfer van −18 LUFS in TD1008 geldt voor spraakgedreven materiaal — nieuws, talk, hoorspel. −18 als muziekdoel noemen is een veelvoorkomende en ernstige fout. Vertelt een masteringgids, een plug-inpreset of een forumbericht je dat AES −18 LUFS aanbeveelt voor muziek, dan heeft dat document het spraakcijfer verward met het muziekcijfer, en zou je de rest ervan moeten wantrouwen.
Het onderscheid tussen −16 en −18 goed hebben is een van de snelste manieren om te zien of iemand die over luidheid schrijft de bron heeft gelezen of een samenvatting heeft overgeschreven.
De meetstandaard, en welke editie geldt
Alles hierboven wordt gemeten met ITU-R BS.1770. Die kent zes edities: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) en -5 (November 2023).
BS.1770-5 is van kracht. BS.1770-4, van October 2015, is vervallen — ook al is het de editie die de meeste in gebruik zijnde meters nog noemen. Noemt de handleiding van je meter -4, dan zegt dat iets over de leeftijd van de handleiding, niet over welke editie geldt. Noem -5 als de huidige.
Wat het algoritme werkelijk doet, en waar meters de fout in gaan
De specificatie is kort en precies, en verschillende details ervan worden zo vaak verkeerd geïmplementeerd dat je ze zou moeten kennen.
K-weging. Een filter in twee trappen: een high shelf (het “head”-filter) gevolgd door een hoogdoorlaat (RLB). De versterking van de K-wegingscurve bij 1 kHz is +0.698 dB — lineair 1.0836. Die afwijking is de reden waarom een K-gewogen meting van een toon van 1 kHz niet gelijk is aan het ongewogen niveau ervan.
Blokken. Luidheid wordt berekend over 400 ms blokken met 75% overlap.
De absolute gate. Blokken onder −70 LUFS worden zonder meer weggegooid.
De relatieve gate — degene die het vaakst verkeerd wordt weergegeven. De relatieve gate wordt berekend uit het gemiddelde van de blokken die de absolute gate hebben overleefd, en vervolgens verschoven met −10 LU. Het is niet het ongegatete gemiddelde. Een meter die gate ten opzichte van een ongegatet gemiddelde, leest een track met lange stiltes anders dan een meter die de specificatie volgt, en de twee verschillen met een bedrag dat afhangt van je arrangement in plaats van van je luidheid.
Loudness Range. LRA, gedefinieerd in EBU Tech 3342, gebruikt een relatieve gate van −20 LU — niet −10 LU. De gate van de integrated loudness hergebruiken voor LRA is een veelvoorkomende implementatiefout, en hij laat dynamisch materiaal consistenter lijken dan het is.
Tijdvensters. Short-term loudness gebruikt een venster van 3 s (EBU Tech 3341). Momentary gebruikt 400 ms. Dat zijn verschillende metingen, geen verschillende smoothing-instellingen van één meting.
True peak. True peak wordt gemeten op een geoversampled signaal — 4× minimum onder BS.1770, en 8× is beter. Sample peak is geen true peak. Intersample peaks kunnen hoger uitkomen dan de hoogste samplewaarde in het bestand, en daarom kan een master die op een samplepeakmeter precies 0.0 dBFS aangeeft, toch een lossy decoder laten clippen. De plafonds van Spotify van −1 dBTP en −2 dBTP zijn true-peak-waarden, dus een samplepeakmeter kan je niet vertellen of je eraan voldoet.
| Parameter | Waarde | Veelgemaakte fout |
|---|---|---|
| Absolute gate | −70 LUFS | — |
| Relatieve gate (integrated) | −10 LU onder het gemiddelde van de overgebleven blokken | Berekend uit het ongegatete gemiddelde |
| LRA-gate | −20 LU | −10 LU hergebruikt van integrated |
| Momentary-venster | 400 ms | — |
| Short-term-venster | 3 s | — |
| True-peak-oversampling | 4× minimum, 8× beter | Sample peak gerapporteerd als true peak |
Normaliseren naar boven: voorwaardelijk, geen ja of nee
Diensten normaliseren bij het afspelen. Een master die luider is dan het doel, wordt met het verschil omlaag gedraaid. Dat deel staat niet ter discussie.
Bij de stille master gaan beide zelfverzekerde antwoorden mis. De pagina van Spotify stelt dat "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS." Ze stelt ook: "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality."
Samen gelezen beschrijven die twee zinnen een voorwaarde. Een stille master kan naar het doel worden opgetrokken. Een stille master met hoge pieken wordt misschien niet helemaal opgetrokken, want optrekken zou de headroom opeten die de tweede zin reserveert.
Dus:
- “Stille masters worden nooit opgedraaid” is fout.
- “Stille masters worden altijd naar het doel opgedraaid” is ook fout.
- Wat klopt: opwaartse gain bestaat, en ze wordt toegepast afhankelijk van de headroom van de track.
Wil je die opwaartse gain, dan is de hefboom piekbeheersing in de master — niet het gemiddelde niveau. Een master met echte headroom is een master die ruimte heeft om opgetrokken te worden.
Wat overlimiteren je werkelijk oplevert
Leg de stukken naast elkaar. Een master die naar een hoge integrated loudness is geduwd, wordt bij het afspelen omlaag gedraaid met het verschil tussen zijn niveau en het doel. Hij komt niet luider bij de luisteraar aan. Wat er wel aankomt, is wat je hem onderweg hebt aangedaan: een lagere crestfactor, afgevlakte transiënten en — als je voorbij het true-peak-plafond bent gegaan — intersample peaks die een lossy encoder op zijn eigen voorwaarden afhandelt.
Overlimiteren levert vlakheid op, geen luidheid. Dat is de verdedigbare uitspraak, en ze houdt stand zonder een gepubliceerd doel van enige andere dienst dan de ene die er een heeft gepubliceerd. Zelfs als elk gerapporteerd cijfer voor de andere vijf precies zou blijken te kloppen, zou de conclusie niet veranderen, want het is het mechanisme — normaliseer bij het afspelen, draai het luide omlaag — dat het werk doet, niet het specifieke getal.
Wat je hiermee doet
- Meet integrated loudness en true peak, met oversampling, voordat je iets aanlevert.
- Toets je master aan −14 LUFS en −1 dBTP (of −2 dBTP als je luider bent dan −14 LUFS), want die zijn gepubliceerd, en behandel al het overige als niet-geverifieerd.
- Geeft een tool, plug-in of artikel je een doel per dienst voor Apple Music, YouTube Music, Amazon Music, TIDAL of Deezer zonder het als gerapporteerd in plaats van gepubliceerd te bestempelen, beschouw dat dan als een signaal over die tool.
- Controleer het gedrag van de relatieve gate en de LRA-gate van je meter als dat kan. −10 LU voor integrated, −20 LU voor LRA.
- Stop met jagen op een getal dat bij het afspelen ongedaan wordt gemaakt en begin met het beschermen van de headroom die bepaalt of opwaartse gain jou bereikt.
De gratis luidheidscontrole van Mazufa staat op /loudness-checker. Ze draait volledig in je browser — er wordt geen audio geüpload — en ze rapporteert de gepubliceerde Spotify-cijfers als gepubliceerd, en al het overige als wat het is.
Bronnen
- Spotify, "Loudness normalization" (supportpagina voor artiesten) — doel −14 LUFS, true-peak-plafonds −1/−2 dBTP, en de uitspraken over positieve gain en 1 dB headroom. support.spotify.com/us/artists/article/loudness-normalization/ — read 2026-09-07.
- ITU-R BS.1770, editiegeschiedenis en werking; BS.1770-5 (November 2023) van kracht, BS.1770-4 (October 2015) vervallen. itu.int — verified 2026-09-07.
- EBU R 128 — −23 LUFS, omroep; en EBU Tech 3341 (momentary- en short-term-vensters) en EBU Tech 3342 (Loudness Range, gate van −20 LU). tech.ebu.ch — in ons feitenblad is geen leesdatum vastgelegd.
- AES TD1008 — −16 LUFS voor muziek; −18 LUFS voor spraakgedreven materiaal. aes.org/community/technical-council/technical-document-aestd1008/ — in ons feitenblad is geen leesdatum vastgelegd.