流媒体服务做响度归一化时，你的母带究竟经历了什么

在响度处理被讨论得最多的六家流媒体服务中，只有一家公布了你可以引用的归一化目标。Spotify 公布的是积分响度 −14 LUFS，真峰值上限 −1 dBTP，若母带响度高于 −14 LUFS 则收紧到 −2 dBTP。Apple Music、YouTube Music、Amazon Music、TIDAL 和 Deezer 完全没有公布任何归一化目标。你见过的关于这五家的每一个数字都是被转述的，而不是公布的——而一旦有人拿它去计算自己的母带会被削减多少增益，这个区别就要命了。

唯一一个公布的流媒体数字

Spotify 自己的响度归一化页面写明目标为积分 −14 LUFS。它写明真峰值上限为 −1 dBTP，而对交付时响度高于 −14 LUFS 的母带为 −2 dBTP。这三个数字，是本文中唯一来自服务方本身的流媒体归一化规范。

这个事实基础比多数母带处理建议所暗示的要窄得多。但它也够用了，因为即便目标没有公布，各处的机制都是一样的：测量积分响度，与目标比较，在播放时施加增益。

什么都不公布的那五家

Apple Music、YouTube Music、Amazon Music、TIDAL 和 Deezer 都没有公布归一化目标。关于它们流传的数字，用唯一诚实的措辞来说是：

广泛转述，服务方未公布： Apple ≈ −16，YouTube Music ≈ −14，Amazon ≈ −14，TIDAL ≈ −14，Deezer ≈ −15。

把它们单独隔出来是刻意的，而随之而来的规则是严格的：不得据此计算任何增益数值。「你的母带在 −8，Apple 在 −16，所以 Apple 会把你压低 8 dB」——这是在一个当事公司从未确认过的数字上做算术，用的还是一套该公司同样从未确认过参数的算法。减法本身很干净，结果却毫无根据。

这不是在源头考据上吹毛求疵。它正是那么多响度建议自相矛盾的现实原因：两位作者为同一家服务捡到两个不同的转述值，都做了那道减法，然后都拿出一个自信的数字。

−23、−16、−18：三个不能互换的数字

另有三个数字被当作可替代的流媒体目标流传。它们不是。

• EBU R 128 规定的是 −23 LUFS。 R 128 是一份广播建议书。它不是流媒体目标，也从来没打算成为流媒体目标。在讨论流媒体交付时引用它，是范畴错误，而不是一个更严格的标准。
• AES TD1008 给出音乐为 −16 LUFS。 这才是人们引用 AES 时通常真正想找的那个面向流媒体的数字。
• TD1008 的 −18 LUFS 适用于以语音为主的内容——新闻、谈话、广播剧。把 −18 说成音乐目标是一个常见且严重的错误。如果某份母带处理指南、插件预设或论坛帖子告诉你 AES 建议音乐用 −18 LUFS，那份文档把语音数字和音乐数字搞混了，它其余部分你也该不予采信。

把 −16 / −18 的区别搞对，是最快判断一位写响度的人是读了原始文献还是抄了摘要的方法之一。

测量标准，以及现行的是哪一版

上述一切都用 ITU-R BS.1770 测量。它有六个版本：-0 (2006)、-1 (2007)、-2 (2011)、-3 (2012)、-4 (2015) 和 -5 (November 2023)。

现行的是 BS.1770-5。2015 年 10 月的 BS.1770-4 已被取代——尽管多数已部署的表头引用的仍是这一版。如果你的表头手册写着 -4，那说明的是手册的年龄，而不是哪一版在生效。要把 -5 称作现行版本。

算法究竟做什么，以及表头在哪里做错

这份规范简短而精确，而其中若干细节被错误实现的频率高到你应该知道它们。

K 加权。 一个两级滤波器：一个高频搁架（「head」滤波器）后接一个高通（RLB）。K 加权曲线在 1 kHz 处的增益是 +0.698 dB——线性值 1.0836。正是这个偏移，使得对 1 kHz 单音的 K 加权测量结果不等于它的未加权电平。

分块。 响度在 400 ms 的块上、以 75% 的重叠计算。

绝对门限。 低于 −70 LUFS 的块被直接丢弃。

相对门限——被说错得最多的那一个。 相对门限由通过了绝对门限的那些块的均值算出，再偏移 −10 LU。它不是未经门限的均值。一个相对于未门限均值来设门限的表头，读取一首含有长时间静音的曲目时，会和遵循规范的表头不一样，而两者的差值取决于你的编排，而不是你的响度。

