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

皆さん、こんにちは。 最近、FFmpegのAACエンコーダーを全面的に書き直しました。レート制御、RDO、およびPNS、TNS、I/S、M/Sといったすべてのコーディングツールが再設計されました。メトリクス（Googleの新しいZimtohrli、ViSQOL、および私自身の聴覚）の観点から、qaacやfdk-aacと比較して、最高のAACエンコーダーのようです。 kbps 8.1 fast 8.1 twoloopnmr fdk-aac apple libopus 64 0.01315 / 2.65 0.00696 / 3.24 0.00309 / 3.83 0.00322 / 3.69 0.00612 / 3.29 0.00100 / 4.59 96 0.00338 / 3.77 0.00268 / 3.99 0.00134 / 4.04 0.00153 / 3.98 0.00175 / 3.87 0.00039 / 4.62 128 0.00229 / 4.10 0.00170 / 4.28 0.00072 / 4.47 0.00143 / 4.27 0.00081 / 4.44 0.00020 / 4.68 160 0.00129 / 4.30 0.00108 / 4.44 0.00051 / 4.56 0.00065 / 4.31 0.00117 / 4.51 0.00084 / 4.68 256 0.00105 / 4.41 0.00121 / 4.55 0.00031 / 4.61 0.00103 / 4.45 0.00067 / 4.63 0.00002 / 4.73 Zim/ViS、それぞれ低いほど良い/高いほど良い。 書き換えは今日マージされます。ソースからコンパイルするか、BtbNの最新のナイトリービルド（マージされ、更新され次第）を入手してテストできます。 いくつかの詳細： 新しいエンコーダーは厳密にCBRであり、レートの変動はほとんどありません。ビット予算の目標を持つことは、コーディングに大いに役立ちます。-q:a（リアルVBRモード）の使用は推奨しません。 他のエンコーダーはTNS以外のコーディングツールを使用しません。そこでまず、TNSのみを使用して公平に競合を打ち破り、その後、PNS、I/S、M/Sを再実装して決定的に打ち負かしました。 qaacをRE'dしたところ、知覚的最適化は行われていないことがわかりました。単にバンドエネルギーと高周波を優先するビット割り当てカーブを使用しているだけです。私は同様のカーブを使用し、RDOにマスクされたバンドエネルギーを使用することでそれを改善しました。 FFmpegのAACデコーダーはステレオPNSに関して破損しており、バグは他のAACデコーダーにも存在する可能性があるため、エンコーダーで回避しています。他のエンコーダーがPNSを使用しなかったため、このバグはこれまで発見されませんでした。 高ビットレートには特別な注意が払われました。I/SやPNSなどのコーディングツールは、エンコーダーがレートを維持するために良好に機能していれば、自動的にオフになります。 すべてのコーディングツール、PNS、TNS、I/S、M/SはRDOループの一部です。模倣されたヒューリスティックや任意のビットレートカットオフは使用しません。ツールが使用できる場合は使用されます。 ダウンミックスする予定がある場合、または出力がダウンミックスされることを想定している場合は、元の信号位相を維持するために-aac_is 0 -aac_pns 0を使用してください。 エンコーダーは主に48KHzオーディオ用に最適化されています。それを乗り越えてください。2026年です、リサンプリングは無料、48KHzが標準です。44.1KHzでも96KHzでも動作しますが、最高の品質が必要な場合は48KHzを使用してください。 スペクトログラムを見ると、多くの穴が残されています。これは設計によるものです。マスクされたバンドはゼロ化されるかPNS処理されます。これは、隣接するバンドが十分に大きく、欠落しているバンドに気づかないようにするためです。すべてのバンドを悪くコーディングするよりも、可聴バンドのみをうまくコーディングする方が良いのです。 ユーザーによるA/Bテストを楽しみにしています。私は3000トラック（私の音楽コレクション）でこれをテストしましたが、テストするスピーチコンテンツがほとんどなかったため、そこには最適化が必要かもしれません。 エンコーダーはuninit時に追加の統計情報を出力します： 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% これらを以下のように読みます。 平均ラムダ値（値が高いほどエンコーダーがレートを維持するのに苦労します） ショートブロック ロングフレームでのTNS使用率 ショートフレームでのTNS使用率 ミッド/サイドコーディング使用率 インテンシティステレオコーディング使用率 知覚ノイズ置換使用率 もし迷惑なアーティファクトが見つかったら、元の入力サンプルと上記の行を投稿してください。私が調査します。「エンコーダーは主に48KHzオーディオ用に最適化されています。それを乗り越えてください。2026年です、リサンプリングは無料、48KHzが標準です。44.1KHzでも96KHzでも動作しますが、最高の品質が必要な場合は48KHzを使用してください。」 しかし、世界のほとんどのオーディオは44KHzです… spoon氏からの引用（2026-06-30 10:37:12）：「エンコーダーは主に48KHzオーディオ用に最適化されています。それを乗り越えてください。2026年です、リサンプリングは無料、48KHzが標準です。44.1KHzでも96KHzでも動作しますが、最高の品質が必要な場合は48KHzを使用してください。」 しかし、世界のほとんどのオーディオは44KHzです… 私が投稿したベンチマークは主に44.1KHzで行われました。しかし、48KHzのデータで耳で調整したため、一部のウィンドウ処理/トランジェントロジックは48KHzに関連しています。タイミングの差がそれほど大きくないため、44.1KHzにも十分うまく翻訳されたので、そのままにしました。 そして、非可逆エンコードを行うのであれば、48KHzにリサンプルして、デコーダーが後端でそうする必要がないようにする方が良いでしょう。耳で調整したとはどういう意味ですか？具体的に何を調整したのですか？古いAACエンコーダーの品質が低いことを明確に示すキラーFLACサンプルをいくつか持っています。 新しいエンコーダーがはるかに優れていることを願っています。ああ、LynneがHAにいますね！ようこそ！ 知らない人のために：LynneはFFmpegのネイティブUSACデコーダーもすべて書いたと記憶しています。少し話題は外れますが、Lynneさん、USAC再生中のシークに関するグリッチをご存知ですか？ここでたくさん議論されています。例えば、https://hydrogenaudio.org/index.php/topic,129641.msg1083064.html#msg1083064とhttps://hydrogenaudio.org/index.php/topic,129641.msg1083087.html#msg1083087 私はMycroft氏の意見に同意します。FFmpegの古いAACエンコーダーはかなり「最適ではない」性能を発揮し、これはKamedo2氏のリスニングテスト結果の1つ、https://hydrogenaudio.org/index.php/topic,119861.0.htmlでも確認されていると思います。Chris 残念ながら、私は現在FFmpeg AACエンコーダーバージョン N-124995-gbb6de744cc（2026年6月13日土曜日19:08:10版）をテストしています。あなたの完全に書き直されたバージョンは、今後のABC/HRリスニングテスト結果（現在19%完了）には含まれません。 aac_mfはMediaFoundation経由のAACです（Windows 10および11で利用可能） コード：[選択] $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a libopus -b:a 89k out.opus $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a opus -strict experimental -b:a 96k out.opus $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a libfdk_aac -b:a 96k out.mp4 $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a aac -b:a 96k out.mp4 $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a aac_mf -b:a 96k out.mp4 $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a libmp3lame -b:a 96k out.mp3 $ ffmpeg124995 -i in.44100Hz.stereo.wav -c:a ac3 -b:a 96k out.ac3 lynne氏からの引用（2026-06-30 10:31:23）：「書き換えは今日マージされます。」 ええと、実際には今日マージされました。ただ…2026年6月30日ではない今日でしたが。はい。C.R.Helmrich氏からの引用（2026-06-30 16:00:40）：「ああ、LynneがHAにいますね！ようこそ！ 知らない人のために：LynneはFFmpegのネイティブUSACデコーダーもすべて書いたと記憶しています。少し話題は外れますが、Lynneさん、USAC再生中のシークに関するグリッチをご存知ですか？ここでたくさん議論されています。例えば、https://hydrogenaudio.org/index.php/topic,129641.msg1083064.html#msg1083064とhttps://hydrogenaudio.org/index.php/topic,129641.msg1083087.html#msg1083087 私はMycroft氏の意見に同意します。FFmpegの古いAACエンコーダーはかなり「最適ではない」性能を発揮し、これはKamedo2氏のリスニングテスト結果の1つ、https://hydrogenaudio.org/index.php/topic,119861.0.htmlでも確認されていると思います。Chris HE-AACでのシークよりも悪くはないはずですよね？FFmpegではまだプリロールを適切に処理していません。HE-AACが持つ遅延のためにプリロールが大きく増加するからです。 Kamedo2氏からの引用（2026-06-30 16:55:06）：「残念ながら、私は現在FFmpeg AACエンコーダーバージョン N-124995-gbb6de744cc（2026年6月13日土曜日19:08:10版）をテストしています。あなたの完全に書き直されたバージョンは、今後のABC/HRリスニングテスト結果（現在19%完了）には含まれません。」 あなたが実行中のテストをキャンセルすべきだとは思いませんが、もし可能であれば、完全なA/Bテストではなく、簡単な比較を実行していただけませんか？ ちなみに、メトリクスについてですが、Zimはより良いメトリクスですが、高ビットレートで飽和するため、ViSがタイブレーカーとして使用されます。このルールを使用すると、すべての比較で勝利します（Opusは最高なので例外です）。 新しいAACエンコーダーをテストしました。 確かに確かなエンコーディング品質です。 私はこのテストを1曲（Marathon [Vol. II]のBurn the Boats: They are Waiting (Original Game Soundtrack)）のみで行いましたが、lynne氏の要求通り-b:aモードで行いました。 テストしたビットレートは64kbps、134kbps、200kbpsです。 64kは良好ですが、アーティファクトが少し見られます。ffmpeg AAC PNSデコーダーのバグかどうか（結果のファイルをffplayで再生しています）、はっきりしません。 134kと200kは素晴らしい聴き心地です。fb2kのコマンドラインヘルプをお願いします！非常に興味がありますが、時間があまりなく、ffmpegにあまり愛情がないので。