Skip to content

LUFS ​

LUFS(Loudness Units relative to Full Scale)は体感上の音量、つまり聴く人が時間全体でどれくらい大きく感じるかを表す単位です。単なるピークレベル(瞬間的な波形のいちばん高い値)よりもマスタリングで有用なのは、一瞬のピークの大きさだけでは曲全体がどれくらい大きく感じられるかがわからないからです。 ピークが同じ 2 つの曲でも、片方は波形がピーク付近に張り付いている時間が長ければ、その曲の方が大きく感じられます。これが波形の「密度が高い」状態で、音量の大小の差が少なく、全体が詰まって聞こえます。LUFS はその違いを扱うための指標です。

目標値主な用途
-14 LUFSSpotify や YouTube 系の一般的な音楽配信。
-16 LUFSスピーチ、ポッドキャスト、Apple 系、ダイナミクスを残す音楽。
-9 LUFSエンジンの club と cd の配信ターゲット(シーリングは -0.3 dBTP)。公開された規格ではなく、密度を優先して選んだ値。

なぜ重要か ​

処理前後を音量差のまま比較すると、大きい方が良く聞こえやすくなります。そのため /ja/mastering デモではラウドネスマッチした A/B を既定にしています。

ラウドネスは配信上の制約の 1 つにすぎません。マスターには十分な True Peak 安全性 も必要で、ダイナミックレンジ は音楽的な意図に合っている必要があります。

METERS · LOUDNESSIDLE
ラウドネス計測 — LUFS・True Peak・レンジ

バーは再生中の瞬時ラウドネスを追い、パネルは時間ごとのラウドネスです。インテグレーテッド LUFS は全体を表す一つの数値、True Peak はサンプル間も含むピークの推定値、LRA はラウドネスの動く幅を表します。ウィンドウを切り替えると、速い瞬時メーターと滑らかな短時間メーターを比べられます。どちらもウィンドウが埋まってから値を出すため、短時間の曲線はクリップの 3 秒後から始まります。

ウィンドウ

計算のしかた ​

LUFS は ITU-R BS.1770 で定義されています。平均二乗(パワー)の測定なので、デシベルは 10 · log10 の形を使います(オーディオ基礎)。その前段にフィルターを置くことで、単純な RMS メーターより聴感に近い値になります。

段階処理内容
K 特性の重み付け各チャンネルを、高域を約 4 dB 持ち上げるハイシェルフ(頭部が入ってくる音に与える影響)と、聴覚の感度が低い超低域を割り引くハイパスに通します。
ブロックごとの平均二乗重み付けした信号を 2 乗し、100 ms ごとに始まる 400 ms のブロック(75% の重なり)で平均します。
チャンネルの合計各チャンネルのブロックのパワーを足します。L、R、センターは 1 倍で数え、LFE チャンネルは含めません。サラウンドは、スピーカーが側方にあれば(5.1 のサラウンドと 7.1 のサイド 2 チャンネル)約 1.41 倍(+1.5 dB)、後方にあれば(7.1 のバック 2 チャンネルとクアッドのサラウンド)1 倍で数えます。
デシベル化ラウドネス = -0.691 + 10 · log10(合計)。-0.691 は 1 kHz での K 特性のゲインを打ち消す値です。
ゲートと平均積分値では、下のゲートが数えるブロックを決め、残ったブロックをパワーとして平均します。

モーメンタリーラウドネスは 400 ms のブロック 1 つ、ショートタームラウドネスは 3 秒の窓で、積分値はプログラム全体を対象にします。差は LU で数え、1 LU は 1 dB と同じ幅です。目盛りの感覚をつかむ基準が 2 つあります。モノラルファイルでフルスケールまで振れる 1 kHz のサイン波は約 -3.0 LUFS(RMS が -3.01 dBFS のため)、同じサイン波をステレオファイルの両チャンネルに置くと、2 チャンネルのパワーが足されて約 0 LUFS になります。

「ゲート付き」とはどういうことか ​

積分(Integrated)LUFS の値は、ファイル全体の平均ではありません。ラウドネスは短いブロック単位で測られ、どのブロックを数えてよいかを 2 つのゲートが決めます。まず -70 LUFS の絶対ゲートが無音を落とし、次に絶対ゲートを通ったブロックの平均より 10 LU 下の相対ゲートが小さい音の部分も落とします。

