藤本健のDigital Audio Laboratory

第774回

BluetoothのaptX音質を再び検証。SBCとの違いを波形で比べた

 以前行なったBluetoothの音質の検証で、AACについては概ね納得のいく結果を得られたが、aptXについてはやや不可解な結果となってしまった。というのもaptXで接続できているのか、SBCで接続しているのかの確信ができなかったからだ。今回はリベンジのため、aptXおよびSBCでの音質検証を改めて少し別の方法で行なってみた。

以前のBluetooth音質テストで不明だった点を改めて検証

 第763回の記事「BluetoothのaptX音質をテストしたら、謎の結果が出てしまった」で実験を行なったとき、トラブルの連続でなかなかうまく実験を進めることができなかった。最大の問題は、各機器がaptXで接続しているのかSBCで接続しているのかを表示してくれない点。接続時にお互いが一番いい音質のコーデックで接続するという取り決めるになっているので、それを信じればいいだけなのかもしれないが、明示してくれないために、不可解なことが起こってしまった。

 特に、話を難しくさせたのはaptXというロゴを表示して接続する2つのケースにおいて、ともに実験がうまくいかなかったこと。

 具体的にいうと、Astell & KernのAK380を使った場合と、Windows 8にサンワサプライのMM-BTUD44を組み合わせた場合の2つのケースは、しっかりとaptXでの接続を明示してくれた。しかし、レシーバとして用いたエレコムのLBT-AVWAR700という機材のヘッドフォン端子からは音を出せたのだが、この機材が持つ光デジタル出力(S/PDIF)から信号がでなかった。

 その実験ではBluetoothで送信されるオーディオ信号を正確にキャッチして、その音質を分析しようというものだったのに、そのデジタル信号が取り出せないのでは、うまく実験を進めることができなかった。そのとき仮定したのは「aptXはSCMS-T(デジタルコピー防止のためのシステム)に対応している」、「よって、うまく接続できるのはaptXではなく、SBCで接続されているのではないか?」ということだった。その結果、「SBCはAACよりも音質がよさそうだ」という結論になってしまったのだ。

 それに対し、読者の方々や、知人からも、いろいろなご指摘、アドバイスをいただいた。その中でも重要な情報だったのは「BluetoothのUSBドングルが、どんなタイプであっても、Windows 10の最新バージョンであればaptXに対応している」という点だった。前回の記事では、エレコムおよびサンワサプライのBluetoothのUSBドングルを使い分けながら、メーカーがaptX対応を謳っているかどうかで判断をしていたが、Windows 10の現行バージョンなら、そうした表記に関係なくaptXで接続できているという。となると、前回の結果はやはりSBCではなくaptXであったということになる。

 でもaptX接続した際に、SCMS-Tで引っかかってしまったのは、どうしてなのか? そこはどうも判然としなかったが、その後エレコムの製品担当者と話をしたところ、「製品の不良があった可能性がゼロではない」ということで、レシーバであるLBT-AVWAR700の代替品をお借りしたが、結果は変わらず。そうした中、AV Watch編集部から「ウォークマンであれば、接続するコーデックを指定してBluetooth接続することができる」ということで、ちょっと前の機種ではあるがNW-A16('14年発売)を使って、改めて実験してみた。

ウォークマンのNW-A16からBluetoothで伝送してテスト

 使ってみるとこのウォークマンではBluetooth設定の中に「ワイヤレス再生品質」という項目があり、ここで「マニュアル選択」を選ぶことで、接続したいコーデックを選べるようになっている。具体的には「LDAC(音質優先)」、「LDAC(標準)」、「LDAC(接続優先)」、「aptX」、「SBC(音質優先)」、「SBC(接続優先)」の計6つの選択肢がある。

NW-A16のBluetooth音質(コーデック)選択画面

 LDACもぜひテストしてみたいところだが、残念ながらデジタルを取り出す機材であるエレコムのLBT-AVWAR700はLDACに対応してないので、ここではaptX、SBC(音質優先)、SBC(接続優先)のそれぞれで接続してテストしてみた。

 接続すると、aptXで接続したこと、SBCで接続したことをしっかりと表示してくれるので間違いはなさそうだ。実際に音を出してみてすぐに分かったことは、ウォークマンのaptXで接続しても、しっかりデジタル出力されたということ。別の言い方をすると、前回の「aptXはSCMS-T対応であり、接続先の機器からデジタルオーディオ信号を出せない」という判断は間違いであること。このとき使ったのがLBT-AVWAR700の代替機だったので、もしかして以前うまくいかなかったAK380でもうまく行くかと思ったのが、これはやはりNG。つまり一部の機器がSCMS-T対応になっている、と考えるのがよさそうだ。

どのコーデックで接続したが明示される

再びテスト。SBCとaptXの違い

 題材として利用したのは、以前と同様で1kHzのサイン波、20Hz~22.05kHzのスウィープ信号、そしてデモ用に作成した30秒の曲のそれぞれ。これらを3つのコーデックで作成するとともに、デジタルで取り込んでみた。ただ、試してみてどうにも不可解な点があった。それはもともと、サイン波もスウィープ信号も-6dBの音量だったのに、6dB小さい(つまり半分の音量の)-12dBちょうどとなっていた。

サイン波もスウィープ信号も、半分の音量の-12dBとなっていた

 この現象は、ウォークマンとLBT-AVWAR700を接続した場合は音量調整が効かなかったので、いかんともしがたい。ほかに設定があるのかと思って、いろいろと試してみたが特に方法はないようだった。ウォークマン関係に詳しい方から「ウォークマンはLDAC以外のコーデックでは、楽曲のサンプリングレートに関わらず送出時にすべて44.1kHzに固定されます」という情報をいただいたが、それが正しければ、そのことと関係があるのかもしれない。試しに、aptX接続およびSBC(音質優先)のコーデックで接続した上で、48kHz/24bitのデータを再生してみたところ、この指摘のとおり、44.1kHzにサンプリングレートコンバートが掛けられていた。

 話を戻そう。とにかくaptX、SBC(音質優先)、SBC(接続優先)のそれぞれでの結果をWAVファイルとしてキャプチャすることができたので、これらの信号を解析するとともに、オリジナルとの差分を見てみることにしよう。まずサイン波を解析したものが下の結果だ。

【サイン波】

aptX
SBC(音質優先)
SBC(接続優先)

 これを見てみると、aptXよりもSBCのほうがSNがいいことが分かる。特にSBCは音質優先でも、接続優先でも低域のノイズがまったく出てないのに対し、aptXのほうがまんべんなく出ているのが見て取れる。一方で、このノイズの出方は前回のWindows 10などで行なった結果とソックリ。ということは、やはり前回の結果はSBCではなくaptXであったと見るのが正しそうだ。なおオリジナル波形との差分もとってみた。前述の通り-6dBとなっていたので、あえてSoundForge上で+6dBした上で差分をとったものが下の結果だ。結果的にはどれでも-54dB程度とごく小さなノイズであることがわかった。+6dBでピッタリとうまくいったことを考えると、ウォークマンでのBluetooth接続では15bitの解像度であったというのと同義ということになりそうだ。

【サイン波のオリジナルとaptX/SBCの差分】

aptX
SBC(音質優先)
SBC(接続優先)

【サンプル音声/Bluetooth伝送後にキャプチャしたもの】
aptX
dif_sine_aptx.wav(1.77MB)
SBC(音質優先)
dif_sine_sbc_h.wav(1.82MB)
SBC(接続優先)
dif_sine_sbc_l.wav(1.81MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

 つづいてスウィープ信号についても見てみよう。これについては周波数解析の横軸をLogではなくリニアにした上で行なった結果が下の通りだ。いずれも(以前のテストの際の)AACのように16kHz以上などの高域が切れることなく、22.05kHzまでほぼ完全に出ている。ただしSBCと比較するとaptXのは17kHzあたりからやや濁っているようにも見える。

【スウィープ信号】

aptX
SBC(音質優先)
SBC(接続優先)

 これについて確認するため、やはり+6dB処理した上で差分を比較してみたのが下の結果だ。見てみると、aptXは特に高域においてかなり大きな差分があるのに対し、SBCは音質優先でも接続優先でも、差分はほぼゼロ。ここまでの状況だけをみれば、aptXよりSBCのほうが断然いい、という結果になってしまう。

【スウィープ信号のオリジナルとaptX/SBCの差分】

aptX
SBC(音質優先)
SBC(接続優先)

【サンプル音声/Bluetooth伝送後にキャプチャしたもの】
aptX
dif_sweep_aptx.wav(3.74MB)
SBC(音質優先)
dif_sweep_sbc_h.wav(3.83MB)
SBC(接続優先)
dif_sweep_sbc_l.wav(3.72MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

 とはいえ、いままでテストしたサイン波もスウィープ信号も、瞬間を捉えれば、非常に単純なサイン波であり、それに最適化した結果だったかもしれない。肝心なのは普通の音楽を再生した場合、どう違うのか、という点だろう。同じように、3つを周波数解析した結果は下の通り。

【自作サンプル楽曲の周波数解析結果】

aptX
SBC(音質優先)
SBC(接続優先)

【サンプル音声/Bluetooth伝送後にキャプチャしたもの】
aptX
demo_aptx.wav(5.50MB)
SBC(音質優先)
demo_sbc_h.wav(5.51MB)
SBC(接続優先)
demo_sbc_l.wav(5.49MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

 いずれも高域まで出ているようにも見えるが、よく見ると、aptXに対してSBCの音質優先は20kHz以上は瞬間的に発生したノイズであって、音楽信号としては出ていない。一方、接続優先になると17kHz以上が出ていないのだ。一方の差分のほうは下記の通り。SBCの接続優先の差分が一番大きかったことは確かだが、それにしても見た目でハッキリ違うほどではなかった。

【自作サンプル楽曲のオリジナルとaptX/SBCの差分】

aptX
SBC(音質優先)
SBC(接続優先)

【サンプル音声/Bluetooth伝送後にキャプチャしたもの】
aptX
dif_demo_aptx.wav(5.51MB)
SBC(音質優先)
dif_demo_sbc_h.wav(5.51MB)
SBC(接続優先)
dif_demo_sbc_l.wav(5.49MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

SBCも決して音が悪いコーデックではない?

 今回の結果から分かるのは、前回のaptXかSBCかハッキリわからなかった結果を今回と照らし合わせれば、明らかにaptXであることがハッキリした。前回、SBCである可能性を強く指摘していたことは誤りであったので、ここでお詫び申し上げたい。

 一方で、SBCは決して悪いコーデックではないこともハッキリと見えた。以前のテストを踏まえると、高域の特性だけで比較すればAACの結果よりもSBCの音質優先のほうがいい結果だった。もちろん、高域特性だけで音質のすべてを図ることはできないが、今回使ったウォークマンNW-A16でデモ楽曲を実験した結果に関して言えば、SBCに比べてaptXの成績が良かったことも分かった。

 Bluetoothでのオーディオコーデックには、先ほども取り上げたソニーのLDACのほか、aptX HDなどもあるので、できればこうしたコーデックもチェックしてみたい。ただ、現時点でこれらをデジタルキャプチャできるツールが存在していないので、すぐに実験することはできない。先日エレコムの担当者と会った際、要望をしたところ、「検討したい」という前向きのお返事はいただけたので、今後に期待したい。

藤本健

 リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。  著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto