メニュー

スペクトログラムは嘘をつかない: ODG と実際にビットが使われている場所

スペクトログラムは嘘をつかない: ODG と実際にビットが使われている場所

比較対象のコーデックランキング: qAAC、Opus、LAME、ADC。ADC は大差で最下位
カテゴリ:
記事
タグ:
ADC
言語:
ENJA
署名:
保存

これは ADC に関する連載記事の第4回です。前回までの記事はこちらこちらこちらです。

ここまでの3本では、主に ADC の主張、マーケティング文句、そして内部設計を見てきました。でも、ホームページのコピーやリリースノートの大言壮語より、よほど大事な問いがもうひとつあります。「同じ目標ビットレートで、既存のコーデックと並べたとき、実際のところどれくらい戦えるのか?」です。

この記事では、2026年2月15日に生成した、私自身のベンチマーク結果を使います。この記事のために自分で作ったコーデックベンチマーク基盤を使い、adclameopusqaac を、名目上 128 kbps という条件で 24 トラックに対して比較しました。音質の客観評価には GST PEAQ Advanced を使い、それに加えて SNR と実効ビットレートも記録しています。

以前のスペクトログラム記事と混同しないように補足しておくと、あちらの比較で使ったのは ADC v0.82 でしたが、今回のベンチマークで使ったのは、この記事執筆時点での新しい版、つまり ADC 0.84 rev.0 の実行ファイルです。ここは重要です。でないと「そのベンチマークは最新版じゃないから古い」と言われかねませんので。

今回使ったエンコーダのバージョンは次のとおりです。

  • ADC (generic) v0.84 rev0
  • LAME 3.100
  • Opus-tools 0.2, using libopus 1.6.1
  • qAAC 2.85, Core Audio Tools 7.10.9

設定も特にひねっていません。

  • ADC は要求ビットレートどおりに指定し、joint stereo を有効にし、さらに宣伝されている -h の「高音質」モードも有効にしました。もっとも、前回の記事で触れたとおり、この -h フラグは高音質オプションのような顔をしておきながら、実際には何もしていないように見えます。
  • LAME は 128 kbps CBR モードで実行しました。
  • Opus は通常の VBR 挙動のまま、ビットレート目標を 128 kbps に設定しました。
  • qaac は CVBR 128 モードで実行しました。

すべてのトラックは、エンコード前とデコード後の両方で 44,100 Hz 16-bit ステレオに正規化しています。ソースはすべて厳密にロスレスです。

スペクトログラム確認から、正式なベンチマークへ

第2回の記事では、いろいろなスペクトログラムを載せました。あのときの主張は比較的シンプルで、ADC ではスイープにひどいエイリアシングが出る、スペクトルに穴が空く、時間経過とともに音が崩れる、そして他のコーデックではそういう問題が可聴な形では出ていない、あるいはまったく出ていない、というものでした。それだけでも十分に示唆的ではありましたが、まだあれは非公式な議論です。スペクトログラムは多くのことを教えてくれますが、ベンチマークそのものではありません。

今回のベンチマークが有用なのは、次のことを一度にやっているからです。

  • すべてのコーデックを同じようなビットレート帯にそろえる
  • PEAQ Advanced で音質を測る
  • 要求ビットレートを盲信せず、実効ビットレートを記録する
  • 採点前にアラインメントのずれを補正し、出力のシフトが音質の悪さとして誤認されないようにする(おっと、前振りですね)

ちなみに、コーデックの評価にはやはり ABX がいちばんだとは思っています。ただ、ここで扱っているすべてのコーデックについて、すべてのファイルを1本ずつ ABX するほどの忍耐力は私にはありません。なので、私にとって現実的な選択肢は PEAQ だけでした。

ODG とは何か

このレポートで最も重要な指標は、PEAQ ODG、つまり Objective Difference Grade です。

ざっくり言うと、こうです。

  • 0 は差が知覚できない
  • -1 は知覚できるが不快ではない
  • -2 は少し不快
  • -3 は不快
  • -4 は非常に不快

もちろん、どんな客観指標も実際に聴くことの代わりにはなりませんし、PEAQ は ABX テストでもありません。でも、ここでは十分に役に立ちます。なぜなら私たちが見ているのは、すでに十分に優秀なエンコーダ同士のごく小さな差ではないからです。既存フォーマットに挑戦すると自称しているコーデックが、本当にそこまで行けているのかどうかを見るベンチマークなのです。

