Of the six streaming services whose loudness handling is most often discussed, exactly one publishes a normalisation target you can quote. Spotify publishes −14 LUFS integrated, with a true-peak ceiling of −1 dBTP, tightened to −2 dBTP if the master is louder than −14 LUFS. Apple Music, YouTube Music, Amazon Music, TIDAL and Deezer publish no normalisation target at all. Every figure you have seen for those five is reported, not published — and the difference matters the moment someone uses one to calculate how much gain reduction their master will get.
The one published streaming figure
Spotify's own loudness normalisation page states the target as −14 LUFS integrated. It states the true-peak ceiling as −1 dBTP, and −2 dBTP for masters delivered louder than −14 LUFS. Those three numbers are the only streaming-service normalisation specifications in this article that come from the service itself.
That is a narrower factual base than most mastering advice implies. It is also enough to work with, because the mechanism is the same everywhere even when the target is not published: measure integrated loudness, compare it to a target, apply gain at playback.
The five services that publish nothing
Apple Music, YouTube Music, Amazon Music, TIDAL and Deezer publish no normalisation target. The figures in circulation for them are, in the only honest phrasing available:
Widely reported, not published by the service: Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15.
Those are set apart deliberately, and the rule that goes with them is strict: do not compute a gain figure from them. "Your master is at −8, Apple is at −16, so Apple will pull you down 8 dB" is arithmetic performed on a number that the company in question has never confirmed, using an algorithm whose parameters it has also never confirmed. The subtraction is clean; the result is unfounded.
This is not pedantry about sourcing. It is the practical reason so much loudness advice contradicts itself: two writers pick up two different reported values for the same service, both do the subtraction, and both present a confident number.
−23, −16, −18: three figures that are not interchangeable
Three other numbers circulate as though they were alternative streaming targets. They are not.
- EBU R 128 specifies −23 LUFS. R 128 is a broadcast recommendation. It is not a streaming target and was never meant to be one. Quoting it in a discussion of streaming delivery is a category error, not a stricter standard.
- AES TD1008 gives −16 LUFS for music. This is the streaming-oriented figure people are usually reaching for when they cite AES.
- TD1008's −18 LUFS figure applies to speech-led content — news, talk, drama. Stating −18 as the music target is a common and serious error. If a mastering guide, plugin preset or forum post tells you AES recommends −18 LUFS for music, that document has confused the speech-led figure with the music figure, and you should distrust the rest of it.
Getting the −16 / −18 distinction right is one of the fastest ways to tell whether someone writing about loudness has read the source or copied a summary.
The measurement standard, and which edition is in force
Everything above is measured with ITU-R BS.1770. It has six editions: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) and -5 (November 2023).
BS.1770-5 is in force. BS.1770-4, from October 2015, is superseded — even though it is the edition most deployed meters still cite. If your meter's manual names -4, that tells you about the manual's age, not about which edition governs. Name -5 as current.
What the algorithm actually does, and where meters get it wrong
The specification is short and precise, and several of its details are implemented incorrectly often enough that you should know them.
K-weighting. A two-stage filter: a high-shelf ("head" filter) followed by a high-pass (RLB). The gain of the K-weighting curve at 1 kHz is +0.698 dB — linear 1.0836. That offset is why a K-weighted measurement of a 1 kHz tone does not equal its unweighted level.
Blocks. Loudness is computed over 400 ms blocks with 75% overlap.
The absolute gate. Blocks below −70 LUFS are discarded outright.
The relative gate — the one that is stated wrongly most often. The relative gate is computed from the mean of the blocks that survived the absolute gate, then offset by −10 LU. It is not the ungated mean. A meter that gates relative to an ungated mean will read a track with long silences differently from one that follows the spec, and the two will disagree by an amount that depends on your arrangement rather than on your loudness.
Loudness Range. LRA, defined in EBU Tech 3342, uses a −20 LU relative gate — not −10 LU. Reusing the integrated-loudness gate for LRA is a common implementation bug, and it makes dynamic material look more consistent than it is.
Time windows. Short-term loudness uses a 3 s window (EBU Tech 3341). Momentary uses 400 ms. These are different measurements, not different smoothing settings on one measurement.
True peak. True peak is measured on an oversampled signal — 4× minimum under BS.1770, and 8× is better. Sample peak is not true peak. Inter-sample peaks can exceed the highest sample value in the file, which is why a master that reads exactly 0.0 dBFS on a sample-peak meter can still clip a lossy decoder. Spotify's −1 dBTP and −2 dBTP ceilings are true-peak figures, so a sample-peak meter cannot tell you whether you meet them.
| Parameter | Value | Common error |
|---|---|---|
| Absolute gate | −70 LUFS | — |
| Relative gate (integrated) | −10 LU below the mean of surviving blocks | Computed from the ungated mean |
| LRA gate | −20 LU | −10 LU reused from integrated |
| Momentary window | 400 ms | — |
| Short-term window | 3 s | — |
| True-peak oversampling | 4× minimum, 8× better | Sample peak reported as true peak |
Upward normalisation: conditional, not a yes or no
Services normalise on playback. A master louder than the target is turned down by the difference. That part is uncontroversial.
The quiet-master case is where both confident answers are wrong. Spotify's page states that "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS." It also states: "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality."
Read together, those two sentences describe a conditional. A quiet master may be raised to the target. A quiet master with high peaks may not be raised all the way, because raising it would consume the headroom the second sentence reserves.
So:
- "Quiet masters are never turned up" is wrong.
- "Quiet masters are always turned up to the target" is also wrong.
- What is correct: upward gain is real, and it is applied subject to the track's headroom.
If you want the upward gain, the lever is peak control in the master — not average level. A master with genuine headroom is a master that has room to be raised.
What over-limiting actually buys you
Put the pieces together. A master pushed to a high integrated loudness gets turned down at playback by the difference between its level and the target. It does not arrive louder at the listener. What it does arrive as is the thing you did to it on the way: reduced crest factor, transients flattened, and — if you pushed past the true-peak ceiling — inter-sample peaks that a lossy encoder will handle on its own terms.
Over-limiting buys flatness, not loudness. That is the defensible statement, and it holds without needing a published target from any service other than the one that has published one. Even if every reported figure for the other five turned out to be exactly right, the conclusion would not change, because the mechanism — normalise on playback, reduce the loud — is what does the work, not the specific number.
What to do with this
- Measure integrated loudness and true peak, with oversampling, before you deliver anything.
- Check your master against −14 LUFS and −1 dBTP (or −2 dBTP if you are louder than −14 LUFS) because those are published, and treat everything else as unverified.
- If a tool, plugin or article gives you a per-service target for Apple Music, YouTube Music, Amazon Music, TIDAL or Deezer without labelling it as reported rather than published, treat that as a signal about the tool.
- Confirm your meter's relative gate and LRA gate behaviour if it lets you. −10 LU for integrated, −20 LU for LRA.
- Stop chasing a number that gets undone at playback and start protecting the headroom that determines whether upward gain reaches you.
Mazufa's free loudness checker is at /loudness-checker. It runs entirely in your browser — no audio is uploaded — and it reports the published Spotify figures as published, and everything else as what it is.
Sources
- Spotify, "Loudness normalization" (artist support page) — target −14 LUFS, true-peak ceilings −1/−2 dBTP, and the positive-gain and 1 dB headroom statements. support.spotify.com/us/artists/article/loudness-normalization/ — read 2026-09-07.
- ITU-R BS.1770 edition history and mechanics; BS.1770-5 (November 2023) in force, BS.1770-4 (October 2015) superseded. itu.int — verified 2026-09-07.
- EBU R 128 — −23 LUFS, broadcast; and EBU Tech 3341 (momentary and short-term windows) and EBU Tech 3342 (Loudness Range, −20 LU gate). tech.ebu.ch — no read date recorded in our fact sheet.
- AES TD1008 — −16 LUFS for music; −18 LUFS for speech-led content. aes.org/community/technical-council/technical-document-aestd1008/ — no read date recorded in our fact sheet.