藤本健のDigital Audio Laboratory

第763回

BluetoothのaptX音質をテストしたら、謎の結果が出てしまった

 前回の記事で、iPhoneからオーディオをBluetooth接続で送った場合、音質がどのように変化するかという実験を行なった。以前は多くのBluetoothイヤフォン/ヘッドフォンがSBCというコーデックのみだったが、高音質な製品としてAAC、aptXにも対応したものが増えている。そしてiOSの場合、aptXには非対応だが、AACのコーデックを内包しており、接続するデバイスがAACに対応していれば、自動的にAACで接続する形になっている。そこで、AACで伝送するオーディオの音質がどの程度のものなのか、波形や周波数分析で見てみた。

前回の実験ではAAC伝送時の音質をチェック

 ではaptXだとAACとどう違うのか、今回はそうした観点から実験を行なってみたのだが、想定外に実験が難航し、予想外の方向に、そしてややショッキングな話へと進展していった……。

aptX伝送時の音質を測定しようとしたが……

 AACそしてaptXで伝送した音を正確に捉えるためにS/PDIF出力を持つBluetoothレシーバーを探してみたところ、エレコムのBluetoothレシーバ「LBT-AVWAR700」が見つかり、これを購入して試してみた、というのが前回の話。その結果、高音質になったとはいえ、19kHz以上の音が出ていないことが判明し、かなりの音が抜け落ちていることもハッキリわかったのだ。

 でも、aptXならさらに高音質なのだろうという期待を元に今回の実験に取り掛かった。aptXはAndroidのスマホが対応しているということなので、これを使って、前回と同様の実験をすればいいだけだと高を括っていたら、そう甘くはなかった。最初に使おうと思ったのは、昨年購入したAndroidスマホのNexus 6P。OSをAndroid 8.1にアップデートして、いざ実験をはじめようとした際、念のためと思って調べてみると、Nexus 6PはaptX非対応だった。

Nexus 6Pを使おうと思ったが、aptX対応ではなかった

 それ以上新しいAndroidは手元にないし、どうしようかと考えていたところ、すごい機材が手元にあったのを思い出した。以前、DSDのレコーディングのテストを行なったAstell&KernのAK300だ。調べてみると、もちろんAK300はaptX対応。さっそく、これに実験素材であるWAVファイルを転送して、実験に取り掛かった。

Astell&KernのAK300

 まずBluetooth接続するとその瞬間AK300にはaptXのロゴが表示される。これで間違いなくaptXで接続したのだが、再生してみると、LBT-AVWAR700のヘッドフォン端子からは音がしっかりと出るが、S/PDIF接続したRolandのオーディオインターフェイスUA-101側が反応しないのだ。44.1kHzの信号が来ていれば、しっかりとロックがかかり同期した上で、音が出るはずなのに、ロックがかからずLEDが点滅しているまま。もしかして48kHzや96kHzなどにリサンプリングされているのかもと、各サンプリングレートに変更してもロックがかからない。これはどうしたことなのだろうか?

aptXで接続
音が出るはずなのに、UA-101ではロックがかからずLEDが点滅

 このまま諦めるわけにもいかないので、次の手を考えてみた。何もスマホに限らなくてもPCを使ってBluetooth接続すればいいではないか、と試してみることにしたのだ。実験に使っているデスクトップPCはBluetooth機能を内蔵していないため、こちらもエレコムのLBT-UAN05C2というUSB接続のアダプタを普段から用いているので、これを使ってみようと思った。ところが、念のため調べてみると、こちらもaptXに対応していないことが判明(CSRチップを使った現行モデルLBT-UAN05C2/NはaptXに対応している)。

エレコムのLBT-UAN05C2

 ただ、ネットで検索してみると、そもそもaptXに対応しているアダプタ自体が結構少ない。いくつかある中、aptX対応ということで見つけたのがサンワサプライのMM-BTUD44という製品。さっそく近所の大手量販店で買ってきた。

サンワサプライのMM-BTUD44

 パッケージを見ると、aptXのロゴも記載されていて、これなら安心。しかし、ここからもトラブルの連続となった。まず、これをWindows 10のマシンに接続すると自動的にドライバがインストールされ、LBT-AVWAR700と接続できた。

