藤本健のDigital Audio Laboratory
第1029回
次世代Bluetooth「LE Audio」の音質ってどうなのよ。LC3を波形で比べた
2025年5月12日 08:00
少しずつではあるけれど、製品が出揃ってきたのが“LE Audio対応Bluetoothイヤフォン・ヘッドフォン”だ。
LE Audioでは、標準のコーデックとして「LC3」(Low Complexity Communications Codec)が使われており、低ビットレートでも「高音質」、そして「低遅延」をうたい文句にしている。現状においてiOSがLE Audioに対応していないので、スマホにおいてLE Audioが利用できるのはAndroidの一部の機種に限られるが、低遅延で高音質なら歓迎したいところだ。
とはいえ、どれほど高音質なのか？ そのクオリティが気になるところ。
探してみても、客観的な比較をした情報などがあまり見つからなかったので、テストしてみることにした。
LC3を検証する何かよい方法はないか？
Digital Audio Laboratoryでは、これまでMP3やAAC、Windows Media AudioやOgg Vorbis……と数多くの圧縮CODECの比較検証をしてきた。
また単に圧縮データファイルとして使われているコーデックだけでなく、SBCやaptXなど、Bluetoothオーディオで使われるコーデックや、OPUSなどストリーミングで使われるコーデックなども検証してきた。
そうした中で、まだ検証したことがなく、気になっていたのがLE AudioのコーデックであるLC3だ。
各種あるBluetoothオーディオのコーデックの中で、非常にレイテンシーを小さくできるのが特徴といわれているため、リスニング用途だけでなく、ゲーム用途やDTM用途などでも可能性が注目されている。
ただ、これを検証するためにはLC3にエンコードしたデータ、さらにはそれをデコードしてWAVに戻したデータが必要となる。
だいぶ以前に「BluetoothのaptX音質を再び検証。SBCとの違いを波形で比べた」という記事で検証した際には、SBCやaptXで飛ばしたBluetoothの信号をエレコムのレシーバーで受信。その後、それをS/PDIFで出力し、S/PDIF対応のオーディオインターフェイスでPCに取り込んでWAV化する、というかなり強引なワザで検証した。
しかし、そもそもLC3対応のイヤフォン・ヘッドフォンも少ないなか、そんなことができるハードウェアも存在しない。
なにかいい方法はないか？ と探していた中、見つけたのが「ffmpeg」を利用するという方法だ。
ご存じの方も多いと思うが、ffmpegは動画圧縮や展開を行なうことができるオープンソースのソフトウェア。オープンソースであるだけにWindowsやもちろん、Mac、Linuxなど、さまざまなプラットフォームーム上で使うことができるのも特徴だ。
そして、動画だけでなくオーディオも含め、数多くのコーデックをサポートする、まさに万能ソフトウェアとなっている。もしかして、と思って調べてみたところ、このffmpegを使うことでLC3へのエンコードやデコードが可能となっていたのだ。
もちろんスマホに搭載されるLC3エンコーダーやイヤフォン、ヘッドフォンに搭載されるデコーダーとは多少違いがあることは想定される。しかし、LC3がどんな音質のものなのかを調べるには十分使えそうだ。
またチェックしてみたところ、ffmpegを使えば、LC3に限らず、SBCやAAC、さらにはaptXやaptX HDでのエンコードやデコードも可能になっている。さすがに片っ端から全部を検証するのは大変そうなので、SBCの256kbpsとAACの256kbpsの2つを比較対象としながら、見ていくことにした。
LC3にエンコードする
まずは、今回のテーマであるLC3へのエンコード作業から行なってみた。
Windowsでこれを行なうにはコマンドラインで操作する必要がある。そこで「Power Shell」に以下のコマンドを実行し、LC3ファイルを生成してみた。
.ffmpeg -i sample.wav -c:a liblc3 -b:a 128k -frame_duration 10 LC3_128.lc3
慣れていないと、呪文のようではあるが、簡単に解説しておくと、オリジナルのWAVファイルであるsample.wavというファイルを入力し、これをLC3のコーデックでエンコードすることを指定したもの。その際のビットレートは128kbps、フレームバッファサイズは10msec、ファイル名としてはLC3_128.lc3とする、と記述しているのだ。
53秒のオーディオデータではあるが、実行するとほぼ一瞬で実行状況が表示されるとともに変換が完了する。同様に、192kbps、256kbpsでもエンコードを行なってみた。
LC3ファイルだけでは検証できないため、これをデコードしてWAVに戻す必要がある。これもffmpegを使うわけだが、このデコードのコマンドは以下のとおり。
.ffmpeg -f lc3 -i LC3_128.lc3 -ar 44100 -ac 2 LC3_128.wav
このコマンドは、LC3のファイルであるLC3_128.lc3を読み込み、サンプリングレート=44.1kHzでステレオのデコードを行ない、LC3_128.wavというファイルで保存する、という内容になっている。
こちらも128kbps、192kbps、256kbpsのそれぞれで実行した結果、3つのWAVファイルができあがった。
LC3とオリジナルを比較(1) 周波数分析
ここで音質検証に入るわけだが、この検証には以前からずっと使わせていただいているフリーウェアのアナライザで、いまは公開が停止されてしまったefu氏のWaveSpectraを用いて、周波数分析を行なう、というのが1つの方法。
さらに、以前のOPUSを検証した際に編み出した新たな検証法で、オリジナルと変換結果のそれぞれをスペクトログラムアナライザで分析するとともに、その2つの画像の差分を見出して、どのくらいの音の成分が抜け落ちたかを比較するという方法の2つだ。
後者において、スペクトログラムアナライザにはSteinbergのWaveLabを、そして2つの画像の差分をとるのにはオープンソースのフリーウェア、Diffimgを使うことにする。
まずはWaveSpectraを使った解析結果が以下の3つだ。
このグラフの見方だが、横軸が周波数で縦軸が音の強さを示している。そして53秒の曲ではあるが、その16秒のところでいったん止めて、その時点の瞬間値が黒、そこまでの最高レベルが赤、300サンプル分の平均値が青となっている。
このグラフを見た感じでは、各ビットレートでの差はあまりないようにも思える。一方で気になるのはいずれも20kHzでバッサリと切られていて、20から22.05kHzの成分が存在しないという点だ。
これはどう見てもローパスフィルターがかかっているようだが、どういうことなのか。
そこでネット検索して、ETSI(欧州電気通信標準化機構)の仕様書をチェックしてみたところ、どうやらLC3およびLC3plusでは0～20kHzをフル帯域として実装することが規格として義務付けられているようで、テスト項目として「Low-Pass Test」なるものまで設けられていた。
そしてそのテストでは、20kHzでのカットオフが正しく入っているかを厳しく審査するとのことだから、あえて20kHz以上が消されている、というわけだ。
オーディオファンからすれば、なぜそこを消すんだ、と憤りを感じてしまいそうだが、医学的見地からすれば20kHz以上なんて聴こえないからよし、とのことのようだ。
一方、今回は検証からは外すが、LC3の高音質規格であるLC3plus HRでは96kHz/32bitまで扱えるとのことで、20kHz以上も行けそうではある。この辺は機会があれば、改めて検証してみることにしよう。
LC3とオリジナルを比較(2) スペクトグラムで差分を比較
さて、続いては2つ目のスペクトログラムの差分のほうを見てみる。
例えば、オリジナルのWAVファイルをWaveLabのスペクトログラム表示で見ると、このようになっている。
一方、128kbpsをWaveLabで見るとこのようになっている。
これらを見ただけでは何が違うかわからないが、Diffimgで差分を見てみるとこのようになる。
これをみると、いろいろな成分が欠けているのが見て取れる。同様にして192kbps、そして256kbpsでの差分をとったのがこちらだ。
これを見ると、確かに128kbps、192kbps、256kbpsとビットレートを上げるごとに差分が小さくなっていくことが一目瞭然で分かる。そして256kbpsだとほぼ音質劣化がないことも見て取れる。
ちなみに、各ビットレートにおいて上下それぞれに紫色の線が引かれているが、これこそがまさに20kHz～22.05kHzの音の成分。ここだけはどのビットレートでも同じようにそぎ落とされているのが、こちらの検証結果からも見えてくる。
LC3の音質は？ SBCとAACもオリジナルと比較する
では、このLC3はほかのコーデックと比較してどうなのか？
これをSBCの256kbps、AACの256kbpsそれぞれで行なってみた。こちらも、前述のとおりffmpegを用いてエンコード、デコードしたわけだが、それぞれのコマンドラインでの指定は以下のとおり。
.ffmpeg -i sample.wav -c:a sbc -b:a 256k SBC_256.sbc
.ffmpeg -i SBC_256.sbc -ar 44100 -ac 2 SBC_256.wav
.ffmpeg -i sample.wav -c:a aac -b:a 256k AAC_256.m4a
.ffmpeg -i AAC_256.m4a -ar 44100 -ac 2 AAC_256.wav
こうしてできあがった、それぞれのWAVファイルをWaveSpectraで検証したのがこちら。
SBCのほうは明らかに劣化しているのがよくわかる。平均でも18kHz以上は出ていないし、リアルタイムを見ると実質的には17kHz以上が出ていない。「SBCって音質よくないよね」といわれるのが、なるほど、とわかる結果といえそう。
もっとも、SBCは最高で328kbpsのビットレートまで対応していて、これに近いビットレートで使われることが多いので、実用上はもう少しはいいのかもしれないが、256kbpsという値ではこのような結果だった。
一方のAACのほうは、以前にも検証しているけれど、かなりオリジナルに近い感じで、高域での劣化もほとんどない。音質的に優れているといわれる理由がここからも見えてくる。
ではDiffimgでの検証結果はどうだろうか？
SBC、AACのそれぞれがこちらだ。
SBCについては、WaveSpectraの結果からも予想できる内容であり、LC3の128kbpsよりも遥かに劣る結果となった。
一方のAACを見て、あれ？ となった。WaveSpectraから予想される結果とあまりにもギャップがある。そこで、WaveLabのデータを細かく見てみると、おかしいことに気づいた。
実は、AACへのエンコード、デコードを行なった際、最後に256サンプル分の空白が追加されていたのだ。その結果、表示される縮尺が変わってしまい、問題が起きていたのだ。
そこでSound Forgeを用いて(本来はWaveLabで操作すべきだが、サンプル操作はSound Forgeに慣れているので、こちらを用いた)、256サンプルを削除した上で、改めてDiffimgで差分をとった結果がこちら。
今度は正しく差分がとれたようで、やはりオリジナルに非常に近いことがわかる。LC3のどのビットレートと比較しても、AACが圧倒的に優れているという結果となったわけだ。
この辺を見ると、なぜAppleがLE Audioを採用しないのかという一端が見えてきそうではあるが、LE Audioは低レイテンシーであるという点で魅力があるのも事実。
今後、各社がどのように対応させていくのかなど、引き続き注視していきたい。
リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。 著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto。