トピック
ソニーのハイレゾ対応コーデック「LDAC」は何がスゴい? 開発者に疑問をぶつけた
（2015/5/14 10:00）
ソニーが1月に発表した新コーデック「LDAC(エルダック)」。非可逆圧縮のBluetoothオーディオながら現状で最大96kHz/24bitのオーディオデータを伝送できるという、“ハイレゾ相当”の音質が売りだ。2015春夏モデルにも続々とLDAC対応モデルが投入され、12日に発表されたスピーカー「SRS-X99/X88/X77」や、ドコモからの発売が決まった「Xperia Z4」でも対応するなど、ソニーの意気込みもうかがえる。
しかし、リニアPCMでは音楽CDの約3倍というデータ幅が必要な96kHz/24bitの音源を、いかにして音楽CD以下のデータ幅に圧縮しているかなど、いまひとつわからない点が多い。ソニー製品以外にも採用が進むのか、という不安も拭いきれない。
そこで、ソニーのLDAC開発陣にインタビューを行ない、LDACについてあれやこれやと疑問点をぶつけてきた。既存の非可逆圧縮コーデックとのアルゴリズムの違い、オーディオデータの圧縮に対する考え方、他社へのライセンス方針……本稿で疑問を一掃していただけるはずだ。
取材に応じてくれたのは、ソニーのシステム研究開発本部でオーディオ技術開発にあたる鈴木志朗氏と松村祐樹氏、剱持千智氏、そしてハイレゾ関連製品の事業戦略を担当する宮原靖武氏の4名(以下敬称略)。
Bluetoothオーディオで「コーデック」が果たす役割
LDACの話へ進む前に、いわゆるBluetoothオーディオにおいて「コーデック」が果たす役割について概説したい。
Bluetoothでは、Hi-Fiオーディオ用プロファイルとして「A2DP(Advanced Audio Distribution Profile)」を規定している。音声に関連したプロファイルとしては、BluetoothにはHFP(Hands-Free Profile)やHSP(Headset Profile)も存在するが、音声通話用であり再生周波数帯域は狭く、音を楽しむという点ではA2DPに比ぶべくもない。
A2DPでは、ステレオまたはモノラルのオーディオデータを、ACL(Asynchronous Connectionless Link)という方式を使い非同期に転送する。しかし、規格策定当時はBluetoothの転送レート上限が1Mbps程度であり、高品質のステレオ音声を扱うには条件的に厳しかった。オーディオCDを無圧縮でストリーミングするために必要なビットレートは約1.4Mbps(44100Hz/16bit/2ch)であり、Bluetooth 2.0で非同期通信するときのデータレートが最大723kbpsであることからしても、なんらかの対策を要した事情は理解できることだろう。
そこで考え出された手法が、音声の符号化と復号化を行なうソフトウェアの導入、すなわちコーデック(CODEC、語源はCOder/DECoder)によるデータ圧縮だ。Bluetooth/A2DPでは、必須のコーデックとして「SBC」を定義することで、非圧縮(PCM)に比べ効率的なデータ転送を可能にしている。つまり、Bluetoothオーディオ機器を開発する場合、必須のSBCさえサポートしておけばどの機器でも鳴り、それなりの音質で聞こえるということだ。なお、HFPの最新仕様(v1.6)では、SBCをもとに策定されたコーデック「mSBC(modified SBC)」をサポートするが、モノラルのみのためオーディオ用途には適さない。
A2DPでは、SBC以外のコーデックも利用可能だ。オプションとしてMEPG-2/4 AACとMPEG-1 Audio(MP3)、ATRACが用意されるほか、最近では英CSR社のaptXをサポートするオーディオ機器も多い。利用するコーデックにより圧縮アルゴリズムやデータ転送のしくみが異なるため、ひと口には言えないが、SBCよりMP3、MP3よりAAC、AACよりaptXのほうが音質的には有利とされる。ただし、それら既存のコーデックが事実上扱える情報量は最大48kHz/16bitという音楽CD水準で、いわゆる“ハイレゾ”には対応しない。ちなみに、AACには最大96kHz/24bitのプロファイルは用意されているが、高負荷なうえデータ効率が低く、これまで対応するオーディオ用途のチップは開発されていない。
LDACの特徴と“謎”の部分
そのような状況下登場したのが、ソニーが開発した新コーデック「LDAC」だ。限られたデータ幅に効率よくオーディオデータを詰め込むこと、それがBluetooth/A2DPにおけるコーデックの役割だが、新しいコンセプトの採用により、難しかったハイレゾ相当品質のオーディオデータ転送を可能にしている。対応機器では96kHzサンプリング/990kbps時で20Hz～40kHzという広い再生帯域(従来型コーデックは20Hz～20kHz)を持つのも、LDACだからこそだ。
最大の特徴は「データ幅を広げる」こと。SBCの最大ビットレートは328kbpsだが、LDACの上限は約3倍の990kbps。Bluetoothには「EDR(Enhanced Data Rate)」という高速通信用拡張規格があり、2Mbpsと3Mbpsの2種類定義された転送レートのうち2Mbpsがよく使われるが、実効値は1.4Mbps程度であり、マージン部分を考慮すると1Mbpsほどが現実的とされる。それを目一杯使い情報量を増やし、最大96kHz/24bitというハイレゾ相当の音データを扱うことで音質向上を図ろう、というわけだ。
「軽い」こともLDACの重要な特徴といえる。データ圧縮の知識があると、複雑な演算を行ない圧縮率を高めることでデータ効率を高めているのだろう、だから処理は重く要求スペックも高いに違いない……という先入観でLDACを見てしまいがちだが、LDACはむしろその逆を行く。ハフマン符号化(出現回数が多いデータをより短い符号で置き換えることで情報の圧縮を図る、可逆圧縮の代表的なアルゴリズム。ZIPなどの圧縮ファイルフォーマットやJPEGに採用されている)など高負荷な演算を伴わないからだ。だから生じる負荷は既存のコーデックと大差ないレベルで、高性能だが高価な最新チップも必要ない。
「音を残す」ことも特徴のひとつ。MP3やAACでは、人間の聴覚では識別しにくい高周波成分を聴覚心理モデル分析により割り出し、それを大胆に切り捨てることでデータ総量を大幅に減らしているが、LDACでは聴覚心理モデル分析は行なわない。他のコーデックではカットされてしまう高域成分も、しっかり残されるのだ。
とはいえ、なんらかの方法でデータを効率化しないかぎり、非圧縮でCDの3倍以上の情報量となる96kHz/24bitの音は990kbpsというレートに載らない。MP3やAACほどではないにせよ、LDACも多少のデータ欠落を伴う「ロッシー」なコーデックであることは確か。そのあたりの謎を探ることが、今回LDAC開発陣を訊ねた理由だ。
高音質の秘密は“シンプルさ”にあり
まずは、LDACというコーデックのしくみと、いかにしてハイレゾ品質の音をBluetooth/A2DPに載せているか、その辺りの事情について訊ねてみた。
――LDACの開発は、いつ頃スタートしたのでしょうか。
鈴木：LDACのベースとなるコーデックの開発に着手したのは、10年ほど前です。当時はメディア容量の制約が厳しく、圧縮率を優先する考え方が支配的でしたが、このコーデックは音質に重きを置いた設計にしました。長らく表舞台には現れませんでしたが……ワイヤレスという制約の多い場面では使えそうだと。そこでアレンジを加え、Bluetooth/A2DP準拠のコーデックにまとめあげたというわけです。だから、LDACイコールBluetoothコーデック、というわけではありません。
――LDACの符号化処理の流れですが、MP3のような聴覚心理モデルを使った分析もハフマン符号化も行なわないという理解で正しいですか?
鈴木：そのとおりです。符号化プロセスを単純化して“軽く”し、データ幅を広げ情報量を増やすことで音質向上を図っています。サンプリングされた信号を複数の周波数成分に変換する機構、周波数スペクトルの形状を数値化する「量子化」といった基本的な符号化処理の流れは既存のオーディオコーデックと同様ですが、LDACはよりシンプルです。LDACでは、サブバンド(部分帯域)分割はせず、そのまま周波数変換へと進みます。
松村：聴覚心理モデルを使うコーデックの場合、人間の耳に"聞こえない"とされる音域を不要なデータとして大きく削りますが、LDACの場合そのような処理は行ないません。
鈴木：オリジナルのデータが残るぶん「0」の連続など同じデータが出現する状況に乏しいLDACの場合、圧縮率を稼げないわりに高い負荷がかかることになるので、ハフマン符号化を行なわないしその必要もないのです。
――なるほど。しかし、サブバンド分割はデータの効率化という点で一定の効果があるのでは?
鈴木：効率化という観点では、サブバンド分割を行なったほうがいいのですが、LDACは効率だけを求めているわけではありません。それにエイリアス成分が入ってきますから(筆者注：いわゆる「音を丸める」処理)、音質的には不利になります。高い負荷がかかることを避けたいこともありますが。
――となると、どのようにして音のデータ量を減らしているのでしょう? 圧縮プロセスを単純化すれば、圧縮率は低下し、そのぶん限りあるビットレートに詰め込める情報は減るのではないでしょうか?
鈴木：量子化の部分でデータを小さくしています。音データを周波数に変換すると、必ず周波数帯域ごとにデータ量が異なる“カーブ”が生じますよね。たとえば、低中域の情報量は多いけれど高域に向かって逓減していくとか。
松村：周波数帯域ごとに、情報量の厚みに変化をつけるわけですよ。わかりやすくいうと、中低域は情報量が多いので24bit割り当てるけれど、より上の音域はそれほどでもないから16bit、人間の耳にあまり聞こえないとされる音域はさらに割り当てを少なく、といった具合です。
鈴木：情報量は減るかもしれませんが、データは削らずに残すので、他のコーデックでは失われがちな音場感など独特のニュアンスも伝えることができるというわけです。人間の聴覚を超える高音域の場合、成分があること自体重要ですが、そこに8bitもあてる必要性は乏しいという考え方です。一方で中低音域はわかりやすいですから、24bitフルに割り当てなければなりません。
――周波数帯域ごとに情報量の“メリハリを持たせる”わけですね。では、見方を変えてPCMと比較するとどうでしょう?
鈴木：PCMはすべての周波数帯域で一律に情報量を持ちますから、24bit音源の場合、全帯域を24bitで記録します。オリジナルに忠実という意味ではそうですが、ムダが多いことも確かです。映像にたとえると、主人公の表情や肌の質感にも、背景の木や波のざわめきにも一律の情報量を持たせている、といったところでしょうか。LDACでは、その背景を描くためのリソースを節約することで情報量を節約しているのです。
――では、どの部分についてオリジナルのまま保つ、リソースを節約する、という判断はどの時点で行なっているのでしょう?
松村：入力信号にあわせ処理していきます。ソースに応じて動的に、最適化した処理を行なうということです。
鈴木：時間軸で記録されているPCMでは前後のサンプルの連続性/整合性を保持するために動的な最適化は行なうことができません。しかし、周波数に変換(量子化)したあとであれば、ビット配分の最適化は自在です。ここがLDACのポイントではないでしょうか。
「実装しやすさ」で、LDAC対応製品が増える日は近い!?
現在のLDACは、Bluetooth/A2DPという"箱"の中で機能するソフトウェアであり、その"箱"を構成するのはオーディオプレーヤーなど送信側と、スピーカーに代表される受信側のデバイスだ。発表から日が浅いだけに対応機器は少なく、本稿執筆時点ではソニー製品くらいなもの。その特徴と利点は理解できたとしても、選択肢が増えないことには盛り上がりようがないことは確かだろう。その辺りの質問も、LDAC開発陣にぶつけてみた。
――LDAC対応機器には、どの程度のスペックが必要なのでしょう?
宮原：それほど高い負荷を必要としませんから、現在他のコーデックに使われているチップと同程度のスペックがあれば十分でしょう。具体的には、数十MIPS程度の処理能力があれば足ります。
――数十MIPSとは、じゅうぶん“軽い”といえるレベルですね。しかし、新たにBluetoothチップを起こさなければならないのでは?
剱持：Cで記述したリファレンスコードを用意していますから、そうしていただくことはもちろん可能です。特定プラットフォームへの依存性もありません。アセンブラレベルでの対応が必要なチップの場合、リファレンスをもとにアセンブラコードを書いていただく必要はありますが。
鈴木：それは大変でしょうということで、英CSRの「8675」というチップの段取りを整えています。CSR8675向けにコードを実装済ですから、チップを購入していただき、そのうえでLDACのライセンスを受けていただければ、LDAC対応製品として開発できます。
宮原：英CSRにLDACをライセンスする権利はなく、ソニーが個別にライセンスをするという形になります。なお、第1弾は英CSRでしたが、もちろん他社のチップにも対応可能です。「パートナーのこのチップを使いたい」という要望があれば、我々が実装を支援するという形になるでしょう。
――しかし、すでにあるBluetooth製品に“後付け”の形でチップを載せるのは難しいのでは?
剱持：他のコーデックよりは実装しやすいと思いますよ。処理サイズも、符号化のタイミングやパケット送出の方法も……メディアペイロードはSBCとほぼ同じに設計しています。このようにデザインしないと使ってもらえないだろう、という考えがありましたから。コーデックとしては、SBCを置き換える形でLDACが動く、というイメージです。
鈴木：Bluetooth/A2DP標準のフレームワークを踏襲して開発していますから、システムフローはSBCのものをほぼそのまま引き継げるのではないでしょうか。
――では、PCやソニー製品以外のスマートフォンでのLDAC対応はどうでしょう?
鈴木：現在流通しているBluetoothチップは、主に無線通信部分を担っています。A2DPに使用されるコーデックは、ソフトウェアスタックとして分けて提供されているものが多いので、あとはOSベンダー次第ですね。Androidスマートフォンの場合は、メーカー対応になるでしょうか。
剱持：実際、BlueZ(筆者注：LinuxやAndroid OSに採用されているBluetoothスタック)にLDACを実装したときの修正箇所は、ごくわずかでした。最初のネゴシエーションの部分とコーデックの切り替えを行なうためのコードを書き加えた程度で、動いてしまいましたから。
鈴木：Android OS 4.xの場合、そのレイヤーまでハイレゾデータを持ってくる“パス”がないという問題はありますが(筆者注：OS標準のオーディオ処理系ではハイレゾ信号を扱いきれない、だから別途開発が必要)。スタックがBlueZかBluedroidかで、対応も違ってきます。
剱持：iPhoneなどApple製品に関しては、スタックの仕様を把握してませんが、ライブラリとしてはARMでも動きますから、対応可能なのではないでしょうか。
宮原：弊社WebサイトにLDACの問い合わせページを用意していますから、連絡いただければすぐにでも。
鈴木：LDACのライブラリ、いそぎご提供します(笑)。
ソニー製品以外への普及に期待。192kHz/32bitやマルチチャンネルなど今後の動きも注目
LDACの発表以来、筆者はたびたびLDACを利用した試聴の場に参加しているが、その音は従来のBluetoothオーディオとは明らかに水準が違う。音の輪郭の鮮明さとリアルな音場感、倍音成分の自然さなど“ハイレゾらしさ”を味わうに足るキャパシティを感じさせる。
周波数帯域ごとに情報量のメリハリをつけるが音の情報の有無そのものは削らない、というLDACの符号化アプローチはユニークで、かつ理にかなっていると思えた。ハイレゾの情報量をBluetooth/A2DPという箱に収めることは、どこかで“節約”しないかぎり困難だが、人間の聴覚特性を考慮したうえでの情報の濃淡であれば納得できる。
ソニーの「LDACを普及させたい」という意思も感じられた。それも、よろしければどうぞ、という控えめなものではなく、「ぜひ、多くのメーカーに採用していただきたい」(宮原氏)という積極的なもので、実際英CSRとの協業で対応チップを手配済という形に現れている。ソニーとしては、一定のクオリティチェックを実施したうえでライセンス供与を決定するとのことだが、なにぶん「ハイレゾ(相当)コーデック」であるだけに、ただ鳴るだけのBluetoothスピーカーでLDAC対応を売りにしようとするメーカーは少ないはず。おそらく、一定のプレミアム性を持つオーディオ機器を中心に採用が進むことだろう。
LDACの今後の展開も興味深いものだ。現在は最大96kHz/24bitというスペックだが、LDACそのものは最大192kHz/32bitまで対応できるという。チャンネル数も2ch以上に増やすことが可能で、サラウンドも視野に入る。その意味では、LDACは「Bluetooth以外も含めたワイヤレスオーディオ・コーデック」という観点から評価すべきで、そのような製品が登場することを心待ちにしたい。
海上 忍
IT/AVコラムニスト。UNIX系OSやスマートフォンに関する連載・著作多数。テクニカルな記事を手がける一方、エントリ層向けの柔らかいコラムも好み執筆する。オーディオ&ビジュアル方面では、OSおよびWeb開発方面の情報収集力を活かした製品プラットフォームの動向分析や、BluetoothやDLNAといったワイヤレス分野の取材が得意。2012年よりAV機器アワード「VGP」審査員。