今回の論文
今回の論文は、Meta AIのAlexandre Défossez、Jade Copet、Gabriel Synnaeve、Yossi Adiによる「High Fidelity Neural Audio Compression」です。2022年10月24日にarXivで公開されました。研究分野は、ニューラル音声圧縮と音響信号処理です。この記事では、論文ページと本文のv1を参照します。
選んだ理由は、音声を「大量の波形サンプル」から「学習可能な離散コード列」へ変える考え方に、圧縮と音声AIの接点があるためです。通信量を減らす仕組みだけでなく、音声生成モデルが扱う表現を設計するヒントも得られます。
どんな技術か
EnCodecは、ニューラルネットワークで音声を圧縮・復元するコーデックです。エンコーダが波形を短い間隔の特徴ベクトルへ変換し、量子化器がそれぞれを有限個のコードへ置き換えます。送信側はコード番号を送り、受信側のデコーダが対応するベクトルから波形を復元します。
文章の単語をIDで表すように、音声も整数の列で扱えるようになります。ただし、このIDは単語や音素そのものではありません。圧縮後に元の音を再構成するための音響的な表現です。EnCodecだけで文字起こしや文章からの音声生成ができるわけではありません。
重要なのは、波形を完全に保存することではなく、限られた通信量で聞こえ方を保つことです。非可逆圧縮なので、復元音と入力音は完全には一致しません。論文本文、3節
課題
音声には時間ごとの細かな変化が含まれます。たとえば24 kHz・16ビット・モノラルの未圧縮PCMは、毎秒384,000ビットを要します。これはサンプル数とビット深度の積から求めた値で、ファイルのヘッダなどは含みません。
通信量を減らすほど、声の自然さ、楽器の響き、雑音に埋もれた成分などを保つことが難しくなります。波形の数値誤差が小さくても、耳に不自然な音が残ることがあります。一方、自然に聞こえても細部を忠実に再現しているとは限りません。
従来のOpusなどは、信号処理と知覚特性に基づく設計でこの問題に取り組みます。ニューラル方式では変換自体を学習できますが、学習データから外れた音に弱くなることや、推論計算が重くなることが課題です。EnCodecは、低ビットレートでの聴感品質と、実時間で処理できる計算量を両立しようとします。
音声アプリでは、保存容量や転送量だけでなく、応答開始までの待ち時間も問題になります。品質、通信量、計算時間を別々に評価する必要があります。論文本文、1・4.6節
用語解説
- ビットレートとサンプルレート
- ビットレートは毎秒送るビット数、サンプルレートは毎秒の波形サンプル数です。EnCodecでは24 kHzの入力を6 kbpsなどへ圧縮します。この二つを区別すると、音の時間解像度と通信量を混同せずに読めます。
- 潜在表現
- エンコーダが波形から作る特徴ベクトルです。EnCodecは波形のサンプルを一つずつ送る代わりに、この表現を量子化して送り、デコーダで波形へ戻します。
- 残差ベクトル量子化（RVQ）とコードブック
- コードブックは代表ベクトルの一覧です。RVQは、最初の一覧で近似した後の誤差を、次の一覧でさらに近似します。使う段数を増減できるため、通信量と復元品質の調整に直結します。
- 因果モデル
- 現在の出力を過去と現在の入力だけから計算するモデルです。未来の音を待たずに処理できるため、EnCodecの24 kHzモデルをストリーミング向けにする鍵になります。
- MUSHRA
- 元の音や複数の処理結果を聴き比べ、品質を採点する主観評価の方法です。この論文では人の聴感を直接確認するために使います。点数は文字起こしの正答率や、波形が完全一致した割合ではありません。
技術の仕組み
波形を、時間方向に短い特徴列へ変換します
エンコーダは1次元畳み込みで時間方向を段階的に縮め、2層のLSTMで系列の関係を捉えます。縮小率は合計320です。24 kHzの波形なら、24,000÷320で毎秒75個の潜在ベクトルになります。
量子化後は、デコーダが転置畳み込みなどで時間方向を広げ、波形へ戻します。24 kHzのモノラルモデルは因果的に処理します。一方、48 kHzのステレオモデルは1秒単位の区間を使う非因果モデルで、両者の遅延条件は異なります。論文本文、3.1節
大まかな近似に、誤差の補正を重ねます
RVQでは、潜在ベクトルに最も近いコードを第1段で選び、その代表ベクトルを引きます。第2段は残った誤差を近似し、以後も同じ処理を繰り返します。復元時は、選んだ代表ベクトルを足してデコーダへ渡します。
各コードブックは1,024個の候補を持つため、番号を固定長で送ると1段につき10ビットです。24 kHzモデルで8段を使う場合、毎秒75個×8段×10ビット＝6,000ビット、つまり6 kbpsになります。これはコード部分の計算であり、通信プロトコルなどの付加情報は別です。
学習時にも使用段数を変え、一つのモデルで複数のビットレートを扱えるようにします。公開実装の24 kHzモデルでは、1.5／3／6／12／24 kbpsに対して2／4／8／16／32段を使います。論文本文、3.2節、著者の公開実装
数値の再現と、音の自然さを一緒に学びます
学習では、波形の差と複数の時間解像度でのメルスペクトログラムの差を小さくします。それに加え、複数の窓幅で計算したSTFTを読む識別器が、復元音と元の音を区別します。復元側は識別器を通じて、数値誤差だけでは捉えにくい不自然さを減らします。識別器の中間特徴を近づける損失も使います。
量子化のコード選択はそのままでは微分しにくいため、逆伝播時には量子化を恒等変換のように扱う近似を使います。コードブックは指数移動平均で更新し、使われない項目を置き換えます。また、エンコーダの出力を量子化結果へ近づける損失も加えます。
複数の損失を足すと、値の尺度が大きい項目に学習が偏ることがあります。EnCodecのloss balancerは、復元波形に対する各損失の勾配の大きさを移動平均で見積もり、寄与を調整します。重みを「どの損失をどれだけ効かせたいか」として解釈しやすくする工夫です。量子化の損失は復元波形に直接依存しないため、この調整の対象外です。論文本文、3.2・3.4節
コードの出現確率を学び、さらに短く保存します
追加の小型Transformerは、過去のコード列から次のコードの確率を予測します。その確率を算術符号化に使い、よく現れるコードを少ないビットで表します。同じ時刻の各コードブックの予測は並列に行い、処理を軽くしています。
この段階は、コードを別の内容へ置き換える処理ではありません。元のコード列を可逆に符号化するので、追加の音質劣化を生まずに容量を減らせます。ただし、確率モデルの計算と符号化が増えるため、速度・遅延との交換条件があります。論文本文、3.3節
実験と結果
低ビットレートでの聴感品質を比較します
24 kHzモデルの学習には、DNS Challenge 4やCommon Voiceの発話、AudioSet・FSD50Kの一般音、Jamendoの音楽を使い、音の混合や残響付与も行っています。評価ではクリーンな発話、雑音付き発話、2種類の音楽セットを分けています。48 kHzモデルは音楽のみで学習しています。
MUSHRA評価では各カテゴリから5秒の音を50件選び、各音に最低10件の採点を集めます。以下は24 kHzのストリーミング条件での平均点です。元の表には95%信頼区間もあり、平均の差だけで有意差を断定できません。
| 方式・ビットレート | クリーン発話 | 雑音付き発話 | 音楽セット1 | 音楽セット2 |
|---|---|---|---|---|
| Opus・12 kbps | 76.5 | 61.9 | 77.8 | 65.4 |
| Lyra-v2・6 kbps | 66.2 | 59.9 | 75.7 | 48.6 |
| EnCodec・3 kbps | 67.0 | 62.5 | 89.6 | 87.8 |
| EnCodec・6 kbps | 83.1 | 69.4 | 92.9 | 91.3 |
EnCodecの3 kbpsは、音楽ではOpusの12 kbpsより高い平均点ですが、クリーン発話では低くなっています。「全種類の音で、より少ないビット数なら必ず勝つ」とは読めません。6 kbps同士では、表の各カテゴリでLyra-v2より高い平均点でした。論文本文、4.1〜4.5節・表1
品質、追加圧縮、計算時間を分けて見ます
識別器の比較では、提案するMS-STFT構成のMUSHRA平均は77.5で、MSD＋単一STFTの62.91より高くなりました。一方、SI-SNRなどの客観指標の順位が聴感評価と常に一致するわけではありません。復元波形の誤差だけで品質を判断しないことが重要です。
コード列の追加圧縮では、24 kHzモデルの3 kbpsが平均1.9 kbps、6 kbpsが平均4.1 kbpsになりました。これは内容に応じて変わる圧縮後の平均で、必ず同じファイルサイズになる保証ではありません。
速度は2019年のMacBook ProのCPU・単一スレッド、6 kbpsで測定されています。24 kHzモデルは追加圧縮なしで符号化9.8倍・復号10.4倍の実時間速度、追加圧縮ありでは両方1.6倍でした。48 kHzモデルは追加圧縮を使うと0.68倍・0.66倍となり、その条件では実時間に間に合いません。24 kHzの約13.3 msという初期遅延は計算時間を含まず、アプリ全体の応答遅延でもありません。論文本文、表1・2・5と4.6節
何に使える？
以下は技術の構造に基づく応用案です。論文がそれぞれの業務サービスを実証したという意味ではありません。
音声投稿や記録の転送量を減らします
音声メモ、現場報告、短い音声メッセージなどで、低ビットレートの復元品質を試す価値があります。24 kHzモデルなら、同じモデルの量子化段数を変えて通信量を調整できます。送信側と再生側に対応するモデルが必要なので、通常の音声形式と比較し、端末負荷や再生環境も測ります。
音声生成モデルのトークン表現に使います
公開実装は離散コード列を抽出できます。この列を予測する別の生成モデルを学習し、デコーダで音に戻す構成が考えられます。波形サンプルのまま扱うより時間軸が短くなる点が役立ちます。
ただし、24 kHz・6 kbpsでは毎秒75フレームに8個ずつのコードがあり、単純に並べれば毎秒600個のIDです。コードブック間の構造をどう予測するかが重要になります。圧縮用Transformerを、そのまま文章条件付き音声生成モデルと見なすことはできません。
音声AIのデータ保存形式を比較します
音声を大量に扱う開発では、原音、圧縮音、コード列のどれを保管するかが設計課題になります。コード列を学習に使う構成なら、同じコーデックを繰り返し走らせる処理を減らせる可能性があります。ただし、整数テンソルをそのまま保存した容量はビットストリームと同じではありません。モデル変更時に再変換できる原音も残す方針が考えられます。著者の公開実装
開発や事業へのヒント
最初の検証は、用途に合う音を集めて行います
小規模な開発なら、学習済みモデルで短い音を圧縮・復元し、Opusなどと比較するところから始められます。静かな発話だけでなく、雑音、複数話者、音楽、対象端末のマイクなど、実際に扱う条件を含めます。論文のカテゴリ別スコアが異なることからも、平均点一つで採用を決めるのは避けたいところです。
会議記録なら聴きやすさに加えて、復元音からの文字起こし誤り率も測ります。これは論文の主評価とは別の追加検証です。「人が自然に聞ける」と「後段の認識モデルが正確に読める」は同じ保証ではありません。
通信量と応答時間の予算を別々に決めます
音声対話なら待ち時間、非同期アップロードなら転送量を優先するなど、処理の目的によって選択が変わります。追加の確率モデルによる圧縮は、保存容量を減らす一方、論文の測定では速度を大きく下げています。
ネットワークの転送量だけを見ず、符号化、送信待ち、復号、後段のAI処理を合計して評価します。48 kHzの非因果モデルと24 kHzの因果モデルも、同じ遅延条件として比較しないようにします。
複数の損失は、値より勾配の影響を見ます
loss balancerから得られる設計上のヒントは、損失係数を調整しても、実際の更新に与える影響が狙いどおりとは限らないということです。再構成と知覚品質を組み合わせるモデルでは、勾配の尺度を計測すると、一つの目的に学習が偏る原因を見つけやすくなります。
別のモデルへ転用する場合も、論文の係数をそのままコピーするのではなく、同じ出力に依存する損失か、勾配の調整後に用途の評価が改善するかを確認します。
限界
EnCodecは非可逆圧縮です。自然な復元音が得られても、入力のすべての細部が保存されるとは限りません。原音の厳密な照合や細かな信号解析が目的なら、復元音だけを残す運用は向きません。
学習には8台のA100を使い、1秒の音64件のバッチで合計60万回の更新を行っています。モデルの学習を再現する作業と、学習済みモデルを試す作業は、必要な資源が大きく異なります。また、評価には非公開の音楽セットも含まれ、全条件の追試には制約があります。論文本文、4.1・4.4節
学習した音の分布への依存もあります。48 kHzモデルは音楽で学習されており、発話や特殊な機械音への品質を同じ結果から保証できません。日本語の会議録や専門用語の認識性能も、この聴感評価から直接は判断できません。
追加圧縮では、送受信側の確率計算の微小な違いが復号エラーにつながり得ます。論文は確率を丸める対策と、実運用に向けた追加検証の必要性を述べています。モデル・コードブックのバージョン管理に加え、異なる実行環境で同じコード列を復号できるかの確認が必要です。論文本文、3.3節
因果的なモデル構造があることと、公開APIで長時間ファイルを低メモリで処理できることも別です。公開実装のFAQは、長いファイルをまとめて処理するとメモリ不足になり得るとしています。ストリーミング、パケット欠損、端末性能、チャンク境界の扱いは、アプリ側で検証する必要があります。著者の公開実装、FAQ
よくある質問
Q. EnCodecは音声認識モデルですか？
A. 音声をコード列へ圧縮して波形へ復元するモデルです。文字起こしには別の認識モデルが必要です。コード列も単語IDではなく、復元のための音響表現です。
Q. ビットレートはどうやって変えるのですか？
A. 主にRVQの使用段数を変えます。24 kHzモデルの6 kbpsは8段、3 kbpsは4段です。補正に使うコードが減るため通信量は減りますが、品質も変わります。対象の音で聴き比べて決めます。
Q. 追加のTransformer圧縮は、音質も下げますか？
A. コード列を可逆に符号化するので、この段階では追加の音質劣化を生みません。ただし、元のニューラル圧縮は非可逆です。また、追加圧縮は計算時間と遅延を増やすため、会話向けなら速度も確認します。
Q. 音声チャットへ導入すれば約13 msで応答できますか？
A. 約13.3 msは24 kHzモデルの計算時間を除いた初期遅延です。通信、バッファ、符号化・復号、認識や生成の時間は別にかかります。48 kHzモデルは1秒単位の処理なので、同じ数字を当てはめられません。
Q. コード列を保存すれば、そのまま音声検索に使えますか？
A. コード番号の一致を意味の近さと見なすことはできません。EnCodecは復元品質を学ぶモデルで、意味検索向けに文章や音声の距離を学んだモデルではないためです。検索には別の表現学習や評価が必要です。
今日の学び
この論文は、音声の通信量を減らしながら聴感品質と処理速度を保つ課題を扱いました。エンコーダ・RVQ・デコーダによる圧縮、複数の知覚・再構成損失、コードの確率を使う追加圧縮で取り組んでいます。開発へのヒントは、音声の表現を設計することが、転送量だけでなく生成モデルの入力や学習データの扱いにもつながる点です。採用時には、音の種類ごとの品質、後段のAI精度、処理時間をそれぞれ測ることが大切です。