「Google Cast for audio」をもう勝手に始める①

iPhoneと訣別して、Nexus5を使い始めてから結構時間が経ったように思う。あまり、iPhoneがどうだとかAndroidがどうだとかいろんな人がその話をしたいだろうので、語るつもりも無いが、Appleの一連の製品群の連携は、それでもかなり評価している。と、AirPlayをRaspberryPiで受信している僕が言ってみる(笑)

さて、今回は音楽のリモートプレイの話をしてみよう。リモートプレイと言うと、今は多くのAVアンプやコンポがその機能を搭載しており、言わば、スマートフォンの中やNASの中に格納した曲を、無線もしくは有線でレシーバーに飛ばし、再生するための機能だ。

おそらく、今回は概略みたいな話になって、次回が実践編になるので、まあ面倒な人は次回まとめて読むか、今回の記事はスキップしても良いかも笑

さて、最近のトレンドとして、リモートプレイは一般的には以下のような技術で実装されているように思う。

・Bluetooth
・DLNA
・AirPlay
・MPD
・独自実装

過去にはアナログを無線で飛ばす方式しかなくて、これはもう良いところが一つも無かったところからすると、今はデジタルで無線で飛ばす事ができるようになっており、これはもう劇的な進歩であろう。

音楽データのサイズも年々大きくなり、NASに音楽データを溜め込んでいる人も多く、ここらで一発、リモートプレイにチャレンジしよう(もしくはできれば見直したい)という人達も増えてきているような気も勝手にしているので、それぞれについて、音質や扱いやすさ、その他の雑感など、僕の個人的見解を述べてみたい。

なお、PCやスマホをつなげて直接再生、というそもそもの方式もあるけど、PCは作業、音楽は別システムで再生ときっちり分けた方がずいぶん快適だと思うので、その辺はこの記事では触れない事とする。現代人がDockにiPhoneをおきっぱなしにして音楽再生、なんてユースケース、ありえるんだろうか?

うーん、これも長くなるだろうなあ。2回に分けるしか(笑)




眠れる獅子、もしくは縁側の猫のBluetooth

僕はBluetoothが嫌いだ。というか、「ちゃんとした」音楽再生のためにBluetoothを使うのは嫌だという方が正確だろう。

よく使いもせず文句を言う人がいるけど、僕は過去にさんざんBluetoothに期待し、挑戦し、そして裏切られてきた。そういう意味では筋金入りのBluetooth否定派だと言っても過言ではない。

何がそこまで嫌なのか。

まず、初期のBluetoothでの音楽転送はひどすぎるといっても良いほど音が悪かった。その印象が強く残っているというのは大きいかもしれない。

とにかくスループットが悪い通信経路に圧縮して音楽を流すものだから、ホワイトノイズはひどいは、音は劣化しまくるは最悪だった。

Bluetoothへのチャレンジの初回は、今ほどオーディオとか多少かじるずっと以前の事ではあったが、それでも音の悪さに閉口し、この時からずっと今まで、Bluetoothオーディオというのは最悪だと思い込んでしまっている。

このように、スループットの悪さから来る音の悪さがBluetoothの最大の欠点であったが、現在は「規格上のデータ転送速度の上限が24Mbps」にまで向上しているという事なので、改善の可能性はあるが、いまだに音楽伝送で用いるA2DPで許される転送幅の上限は512kbpsと狭くなっているようで、これでは永遠にハイレゾなんぞ送れやしない。(ハイレゾなんていらないとは思っているけれど)

おそらく、Bluetoothでは同時に様々なプロファイルで通信させる必要があるため(Bluetoothヘッドフォン使用中にもマウスが使える、等)、”占有させる”事自体が許容されないのだろう。

そもそも、Bluetoothはモバイルでの省電力無線技術として開発がなされ、実用化がなされているものである。そのため、モバイル用途を許容するための様々な仕様の限界が、据え置きの自宅オーディオを構築するためにはまったく持って不要な足枷となり、限界が突破できないのだろう。

誰しも原チャリが便利で幾ら高性能になってきたからと言って、原チャリで高速に乗って避暑地に向かったりしないだろう。僕にはそんなものにしか見えない。
期待すべきはイヤホンケーブルの無線化などのモバイル用途であって、本格用途には向いていない技術である、というのが僕の結論だ。

少なくとも音質を求めるのであれば、Bluetoothは選択すべきではない。(今のところ)

なお、一応、Bluetoothオーディオの音質に触れておくと、あくまで僕の個人的な見解だけど、最新の機器ではずいぶん改善されているように思う。ただし、薄く硬質な乾いた音がするような気がしており、再生するシステム(特にスピーカー)にもよるけど、誰でも感じられる程度の劣化(つまりそれは大幅な劣化)は存在していると思う。

まあ、スピーカーがずいぶん癖があったり(原音など出す気も無い)、あまり繊細な音を出さない環境であれば、その汎用性のただ1点で選択しても良いとは思う。また、LDACなどの新しい実装も色々出てきているみたいなので、今後に期待、というところだろうか。