平均に届くのはどのブロックか
-10-20-30-40-50-60-70-80絶対ゲート -70 LUFS相対ゲート(10 LU 下)積分 LUFS -13.2400 ms ブロック(時間順)この例では無音と静かなイントロは平均に入らないブロックのラウドネス(LUFS)
  • 積分値に数えられる
  • 相対ゲートで落とされる
  • 絶対ゲートで落とされる
この例ではイントロが相対ゲートより低いため除外されます。相対ゲート以上の静かな区間は平均に入ります。長い無音の余白を足しても積分 LUFS は下がりません。

絶対ゲートより低い無音は除外されます。フェードインや冒頭のナレーションでも、ブロックが相対ゲート以上なら積分 LUFS を下げることがあります。ゲートを通った音声は、音楽かナレーションかを区別せずに算入されます。

ターゲットの選び方 ​

迷ったら -14 LUFS から始めます。多くの音楽配信や動画プラットフォームで扱いやすく、リミッターを過度に押し込まなくても到達しやすい値です。

スピーチやポッドキャストは、子音・息継ぎ・部屋鳴りが聞き取りやすいことが優先されるため、少し余裕のある -16 LUFS が扱いやすいことがあります。ダンス/クラブ系では、フルスケールにかなり近い値を狙うこともあります(エンジンの club と cd ターゲットは -9 LUFS)。その場合は、True Peak、安全な低域、長時間聴いたときの疲れを必ず確認します。

配信プラットフォーム側で正規化が行われる場合、ターゲットを大きく超えたマスターは結局下げられて再生されます。ターゲットを上回ること自体に音量上の利点があるとは限らず、リミッターを深く動かして得た「数字上のラウドネス」が、再生時には削られたパンチだけ残るという結果になることもあります。

数値だけで判断しない ​

ラウドネス目標に近いことは、マスターが良いことの十分条件ではありません。Integrated LUFS が合っていても、リミッターが強く働きすぎてトランジェントが潰れている、低域が痩せている、歯擦音が痛い、という失敗は起こります。

逆に、素材によっては目標より少し低い方が自然に聴こえることもあります。特にアコースティック・スピーチ・余白の多い音楽では、数字を追い込むより、ラウドネスマッチした A/B と、再生環境ごとの聴こえ方の確認を優先します。

libsonare で測る ​

lufs は、Integrated の値、ファイル末尾時点の Momentary と Short-term の値、ラウドネスレンジを返します。

typescript
import { init, lufs } from '@libraz/libsonare';

await init();

const { integratedLufs, shortTermLufs, loudnessRange } = lufs(samples, sampleRate);
python
import libsonare as sonare

result = sonare.Audio.from_file("song.wav").lufs()
result.integrated_lufs, result.short_term_lufs, result.loudness_range
bash
sonare lufs song.wav            # Integrated/Momentary/Short-term の LUFS とラウドネスレンジ
sonare lufs song.wav --series --json   # Momentary と Short-term の時系列を追加
実装メモ

libsonare のラウドネス測定は、ITU-R BS.1770 と EBU R128 系列の勧告で定義されたゲート付き Integrated LUFS モデルに従います。そのうえで、マスタリングチェーンはラウドネス目標とリミッターシーリングを別々に扱います。ラウドネス目標は曲全体の聴感レベルを決め、シーリングはサンプルピーク/True Peak が超えてはいけない上限を決めます。

この 2 つを分けることで、「十分なラウドネスはあるがピークが危険」「ピークは安全だが目標に届かない」といった状態を区別できます。デモのレポートでも入力 LUFS・出力 LUFS・適用ゲインを分けて出します。

LUFS の測定値はレンダリング後のバッファに対して計算します。プレビュー中の一瞬のラウドネスではなく、書き出し対象全体の Integrated 値を見るためです。Short-term や Momentary の動きは聴感判断に役立ちますが、配信ターゲットの判定とは分けます。

関連: ラウドネスマッチングと A/B 比較、True Peak、ダイナミックレンジ