ラウドネスマッチングと A/B 比較
A/B 比較は、同じ音源の 2 つのバージョン（多くは処理前の音源と処理後のマスター）を切り替えて聴く方法です。ラウドネスマッチングは、それを同じくらいの聴感音量で行うことで、単純な音量差ではなく音色、ダイナミクス、広がり、ピークの挙動を比べられるようにします。マスタリング判断を良くするための、もっとも基本的で効果の大きい方法の 1 つです。
ラウドネスマッチングをしないと、最初の印象では大きい方が良く聞こえやすくなります。最終的な納品レベルを確認する場面では音量差そのものも重要ですが、EQ、コンプレッション、ステレオ幅、サチュレーション、リミッターが本当に改善になっているか判断するには不向きです。
なぜ大きい方が良く聞こえるのか
似た音を違う音量で再生すると、大きい方がより明瞭で、明るく、広く、迫力があるように感じやすくなります。実際にはゲインしか変わっていない場合でも起こります。
このバイアスは、マスタリングでは特に危険です。多くのプロセッサは副作用としてラウドネスを変えるからです。
| プロセッサ | 比較が偏る理由 |
|---|---|
| EQ | ブーストによって処理後の方が大きく、良く聞こえることがある。 |
| コンプレッション | ピークを抑えつつ平均レベルが上がる。 |
| サチュレーション | 倍音が増え、体感上の音量が上がる。 |
| リミッティング | ピークを抑えた後、メイクアップで密度が上がる。 |
| ステレオワイドニング | 音像が広がると、センターの芯（モノラルでも崩れない成分）が弱まっていても、大きく迫力があるように感じられることがある。 |
ラウドネスマッチングは比較を完璧にするものではありません。それでも、「大きいから良い」という一番わかりやすい落とし穴を避けられます。
使い方
処理の良し悪しを判断するときは、ラウドネスマッチングを有効にします。
- 処理後のバージョンをレンダリングする。
- ラウドネスマッチした A/B 再生を有効にする。
- 同じフレーズで処理前 / 処理後を切り替える。
- 音色、パンチ、ボーカルの安定、低域の制御、ステレオイメージ、アーティファクトを聴く。
- 実際の最終納品レベルを確認するときだけマッチングを外す。
マッチングを外したときだけ処理後が良く聞こえるなら、それは主に音量が上がっただけかもしれません。その場合は処理量を下げて、もう一度比較します。
何を聴くか
A/B では「大きくなったか」ではなく、問題が減ったかを確認します。低域が安定したか、ボーカルや主旋律が埋もれにくくなったか、シンバルや歯擦音（サ行の耳につく成分）が痛くないか、サビでリミッターが潰していないかを順番に見ます。
短いループだけで判断しないでください。イントロ、サビ、低域が多い部分、静かなテイルでは、副作用の見え方が変わります。特にデノイズ、エキサイター、ステレオ幅の副作用は、静かな箇所やヘッドホンで分かりやすくなります。
これだけでは判断できないこと
ラウドネスマッチングは納品ターゲットではありません。A/B では公平に比較できても、ファイル自体が大きすぎる、小さすぎる、またはリリースに対してピークが危険ということはあります。
また、メーターの代わりにもなりません。LUFS（Loudness Units relative to Full Scale。放送・配信で使われる聴感ラウドネスの単位）と True Peak で配信上の制約を確認し、そのうえでラウドネスマッチした聴取で音楽的に有効な処理かを判断します。
書き出した WAV の実音量や True Peak シーリングを確認するときは、マッチングを外します。別環境での確認も同じ考え方です。スマートフォン、安いイヤホン、車内スピーカー、小音量再生では、マッチングを外して実音量で聴くほうが、再生環境ごとの聴こえ方の差（トランスレーション）を把握しやすくなります。差が出るのは絶対的な音量、低域の量、歯擦音まわりであり、マッチングが担う比較の公平性とは別の問題だからです。
libsonare で測る
それぞれのバージョンの Integrated LUFS を測り、大きい方を小さい方に合わせて下げます。ゲインが正になることはないので、マッチングは常に下げる方向にしか働きません。サイトの comp-take-a.wav（-8.3 LUFS）と comp-take-b.wav（-10.8 LUFS）なら、テイク A が 2.5 dB 下がり、テイク B はそのままです。
import { init, lufs, masteringAbMatchLoudness } from '@libraz/libsonare';
await init();
const a = lufs(samplesA, sampleRate).integratedLufs;
const b = lufs(samplesB, sampleRate).integratedLufs;
const anchor = Math.min(a, b);
const gainA = anchor - a; // A にかける dB
const gainB = anchor - b; // B にかける dB
// エンジンに、大きいほうのテイク（A）を小さいほう（B）まで下げさせることもできます:
const { samples: matched, appliedGainDb, matchedTruePeakDbtp } = masteringAbMatchLoudness({
source: samplesA,
reference: samplesB,
sampleRate,
});import libsonare as sonare
a = sonare.lufs(samples_a, sample_rate).integrated_lufs
b = sonare.lufs(samples_b, sample_rate).integrated_lufs
anchor = min(a, b)
gain_a = anchor - a # A にかける dB
gain_b = anchor - b # B にかける dB
# エンジンに、大きいほうのテイク（A）を小さいほう（B）まで下げさせることもできます:
matched, match = sonare.mastering_ab_match_loudness(samples_a, samples_b, sample_rate)sonare lufs take-a.wav # A の Integrated LUFS
sonare lufs take-b.wav # B の Integrated LUFS
# 小さい方の値を各値から引くと、2 つのゲインが求まりますmasteringAbMatchLoudness は、上げる方向にも下げる方向にもソースをリファレンスのレベルへ動かします。逆向きに、小さいソースを渡すとヘッドルームの制限なしに持ち上げるため、ピークが 0 dBTP を超えることがあります。返ってきた音声を書き出す前に、matchedTruePeakDbtp を確認してください。
エンジンの配信ターゲット
マスタリングアシスタントは、次のターゲットを名前で扱います（masteringPlatformNames() で一覧できます）。これはエンジン自身の設定であり、各配信サービスが現在採用している基準ではありません。
targetPlatform | Integrated ラウドネス | True Peak シーリング |
|---|---|---|
streaming、youtube | 独自の値はなく、アシスタントの既定の -14 LUFS を使う | -1 dBTP |
broadcast | -23 LUFS | -1 dBTP |
podcast | -16 LUFS | -1 dBTP |
club、cd | -9 LUFS | -0.3 dBTP |
audiobook、cinema | なし。渡した値がそのまま使われる | なし |
club と cd は、ヘッドルームを削って密度を取る設定です。-0.3 dBTP は、ほかの行が残している余裕の一部を手放します。masteringStreamingPreview は逆に、各プラットフォームの正規化があなたのマスターに何をするかを見せます。既定では Spotify と YouTube が -14 LUFS、Apple Music が -16 LUFS で、いずれもシーリングは -1 dBTP です。結果として、プラットフォームごとの normalizationGainDb と ceilingRisk が返ります。
libsonare デモでの扱い
マスタリングデモでは、A/B 再生の「ラウドネスを揃える」が既定で有効です。切り替えた先のバージョンは、読み込んでいるバージョンのうちもっとも小さいものに合わせて下げられるため、単純な音量差でどれかが有利になることはありません。リファレンストラックを読み込んでいる場合はリファレンスが基準になることもあり、そのときはソースとレンダリング後マスターの両方が下げられて再生されます。
この設定は書き出し音声には影響しません。WAV のダウンロードはレンダリングされたレベルのままです。ラウドネスマッチングは、ブラウザプレイヤーで 2 つのバージョンを比較するときだけ使われます。
実装メモ
デモは、ソース・レンダリング後マスター・（読み込んでいれば）リファレンストラックの Integrated LUFS を取り、そのうちもっとも小さい値を基準にします。再生中の側には、その基準まで下げるための再生時だけのゲインオフセットがかかります。オフセットが正になることはなく、マッチングは常に下げる方向にしか働きません。
この方式ではどちらのバッファも書き換えません。書き出される WAV が正式な結果であり、レポートや CLI／API で再現する場合は、ブラウザプレイヤーの一時的な比較ゲインではなく、レンダリング後 LUFS とチェーン設定を見ます。