総合順位

まずは、今回の総合順位です。

CodecMean ODGMean SNR (dB)Mean kbpsQuality scoreAdjusted score
qaac-0.39120.37132.8174.0073.15
opus-0.40318.65130.1972.9072.02
lame-0.72818.41128.0369.5369.53
adc-1.57615.84126.9259.3959.39
xychart-beta
    title "名目 128 kbps における平均品質スコア"
    x-axis ["qaac", "opus", "lame", "adc"]
    y-axis "score" 0 --> 80
    bar "Quality score" [74.00, 72.90, 69.53, 59.39]

最初に目につくのは、ADC が完全に置いていかれていることです。平均 ODG は -1.576。少なくとも、サイトに書いてあるような「音声圧縮の DNA を再定義する」などという話ではありません。あの文句は、さすがにこの ODG を見るとちょっと笑ってしまいます。

確かに qaac と Opus は、平均すると名目値より数 kbps ほど上振れしています。でも、その点はレポート側でビットレート係数をかけて補正してあり、だからこそ adjusted score を別に出しています。そのペナルティを入れてなお、qaac と Opus は余裕で上位のままです。ビットレート補正を完全に無視して、生の quality score だけを見ても、ADC はやはり最下位です。LAME に対してすら 10 ポイント以上負けていて、Opus と qaac にはおよそ 13 から 15 ポイント差をつけられています。つまり、これは「他のコーデックがビットレートでズルをした」みたいな話ではありません。ADC が普通に、より悪い音を出しているだけです。

ADC は、ちょっと負けているだけではない

トラックごとの勝敗数で見ると、絵はもっとひどくなります。

CodecFirst-place finishesLast-place finishes
qaac210
opus30
lame01
adc023
xychart-beta
    title "24 トラック中の1位獲得数"
    x-axis ["qaac", "opus", "lame", "adc"]
    y-axis "tracks" 0 --> 24
    bar "Wins" [21, 3, 0, 0]

文字どおりです。ADC は1トラックも勝っていません。

しかも 24 トラック中 23 トラックで最下位でした。唯一最下位を回避したのは Chief Keef - Love Sosa で、そのときだけは LAME をほんのわずかに上回りました。ただし、そこでも Opus と qaac には負けています。ここは大事です。今回の結果は「ADC は現代的コーデックには負けるが、少なくとも MP3 には食らいついている」という話ではありません。違います。ほぼ 全部 に負けています。しかも、多くの人がもう古典扱いしているようなエンコーダアーキテクチャに対しても、です。おまけに MP3 だって ADC と同じく QMF を使っています。やれやれ、QMF を使うとベンチマークで派手に負けるのと何か相関でもあるんでしょうか。うーん。

ODG の結果を深刻度ごとにまとめることもできます。

CodecBetter than -1-1 to -2-2 to -3<= -3
qaac24000
opus24000
lame22200
adc51423
pie showData
    title ADC ODG の深刻度分布
    "Better than -1" : 5
    "-1 to -2" : 14
    "-2 to -3" : 2
    "<= -3" : 3

つまり ADC は、ベンチマークの大半を「劣化が測定できる」どころか、普通に気づける領域で過ごしていたことになります。そして3トラックでは、「不快」領域にまで突っ込みました。128 kbps で、です。 「現代的」で「革命的」な非可逆音声コーデックが 128 kbps で「不快」まで行く。なかなかの話です。私はちょっと信じたくありません。

最悪ケースが語っていること

今回のベンチマークで、ADC の結果が特に悪かった5例は次のとおりです。

TrackADC ODGBest codecBest ODGADC kbpsBest codec kbps
Air Supply - Making Love Out Of Nothing At All-3.398qaac-0.443127.95133.05
Fearofdark - Surfing on a Sine Wave-3.227qaac-0.172126.00127.10
Fearofdark - Rolling Down The Street, In My Katamari-3.018qaac-0.152128.49126.59
Sergio Mendes & Brasil 66 - Batucada-2.377qaac-0.602124.35140.07
Sergio Mendes & Brasil 66 - The Look Of Love-2.151qaac-0.604124.48140.14

