True Peak (dBTP) 測定 — 4x オーバーサンプリングで inter-sample peak を検出

True Peak チェックが必要な音声は配信直前のマスターファイル

True Peak (dBTP) の計測は、楽曲を配信プラットフォームに提出する前の最終工程です。このタイミングで処理されるファイルは、エンジニアが仕上げたベストテイクの音楽マスターです。Spotify や Apple Music などへの提出前に、MP3 / AAC エンコード後のクリッピングを防ぐために行うこの確認を、外部サービスに頼ると未公開音楽がサーバーへ届きます。

True Peak はサンプル間の補間波形のピーク値であり、計算には 4 倍オーバーサンプリングが必要です。この計算がそれなりの処理量を必要とするため、クラウドで処理したいというニーズが生まれますが、その代償として未公開の音楽マスターがサーバーへ届くことになります。

マスターをオンラインチェッカーに送るときに起きること

True Peak 計測に特化したオンラインサービスは比較的少ないですが、ラウドネス計測を兼ねたオンラインツールが代替として使われることがあります。いずれもサーバーで計算するモデルをとる場合、配信直前のマスターが外部のサーバーへ届きます。利用規約でコンテンツ使用権が設定されているサービスでは、楽曲マスターがデータ活用の対象になり得ます。

さらに、True Peak の値だけでなく「この楽曲のダイナミクスはこうなっている」という波形の特性が、計測処理を通じてサーバー側に明らかになります。これはアーティストや制作チームが公開前に知らせたくない情報を含む場合があります。

49 タップ Kaiser-windowed sinc FIR でブラウザ内 4 倍補間

このツールは Web Audio API の decodeAudioData でファイルをデコードし、OfflineAudioContext を使って音声データを処理します。True Peak の計算は、49 タップの Kaiser 窓付き sinc ローパスフィルタを 4 つの多相フィルタ (poly-phase filter) に分解し、隣接サンプル間の補間値を計算する方式で実装しています。ITU-R BS.1770-4 Annex 2 のリファレンス FIR に準拠しており、サイン波や無音区間での検証では公式リファレンス実装とほぼ一致します。

計算全体がブラウザのメモリ内で完結します。DevTools の Network タブを確認すると、ページロード後の音声関連リクエストはゼロです。Kaiser 窓のパラメータと多相フィルタの実装を含めて、ソースコードは GitHub で公開されています。

配信前の True Peak チェックをブラウザ内フローに組み込む

True Peak チェックは audio-loudness-lufs と組み合わせて使うのが標準的なワークフローです。両方の値を確認してから配信に提出する習慣をつけると、プラットフォームのエンコード後にクリッピングが出る、という問題を防げます。ストリーミング配信向けの目安は Integrated LUFS -14 LUFS + True Peak -1.0 dBTP です。

True Peak が 0 dBTP を超えている場合は、リミッターのしきい値を 1〜2 dB 下げるか、DAW を経由せず手早く確認したいときは audio-volume で全体ゲインを下げて再測定するフローも有効です。波形上のどこでピークが立っているかを目視したい場合は audio-waveform、その瞬間のスペクトル特性を見たい場合は audio-spectrum を並列に開いて確認すると、音楽が外部に出るのは最終的な配信プラットフォームへの提出時だけ、という運用が実現できます。

Inter-sample Peak の物理的意味と Sample Peak との差

Sample Peak (dBFS) は離散サンプルの最大絶対値で、PCM データから直接読める値です。一方 True Peak (dBTP) は、デジタル → アナログ変換器 (DAC) が低域通過フィルタで補間して再構成する連続波形のピーク値で、サンプル点と次のサンプル点の「あいだ」に発生する Inter-sample Peak まで含めて評価します。Sample Peak が -0.1 dBFS でも、Inter-sample Peak が +0.5 dBTP に達することは珍しくありません。

なぜサンプル間のピークがサンプル値を超えるのか — Nyquist-Shannon のサンプリング定理に基づき、PCM データは「無限長の sinc 補間で連続信号を完全に再構成できる」前提で記録されています。実機の DAC や MP3 / AAC の周波数領域処理を経た後の再生波形は、入力 PCM の最大値より高いピークが出現します。特に高域が支配的な楽曲、リミッターで強く整形された楽曲では Inter-sample Peak が +1〜+3 dBTP に達することもあり、これがストリーミング配信先で「謎のクリッピング」として発覚する主因です。

配信先別のラウドネス + True Peak ターゲット早見表

各ストリーミング・放送プラットフォームには公式のラウドネスノーマライゼーション仕様があり、True Peak の上限も同時に規定されています。Spotify は Integrated -14 LUFS / -1.0 dBTP、Apple Music は -16 LUFS / -1.0 dBTP (Sound Check 仕様)、YouTube は -14 LUFS / -1.0 dBTP、Amazon Music は -14 LUFS / -2.0 dBTP、Tidal は -14 LUFS / -1.0 dBTP、SoundCloud は -14 LUFS 程度 (公式値なし) です。放送系では EBU R128 が Integrated -23 LUFS / -1.0 dBTP、米国 ATSC A/85 (CALM Act 対応) が -24 LKFS、日本の TR-B32 が -24 LKFS と地域差があります。

ストリーミング配信向けは概ね -14 LUFS / -1.0 dBTP が現代的な目標で、これより大きい (=-9 LUFS など) と各プラットフォームが自動でゲインを下げるため、「音圧を上げても無意味」が現代の常識になりつつあります。逆に -16 LUFS より小さいと、プラットフォームによっては自動的にゲインを上げてくれるサービスとそうでないサービスがあり、Apple Music の Sound Check のような ReplayGain 方式は再生時のみゲイン補正、Spotify の Loudness Normalization は再生レベル設定によって挙動が変わります。完成マスターの True Peak と Integrated LUFS の組み合わせを把握しておけば、配信先ごとに別マスターを書き出す必要があるかどうかが判断できます。