うーん、Bluetoothはずっと先への期待で裏切られ続けているんだけど、まだ追わないといけないのか、なんて個人的には思うけど(笑)

これくらいのサイズでレシーバーが完結すれば最高なんだけど。

扱いにくいよDLNA

DLNAというのはDigital Living Network Allianceの略だということだが、まあ、簡単に言うと、DLNAサーバにあるコンテンツをDLNAクライアントにストリーミングして再生させるための標準規格である。AVアンプや一部のコンポやレシーバー、HDDレコーダ、テレビなんかに実装されている事が多い。

これはまあ、簡単に言うとYoutubeとPCのブラウザなんかと同じで、クライアントでコンテンツをダウンロードしながら、再生するわけであるので、単純な仕組みであり、再生可能なファイル形式も柔軟性があるように思う。

有線だろうが、無線だろうがネットワークでつながっていれば、サーバからコンテンツをストリーミング再生できるわけなので、これは便利に思えるだろう。先ほどBluetoothで仕様限界だといった圧縮も不要なので、音質的劣化も考慮しなくて良い。

ただし、DLNAはなんとも扱いにくい印象がある。

まず、DLNAサーバ機能を持った機器(サーバー、クライアント)を導入しなければならなく、それが一つの壁であろう。そして、DLNAクライアント機能を持った再生機器、それは例えばレシーバーやコンポ、AVアンプだったりするのだが、特にコンポやAVアンプだと、「好みのアンプを選べない」問題が出てくる。

そして、クライアントによって再生できるファイル形式がまちまちな事も問題だと思う。インターネットのレビューではその相互接続性の問題も多く散見される。

そして、これは個人的な見解かもしれないが、DLNAはそのプロトコル仕様なのか、何とも動作が重く、プレイリストも「別ファイルを別で作成して配置する」ような事でしか対応できない(独自実装でうまく実装できているものもあるかもしれないが)ので、自由な選曲の観点で、遅く、不自由だという欠点があり、なんとも使いにくい印象がある。

特にコンテンツ(ファイル)リストまでストリーミングで都度取得するのが、モタモタして扱いづらく、積極的には使いたいと思わない。サーバ側/クライアント側で、コンテンツリストをキャッシュデータとして作成するような実装があればこれは改善できるのだろうが、今のところそんな実装がなされているDLNA機器には出会ったことが無い。

ただし、現時点でDSDをストリーミング再生するにはDLNAを使うか、DoPEというさらに独自の実装でしか実現できないので、DSD再生を考慮した場合はほぼ一択でDLNAを選択する必要がある。

というわけで、「我慢するのがオーディオだ」と思える人以外はDLNAを選択するのは大変ストレスが多いような気がしており、DSDや動画用途以外には避けたい、というのが私の見解となっている。

僕は動画再生に関してのみ、DLNAを活用している。

ツンデレひどいよAirPlay

上記の2つに比べれば、AirPlayは大好きだ。

特にiPadで再生しているYoutubeの音声のみをAirPlayで飛ばす方法がある(普通ならAirMac Expressを使う、僕はRaspberry PiのAirPlayサーバに飛ばしている)のだけど、その機能は毎日使っているといっても過言ではない。

音もBluetoothに比べればずいぶん良いように思う。伝送方式としては44.1kHzか48kHzのAppleLossless形式となっていて、可逆圧縮の音声データを無線Or有線でAirPlay対応機器にストリーミングで流しているわけなので、仕様上は「CDと同等」の品質で音楽再生が可能だ。

ただし、残念な事に「Windowsの汎用オーディオ再生アプリ」やAndroidからのAirPlayはかなりの困難を伴う。これはAndroidに移行してしまった僕にとっては致命的な問題となっている。

また、AirMac Expressでは44.1kHzというCDと同じサンプリングレートでの再生が可能なのに対し、僕も使っているAppleTVでは48kHzに強制変換されるという製品仕様があり、ここのサンプリングコンバータの性能が悪いのか、どうにも音が薄っぺらくなる傾向がある。

この辺りは海外のユーザも指摘していて、なんとかApple TVでも44.1kHzで再生できないか色々試しているみたいだけど、やはりチップ仕様で48kHzでの再生しかできないようである。

幸い、このAirPlayの仕様は公開されていて、実装も簡単なようで、AirMac Expressと同等の機能を持つLinux用のアプリケーション(サーバ)が有志によって開発されていて、僕もこのアプリを活用させてもらっている。

Linuxの知識が多少あるのであれば、Raspberry Piなどの組み込み機器を活用して、こういったレシーバを自前で作るのもおススメだ。この辺りは、かなりオススメなので、またどこかで記事化したい。

今の音楽再生環境を活用しつつ、何か製品を導入するという事であれば、ELECOMの「LDT-AVWAR800」なんて機器が販売されていて、明記はされていないが、どうもAirPlayには対応しているようであるので、こういった機器を導入するのが良いと思う。(なお、類似の機器としてBluetoothのみに対応した製品もあるので間違えないように。)