かなりひどい負け方です。いや本当に。

特に Fearofdark の2曲は壊滅的です。というのも、以前のスペクトログラム結果とほとんど完璧に一致しているからです。合成的な音、鋭い高調波、上の帯域に高密度で詰まった成分。こういう素材こそ、粗い、あるいは不安定な符号化フロントエンドの弱さをきれいに露呈させます。

Sergio Mendes & Brasil 66 の結果も興味深いです。これらは古いボサノヴァ録音で、ステレオの振り方がかなり極端です。楽器がほとんど左か右に張りついていて、その中間がほとんどないようなミックスです。そうなると、もともとステレオ状態に妙な癖がありそうなコーデックにとっては、かなり相性が悪い。しかも、チャネル入れ替え問題をひとまず脇に置いたとしても(おっと、前振りを自分で潰してしまいましたが)、こういうハードパンのミックスはそうそう甘くありません。

ここで非常に重要な細部がひとつあります。Rolling Down The Street, In My Katamari では、ADC は qaac より 多く のビットレートを使っていて、Opus に対してはそれ以上に大きな差でビットを使っていたのに、それでも ODG は -3.018 まで崩れています。

これこそ、この記事全体の中心テーマです。問題は単に ADC のビット数が少ないことではありません。問題は、そのビットが耳にとって必要な場所に向かっていないことです。

公平のため、一応書いておくと、ADC の 最良 の結果は次の3つでした。

TrackADC ODGBest codecBest ODG
Chief Keef - Love Sosa-0.574qaac-0.470
Dragonforce - Through The Fire And Flames-0.654qaac-0.413
Orchestre de Paris - Le Sacre du Printemps: II. Les augures printaniers-0.838qaac-0.486

Chief Keef の Love Sosa は、ハイハットとスネアがかなり鋭い drill / trap 系の曲なので、ADC がそこで LAME を上回るとは正直思っていませんでした。まあ、本当にギリギリですが、それでも上回っています。一方の Dragonforce は高速なメタルの壁みたいなアレンジですし、The Rite of Spring の結果はストラヴィンスキーのオーケストラ断片です。つまり、ADC の比較的ましな結果は特定ジャンルに偏っているわけではありません。ただし、やはり 勝ち ではないのですが。

実際にビットが向かっている場所

もっと役に立つ比較はこちらです。

Compared against ADCMean ODG improvementMean SNR improvementMean bitrate difference
lame+0.812+2.31 dB+1.28 kbps
opus+1.145+2.55 dB+3.52 kbps
qaac+1.159+4.24 dB+6.35 kbps

LAME は、平均するとたった 1.3 kbps ほど多く使うだけで、ADC に対してかなり大きな音質差をつけています。Opus と qaac は、さらに大きな音質向上を得つつ、ビットレート的には依然として同じような帯域に収まっています。

しかも、個別トラックでは ADC のほうが 多く 使っているのに、それでも大きく負けている例がちゃんとあります。

  • Surfing on a Sine Wave: ADC は Opus より 7.96 kbps 多く使っているのに、スコアは -3.227 対 -0.235
  • Rolling Down The Street, In My Katamari: ADC は qaac より 1.90 kbps 多く使っているのに、スコアは -3.018 対 -0.152
  • Belphegor - Baphomet: ADC は Opus より 6.48 kbps 多く使っているのに、スコアは -1.196 対 -0.524

これが、「時間領域の純粋性」とやらのマーケティングが何の助けにもならない理由です(そもそも QMF をパイプラインに入れた時点で、純粋な時間領域でも何でもありませんが)。どう……うーん、「現代的」とは言えませんね。QMF 自体がかなり古いので。まあそれはさておき、エンコーダがビットを変なところに使い、耳にとってまずい損傷をそのまま残すなら、どれだけそれっぽい思想を掲げても ODG では勝てません。まず無理です。現代のコーデックが強いのは、限られたビットを知覚に合わせてどう配るべきかを知っているからです。少なくとも私のテストでは、ADC はそれがまるでできていません。そして開発者自身も、それを認めています。

To reiterate for clarity: ADC is a free, experimental, and demonstrative lossy audio codec/archiver. It belongs to the DPCM family, and its current performance and characteristics are inherently shaped by this foundational choice. As such, it operates within certain technical boundaries that differ from codecs based on other principles (like MDCT-based transforms).

