最大サンプルが 0.0 dBFS を示すファイルは、信号が 0 dB に達しているファイルではありません。任意の 2 つのサンプルの間で、再構成された波形はその両方より高く持ち上がりえます。そしてサンプルピークのメーターは、構造上それを見ることができません。そこへ非可逆コーデック — 誰かが聴く前に、すべてのストリーミングサービスがあなたのマスターに適用するもの — が、その飛び出しをさらに高く押し上げます。結果として、DAW ではきれいに測れたマスターが再生時に歪みます。そしてこれはどれも意見の問題ではありません。標本化されたオーディオがどう再構成されるかの帰結です。
この記事で扱うのは、サンプルピークとトゥルーピークが実際に何なのか、なぜオーバーサンプリングが後者を測る唯一の方法なのか、4 倍のメーターに何が見えて何が見えないのか、そして標準化された三つのラウドネスメーターのどれがどの問いに答えるのかです。各サービスが目標値として何を公表しているのか、そして音量の小さいマスターに何が起きるのかは、マスターに実際に起きること で別に扱っています。
サンプルピークはファイル内で最も高い点。トゥルーピークはファイルの中にない。
サンプルピークのメーターは、ファイル内で絶対値が最大のサンプル値を報告します。これは実在する数で、計算も簡単です。すべてのサンプルを見て、いちばん大きいものを残すだけです。
しかしサンプルは連続波形の上の点であって、波形そのものではありません。それらの点を通る波形は、点と点の間で両方より高く持ち上がりえます。再構成されたアナログ波形はファイル内の最大サンプルを超えることがあり、サンプルピークのメーターにはそれを検出する仕組みがありません。 その飛び出しが インターサンプルピーク です。それを含めた再構成波形のレベルが トゥルーピーク で、dBTP で表されます。
これが、「クリップしていない」と「クリップしないだろう」が別々の主張である理由です。サンプルが −0.1 dBFS で頭打ちのデジタル的に安全なファイルでも、トゥルーピークは 0 dBTP をかなり超えていることがあります。ファイルの中には超えているものがありません。波形を再構成する下流のすべて — DAC、サンプリング周波数変換器、非可逆デコーダー — がそれをクリップしうるのです。
実務上の判定は身も蓋もありません。トゥルーピーク、あるいは dBTP の明示的なモードを持たないメーターは、マニュアルが何をほのめかしていようとサンプルピークのメーターです。 これには DAW 内蔵のレベルメーターのほとんどが含まれますし、非常に多くのリミッターのシーリング設定も含まれます。
非可逆エンコードが事態を中立ではなく悪化させる理由
ストリーミングはあなたの WAV を配信しません。配信するのはその AAC、Ogg Vorbis、MP3 エンコードであり、非可逆コーデックはあなたの波形をサンプル単位で再現しません。知覚的に似た別の波形を再現します。デコーダーの出力は、エンコーダーの入力を日常的に上回ります。
その行き過ぎは、特定のエンコーダーのバグではありません。スペクトルの細部を量子化して捨てることの避けられない帰結であり、そして — マスタリングの判断にとって効いてくるのはここです — 元の素材をどれだけ強くリミッティングしたかに比例して大きくなります。 シーリングに向けて信号を強く潰したほど、コーデックは出口でより大きな行き過ぎを生みます。
つまり、ちょうど 0.0 dBTP に乗っているマスターは、0 dBFS を超えるピークを伴ってデコードされ、デコーダーはそれをクリップします。あなたは自分のファイルでこれを聴くことがありません。聴くのは、リスナーが受け取るバージョンの上でだけです。
これに触れている公表仕様は、どれも同じ結論に至っています。AES TD1008 はこう述べています。"For all content, it is recommended that the Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams."（すべてのコンテンツについて、非可逆エンコードされるストリームのコーデック入力において、最大トゥルーピークレベルは −1 dBTP を超えないことが推奨される。）Spotify はトゥルーピークを "below −1dB TP (True Peak) max"（最大 −1dB TP（トゥルーピーク）未満）に保つよう求め、−14 LUFS より大きいマスターについては "keep True Peak below −2dB to avoid extra distortion."（余分な歪みを避けるためトゥルーピークを −2dB 未満に保つ）よう求めています。
Spotify の二つ目の数字が興味深いところです。これは、強くリミッティングされた素材ほどコーデックでの行き過ぎが大きくなるからこそ存在します。シーリングは固定された迷信ではありません。素材が密になるにつれて締まるのです。
オーバーサンプリングがしていることと、4 倍に見えないもの
ファイルの中にないピークを測るには、サンプルとサンプルの間の波形を再構成しなければなりません。ITU-R BS.1770 はそれをオーバーサンプリングで行うと規定しています。サンプル点を補間で追加し、密になった信号のピークを測るのです。
勧告は 48 kHz において 4 倍のオーバーサンプリングを最低限 と定め、"Higher sampling rates and over-sampling ratios are preferred."（より高いサンプリング周波数とオーバーサンプリング比が望ましい）と注記しています。
書いてあるとおりに読んでください。4 倍は適合の下限であって、正確な答えではありません。 4 倍のメーターは、サンプルピークのメーターより多くを捕まえることは保証されますが、すべてを捕まえることは保証されません。4 倍では、本当のピークを 0.1 dB 台で低く読むことがなおありえます。その 0.1 dB 台こそ、人々がシーリングから削ろうとするマージンとちょうど同じ大きさです。
| 使っているもの | 報告するもの | 見落とすもの |
|---|---|---|
| サンプルピークのメーター | ファイル内で最大のサンプル値 | すべてのインターサンプルピーク。コーデックの行き過ぎの問題まるごと |
| 4 倍のトゥルーピークメーター | BS.1770 の適合下限における再構成ピーク | 本当のピークを 0.1 dB 台で低く読むことがなおありえる |
| 8 倍または 16 倍のトゥルーピークメーター | 再構成ピークのより近い推定値 | 段階的に少なくなる。CPU 負荷の増加はごくわずか |
メーターが備えているなら 8 倍か 16 倍のオーバーサンプリングを使ってください。 追加の CPU 負荷はごくわずかですが、追加の精度はそうではありません。
リミッター側にも対になる罠があります。−1.0 dBTP に設定したトゥルーピークのシーリングは、そのリミッターが実際にトゥルーピーク・リミッティングをしている場合にだけ意味を持ちます。多くのリミッターのシーリング設定はサンプルピークであり、−1.0 に設定してもインターサンプルピークは −0.5 dBTP よりどこか上に出ます。コーデックがファイルに触れる前に、マージンの半分が消えているわけです。
あなたのメーターが引用している規格の版
BS.1770 には 6 つの版があります。2006、2007、2011、2012、2015、2023 年です。BS.1770-4（2015 年 10 月）が、実際に出回っているメーターの多くが引用している版であり、BS.1770-5（2023 年 11 月）が現在効力を持つ版です。 ここで述べる 4 倍のオーバーサンプリングの下限、フィルター段、二つのゲートは、いずれも公表された BS.1770-5 に照らして検証しています。
これを知っておく意味は主に、メーターのドキュメントを正しく読むためです。-4 を引用しているメーターがそれゆえに間違っているわけではありませんが、-5 が現行のテキストであり、主張を文書に照らして確かめるときに名前を挙げるべきものです。
モメンタリー、ショートターム、積分 — 三つのメーター、三つの問い
問題のもう半分は、たいていの人が下そうとしている判断に対して間違ったラウドネスメーターを読んでいることです。EBU Tech 3341 は三つの窓を定義しており、それらは本当に別々の三つの問いに答えます。
モメンタリー（M）— 400 ms、ゲートなし。 BS.1770 のゲーティング・ブロックと同じ窓です。モメンタリー・ラウドネスは個々の出来事を追います。スネア、ボーカルの子音、ダウンビート。使うべきなのは何かを 捕まえる ときです。周囲より 6 LU 飛び出しているキック、突出しているセクション。レベルの判断には使わないでください。あまりに落ち着きがなく、モメンタリーのメーターを追いかけることは、まさに再生時のノーマライゼーションが罰する過剰なコンプレッションの結果を生みます。
ショートターム（S）— 3 s、ゲートなし。 3 秒はおおよそ音楽のひとフレーズです。トラック内のバランスの判断に正しいメーターはショートターム・ラウドネスです。3 秒が、リスナーがあるセクションを大きい・小さいと実際に知覚する時間尺度だからです。 ヴァースとコーラスを比べるのに、ブリッジが崩れていないか確かめるのに、そしてアレンジの形を数字として見るのに使ってください。
積分（I）— 番組全体、二重にゲートあり。 サービスがノーマライズの基準にする数字であり、納品仕様に載るべき唯一の数字です。選んだ区間ではなく、トラック全体、最初のサンプルから最後のサンプルまでで測られます。積分ラウドネスは納品仕様であって、ミキシングの道具ではありません。作業中にこれを見ているなら、見ているメーターが間違っています。
| メーター | 窓 | ゲーティング | 答える問い |
|---|---|---|---|
| モメンタリー | 400 ms | なし | いま何が起きた？ |
| ショートターム | 3 s | なし | このセクションはあのセクションに対して釣り合っている？ |
| 積分 | 番組全体 | 絶対 −70 LKFS、続いて相対 −10 LU | 納品時にサービスは何を測る？ |
そこから出る規則はこうです。ショートタームでミックスしマスタリングし、積分で検証し、異常はモメンタリーで調べる。
これが実際に引き起こす誤り
よくある誤りは、マスタリング中に積分ラウドネスを見ながら、誰かに言われた数字になるまでリミッティングを足していくことです。この振る舞いには、二つの別々の失敗が積み重なっています。
一つ目は、積分ラウドネスが二重にゲートされていて、そのゲーティングのために皆が思っているものを測っていないことです。−70 LKFS を下回るブロックはその場で捨てられます。次に、生き残ったブロックの平均が計算され、そこから 10 を引き、その相対しきい値を下回るブロックもまた捨てられます。相対ゲートは、絶対ゲートを通過した平均の 10 LU 下にあります。ファイル全体のゲートなしの平均の 10 LU 下ではありません。 作業セッションへの帰結は直接的です。あなたのトラックの積分ラウドネスは、実質的にその大きい部分の平均ラウドネスであって、トラック全体の平均ではありません。 囁くような 40 秒のイントロと分厚いコーラスを持つ曲は、ほぼ完全にコーラスで測られます。完成したマスターに静かなイントロを足しても積分の読みはほとんど動かず、動くと思っていたエンジニアは驚くことになります。
二つ目の失敗は、ラウドネス・レンジがまた別のゲートを使うことです。EBU Tech 3342 で規定される LRA は、ショートターム・ラウドネスの分布の 10 パーセンタイルと 95 パーセンタイル の推定値の差であり、Tech 3342 はその相対しきい値を、絶対ゲート後のラウドネスレベルの −20 LU 下に設定しています。−10 LU ではありません。 この広いゲートは意図的なものです。LRA は変動を特徴づけるものなので、積分の測定があえて排除している静かな箇所を取り込まなければならないからです。積分用の −10 LU ゲートを LRA に流用するメーターは、系統的に小さすぎる値を報告します。同じファイルで、あるメーターの LRA が別のメーターより明らかに低いなら、−20 LU であるべきところに −10 LU のゲートがあることを疑ってください。
これは数分で試せます。トラック本体より 15 LU 低い素材を 20 秒付け足してください。正しい実装なら LRA は大きく上がります。壊れた実装ではほとんど動きません。
実際に納品すべきもの
指針は短く、そこに出てくる数字はすべて公表されているものです。
- まずシーリングを決める。−1.0 dBTP、トゥルーピーク、オーバーサンプリングあり。 この一覧の中で本当に硬い制約はこれだけです。マスターが積分で −14 LUFS より大きいなら −2.0 dBTP を使ってください。締めた数字が存在するのは、強くリミッティングされた素材ほどコーデックでの行き過ぎが大きいからです。
- 音楽のためにマスタリングする。 リミッターの仕事をできるだけ少なくしたまま、バランス、音色、ダイナミクスを整えてください。この段階では積分のメーターを見ないこと。
- 結果を測る。 たどり着いた積分ラウドネスが何であれ、それがあなたの候補値です。おおよそ −14 から −9 LUFS の間に収まっているなら、公表されている目標値も報じられている数字も、すべてあなたから数 LU の範囲にあります。−9 LUFS より大きいなら、そのリミッティングが何を買ったのかを問うてください。
- リミッティングを足すのではなく、マスタリングを変えて調整する。 メーターが正しい数字を示すまでリミッティングを足して LUFS の数字を狙う行為こそ、ノーマライゼーションが無意味にするために作られた、まさにその振る舞いです。
してはいけないことが二つ。−0.1 dBTP のシーリングはストリーミングにとって様式上の選択ではなく、納品の誤りです。そして、サービスごとに別々のマスターを切らないでください。公表値と報じられた値の広がりはおおよそ 2 LU であり、数字をぴたり当てても聴こえるものは何も変わらず、−1 dBTP で分別のあるダイナミクスを持つ一つのマスターが、どこでも正解です。
納品前に仕上がったファイルを確認したいなら、Mazufa が /loudness-checker で無料のラウドネス／トゥルーピーク・チェッカーを提供しています。すべてあなたのブラウザ上で動き、音源はアップロードされません。
出典
ITU-R BS.1770 — 測定アルゴリズム、K 特性重み付け、ゲーティング、トゥルーピーク
- Recommendation ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level（全文 PDF）: https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
- BS.1770 の勧告ページと版の履歴（BS.1770-0 から BS.1770-5 まで）: https://www.itu.int/rec/R-REC-BS.1770/en
EBU — メーターの窓とラウドネス・レンジ
- EBU Tech 3341, Loudness Metering: EBU Mode metering to supplement EBU R 128（モメンタリー 400 ms、ショートターム 3 s）: https://tech.ebu.ch/publications/tech3341
- EBU Tech 3342, Loudness Range: A measure to supplement EBU R 128 loudness normalisation（−20 LU ゲート、10/95 パーセンタイル）, PDF: https://tech.ebu.ch/docs/tech/tech3342.pdf
AES — コーデック入力におけるトゥルーピークのシーリング
- AES TD1008.1.21-9, Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution（コーデック入力で −1 dBTP）, PDF: https://aes2.org/wp-content/uploads/2024/01/20210924_TD1008_v3.13.pdf
- AES TD1008 の文書ページ: https://aes.org/technical-council/technical-document-aestd1008/
Spotify — 公表されているトゥルーピークのシーリング
- Spotify for Artists, Loudness normalization（−1 dBTP、−14 LUFS より大きいマスターには −2 dBTP）: https://support.spotify.com/us/artists/article/loudness-normalization/