パッケージにaptXのロゴ
LBT-AVWAR700と接続

 しかし、画面上とくにaptXのロゴが表示されることもなく、本当にaptXで接続できているのかの確証が得られない。マニュアルを見ると、Windows 7およびWindows 8.x用にはBluetoothチップメーカーCSR社製のドライバが用意されているが、Windows 10はWindows 10標準のものを使うように、と記載されている。それが同じものならば、何ら問題ないのだが、動作状況を見ると明らかに異なる。CSR製のドライバを使っていると、aptX接続した際には、その旨の表示が出るようだが、Windows 10のものだと、何も出てこない。ならば、普段持ち歩いているWindows 7のノートPCで使ってみよう……とドライバのインストールまで行なったところで、問題があることに気づいた。MM-BTUD44のパッケージに赤字で大きく「Bluetooth機能を既に搭載しているパソコンには本製品を接続しないでください」と書かれている。

Bluetooth機能を既に搭載しているパソコンには接続しないようにという注意書き

 ほかにも何台かあるノートPCもすべてBluetooth機能を装備しているので、ダメ。だったら……と以前使っていたデスクトップPCを引っ張り出してみた。4年前に組み立てたCore i7 4770Kを搭載したマシンなのでスペック的には問題ない。すでにWindows 10をインストールしていたが、Windows 8.1をインストールし直して、ここにMM-BTUD44のドライバを入れてみた。

 とりあえず、これでBleutooth接続もできるようにはなったが、起動時にいろいろなエラーが発生して、やや動作が怪しい。そして何より問題は接続時にaptXの表示が現れないのだ。何時間か格闘してみたが、このままでは埒が明かない。そこでダメ元で試してみたのは、MM-BTUD44のWindows 8.1用のドライバをWindows 10にインストールしてみるという方法だ。

Bleutooth接続できたが、起動時にエラーが発生

 結果的にいうと、これでようやく明示的にaptX接続が実現できた。Bluetoothのネゴシエーションが完了したところで、右下に大きくaptXのロゴが表示されることでうまく接続できたことが確認できたのである。

aptXのロゴが表示された

 ようやく、これで準備ができたので、WAVファイルを再生し、UA-101のS/PDIFを使って取り込もうと思ったら、またロックがかからず、キャプチャすることができない。LBT-AVWAR700のヘッドフォン端子からは音が出ていることから考えて、思い当たるのはSCMS(シリアル・コピー・マネジメント・システム)だ。最近、あまり話題に上ることもなくなっていたが、昔、CDからDATへデジタルコピーしたものを、さらにDATなどへコピーしようとすると、SCMSのプロテクトが働き、2世代目以降へコピーできなくしていたが、それと同じ抑制がかかっている可能性がありそう。調べてみると、BluetoothではSCMS-Tという新世代のものがあるので、それが絡んでいる可能性がある。あくまでも可能性であって断言はできないが、とにかく使えないのでは仕方ない。

 そこでいったんPCをフォーマットし直し、Windows 10の初期状態に戻した上で、CSR製ドライバはインストールせずにWindows 10の標準ドライバで接続し、前回と同じ実験を行なってみた。特に画面上でのはどのコーデックが使われているのか表示はされていないが、UA-101のS/PDIF入力でロックがかかって、しっかりデジタルで取り込めることを考えるとSBCコーデックでの接続だと思う。もしかしたら、aptXのSCMSなしバージョンという可能性もゼロではないが、試しにBluetoothのアダプタを、サンワサプライのものからエレコムのアダプタ「LBT-UAN05C2」(aptX非対応)に交換しても、波形や周波数特性がほぼまったく同じであった。さらにタブレットのNexus 10(2013年発売)でも試したところ、Windowsの場合とは少し異なったが傾向としては同様だった。やはりSBC接続であると考えるのが正しそうだ。

 なぜここまで執拗なまでに確認をしているのかというと、そこには大きな理由がある。最初にサンワサプライのアダプタを接続し、Windows 10の標準ドライバで試した時点で、すでにキッチリと実験は完了していたが、ここでの結果が想定していたものがだいぶ違ったからだ。動作状況から考えてSBCだろうと思ってはいたのだが、波形から見る音質がどう見てもAACより、ずっとよかった。実際にどういう結果なのかをお見せしていこう。

伝送時の音声を元のWAVと比較

 SBCと思われる音声を、元のWAVと比較してみた。まず1kHzのサイン波は、若干のノイズはあるものの、AACと異なり、歪みのない非常にキレイなもので、生成したオリジナルのサイン波の分析結果に非常に近い。では、20Hz~22.05kHzのスイープ信号はというと、AACでは19kHz以上が完全にカットされていたのに対し、こちらは22.05kHzまでフラットに出ている。

サイン波(SBC)
サイン波(AAC)
サイン波(オリジナルのWAV)