Key aspects of its current experimental state include "It does not yet employ psychoacoustic models for inaudible frequency trimming or masking."

へえ。ホームページの説明とはだいぶ違いますね。

ベンチマークは、むしろ ADC に優しかった

結果には、もうひとつ重要な点があります。ADC の出力は、そもそも そのままでは公正に採点すらできなかった ので、ベンチマーク側で後始末をしています。

IssueADCOther codecs
Non-zero alignment delayall 24 tracks, from -32 to -136 samples0 on all competitor decodes
Left-right channel swap correction4 tracks0

左右の入れ替え補正が必要だった ADC の4トラックは次のとおりです。

上でも触れたとおり、Sergio Mendes & Brasil 66 の2曲は、左右にかなり大きく振られた録音です。そういう素材でチャネルが混乱するのは、なおさら言い訳しづらい話です。

開発者は実際に、これを FFmpeg のせいにしようとしていました。「メタデータを読むときに、ときどきステレオチャンネルを反転させる」と。

Warning: In this version, ffmpeg sometimes inverts the stereo channels when reading metadata. In the next version, I will disable metadata processing, at least for ADC.

この説明は、私はまったく信用していません。まず、チャネルの左右入れ替えなんて、FFmpeg に対して人が普通に予期するような挙動ではありません。しかも FFmpeg ですよ。よりによって。第二に、私は FFmpeg も、FFmpeg に依存する ADC の GUI コンバータも使わずに ADC をテストしました。それでも左右入れ替えは起きました。そこまで来ると、FFmpeg を責めるのは、単に開発者が「自分が何か間違えたかもしれない」という可能性を頭に置いていないだけに見えます。ADC が壊しているのではなく、きっと何か別のもののせいだ、と。そうですか。もちろん FFmpeg のせいであって、私の完璧で革命的で画期的な音声コーデックのせいではない、と。はいはい。

重要なのは、レポートは こうした問題で ADC を罰していない ということです。ステレオの入れ替えも、謎のアルゴリズム的遅延もです。(しかも作者はゼロレイテンシだとも言っていますが、まあそれはさておき。)ベンチマーク基盤はそれらを検出し、補正し、そのうえで ODG や SNR などを計算しました。つまり、もし何かあるとすれば、このベンチマークは雑な測定よりも ADC に優しいくらいです。点数が低いのは、ファイルがずれていたからではありません。先にちゃんとそろえたうえで、それでも ADC が大差で負けているのです。

「ソロ開発者だから」擁護

この段になると、よくある擁護 がほぼ自動的に出てきます。

As a final note, consider this: ADC is developed by a single individual without an audio engineering team, corporate funding, or the decades of research backing MPEG codecs. That it can even be compared to xHE-AAC [...] on any metric is remarkable.

もちろんです。音声コーデックをひとりで書くのは大変です。非可逆ならなおさらです。企業の研究所も、正式なリスニング評価基盤も、何年分もの実装知見もなしにやるなら、さらに大変です。AAC や Opus や、下手をすると MP3 にすら届かない実験的コーデックを作ったとしても、別に恥ずかしいことではありません。たいていの実験はそうなります。

でも、だからこそマーケティングが問題になるのです。もし ADC が、個人実験、学習用プロジェクト、あるいは少し変わった試作として提示されていたなら、「ひとりで作った」は完全に妥当な文脈でした。その枠組みなら、エンコーダとデコーダが動いているだけでも十分に面白い話です。

問題は、ADC がそういう見せ方をされていなかったことです。実際には、次のようなものとして提示されていました。

  • 音声符号化の大きな飛躍
  • 変換コーデックへの挑戦
  • 既存の業界標準と「競争力がある」もの
  • 非可逆音声圧縮が何をすべきかを見直すもの

ここまで言ってしまうと、基準は変わります。もう「趣味プロジェクトとして見てください」とは言えません。実際の、真面目な業界標準コーデックとして評価してください、と自分で言っているのです。そしてその基準で見たとき、ベンチマーク結果はやはりベンチマーク結果のままです。

