LUFS ラウドネス測定 — 配信ターゲット (YouTube / Spotify / EBU) との差分

ラウドネス計測に持ち込む音源は配信直前のマスター

Integrated LUFS を確認する操作は、楽曲やポッドキャストを配信プラットフォームに出す直前に起きます。つまり処理するファイルは、その時点でのベストテイクです。エンジニアが最終確認のために LUFS を計測しようとするタイミングに、クラウドツールを使うとマスターが外部サーバーへ届くことになります。

ラウドネス値 (Integrated LUFS / LRA) は音楽の構造的な情報でもあります。ダイナミクスレンジの広い繊細な楽曲なのか、ヘビーコンプレッションされた EDM なのかは LUFS と LRA の組み合わせで大まかに分かります。つまり計測結果を保持することは、楽曲の特徴的な情報を保持することと同じです。

オンラインラウドネスチェッカーに音楽を送ることのリスク

無料のラウドネス計測サービスは多く存在しますが、音声ファイルを受け取ってサーバーで解析するアーキテクチャをとるものでは、マスターファイルが外部に届きます。利用規約でコンテンツの使用権が設定されているものもあり、配信直前の音楽が「サービス向上のための素材」として扱われる可能性は、利用者側からは確認できません。

「計測しかしていない、変換はしていない」という操作感があっても、ファイルの転送は起きています。LUFS 計測は音声波形のすべてを読む必要があるため、ファイル全体を受け渡さないと計測できません。計測という操作の軽さと、転送されるデータの重さがズレているのが、オンラインラウドネスチェッカーの構造的な問題です。

K-weighting biquad フィルタがブラウザ内で BS.1770 を実装

このツールは Web Audio API の decodeAudioData で音声を取り込み、OfflineAudioContext を 48 kHz にセットして decodeAudioData で再サンプリングした後、自前実装の K-weighting biquad フィルタ (ITU-R BS.1770-4 準拠の高域棚上げ + DC 除去フィルタの 2 段構成) を適用します。フィルタ後の瞬時パワーを 400 ms ゲートのブロックに分割し、相対ゲーティング (-70 LKFS 絶対閾値 → -10 LU 相対閾値) をかけて Integrated Loudness を算出します。LRA は短期ラウドネス (3 秒窓) のパーセンタイル差で求めます。

計算の全工程がブラウザのメモリ内で動き、ネットワーク通信はゼロです。DevTools の Network タブを開いた状態で操作しても、ページロード後の音声関連リクエストは発生しません。実装は GitHub で公開されており、biquad の係数計算を含めて監査できます。

配信フローの中でラウドネスチェックを習慣にする

LUFS の値を一度確認する習慣をつけると、配信プラットフォームによる音量正規化後に意図したミックスバランスが崩れる、という問題を事前に発見できます。特に Spotify / YouTube の -14 LUFS を大きく上回るマスターは、プラットフォーム側で音量を下げられることで相対的な余白感が変わります。目標値に対してどれだけずれているかを「ブラウザの中だけで確認してから調整する」フローは、音声が外に出ずに済む分、リスクが小さくなります。

LUFS チェックだけでなく、audio-true-peak で True Peak (inter-sample peak) も合わせて確認することを推奨します。Sample Peak ではクリッピングが検出されなくても、MP3 / AAC エンコード後に真の波形ピークが 0 dBTP を超えることがあります。ラウドネスと True Peak を同時に確認して、両方をターゲット内に収めてから配信するのが現在の標準的なワークフローです。差分が出たら audio-volume でゲインを当てて再測定、波形の見え方を視覚的に確認したい場合は audio-waveform や audio-spectrum も同じブラウザ内で参照できます。

ITU-R BS.1770 と K-weighting の中身 — なぜ単純な RMS ではないのか

ラウドネス測定は、単純な RMS (二乗平均平方根) ではなく K-weighting という人間の聴覚特性を模した周波数重み付けを通したパワーを基準に計算します。BS.1770 が定める K-weighting は 2 段の biquad フィルタで構成され、(1) 38 Hz 周辺の DC 漏れと低周波の不要成分をハイパスで除去する stage 1 (RLB フィルタ)、(2) 1.5 kHz 以上を +4 dB ほど持ち上げる stage 2 (high-shelf フィルタ) を直列に通します。これにより、人間が「うるさい」と感じる中高域 (2〜4 kHz、子音の帯域) が強調され、低域だけが大きい曲が過剰に評価されないように補正されます。

Integrated Loudness の計算は、K-weighted パワーを 400 ms 矩形窓 でブロック化し、(a) -70 LUFS の絶対しきい値で無音区間を除外、(b) 残りブロックの平均から -10 LU の相対しきい値で「小音量区間」を除外する、という二段ゲーティングを経て最終値を出します。Loudness Range (LRA) は短期 (3 秒窓) ラウドネスの第 10〜95 パーセンタイル差で、ダイナミクスの広さを表します。LRA = 3〜5 は強くコンプレッションされた EDM、LRA = 8〜12 は標準的なポップス、LRA = 15〜20+ はクラシックや映画音響、というのが大まかな目安です。ステレオでは ITU 重み (L=R=C=1.0、Ls=Rs=1.41) を適用しますが、本ツールではステレオ素材 (L=R=1) のみをサポートしています。

配信プラットフォーム別ターゲットと「正規化されると何が起きるか」

ストリーミング各社のラウドネス正規化ターゲットは、Spotify -14 LUFS、YouTube -14 LUFS、Apple Music -16 LUFS、Amazon Music -14 LUFS、Apple Podcasts -16 LUFS、TIDAL -14 LUFS、放送向け EBU R128 -23 LUFS、米国地上波 ATSC A/85 -24 LKFS というのが現状の主要ターゲットです。マスターがターゲットを上回る場合 (例: -9 LUFS のミックスを Spotify に上げる)、プラットフォーム側で -5 dB の自動減衰がかかります。逆に大きく下回る (例: -22 LUFS のクラシック録音) と、Spotify Loud / Normal 設定によっては自動的にゲインアップされ、True Peak が 0 dBTP を超えてクリップする可能性があります。

落とし穴として、(a) ストリーミング各社の正規化はオプトイン / オプトアウト可能 (Spotify Premium のラウドネス設定、Apple Music Sound Check) で、ユーザーが切っているリスナーには元のレベルで届く、(b) Album モード (Spotify / Apple Music) は単曲ではなくアルバム全体の最大 Integrated Loudness で正規化されるため、アルバム内の静かな曲はそのままの音量で再生される、(c) ポッドキャストの -16 LUFS ターゲットは音楽より静かなため、楽曲挿入があると相対的に大音量になりすぎる、(d) 自動正規化は True Peak ≤ -1 dBTP を保証しないので、audio-true-peak での追加チェックが必須、などがあります。本ツールで -14 LUFS 配信ターゲットに対して差分が +3 LU と出たら、audio-volume で -3 dB 適用してから audio-true-peak で確認、というルーチンが安全です。