ラウドネスの扱いがよく話題になる 6 つのストリーミングサービスのうち、引用できるノーマライゼーション目標値を公表しているのはちょうど 1 社です。Spotify は積分ラウドネスで −14 LUFS を公表し、トゥルーピークの上限を −1 dBTP、マスターが −14 LUFS より大きい場合は −2 dBTP に締めると公表しています。Apple Music、YouTube Music、Amazon Music、TIDAL、Deezer はノーマライゼーション目標値をまったく公表していません。この 5 社について目にした数字はすべて伝聞であって公表値ではありません。そしてこの違いは、誰かがその数字を使って自分のマスターがどれだけゲインを下げられるかを計算した瞬間に効いてきます。
唯一の公表されたストリーミング側の数字
Spotify 自身のラウドネス・ノーマライゼーションのページは、目標値を積分ラウドネスで −14 LUFS と述べています。トゥルーピークの上限は −1 dBTP、−14 LUFS より大きく納品されたマスターについては −2 dBTP と述べています。この記事に出てくるストリーミングサービスのノーマライゼーション仕様のうち、サービス自身から出ている数字はこの三つだけです。
これは、たいていのマスタリング談義が前提にしているより狭い事実の土台です。同時に、作業する土台としてはこれで十分でもあります。目標値が公表されていなくても、仕組みはどこでも同じだからです。積分ラウドネスを測り、目標値と比べ、再生時にゲインをかける。
何も公表していない 5 社
Apple Music、YouTube Music、Amazon Music、TIDAL、Deezer はノーマライゼーション目標値を公表していません。この 5 社について流通している数字は、可能な唯一の誠実な言い方をすれば、次のとおりです。
広く報じられているが、サービス自身は公表していない値： 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 で測定されます。この規格には 6 つの版があります。-0（2006）、-1（2007）、-2（2011）、-3（2012）、-4（2015）、-5（2023 年 11 月）。
効力を持っているのは BS.1770-5 です。2015 年 10 月の BS.1770-4 は置き換えられています。 それでも、実際に出回っているメーターの多くはいまだに -4 を挙げています。手元のメーターのマニュアルが -4 と書いているなら、それはマニュアルの古さを教えているのであって、どの版が現行かを教えているのではありません。現行として挙げるべきは -5 です。
アルゴリズムが実際にしていることと、メーターが間違えるところ
仕様は短く、正確です。そして、いくつかの細部は十分な頻度で誤って実装されているので、知っておくべきです。
K 特性重み付け。 2 段のフィルターです。ハイシェルフ（「head」フィルター）に続いてハイパス（RLB）。K 特性カーブの 1 kHz におけるゲインは +0.698 dB — 線形で 1.0836 です。このオフセットがあるため、1 kHz のトーンを K 特性で測った値は、重み付けなしのレベルと一致しません。
ブロック。 ラウドネスは 75% オーバーラップの 400 ms ブロック で計算されます。
絶対ゲート。 −70 LUFS を下回るブロックは、そのまま捨てられます。
相対ゲート — 最も頻繁に誤って説明されるもの。 相対ゲートは 絶対ゲートを通過した ブロックの平均から計算され、そこから −10 LU オフセットされます。ゲートをかけていない平均では ありません。ゲートなしの平均を基準に相対ゲートをかけるメーターは、長い無音を含む曲について、仕様どおりのメーターとは違う値を示します。そして両者のずれは、あなたのラウドネスではなくアレンジ次第の量になります。
ラウドネス・レンジ。 EBU Tech 3342 で定義される LRA は、−20 LU の相対ゲートを使います。−10 LU ではありません。積分ラウドネス用のゲートを LRA に流用するのはよくある実装バグで、ダイナミックな素材を実際より均一に見せてしまいます。
時間窓。 ショートタームのラウドネスは 3 s の窓を使います（EBU Tech 3341）。モメンタリーは 400 ms です。これは別々の測定であって、一つの測定のスムージング設定の違いではありません。
トゥルーピーク。 トゥルーピークは オーバーサンプリング した信号上で測定します。BS.1770 のもとでは 4 倍が最低限 で、8 倍 ならなおよいです。サンプルピークはトゥルーピークではありません。インターサンプルピークはファイル内の最大サンプル値を超えうるので、サンプルピークのメーターでちょうど 0.0 dBFS を示すマスターでも、非可逆デコーダーではクリップすることがあります。Spotify の −1 dBTP と −2 dBTP の上限は トゥルーピーク の数字なので、サンプルピークのメーターでは満たしているかどうか判定できません。
| パラメータ | 値 | よくある誤り |
|---|---|---|
| 絶対ゲート | −70 LUFS | — |
| 相対ゲート（積分） | 通過したブロックの平均から −10 LU | ゲートなしの平均から計算している |
| LRA のゲート | −20 LU | 積分用の −10 LU を流用している |
| モメンタリーの窓 | 400 ms | — |
| ショートタームの窓 | 3 s | — |
| トゥルーピークのオーバーサンプリング | 4 倍が最低限、8 倍がなおよい | サンプルピークをトゥルーピークとして報告している |
上方向のノーマライゼーションは条件つきで、イエスかノーかではない
サービスは再生時にノーマライズします。目標値より大きいマスターは、その差だけ 下げられます。ここには異論がありません。
小さいマスターの場合が、自信に満ちた二つの答えがどちらも間違っている場所です。Spotify のページはこう述べています。"Positive gain is applied to softer masters so the loudness level is -14 dB LUFS."（ラウドネスレベルが -14 dB LUFS になるよう、音量の小さいマスターにはプラスのゲインが適用されます。）そしてこうも述べています。"We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality."（トラックのヘッドルームを考慮し、音質を保つために非可逆エンコード用に 1 dB のヘッドルームを残します。）
二つを合わせて読むと、この二文は条件を述べています。音量の小さいマスターは目標値まで上げられる ことがあります。ピークの高い小さいマスターは、最後まで上げられない ことがあります。上げれば、二文目が確保しているヘッドルームを使い切ってしまうからです。
つまり、
- 「音量の小さいマスターは決して上げられない」は誤りです。
- 「音量の小さいマスターは必ず目標値まで上げられる」も誤りです。
- 正しいのはこうです。上方向のゲインは実在し、そのトラックのヘッドルーム次第で適用されます。
上方向のゲインが欲しいなら、レバーはマスターのピーク管理であって、平均レベルではありません。本当にヘッドルームのあるマスターとは、上げてもらう余地のあるマスターです。
過剰なリミッティングで実際に手に入るもの
要素を組み合わせてみます。積分ラウドネスを高く押し上げたマスターは、再生時にそのレベルと目標値の差だけ下げられます。リスナーのところに大きな音で届くわけではありません。届くのは、そこへ至る途中であなたがそれに施したものです。クレストファクターの低下、潰れたトランジェント、そして — トゥルーピークの上限を超えて押していたなら — 非可逆エンコーダーがそれぞれの流儀で処理することになるインターサンプルピーク。
過剰なリミッティングが買えるのは平坦さであって、大きさではありません。 これが擁護できる言明であり、公表値を出している 1 社以外の目標値を必要としません。仮に他の 5 社についての伝聞値がすべてぴたりと正しかったとしても、結論は変わりません。働いているのは仕組み — 再生時にノーマライズし、大きいものを下げる — であって、個々の数字ではないからです。
これをどう使うか
- 何かを納品する前に、積分ラウドネスと トゥルー ピークを、オーバーサンプリングありで測ってください。
- 自分のマスターを −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/ — 2026-09-07 読み取り。
- ITU-R BS.1770 の版の変遷と仕組み。BS.1770-5（2023 年 11 月）が効力を持ち、BS.1770-4（2015 年 10 月）は置き換えられている。itu.int — 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/ — 当社のファクトシートに読み取り日の記録なし。