响度范围。 LRA 定义于 EBU Tech 3342，使用 −20 LU 的相对门限——不是 −10 LU。把积分响度的门限拿来复用给 LRA 是一个常见的实现缺陷，它会让动态素材看起来比实际更平均。

时间窗。 短时响度使用 3 s 的窗（EBU Tech 3341）。瞬时响度使用 400 ms。这是两种不同的测量，不是同一种测量的两档平滑设置。

真峰值。 真峰值是在过采样信号上测量的——BS.1770 下最低 4×，而 8× 更好。采样峰值不是真峰值。采样间峰值可以超过文件中最高的采样值，这正是为什么一份在采样峰值表上恰好读作 0.0 dBFS 的母带，仍然可能让有损解码器削波。Spotify 的 −1 dBTP 和 −2 dBTP 上限是真峰值数值，所以采样峰值表头没法告诉你是否达标。

向上归一化：有条件，不是是非题

服务在播放时做归一化。响度高于目标的母带会按差值被调低。这部分没有争议。

安静母带这一情形，才是两种自信的答案都错的地方。Spotify 的页面写道：「Positive gain is applied to softer masters so the loudness level is -14 dB LUFS.」它同时写道：「We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality.」

把这两句放在一起读，描述的是一个条件。一份安静的母带可能被抬到目标。一份峰值很高的安静母带则可能不会被完全抬上去，因为抬上去会吃掉第二句话所保留的那点余量。

所以：

• 「安静的母带永远不会被调高」是错的。
• 「安静的母带总会被调高到目标」也是错的。
• 正确的说法是：向上增益确实存在，而它的施加取决于该曲目的余量。

如果你想要那份向上增益，杠杆在母带的峰值控制上——不在平均电平上。一份有真实余量的母带，才是有空间被抬起来的母带。

过度限幅到底给你买到了什么

把这些拼起来。一份被推到高积分响度的母带，会在播放时按其电平与目标之差被调低。它不会更响地到达听众耳边。它到达时带着的，是你在路上对它做的那些事：削减了的波峰因数、被压平的瞬态，以及——如果你冲过了真峰值上限——一堆有损编码器会按自己的方式处理的采样间峰值。

过度限幅买到的是平坦，不是响度。 这是站得住脚的表述，而且它不需要除了那唯一一家公布过目标的服务之外的任何公布数据来支撑。即便另外五家的每一个转述数字最后都完全正确，结论也不会变，因为起作用的是机制——播放时归一化、把响的调低——而不是那个具体的数字。

拿这些做什么

• 交付任何东西之前，先测量积分响度和真峰值，且要开过采样。
• 拿你的母带对照 −14 LUFS 和 −1 dBTP（若你的响度高于 −14 LUFS 则为 −2 dBTP）来检查，因为这些是公布过的，其余一切都当作未经核实。
• 如果某个工具、插件或文章给了你 Apple Music、YouTube Music、Amazon Music、TIDAL 或 Deezer 的分服务目标，却没有标明那是转述而非公布，那就把这件事当作关于该工具的一个信号。
• 如果你的表头允许，确认它的相对门限和 LRA 门限行为。积分用 −10 LU，LRA 用 −20 LU。
• 别再追一个在播放时会被抵消掉的数字，转而去保护那份决定向上增益能否落到你头上的余量。

Mazufa 的免费响度检查器在 /loudness-checker。它完全在你的浏览器中运行——不上传任何音频——并且把 Spotify 公布的数字标为已公布，把其余一切标为它们本来的样子。

参考来源

• Spotify, "Loudness normalization"（艺人支持页面）—— 目标 −14 LUFS、真峰值上限 −1/−2 dBTP，以及正增益与 1 dB 余量的表述。support.spotify.com/us/artists/article/loudness-normalization/ — read 2026-09-07.
• ITU-R BS.1770 版本沿革与机制；BS.1770-5 (November 2023) 现行，BS.1770-4 (October 2015) 已被取代。itu.int — verified 2026-09-07.
• EBU R 128 —— −23 LUFS，广播用；以及 EBU Tech 3341（瞬时与短时窗）和 EBU Tech 3342（响度范围，−20 LU 门限）。tech.ebu.ch — 我们的事实清单中未记录阅读日期。
• AES TD1008 —— 音乐 −16 LUFS；以语音为主的内容 −18 LUFS。aes.org/community/technical-council/technical-document-aestd1008/ — 我们的事实清单中未记录阅读日期。