※AirMac Expressは無線LANルータにAirPlayレシーバ機能を兼ね備えた物なので、値段も高く、無線LANルータをすでに導入している家庭には多少導入しにくいと思う。中古の古いAirMac Expressをヤフオクなどで購入するというなら話は別であるが。

音もよく、接続も簡単、音声のみを機器に飛ばして映像はiPadで見るなんて芸当も可能な、なんとも優秀なAirPlay機能ではあるが、Androidでは再生しにくいという問題はやはり大きな壁となっていて、Apple製品に対する態度とAndroidに対する態度がもうまさにツンデレで、おじさん困っちゃうというのが、AirPlayの現状である。

<追記>
あと、IOS9になった際にAirPlayの仕様を大幅に変更したらしく、多くのLinuxの互換アプリケーションが動かなくなるという事態を招いているようだ。しかも、その動かなくなる機器にはAppleTV(第2世代)も含むという(笑)。IOSを年々重くしたり、こういう風に自社製品の互換すら切り捨てていく(AppleTVは事故だとも思うが)姿勢はなんともAppleらしく、僕が最後の最後にApple製品を信用しきれないのはこういうところにある。世界の誰かが見つけ実現させた宝石のごとく素晴らしいツールをいともたやすく潰してしまうのはやめてもらいたいところだ。もしくは「光デジタル出力から44.1kHzが出せるAppleTVを出せ!」とか思ってたら、新しいAppleTVが発表されて、光デジタル出力が無くなってたり(笑)
ちなみに、アップデート提供が止まったiPad初代とLinuxの互換アプリケーションとの相性はバツグンである。古い機器が捨てられなくて困る。

MPDという名の天使

RaspberryPi+SabreBerryPlus+MPD

我が家の音楽再生環境はMPDというLinuxアプリケーションをずいぶん前から導入していて、音もよく、大変便利で、もうこれは「無くてはならない」環境となっている。

多少の知識があれば環境は構築できるので、絶賛オススメしたいが、今回書きたい内容からはずいぶんはずれてしまうので、別の機会に紹介してみたいと思う。こういうアプリケーションは勝手にアップデートされることも無く、その点でとても安心して使用できる。

個人的には、誰でも使えるMPD機能を持ったレシーバをメーカーが出す事が世界にとって有意義だと僕は思っている。

持続力が心配な独自実装

その他、Wirelessの実装として、メーカー独自のワイアレス機能が実装されていたりするが、専用のアプリケーションを導入しないとならなく、メーカーサポートもいったいいつまでしてくれるのかなど、長期運用にはかなりの不安が残る。

なるべく、ある程度の汎用性を持ったリモートプレイの方法を確立する方が吉なので、メーカー独自実装の方式については一切無視したいと思う。

ただし、おそらくDSDの伝送など、一時的には需要があり、しばらくは仕方なく使うという事もあるかもしれない。

唯一、オープンソースのPiCastというのがあり、これはもう少し追ってみるつもりだ。

僕らの「Google Cast for audio」!

さて、いったいどれくらいの人がここまでこの記事を読んでいるのであろう笑

いつも長くなり申し訳ないが、やっと本題だ。僕ら世界中のAndroidユーザが期待すべき機能が、2015年の頭にGoogleより発表された。それが「Google Cast for audio」だ。

「Google Cast for audio」

ついにAndroidユーザも今、AirPlayでやっているような「音声のみをリモートで飛ばす」事が可能になるという(僕にとっての)ビッグニュースだ。

これこそ、僕が今、求めていたまさにその機能だ。

ただし。残念な事に2015年の9月になっても、このニュース、ほとんど動きがない。どうやらSONYのSTR-1060というAVアンプが対応しているようであるが、見る限り、国内で販売されているのはこの商品だけで、AVアンプという僕にとっては扱いにくい(特に大きさ)カテゴリであるため、何とも手を出しにくい。

その他も、どうも予定されているものは一体型スピーカーのようなものだったり、僕の欲しい「音楽用小型レシーバー」として使えるものはまだどこからも発表されていない。

ならば、もう製品の発表だとか、有志によるLinuxアプリケーションの開発なんかは一度あきらめて、自分なりに「Google Cast for audio」を始めてしまおうかというのがこの記事の趣旨。ここまで長かった。

ちなみに直近で発表されそうなChromecastの新型にはどうも「Google Cast for audio」の機能が乗っているんじゃないかと噂されている。こいつがデジタル出力も可能なら、次の記事もいらないけど(笑)、たぶんアナログ出力なんじゃないかと思っていて、そうなるとDAC上等だと思っている僕からすると、「Chromecast搭載の廉価な統合チップでDA変換がなされる」事がどうしても気になり、AppleTVの48kHz問題程度を気にしている程度の僕の脳なので、やっぱり他に何か新しいやり方を模索してしまう事だろうと思う(笑)

新型Chromecastの中身はiFixitによる分解レポートに期待しつつ(笑)、実践編は次回、ようやっと「Google cast for audio」をもう勝手に始めるの本編となります。

みんな、付いてきてるんだろうか?心配(笑)

スポンサーリンク
スポンサーリンク