【サンプル音声/Bluetooth伝送後にキャプチャしたもの】
サイン波
sine_sbc.wav(1.71MB)
スイープ信号
sweep_sbc.wav(3.40MB)
自作した楽曲
demo_sbc.wav(5.41MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

スイープ信号(SBC)
スイープ信号(AAC)

 もしかしたらSBCというコーデックでは、サイン波に非常に強い特性を持っているもので、AACやMP3などの圧縮コーデックとはかなり異なるアルゴリズムのものなのでは、なんて風にも想像できる。そこで自作した音楽ファイルにつても分析してみた結果、こちらでも明らかにAACよりいい結果が出てきた。これはどういうことなのだろうか?

SBC
AAC

 前回AACで行なった実験では、単に結果の周波数分析を行なうだけでなく、波形を表示して確認してみたり、オリジナル波形との差分を取り、どのくらいの信号が失われたのかを確認した。もしかしたら、周波数分析上はよさそうな結果に見えても、実はいろいろな信号が失われている可能性もある。

 まず頭に入れておいた-6dBのインパルス信号がどうなっているかを見てみよう。これはAACのときとも異なった波形になっているし、そもそも信号レベルが-12dB程度と小さくなっている。一方、低い音から高い音まで変化していくスイープ信号を見てみると、AACでは17秒あたりから消えていたものが、今回のものでは最後までしっかりある。やや波形が乱れた状況にあるのも確認できる。

信号レベルが-12dB程度と小さい
スイープ信号

 ここで、まずサイン波の差分を見てみると、AACではかなりノイズが残っていたものが、SBCと思われるファイルでは見かけ上完全に消えた。もっとも、先ほどの周波数分析結果から見ても完全に同じであるはずがないので、拡大していくと-54dB程度でのごくわずかなノイズが残っていることは確認できた。これならAACと比較すれば、ほぼ無視できるレベルといってもいいだろう。

サイン波の差分では、ノイズが残っていないように見える
-54dB程度では、ごくわずかなノイズが残っていた

【サンプル音声/オリジナルとBluetooth伝送の差分】
サイン波
difference_sine_sbc.wav(1.78MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

 同様にスイープ信号でも差分を見てみると、こちらは高域になると、少し差分が出てくるのが見える。ただ、AACのときのように19kHz以上が完全に失われているというようなものではない。

スイープ信号は、高域になると少し差分が出てくる

【サンプル音声/オリジナルとBluetoothの差分】
スイープ信号
difference_sweep_sbc.wav(3.57MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

 そして音楽はというと、こちらはわずかなレベルで差分があるが、AACの場合と比較するとかなり少ない。実際音を聴くと、SBCにすることで失われた成分を認識することができるが、やはりAACと比較して小さい音だし、高域だけが消えたのと異なり、低音も含めて小さく消えているので、音質的な影響は少なそうだ。

自作した曲では、わずかなレベルで差分があった

【サンプル音声/オリジナルとBluetoothの差分】
自作した楽曲
difference_demo_sbv.wav(5.45MB)
※編集部注:編集部ではファイル再生の保証はいたしかねますのでご了承下さい

SBCでも高いビットレートは伝送できる?

 今回試したものがaptXでなくSBCであるという確証はまだとれていないが、実験結果から分かるのは、実際に伝送されたデータがAACよりも音質が良いということ。従来「SBCは通話レベルの音質、AACとaptXは高品位な音楽用」なんて言われ方をすることもあったが(さすがに誰が聞いても通話レベルの音質ではないと思うけれど)、SBCは言われているよりずっと高音質であった、といえる可能性も出てきた。

 その後、SBCのコーデックの仕様を調べてみたところ、Bluetooth SIGでまとめられたAdvanced Audio Distribution Profile version 1.3(PDF)というドキュメントに行きついた。ここでSBCの転送レートを調べてみると、Middle QualityとHigh Qualityという2つのモードと44.1kHzと48kHzの2つのサンプリングレート、そしてモノラルおよびステレオがあるが、Middle Qualityでもステレオなら44.1kHzで229kbps、High Qualityなら328kbpsとなっている。

Bluetooth SIGのドキュメントの記載を抜粋

 前回のAACの状況から128~192kbpsの間くらいではという予想をしたが、それと比較しても高ビットレート。そう考えると、今回の実験結果でSBCがよかったというのも納得いく結論のように思える。

 SCMS-Tの件も含め、筆者の実験ではこの辺が限界。できるなら、どうしてこのような結果になったのかなど、メーカーへのインタビューをしてみたい。

藤本健

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