FFmpeg 9.1の新しいAACエンコーダ

 (hydrogenaudio.org)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • FFmpegのネイティブ AACエンコーダ が、rate control、RDO、PNS・TNS・I/S・M/S まで全面的に書き直され、外部AACエンコーダと直接比較できる品質を目指している
  • 新実装は 厳格なCBR に近い動作をし、-q:a ベースの実質的なVBRモードは推奨されない
  • Zimtohrli・ViSQOL比較では、新しい nmr エンコーダは 64〜256kbps 帯で fdk-aac・Apple AAC より概ね良い結果を示したが、Opus は別比較でも依然として優位を保った
  • PNS・TNS・I/S・M/S は RDOループ 内で選択され、ダウンミックスが想定される場合は位相維持のため -aac_is 0 -aac_pns 0 の使用が推奨される
  • 128kbps以上では改善を評価する声が多かったが、64kbpsステレオ・一部のTNSサンプル・音声コンテンツは追加検証が必要な領域として残っている

FFmpeg AACエンコーダの全面再設計

  • FFmpegのAACエンコーダが rate control、RDO、PNS、TNS、I/S、M/S を含めて全面的に書き直された
  • 再設計PR はマージ候補として共有され、その後のスレッドで実際にマージされたことが確認された
  • テストはソースビルド、または BtbN nightly builds の更新後に可能
  • 新エンコーダは aac コーデックとして利用できる
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • I/S を無効化: -aac_is 0
    • PNS を無効化: -aac_pns 0

品質指標と比較対象

  • 比較には Google の Zimtohrli、ViSQOL、聴感テストが使われた
    • Zimtohrli は低いほど良い
    • ViSQOL は高いほど良い
  • 表では新エンコーダは nmr と表記され、従来の FFmpeg 8.1 fast・twoloop、fdk-aac、Apple AAC、libopus と比較された
  • 代表的な結果:
    • 64kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • 高ビットレートでは Zimtohrli が飽和するため ViSQOL がタイブレーカーとして使われ、この基準では Opus を除く比較で新エンコーダが優勢だった

CBR中心の設計とコーディングツール

  • 新エンコーダは CBR専用 に近い形で設計されており、ビットレート変動が非常に小さい
    • ビット予算の目標設定がコーディング品質に役立つ
    • -q:a ベースの実質的なVBRモードは推奨されない
  • 他のエンコーダは TNS 以外のコーディングツールをほとんど使っていないことが比較で確認され、新エンコーダはまず TNS のみで比較した後、PNS、I/S、M/S を再実装した
  • qaac はリバースエンジニアリングの結果、知覚最適化を行っておらず、高周波を優先するビット割り当てカーブとバンドエネルギーを使っている
    • 新エンコーダは類似のカーブに masked band energy を RDO で使用している
  • すべてのコーディングツールである PNS、TNS、I/S、M/S は RDOループ 内で選択される
    • 固定ヒューリスティクスや任意のビットレートカットオフは使わない
    • 利用可能なツールは RDO の判断に従って適用される
  • 高ビットレートでは、エンコーダ自体が十分にうまく動作していれば I/S や PNS のようなツールは自然に無効化され、ビットレートを維持する

デコーダ互換性とダウンミックス時の注意点

  • FFmpeg の AAC デコーダ は stereo PNS 処理に問題があり、同じバグが他のAACデコーダにも存在する可能性があるため、エンコーダ側で回避している
    • 既存エンコーダが PNS を使っていなかったため、この問題はこれまで表面化していなかった
  • ダウンミックスが予定されている、または出力がダウンミックスされる可能性がある場合は -aac_is 0 -aac_pns 0 の使用が推奨される
    • 目的は元の信号の 位相 を保つこと
  • スペクトログラムで多くの穴が見えるのは意図された動作
    • マスキングされたバンドは 0 にするか、PNS 処理する
    • 隣接バンドが十分大きく、欠けたバンドを知覚しにくいなら、すべてのバンドを悪く符号化するより、聞こえるバンドをより良く符号化する方を選ぶ

サンプリングレートとカットオフ方針

  • エンコーダは主に 48kHzオーディオ 向けに最適化されている
    • 44.1kHz と 96kHz でも動作する
    • 最高品質を求めるなら 48kHz の使用が推奨される
  • 公開されたベンチマークは主に 44.1kHz で実施され、耳でチューニングしたデータは 48kHz だった
    • 一部の windowing/transient ロジックは 48kHz に結び付いている
    • 44.1kHz でもタイミング差が大きくないため、そのまま維持されている
  • その後、帯域幅ポリシーが調整された
    • 128kbps は 16kHz に制限
    • 160kbps 以上は 18kHz に制限
    • 192kbps per channel では 20kHz 以上の全スペクトラムを符号化するよう変更された
  • 64kbpsステレオではできることが多くなく、PNS をさらに強めるとステレオイメージが崩れる可能性がある
    • 64kbps では 15kHz でも高すぎる可能性があり、12kHz カットオフでの再テストが求められた
    • モノラルではデコーダバグ回避が不要なため、PNS をはるかに多く使える

テスト範囲とデバッグ統計

  • 開発側のテストは 3000曲のトラック からなる音楽コレクションで行われた
    • 音声コンテンツのテストは非常に少なく、追加最適化が必要な可能性がある
  • エンコーダは終了時に追加統計を出力する
    • 例: Qavg: 207.975 Tr: 5.3% TNS(L): 4.8% TNS(S): 36.9% M/S: 3.9% I/S: 10.0% PNS: 5.1%
  • 統計の意味:
    • Qavg: 平均 lambda 値で、高いほどレート維持が難しい
    • Tr: short blocks
    • TNS(L): long frame における TNS 使用率
    • TNS(S): short frame における TNS 使用率
    • M/S: Mid/Side coding 使用率
    • I/S: intensity stereo coding 使用率
    • PNS: perceptual noise substitution 使用率
  • 気になるアーティファクトを見つけた場合は、元の入力サンプルとこの統計行を一緒に提供すれば分析できる

初期ユーザーテストと残っている問題

  • あるユーザーは Burn the Boats 1曲で 64kbps、134kbps、200kbps をテストした
    • 64kbps は良好だが、わずかなアーティファクトがある
    • 134kbps と 200kbps は非常に良く聞こえる
  • 別のテストでは、64kbps の The Tower サンプルで新しい nmr エンコーダは従来の twoloop より smeary で metallic に感じられるというフィードバックがあった
    • 既存の twoloop にも冒頭部分の collapse、全体的な noise と roughness の問題がある
  • fatboy_30sec サンプルでは、192kbps で 6.836秒と 10.480秒に ticking sound が聞こえ、48kHz にリサンプリング後は 14.125秒の tick が追加された
    • -aac_tns 0 で TNS を無効化すると ticking は消える
    • libavcodec/aacenc_tns.c の TNS_PG_C1_SHORT 値を 3.2、4.2、5.0 に上げて確認してほしいという要望が続いた
  • あるユーザーは 64kbps と 16kHz カットオフ条件では Fraunhofer AAC の方が良く聞こえ、新エンコーダは metallic に聞こえたと評価した
    • 同じユーザーは 128kbps を超える高ビットレートでは新エンコーダがうまく動作すると評価している
    • ネイティブFFmpeg内で広く利用できるAACエンコーダが十分実用的になったという評価もあった

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker News の意見

  • Opus がどれほど強力かを示す事例だと思う
    こうした取り組み自体にも価値はあるし、古いコーデック向けエンコーダが改善されるのは明らかに有益だが、このベンチマークでの Opus の数値を見ると、64kbps でもすべての AAC エンコーダを圧倒している

    • 優れた AAC エンコーダ の最大の利点は効率ではなく互換性だ
      ほぼ 20 年にわたり、リアルタイム動画配信の事実上の標準は H.264 動画と AAC 音声を使う RTMP で、ほかのコーデック対応はほとんどない
      YouTube や Twitch にストリームを送るには結局 H.264 と AAC を送ることになり、OBS も配信モードではほかの映像・音声コーデックの選択をそもそも許可せず、配信者は H.264 と AAC を使うものと想定している
    • 記事を読むまでは、Opus がモデルではなくエンコーダのことだと一瞬勘違いしていた
    • 非可逆音声コーデックの選択は、もうほとんど悩む必要がなくなった
      単に Opus を使えばよく、何らかの理由で Opus を使えないなら互換性のために AAC をかなり高いビットレートで使えばいい
      どのエンコーダやモードを選ぶべきか調べなくても、高品質を得られる
      それでも高品質な標準 AAC エンコーダができるのは素晴らしいが、なぜ主に 固定ビットレート なのかはよく分からない
    • [https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...](https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_bitrate+latency_comparison.svg)
    • Opus の最大の問題は仕様の不足にあると思う: https://nothings.org/stb/stb_opus.html
      このため、特定のライセンス問題が発生しうるゲームやストア配布物では Opus がほとんど使われなくなっている

  • 実際の性能がどうなるのか楽しみだ
    FFmpeg の従来の AAC エンコーダ は出力品質が悪く、耳障りなさえずりのようなアーティファクトが頻繁にあったため、まともな音を得るには動画録画用の各 PC に Apple Core Audio エンコーダをインストールする必要があった
    A/B/X 比較をすると、320kbps の MP3 は FFmpeg でエンコードした 320kbps AAC より良く、Core Audio でエンコードした 256kbps AAC とは同程度だった
    これで Core Audio の導入が不要になるなら大きな改善であり、OBS のようなツールで画面録画や配信をしている人たちは、次のアップデートで音質が大きく向上するかもしれない

    • Apple Core Audio に関しては qaac が便利だ
      iTunes の Windows DLL をラップして CLI 付きの独立したエンコードツールにしてくれ、Linux の Wine でも動作すると理解している: https://web.archive.org/web/20250814194428/https://www.andre...
      高品質な AAC エンコードのために Mac や iTunes 一式のインストールが必須というわけではない
    • 私は FDK AAC エンコーダを使っていたが、Apple のエンコーダが Apple 以外の環境でも使えるとは知らなかった
      以前 192kbps で FDK AAC と Apple AAC を比較したときは違いを感じなかったが、従来の FFmpeg AAC エンコーダはこのビットレートでは破綻していた
    • Hydrogenaudio の議論スレッドにある指標表では、新しいエンコーダが Core Audio より高いスコアを取っている
      ただし固定ビットレート基準だ
      Core Audio には新しいエンコーダにない 可変ビットレート モードの TVBR もある
      そのため、TVBR を使える場合は Core Audio が引き続き最高かもしれないが、より多くの人が問題サンプルを見つけて提供し、チューニングが進めば、新しい FFmpeg エンコーダも十分良くなるはずだと期待している
    • 品質を気にするなら、なぜ可逆コーデックを使わないのか不思議だ
      あるいは Opus を使えばよく、音声にも十分向いていて、今ではほぼどこでも動作する
    • Apple が独自コーデックに固執するのは理解できない
      Apple が H.265 を採用していなければ、今ごろ私たちは AV1 ユートピアに住んでいたかもしれない

  • 「FFmpeg の AAC デコーダにはステレオ PNS 処理のバグがあり、ほかの AAC デコーダにもある可能性があるため、エンコーダ側で回避している。ほかのエンコーダは PNS を使っていなかったので、これまで見つからなかった」という部分が興味深い
    PNS が何なのかは分からないが、誰かのかなり特殊なユースケースを 20 年間悩ませてきたのだろうと思う

    • 問題は 2 つあった
      1 つは、PNS の上に TNS を使うと挿入されたノイズが TNS でシェーピングされるのだが、ノイズを生成したのはエンコーダではなくデコーダなので筋が通らないことだ
      このせいで PNS が壊れており、さらに大きな問題として、PNS をある種のステレオツールと組み合わせるとノイズが両チャンネルに同じように漏れ込み、ステレオイメージング を損なってしまうという点があった
      そのため、両チャンネルの該当帯域がどちらもノイズであるか、十分に非音調的でマスキングされる場合にのみ PNS を有効にするのが最善だ
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • 細部までよく整理された素晴らしいアップデートだ
    Opus は優れていて確固たる位置を占めているが、AAC がなくなることはない

  • 「エンコーダは主に48kHzオーディオ向けに最適化されている。受け入れよう。2026年であり、リサンプリングは無料同然、48kHzが標準だ。44.1kHzでも動くし96kHzでも動くが、最高の品質が欲しいなら48kHzを使え」というくだりがあるが、今どき本当に48kHzが標準なのか？

    • 実際に「標準」に最も近いのは AES5-2018、つまり「プロフェッショナル・デジタルオーディオ推奨慣行」だと思う
      要旨では、PCMを使うオーディオ番組の制作・処理・交換には48kHzのサンプリング周波数を推奨し、一部の民生デジタルアプリケーション向けの44.1kHz、伝送関連アプリケーション向けの32kHz、より高い帯域幅や緩やかなアンチエイリアシングフィルタが必要なアプリケーション向けの96kHzも認めるとされている
      個人的には、44.1kHzは遺産として残ったちょっとした煩わしさのように感じる
    • AACにはサンプリングレートによって窓サイズが変わる奇妙な特性がある
      そのため20ms窓と60ms窓は人間の耳にはかなり違って聞こえるので、各サンプリングレートごとにエンコーダのすべての心理音響パラメータを完全に再最適化しなければならない
      Opusでは当然この問題は解決されている
    • 48kHzは映像と音声の整合をはるかに容易にしてくれる
      たとえば編集後のリップシンクが合わせやすくなる
    • Opusコーデックはすべての入力を48kHzだと仮定し、入力をそこへリサンプリングすると理解している
    • ほぼすべてのDACは、OSが妥当なデフォルト値として選ぶため、基本的に48kHzで動作する

  • より良い新しいFFmpeg AACエンコーダは歓迎だが、細部にはかなり大きな留保が2つある
    固定ビットレートしかサポートしておらず、48kHzサンプリングにしか最適化されていない
    品質基準の可変ビットレートエンコードができないのは大きな空白であり、世界中のCDオーディオが44.1kHzであることを考えると、これも大きな欠落に見える

    • オーディオエンコードにどうして可変ビットレートが必要なのか分からない
      可変ビットレートのオーディオは音がひどいし、ビットレートもそれほど多く節約できない
    • -q:aを使えば「本物の」可変ビットレートを使えるが、指標は数パーセント低い
      それでも知覚しにくく、なお勝っていると思う
      ベンチマークは主に44.1kHzで行い、耳でチューニングしたデータは48kHzだったため、一部のウィンドウイング・トランジェント処理ロジックは48kHzに結び付いている
      ただし44.1kHzにも十分うまく移植されており、タイミング差も大きくないのでそのままにしたということだ

  • これほど多くの部分が開発者本人の耳に依存しているのが興味深い
    同時に不安でもあり、かなりクールでもあるが、オーディオ品質の判断はこれほど主観的だ

    • 表や比較には「Googleの新しいZimtohrli、ViSQOL、そして自分の聴覚」が使われた
    • オーディオでは普通こんなものだ
      Musepackも一時期ニッチで人気があったが、単純ながら非常によくチューニングされたコーデックだった
      スピーカーやヘッドホンも同様で、人々は部品の品質だと思いがちだが、実際には音響物理全般への理解と上手にチューニングする能力が大半を左右する

  • とても嬉しい追加だ
    これでfdk-aacを置き換えられるようになるといい

  • 誰かが史上最高のAACエンコーダを作ってきたのに、最初の反応が48kHzか44kHzかで管理人みたいに小言を言うことだなんて、いかにも昔のインターネットらしい

    • そんなふうに冷笑的に見ることでもない
      書き手は実際に最も一般的に使われるサンプリングレートでテストしていないのだから、どんな真面目なプロジェクトでも数十年動いている既存パイプラインを丸ごと入れ替えるのは無茶だ
      十分な検証が終わるまで待つのはまったく妥当だ

  • 以前 ffmpeg で iPod nano 向けに曲をエンコードしたときはファイルが壊れていた
    再生中、数秒ごとにポップ音やクリック音が途切れ途切れに入っていたが、今は直っているのか気になる