ひとりで書かれたことは、tracker 系素材で ODG -3.227 を出した事実をましにはしません。チャネル入れ替えを許容可能にもしてくれません。ADC が 23 回最下位を取ったことも正当化しません。「大半の場面で LAME より悪い」を、「AAC と競争力がある」に変えてくれるわけでもありません。そんなものは何の説明にもなっていません。

なので、ソロ開発として見れば ADC は野心的です。ものすごく野心的です。でも、コーデック性能についての主張が成り立たないという事実は、それでも変わりません。

予告されている v0.85 はどうなのか

さて、ここで当然出てくる次の問いがあります。開発者がすでに 予告し始めている、未公開の v0.85 はどうなのか、という話です。

説明文によれば、より洗練された「dual-predictor architecture」、より鋭いトランジェント応答、130 から 134 kbps で「excellent/transparent」品質、より低い CPU と RAM 使用量、0.18 ms のレイテンシ、120 分超でも安定したシーク、そして開発者が「mathematical transparency」と呼ぶものへのさらなる前進が約束されています。

公平に言えば、未公開版が改善していても何の不思議もありません。というか、改善しているべきです。もし v0.85 が v0.84 rev.0 で見えた問題のいくつかを本当に直しているなら、それは良いことです。実験的コーデックとしては、むしろ健全で普通の振る舞いです。ただ、この連載全体の文脈で見るなら、正直に言っておきましょう。この予告文は、証拠というより、同じパターンが続いているようにしか見えません。

まず、語り口が相変わらずまったく同じ種類の混乱を引きずっています。"treating audio as a continuous wave rather than a set of frequency bins" とか(あれ、ADC は純粋な時間領域処理じゃなかったんでしたっけ。うーん……)、"without the pre-echo smear typical of MDCT-based codecs" とか。これらは中立的な技術説明ではありません。過去の記事で見てきた ADC お得意のレトリックを、そのまま繰り返しているだけです。つまり、変換コーデックは本質的に欠陥があるものとして定義し、その欠陥を避ける ADC を思想的に純粋なものとして持ち上げる、あのいつものやり方です。でも、これまでの記事で確認したとおり、プリエコーを引き起こすのは MDCT そのものではありませんし、「continuous wave」みたいな言い方をしたところで、符号化効率が優れている証明にはなりません。要するに ADC は、「欠陥がある」ことにした MDCT を捨てて、その代わりに別の欠陥持ちの手法を使っているだけです。

次に、音質に関する主張があまりにも大きい。だいたい同じビットレート帯で、v0.84 rev.0 は「少し足りない」程度では済みませんでした。私のベンチマークでは、24 トラック中 23 トラックで最下位、平均 ODG は -1.576 です。なので、v0.85 が今や 130 から 134 kbps で「excellent」どころか「transparent」に届くとまで言われるなら、それは小さな改良ではなく、とんでもない跳躍です。並外れた改善が起きること自体は、まあ、なくはありません。でも、並外れた主張には並外れた証拠が要ります。新しいベンチマーク、リスニングテスト、サンプルファイル、再現可能な手法、そして現行エンコーダとの比較です。予告文の中の形容詞ではなく。

三つ目に、ほかのいくつかの主張は、ブレークスルーというより「以前にもう解決したと言っていた問題を、今になって解き終えようとしている」ように聞こえます。"Ultra-stable search" も、あらためて持ち出される低レイテンシ話も、実現するなら歓迎です。でもそれらは同時に、過去の ADC リリースが大げさな約束をしておきながら、実際に見てみるとそうではなかった領域そのものでもあります。言葉より実行ファイル、というやつです。たぶん。

そして最後に、"mathematical transparency" という言葉は、やはり非可逆コーデックに対しては妙です。非可逆コーデックが目指せるのは 知覚的 透明性です。アーティファクト制御の改善や、効率の向上を目指すこともできます。でも、一度量子化して情報を捨てた時点で、「digital integrity」だの「mathematical transparency」だのは、もはや文字どおりの性質ではなく、またマーケティング文句に戻っています。

なので、v0.85 に対する私の立場は単純です。良くなっているかもしれません。本当にそうであってほしいとは思っています。でも、公開ビルドが出てきて、実際にテストできて、比較できて、聴けて、調べられるようになるまでは、v0.85 もまた、同じ種類の主張の追加分にすぎません。

ロードマップ

この記事は、ADC とその主張を検証していく連載の第4回です。