HIRO.F's Scrawl

Free Space

☆復活！！Fairlady GS130Zのお部屋
☆Fairlady Zのおもちゃのお部屋
☆おもちゃ＆漫画部屋公開

☆SUZUKI GSX-RとΓのお部屋
☆SUZUKI ALTOのお部屋
☆SUZUKI ADDRESS V100のお部屋
☆SUZUKI GAGのお部屋
☆車にまつわるエトセトラのお部屋
☆車、バイク関係の漫画のお部屋

☆ネコちゃんのお部屋
☆HIRO.Fの所有するCDなどのLIST
☆HIRO.F's SHOP☆

Calendar

AQUOS R7,R5G,R,Xx106SH,206SH,404SH,003SH

(268)

ソニーのハイレゾ対応コーデック「LDAC」は何がスゴい? 開発者に疑問をぶつけた

テーマ： Bluetoothでいこう！(39)

カテゴリ： Bluetooth

最近オカルトな仕様が多いSONYさんですが、このLDACも、どこまで実用的なのか試してみたいところです。

もちろん、帯域を広くすれば音は良くなるんですが、SBC自体も、帯域を広く取れれば、そんなに悪い音ではない。
帯域を広く取れば、その分、音切れも多くなります。Bluetoothの電波なんて、ちょっと身体が入っただけで切れちゃうので、これだけ帯域を利用して、音切れなしで使えるかどうか。。。

スマフォとBluetoothレシーバーを重ねて置いても周りの環境で切れるときはあるので
そんなシビアな仕様にしてまで、Bluetoothに拘る必要があるのかどうか？？

あとは、バッテリーの持ちと、対応製品がどれだけ出てくるか。。。

aptXは、スタンダードになったけど、はたして、ハイレゾがそこまで需要があるかな。。。

日本だけをターゲットにしても、そこまで売れないし、そうなるとライセンス料高かったりすると使えない。。。

AndroidのiOSのスタックの問題も、いまだに解決されていないようなのに、本当に普及するのでしょうかね？

複雑になればなるほど、SONYのBluetoothレシーバーも不安定なものばかり。。。

フリーズ多すぎるし、接続できなくなることも多い。。。

ソニーのハイレゾ対応コーデック「LDAC」は何がスゴい? 開発者に疑問をぶつけた
（2015/5/14 10:00）

LDACの特徴と“謎”の部分

　そのような状況下登場したのが、ソニーが開発した新コーデック「LDAC」だ。限られたデータ幅に効率よくオーディオデータを詰め込むこと、それがBluetooth/A2DPにおけるコーデックの役割だが、新しいコンセプトの採用により、難しかったハイレゾ相当品質のオーディオデータ転送を可能にしている。対応機器では96kHzサンプリング/990kbps時で20Hz～40kHzという広い再生帯域(従来型コーデックは20Hz～20kHz)を持つのも、LDACだからこそだ。

　最大の特徴は「データ幅を広げる」こと。SBCの最大ビットレートは328kbpsだが、LDACの上限は約3倍の990kbps。Bluetoothには「EDR」という高速通信用拡張規格があり、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の符号化処理の流れですが、MP3のような聴覚心理モデルを使った分析もハフマン符号化も行なわないという理解で正しいですか?

鈴木：そのとおりです。符号化プロセスを単純化して“軽く”し、データ幅を広げ情報量を増やすことで音質向上を図っています。サンプリングされた信号を複数の周波数成分に変換する機構、周波数スペクトルの形状を数値化する「量子化」といった基本的な符号化処理の流れは既存のオーディオコーデックと同様ですが、LDACはよりシンプルです。LDACでは、サブバンド(部分帯域)分割はせず、そのまま周波数変換へと進みます。

松村：聴覚心理モデルを使うコーデックの場合、人間の耳に"聞こえない"とされる音域を不要なデータとして大きく削りますが、LDACの場合そのような処理は行ないません。

――なるほど。しかし、サブバンド分割はデータの効率化という点で一定の効果があるのでは?

鈴木：効率化という観点では、サブバンド分割を行なったほうがいいのですが、LDACは効率だけを求めているわけではありません。それにエイリアス成分が入ってきますから(筆者注：いわゆる「音を丸める」処理)、音質的には不利になります。高い負荷がかかることを避けたいこともありますが。

――となると、どのようにして音のデータ量を減らしているのでしょう? 圧縮プロセスを単純化すれば、圧縮率は低下し、そのぶん限りあるビットレートに詰め込める情報は減るのではないでしょうか?

鈴木：量子化の部分でデータを小さくしています。音データを周波数に変換すると、必ず周波数帯域ごとにデータ量が異なる“カーブ”が生じますよね。たとえば、低中域の情報量は多いけれど高域に向かって逓減していくとか。

松村：周波数帯域ごとに、情報量の厚みに変化をつけるわけですよ。わかりやすくいうと、中低域は情報量が多いので24bit割り当てるけれど、より上の音域はそれほどでもないから16bit、人間の耳にあまり聞こえないとされる音域はさらに割り当てを少なく、といった具合です。

――周波数帯域ごとに情報量の“メリハリを持たせる”わけですね。では、見方を変えてPCMと比較するとどうでしょう?

鈴木：PCMはすべての周波数帯域で一律に情報量を持ちますから、24bit音源の場合、全帯域を24bitで記録します。オリジナルに忠実という意味ではそうですが、ムダが多いことも確かです。映像にたとえると、主人公の表情や肌の質感にも、背景の木や波のざわめきにも一律の情報量を持たせている、といったところでしょうか。LDACでは、その背景を描くためのリソースを節約することで情報量を節約しているのです。

――では、どの部分についてオリジナルのまま保つ、リソースを節約する、という判断はどの時点で行なっているのでしょう?

松村：入力信号にあわせ処理していきます。ソースに応じて動的に、最適化した処理を行なうということです。

鈴木：時間軸で記録されているPCMでは前後のサンプルの連続性/整合性を保持するために動的な最適化は行なうことができません。しかし、周波数に変換(量子化)したあとであれば、ビット配分の最適化は自在です。ここがLDACのポイントではないでしょうか。

LDACにおけるビット配分方法の概念図。ゲインに応じてビットを最適配分することで、データ量をリニアPCMの半分程度に低減することにくわえ、「Super Spectrum Mapping」と呼ばれる手法で高域のビットを低減、990kbpsというビットレートでも96kHz/24bitを表現できる
「実装しやすさ」で、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のライブラリ、いそぎご提供します(笑)。

お気に入りの記事を「いいね！」で応援しよう