aptXは本当に高音質で低遅延なのか
WH-1000XM4が発売されたが、aptXが排除されたことで、ネットの一部では騒ぎになっている。これを機にこの記事ではBluetoothコーデックについて分析していきたい。
Bluetoothのオーディオ(A2DP)には圧縮方式がいくつかあり、SBC、AAC、aptX(HD)、LDACなどがあり、一部の人は「aptXは他よりも音質が良く遅延も少ない」と吹聴している。本当だろうか？
長い記事になったので、結論を先に書く。詳しく知りたい方は、下にスクロールして詳細を読んでほしい。
- SBC、AptXで音質に違いを見出すことは難しい
(※aptX HD はまた別の話です) - PC(macOS)上ではSBCとの間で32ミリ秒の差があり、
再生遅延はaptXで180ms程度、SBCで210ms前後であると考えられる - Android上ではどのコーデックでも遅延は大して変わらず、最低でも200ms、平均して300msを超える
むしろコーデックの違いより機種の違いの方が大きい
Android上ではAACは避けた方が良い - AACは電波強度に左右されにくく接続品質が高い
iPhoneではAACを使おう
上の記事でRMAAを用いたテストも行なったので合わせて見てほしい。
音質: SBCとaptXの音質の差は区別できない
私によるテスト
以前の記事で、私はSBCの328kbpsで原音と区別することはできないと結論した。つまり、SBCの328kbpsではオリジナル音声と区別することができないので、「高音質」であるとした。また、aptXとオリジナル間でも音声を聞き分けられたことはないので、オリジナル、aptX、SBC (328kbps)間の音質差はないというのが私の結論だ。
SoundExpertによるテスト
私を信頼できない？であれば、プロによるテストを紹介しよう。
SoundExpert.orgがリスニングテストと客観的な手法(df-metric)とでテストを行った結果、次のような結論を出している：
BTアプリケーションで使用されているaptXコーデックはSBC@328よりも優れていません。aptXのアルゴリズム遅延が若干低いにもかかわらず、実際のBTアプリケーションではSBCもaptXも同じ100–150msの遅延を提供しています。あなたがいくつかのBT製品でSBCとaptXの違いを感じた場合は、2つのことが考えられます — 1,プラシーボ効果。2,低品質モードでSBCを使用している。このように、CSR（現在Qualcomm）のマーケティング戦略の重要な要素としてaptXが必要であったことは、今となってはかなり明らかです。AptXはただの銅なしの高額オーディオケーブルです。
読み解くと、私が前の記事で結論したように、aptXはSBCより優れているとは言えないということであり、違いを感じた場合はプラセボ効果か、bitpool=32 (192kbps)などの低ビットレートで接続されているからとしている。また遅延についても言及されており、「実際」にはSBCでもaptXも同じ程度の遅延が生じているとしている。
レイテンシ: ほんの少しだけaptXが短い
私によるMac上での計測 — 思ったほど大きな差はない
音質に大した違いがないとわかったところで、次に気になるのは遅延(レイテンシ)だろう。接続コーデックの分かるAvantree Oasisをレシーバーとして用いて、macOSから音を発し、遅延を計測してみた。macOS側でBluetoothコーデックを指定し、Audacityで再生しながら録音（オーバーダブ）することで、遅延を計測できる。
なお遅延にはコーデック遅延だけでなく、オーディオインターフェイスによる遅延やOSによる遅延が含まれることに注意が必要だが、条件を変えていないため比較としては問題はない。
このスクリーンショットは、録音したファイルをAudacityで開いたものである。上のトラックから順に、オリジナル、SBC、aptXとなっている。音声はAudacityで生成したDTMFで、波形が潰れているように見えるが気にしないでほしい。
差の部分をAudacityのカーソルで選択して計測した結果、SBCとaptXの遅延の差は32ms程度であった。オリジナルの音が発せられてから録音されるまで、360ms以上あったものの、これはオーディオインターフェイスを再生と録音の2度通過しているためだ。再生だけであれば、その半分の180ms程度となるだろう。後述するように、この遅延はITUの基準の範囲内であり、確かに、それほどリップシンク（口パクのズレ）の違和感や遅延にイラつくこともなかった。
重要なのはSBCとaptXの違いが32msであることで、差は14%程度となっていることだ。
Windows上ではSBCとaptXを切り替える方法が不明なため、今回は実験していない。
専門家によるAndroidでのテスト — Androidの遅延は絶望的
専門家の文献を調査したところ、音響工学の理学士 Robert Triggs氏による「AndroidのBluetoothのレイテンシーは深刻なオーバーホールが必要です」と題された記事が見つかった。
これによると、Androidのオーディオに問題があり、Googleは過去に修正を施してきたものの、Bluetoothにおける問題はそれほど解決されておらず、バッテリー寿命を考慮してCPUのスロットリングとオーディオのバッファを設定しているため、遅延が大きくなっているメーカーもあるということだ。
これはSBCやaptXといった圧縮が行われる“以前”の問題であり、問題はBluetoothコーデックよりも、AndroidのOS自体が抱える問題といえる。
この図から分かるように、機種により差があるものの、aptXとSBCはそれほど変わらず、むしろaptXの方が遅延しているようなGoogle Pixel 3の例もある。またOnePlus 6TではLDACとaptXでも大して変わらず、むしろLDACの方がaptX HDより低遅延である。
aptXが低遅延！SBCが高遅延！と叫び、コーデックの設定を変更する以前に、Pixel 3などの比較的低遅延な機種を選んだ方が効果が大きいのだ。
グラフを見ればわかるように、AACやLDAC990は明らかに遅延しているが、LDAC 660kbpsとaptX、SBCは横並びで大して違いがない。
Robert氏はどのコーデックにしても遅延がひどく、Androidにおいて低遅延でBluetoothオーディオを使う方法は現状存在しないとしている。
ただ私の所有するPixel 3aとHuawei Nova lite 2においてWH-1000XM3でLDAC、MDR-EX-31BNでaptXとSBCにおいてYouTubeでリップシンク（口パクのズレ）の度合いを見てみたが、それほど違いが分からなかったことも記しておく。（ただし、YouTubeのアプリが映像を遅らせて遅延を気付きにくくしている可能性は否定できない）
少なくとも、OSとヘッドフォンやイヤホンの設計が問題ない場合、コーデックによる遅延の差はそれほど大きくはない。
論文による検証
ネット上には不確かな情報が溢れていて、SBCとaptXの遅延の比較もその一つだ。
SBCはaptXに比べて遅延すると言われているが、実際のところ、論文によるとSBCのエンコーダ自体のアルゴリズム遅延(algorithmic delay)は5msで、aptXは1.9msである。SBCとaptXのアルゴリズム遅延はたったの数msしか違わないのである。
おそらくネット上の誤情報はOSのエンコーダやイヤホン、ヘッドフォンのデコーダの実装上の違いによって、SBCとaptXで異なる遅延が発生していて、それをアルゴリズムによる遅延と勘違いした可能性はある。また、aptX LLとaptXを混同して、「aptXの方が遅延が少ない」とした可能性もある（厳密には間違ってはいないが、上記のようにSBCとaptX自体の遅延は大きくは変わらない）。
遅延はどこまで許されるのか？
テレビ会議教科書によると、ITU-R BT.1359の規定によれば、音声が遅れる場合は185msまで許容されるという。ただし厳しいEBUの放送の基準としては60msとされている。
いずれの基準を採用しても、良くて200ms、平均で300msを上回るAndroidの場合は全くもって論外だろう。
Macの場合は再生・録音の往復で360msであったから、再生だけなら180ms程度であろう。ギリギリセーフといったところである。
AACは違った面で優秀
Robert氏の記事では、AndroidにおいてAACは使うべきでないとしていたが、AACにも利点はある。
接続品質が良い
AACは圧縮効率が高いため、低ビットレートでも音質を保てる。そのためBluetooth A2DPコーデックの中で最もビットレートが低く(macOSとの接続では平均240kbpsとなる)、そのおかげで接続が切れにくい。それを示しているのが上のグラフである。
これによるとLDACは最も電波強度(RSSI)に影響され-60dBmで音声がドロップし始め、aptX HDが-70dBmでそれに続いている。aptXは中間程度だ。SBCとAACはかなり良く、僅差でAACが勝っており、-80dBmまで耐えていることがわかる。
可変ビットレート
aptX Adaptiveが出る以前から、AACは可変ビットレートであり、接続品質によってビットレートを変動させることも可能だ。
例えば曲や動画の静かな部分や、ASMRなど、ビットレートを必要としない場面は多い。そこでビットレートを節約し、消費電力を減らすことが可能だ。
固定ビットレートでは例え無音に近い音でも、その固定分を使い切るために無駄な転送となってしまう。
なお、可変ビットレートは同様のデータサイズで比較した場合、固定ビットレートよりも音質が高くなる。
AAC-ELDという低遅延バリアントもある
FaceTimeでも使用されているような、AAC-ELDという低遅延リアルタイムコミュニケーション向けのコーデックも存在する。一説によるとAirPods Proにも採用されるという。
BluetoothのAACのビットレートが240kbpsだって？SBCの328kbpsよりも小さいじゃないか！と思われる方もいるかもしれないが、AAC 256kbpsで10回重ねて圧縮したとしても、実際のところオリジナルと区別することはできないほどの音質を誇っている。以下の記事を参照してほしい。
AndroidはAACを使う際にはエンコーダに注意
AACは世界標準の規格であり、フォーマットは決まっているものの、エンコードの実装によって音質が変わるというのはよく知られている。例えば最高音質のAACエンコーダはApple製のエンコーダであることが知られている。
Appleは古くから自社AACエンコーダを作っており、iTunesの登場からAACを採用し、iTunes PlusやApple Digital Mastersと言ったAACの音質向上に力を注いできた。
そのAACであるが、Bluetoothオーディオで利用する場合、機種によって異なる特性が観察されたという。
下のグラフは周波数応答（スイープ）を示しており、これによるとiPhone 7が最もフラットな形を示している。ついでSamsung Note 8, LG V30, Huawei P20 Proの順に上限の周波数が減少している。
ただし、周波数だけを見て音質を語ることはできない。このグラフからは音質の良し悪しではなく、「同じAndroidでも機種によって違うエンコード設定のAACとなる」ことを読み解くべきである。
つまり、AndroidのAACは、機種によって品質が異なることがわかる。加えて、AndroidのAACの実装はFDKである。FDKはApple製のエンコーダよりも音質が若干劣ると考えられている。(目立って悪いわけではないが)
このことから、スマートフォンの中ではiPhoneのAACエンコーダの音質が最も優秀で、次点でAndroidのAACとなるだろう。
機種によって音質にばらつきがある可能性があることに注意した上で、AndroidでAACを使うのも良い。以下は、Androidで使われているFDK AACとSBC, aptXの音質比較であるが、AACがもっとも優秀であることがわかっている。iPhoneより音質が劣る可能性はあるものの、他の2つのコーデックより低ビットレートの音質も良いことから、FDK AACが搭載されているAndroidはAACを利用する価値がある。ただし、FDK AACが搭載され実際に利用されているか不明であるし、ビットレートなどのパラメータも差異があるため、確実性という意味ではAACではなく、LDACやaptXを使うのもいいだろう。
一方で、Apple製品においては接続が安定することと、AppleのAACエンコーダの品質の高さの2つの理由でAACを使うべきだろう。
結論
以上のことから、PC上ではaptXはSBCと比較して14%程度、低遅延というメリットを見出すことができたものの、AndroidにおいてはaptX、SBC、LDACにかかわらず、そもそもOSの問題で遅延が大きいということがわかった。ただし、私個人の感想としては、どのコーデックにおいても違和感を感じるほどの遅延を感じなかったし、差も感じられなかった。
（※aptX HDはこの記事では取り上げていない。「aptX (HD)の高域に量子化雑音が入るわけ」を参照のこと）
コーデックの選び方
音質はどれも大差がないため、bitpool=53が使えるデバイスであればSBCで問題はない(参考: Bluetooth SBCコーデックは本当に音質が悪いのか)し、aptXでもよい。遅延を非常に気にする場合、aptXにしたとしても14%しか改善しないため、根本的に解決するならこちらでは触れていないがaptX LLなどが選択肢に上がる。iPhoneなどApple製品で使うなら、AACを使えるデバイスを選べば、混雑した場所でも途切れにくい恩恵を受けられるだろう。
ただSBCに関しては計測上は IMD (相互変調歪)が大きいという問題を「BluetoothはAACが最強だった… aptX(HD) vs AAC vs SBC 最終決戦」に示したので、SBCとaptXを選ぶときの参考にしていただきたい。
WH-1000XM4のはなし
WH-1000XM4にaptXが搭載されなかったのは、音楽や動画などをターゲットにしており、ゲームはターゲットにしていないからかもしれない。（Qualcommにライセンス料を払いたくないだけかもしれない）
Androidには既にLDACのエンコーダが搭載されており、ソニーとしてはAndroidであればLDAC、Apple製品(macOS, iOS)であればAACを使うことを想定しているのだろう。唯一WindowsにおいてはSBCで繋がることになる。
正しく“ごまかせば”、遅延は問題にはならない
音楽であれば遅延は全く問題にならないし、動画であればソフトウェア側で映像を遅らせ、音声を同期する処理（リップシンク）をすれば良いだけである。実際のところ、AndroidのYouTubeを試聴した際に全くズレを感じなかったのは、そういった処理が入っているからなのかもしれない。
例えばAppleTVでは、オーディオシステムを介した音声のリップシンクを行うソフトウェアが搭載されている。
遅延の酷いOSの設計のままワイヤレスを推し進めるならば、最低限このような仕組みをOSで提供すべきだと思う。
ゲームにおいてはこのようなごまかし方は無理ではあるが。
関連記事の紹介です。相互変調歪みやダイナミックレンジ、クロストークなど数値に出る指標で音質比較を行なった記事です。
WAVとFLACで音質が違うという都市伝説を探り、科学的な反証を紹介しています。
以下は記事内で触れた「可変ビットレートがなぜ高音質なのか」を説明した記事です。
