響度正規化到底做了什麼
串流平台會測量你曲目的整合響度，和它自己的目標比較，然後在播放時套用一個增益變化。沒有任何東西被重新編碼，也沒有任何東西被重新壓縮：它是一次音量調整，套用在整首曲目上，在收錄時決定一次，之後每次播放都照樣套用。
結果正是大家覺得違反直覺的部分：母帶做得比目標大聲，並不會讓你比其他人大聲。它只會讓平台把你調小那個差距，你最後和其他所有人落在同樣的播放響度，還為此付出了動態範圍。
這裡的測量，是 ITU-R BS.1770 定義的整合 LUFS 讀數：測量整首曲目，並經過閘控，讓靜音和安靜的段落不會把數字拉低。如果這句話需要拆開來解釋，可以從〈LUFS 到底在測量什麼〉開始；這篇文章假設你已經知道，直接談平台做了什麼。
各平台的目標，以及由誰公布
這裡的數字，不全是由它所描述的平台公布的。Spotify 和 EBU 公布了自己的數字。Apple 和 YouTube 沒有公布任何音樂的響度數字，所以它們的數字是第三方的測量結果。每一行都註明了數字的出處。數字偶爾會變動，所以值得去查看出處，而不是相信你某次學到的數字。
- Spotify：整合響度 -14 LUFS，上限 -1 dBTP（響度高於 -14 LUFS 的母帶為 -2 dBTP）。由 Spotify 在給藝人的指南〈Loudness normalization〉中公布。
- Apple Music：整合響度 -16 LUFS，上限 -1 dBTP。由第三方測得；Apple 只在 Podcast 規範中公布 Sound Check（音量平衡）的 −16 dB，並在 Digital Masters 指南中要求至少 1 dB 的餘量（headroom）。
- YouTube：整合響度 -14 LUFS，未公布真峰值上限。由第三方測得；YouTube 沒有公布任何響度數值，也沒有公布真峰值上限。
- 廣電（EBU R 128）：整合響度 -23.0 LUFS，±0.2 LU，上限 -1 dBTP。由 EBU 在 R 128（2023）中公布。這是廣電節目交付時的響度，而不是播放器的設定。
兩個平台的目標數字可以不同，做的卻是同一件事。Apple Music 的 −16，並沒有以任何你能據以行動的方式，比 Spotify 的 −14「更小聲」：每個平台設定自己的播放響度，你的母帶會被它們各自獨立地調整。大聲的母帶在兩邊都會被調小。兩者的差別在於小聲的母帶，後面談到低於目標的段落會說明。兩個平台各有一頁專門談細節：〈Spotify 的 LUFS 響度〉和〈Apple Music 的 LUFS 響度〉。
列出 EBU R 128 是為了比較，而它是另一種數字。它是廣電業者要求節目交付時的響度，不是播放器的設定，所以不會有任何東西為了符合它而被調小。
我的母帶應該做多大聲？
不是因為 Spotify 說 −14，就做到 −14 LUFS：這是對上面那張表最常見的誤讀。目標描述的是平台會把你的曲目放在哪裡，而不是它希望你以什麼響度交付。一份以 −14 交付的母帶，和一份以 −9 交付的母帶，在開啟響度正規化的串流上都以 −14 播放；聽眾唯一聽得出的差別，是比較大聲的那一份放棄掉的動態。
所以由素材決定。一張稀疏、動態大的唱片，低於串流平台的目標也沒問題：它的峰值離上限很遠，所以 Spotify 可以把它調大，而 Apple 說 Sound Check（音量平衡）也可以。一張密實的唱片，母帶可以做得遠高於目標，而不會失去它原有的任何東西，只是被調小而已。兩個方向的錯誤，都是在追逐數字：為了達到 −14 去壓縮一張民謠唱片，或把一張電子音樂唱片壓到瞬態不再是瞬態，只為了換取一個在播放時就被拿走的響度優勢。
實際的做法是：把唱片做到聽起來已經完成，放在你欣賞的同曲風作品旁邊也站得住；然後測量它，並根據真峰值採取行動。整合響度的數字是資訊，上限才是規則。
如果低於目標呢？
這要看平台，而這也是各平台真正不同的唯一地方。
- Spotify 會把小聲的曲目調大，並公布了能調多大：只調到真峰值達到 −1 dBTP 為止。這就是下面談到上限之所以重要的地方。
- Apple 說 Sound Check 可以「調高或調低每首曲目的音量」。它沒有說會把一首曲目調大多少。
- YouTube 對此什麼也沒有公布。測量過 YouTube 的人回報，它會把大聲的曲目調小，但不會把小聲的曲目調大，所以小聲的母帶會以交付時的響度播放。
把一首曲目調大 4 dB，它的峰值也會升高 4 dB。Spotify 自己的文件說，它在套用正增益時，會為有損編碼留下 1 dB 的餘量，所以一首 −20 LUFS、真峰值已經在 −5 dBTP 的曲目，只會被調大到 −16，而不是 −14：而只有「大聲」這個聆聽設定，會加上限制器把它推得更高。因此，一份峰值接近滿刻度的小聲母帶，在預設設定下聽起來會比周圍所有曲目都小聲，而且沒有任何東西能搶救它。同一份文件也要求，比 −14 LUFS 大聲的母帶，真峰值要保持在 −2 dBTP 以下，因為「較大聲的曲目在為串流編碼時，更容易產生額外的失真」。
結論在每個平台上都一樣：讓峰值遠低於上限，不需要付出任何代價，而能讓響度正規化有空間去做那件簡單的事的，也只有它。
開啟或關閉響度正規化：以及專輯模式
在大多數平台上，響度正規化是聽眾端的設定：Spotify 提供「安靜」「正常」「大聲」三種等級，Apple 則稱之為 Sound Check。有些聽眾會把它完全關掉，有些則根本不會用到：Spotify 表示，它的網頁播放器，以及電視、喇叭等第三方裝置，都不使用響度正規化。不經響度正規化直接播放的曲目，會以它做母帶時的響度被聽到，夾在其他曲目之間，而那些曲目也以它們做母帶時的響度播放。這是比較大聲的母帶唯一真的比較大聲的情境：也正是在這個情境裡，一份要靠響度正規化才聽起來對的母帶，就不對了。
另一個值得了解的設定是專輯模式。聽眾依序播放一整張專輯時，提供這個模式的平台會把整張專輯當成一個整體做響度正規化，而不是逐首處理，所以一首刻意做得小聲的過場曲，相對於下一首曲目仍然是小聲的。在隨機播放或播放清單裡，曲目會被逐首正規化。對母帶工程師來說，這代表一張唱片裡曲目之間的響度關係，在專輯播放時會被保留，在播放清單裡則會被拉平，這也是為什麼一首必須單獨成立的曲目，母帶要做到能單獨成立。
唯一值得嚴格看待的數字
取樣間峰值。這些平台送出的全都是有損音訊，而有損編碼器重建出的波形，會穿過你的取樣點，而不是停在取樣點上：所以一份在取樣峰值表上峰值為 −0.1 dBFS 的母帶，在編碼時可能超過滿刻度而失真。
這就是為什麼公布的上限在 −1 dBTP 左右，而不是 0。這是這些建議裡唯一真正的警告，而不只是偏好，而它的測量方式也和大多數 DAW 裡的峰值表不同：真峰值會對訊號做超取樣，找出取樣點之間的曲線。一個真峰值上限設在滿刻度以下 1 dB 的限制器，就是全部的解法，而且聽不出任何代價。已經做進檔案裡的失真，是另一個診斷：回答那個問題的，是削波與雜訊偵測。
Podcast 與說話類內容
在各大應用程式中，只有 Apple 公布了 Podcast 的響度數字。它的 Podcast 規範建議約 −16 LUFS（它寫成「dB LKFS」，是同一個單位），上下誤差在 1 dB 以內，真峰值不高於 −1 dB。同一頁面說，開啟 Sound Check 時，內容會以 −16 dB 播放。我們沒有找到 Spotify、Amazon 或 YouTube 公布的 Podcast 數字，所以你看到任何被說成是它們的數字，都請當成猜測。說話的動態通常也比音樂大得多，同一集裡，離麥克風比較近的講者和另一位講者，可能相差好幾 LU，所以 Podcast 的響度數字只是工作的一半。另一半是把各個講者的音量拉平，而沒有任何響度正規化會替你做這件事。我們為說話類內容做的事說明了這條路，它主要是音訊修復與音量拉平的問題，而不是母帶後製的問題。
上傳前檢查母帶
測量完成的檔案，在限制器之後、抖動之後、任何取樣率轉換之後，而不是工程檔，並測量整首曲目，而不是最大聲的段落。任何符合 BS.1770 的響度計，給出的整合響度數字誤差都在 0.1 LU 以內；本站的響度計會在你的瀏覽器裡完成測量，不必上傳檔案，並把讀數拿來和上面的目標對照。
然後用正確的方向解讀結果。「比 Spotify 的目標高 3 LU」代表曲目會被調小 3 dB，這不是毛病。「比上限高出 0.4 dB」才是需要處理的那一行。
實際上該怎麼做
為歌曲本身做母帶，事後再檢查數字，而且只根據真峰值採取行動。如果你的曲目落在 −8 LUFS，是因為它就需要這樣，平台會把它調小，而它聽起來仍然是它自己。如果它落在 −8 LUFS，是因為你在追逐響度，那你就是為了一個沒有人聽得到的音量，白白送掉了動態。
如果你寧可根據素材、而不是根據一張表來設定目標，Euphona 的 AI 母帶後製會為它拿到的曲目選擇響度與真峰值目標，稀疏的唱片和密實的唱片會得到不同的答案，並回報它做的每一個調整，讓你可以回頭讀懂它的理由，而不必只是相信它。〈如何為歌曲做母帶後製〉則用手動的方式，談同樣的決定。
繼續閱讀