Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,014)  
HandBrake Japanese Language Version  (2,964)  
CrystalDiskInfo  (1,714)  
Boookends  (1,269)  
CrystalDiskMark  (874)  
Tera Term  (825)  
CotEditor  (626)  
FFFTP  (593)  
えこでこツール  (532)  
10  ffdshow  (524)  
11  SMPlayer  (503)  
12  Cabos  (492)  
13  ギコナビ  (475)  
14  Rappelz Server  (471)  
15  MergeDoc  (457)  
More >>

最近ブックマークされた記事

LinuxでのDAAPを用いたミュージックのネットワーク共有

2006年05月01日 12:46 Nathan-Willis(2006年4月26日(水))
AppleのiTunesのおかげで一気に普及が進んだものにDigital Audio Access Protocol (DAAP)があるが、これはネットワーク上でミュージックファイルのプレイリストを簡易的に共有するための規格だ。その恩恵はLinuxユーザであっても受けることができる。Linuxユーザであれば、ミュージックファイルの共有には各種の簡易型DAAPサーバが利用できるし、これらのファイルを再生するためのDAAP対応型アプリケーションもいくつか存在しており、そうした事情は他のユーザのミュージックコレクションを探してアクセスするような場合も同様だ。

そもそもDAAPは、HTTPの簡易拡張版としてAppleによって作成されたものである。DAAPに関する情報については、opendaap.orgによく整理された解説があるので参照して頂きたい。DAAPのクライアントおよびサーバはZeroConfを通じて相互の照会を行い、各自の基本情報をHTTP経由で交換するが、その際にはMIME type application/x-dmap-taggedを使用してTCPポート3689を介した交信を行う。

基本的な処理の流れは至って単純なものだ。まずサーバが、使用可能なミュージックとプレイリストの一覧を送信する。そしてクライアントからミュージックのリクエストが出されると、サーバがストリーム送信をして返すというだけである。またクライアントは定期的にサーバをチェックして、使用可能なコンテンツが更新されていないかを確認する。

iTunesに実装されたDAAPでは、同一クライアントによる24時間以内の接続数の上限が5回に制限されている。iTunesのオリジナル実装ではインターネット上の任意のDAAPサーバに接続できたが、Appleは同アプリケーションの4.xリリース以降に制限を付加しており、現行のiTunesではローカルサブネットへのDAAP接続のみが可能となっている。こうした実装はプロトコルに含まれているものではなく、このような変更が行われた背景にはAppleに対して大手の音楽レーベルによる圧力がかかったのではないか、というのが有力な見方である。

ご注文は何なりと

Appleの話はこれくらいでいいだろう。フリーオペレーティングシステムを運用している私達にとってDAAPサーバの選択肢は複数存在している。普及率の高いものは、daapdmt-daapddeleet daapdといったところだろう。これら3つの中でもmt-daapdは最も単純であり、開発コミュニティの活動も活発であるので、ここではこのサーバについて詳しく見てみよう。

インストールの手順については、Quickstartというガイドをmt-daapd.orgから入手できる。またいくつかのLinuxディストリビューション用のバイナリおよび、個々のディストリビューションに特化したインストレーションガイドも用意されている。

mt-daapdはlibid3tagおよびgdbmを用いてミュージックのトラッキングをしており、AvahiなどでZeroConfを実装してサービスの自動検出を行わせる必要がある。使用開始にあたっては/etc/mt-daapd.confの設定が必要だが、mt-daapdには多数のコメントが記されたサンプルファイルが同梱されているので、設定時に説明不足で困ることはまずないだろう。設定ファイルには、mt-daapdの使用するファイルの格納ディレクトリを指定するが、必要であれば、ファイル共有をするユーザ用の接続パスワードを設定することもできる。

mt-daapdの初回実行時には、ミュージックの共有ディレクトリがスキャンされ、コンテンツのインデックス作成が行われるが、その際にはMP3のID3情報などファイルのメタデータも取り込まれる。mt-daapdが標準でサポートするメタデータは、MP3、Vorbis、FLAC、AppleのAAC、M4A、M4P、M4Bオーディオブックファイルである。なおmt-daapdからはAppleの暗号化ファイルをストリームすることもできるが、これらのファイルの再生については、再生が許可されたコンピュータ上でしか行えないので注意が必要だ。

/etc/mt-daapd.confには管理用パスワードを設定する必要があり、これはビルトインされたWeb管理インタフェースにhttp://localhost:3689経由でアクセスする際に使用する(前述したようにDAAPのベースはHTTPである)。このURIからは、サーバの始動と停止、共有ファイルの再スキャン、その他の設定の変更が行える。

稼働状態に入ったサーバに対しては、DAAP対応型クライアントアプリケーションから接続して、すべてのミュージックコレクションおよび、ユーザの作成するサーバサイドの“スマートプレイリスト”のブラウジングを行うことができる。このプレイリストは、/etc/mt-daapd.playlistというファイルにいくつかのルールを定めておくことで自動作成されるのだが、ルールの構文は簡単なものであり、当該ファイル中にドキュメントが用意されている。サンプルとして用意されているプレイリスト「Recently Added」は、過去14日間に追加されたファイルをすべてリストアップしたものであり、同じく「'60s Music」は、Dateタグが1960年代に設定されているファイルを収集したものとなっている。初心者にとってありがたいのは、mt-daapd.playlistファイルには詳細なコメント付けが行われており、多数の使用例が用意されていることだ。

mt-daapプロジェクトのwikiには、いくつかの上級者用チュートリアルが用意されており、共有ミュージックコレクションへのリモートMP3ストリームの追加、SSHを用いた接続のトンネリング化、WAV出力への転送時トランスコーディングなど、より高度なサーバの運用法を習得することができる。これらが特に有用なのは、未サポートのコーデックがあるクライアントとの接続をする場合で、たとえば私の経験で言うと、Mac用iTunesはVorbisプラグインを使うことでローカルファイルに対しては正常に機能する反面、Ogg Vorbisのストリーミングは正しく扱うことができない。

クライアント様は神様です

Macの話はこれくらいでいいだろう。フリーオペレーティングシステムを運用している私達にとって、DAAP準拠のオーディオプレーヤーの選択肢も複数存在している。

一番お手軽な選択肢はRhythmboxを使用することである。なお、RhythmboxにDAAPのサポートが追加されているのは、2005 Google Summer of Codeの一環としてCharles Schmidt氏が行った功績だ。ユーザが用意すべきものは、Rythymbox 0.9以降および、GStreamer 0.10である(Rhythmboxの動作に必要)。またディストリビューションによっては、最新バージョンのRhythmboxまたはGStreamerが用意されていない場合があるので、必要に応じてソースからビルドしなければならない。ソースをコンパイルする場合は--with-daapフラグを./configureコマンドに指定する必要があるので注意しよう。

MonoベースのオーディオプレーヤーであるBansheeもDAAPのサポートを謳っているが、私が手元のAMD64システムで試した限りでは、正常に動作しなかった。その他いくつかのアプリケーションはDAAPのサポートを準備中だとしており、そうしたものには(意外なことに)MythTVも含まれるが、各種のKDE用プレーヤーについてはKDE本体のDAAP対応待ちということだ。またWINEを使えばWindows用iTunesを利用できることは有名な話である。

いくつかのJavaベースのオーディオプレーヤーもDAAPをサポートしており、mt-daapおよびOpenDAAPのサイトを見るとourTunesiLeechGetItTogetherの使用が推奨されている。これらの多くは、Linuxネイティブのプレーヤーよりも早くからDAAPへの対応努力を進めていたようである。ただしAMD64マシンで試用したところ、やはり何らかの不具合に遭遇せざるをえなかった。このような時に私のライタとしての本能から沸き上がってくるのは、「write once, run anywhere」(一度書けばどのマシンでも実行できる)というお題目を唱え続けているJavaおよびMonoのコミュニティを両方とも小一時間問い詰めてやりたいという衝動であり、アプリの開発時に使用されたJVMや.Netのランタイムさえ用意すればi386ハードウェアであってもストックシステムを使えるというのでなければ、そんなお題目は単なる虚構に過ぎないと声を大にして苦言を呈したいという衝動である。そういう訳にもいかないので、ここでは、これらのアプリケーションを正常に動作させるのは、ひとえにユーザの忍耐力にかかっており、手元のJavaインストレーションを丹念に調整する度量の広さがユーザには求められているのだという、小規模な開発チームが支えているJavaアプリを扱う際のいつもの注意を読者諸兄に呼びかけるだけにしておこう。

DAAPとファイルサーバとを比べると

ありがたいのは、DAAPのサポートがメインストリーム化するにつれ、Javaプレーヤーのような専用ソリューションへの依存度が低くなりつつあることである。最終的には、GNOMEやKDEのミュージックアプリケーションで標準的にDAAPがサポートされる時代も来るだろう。1年も経てば、今日におけるインターネットでのラジオストリーミング並の一般化も期待できるのではなかろうか。

これが喜ばしい事態であることには疑いがない。ミュージックファイルのコレクションが増大し、アクセスするコンピュータの数が増えてゆけば行くほど、その管理負担も増え続けるのは必然である。仮に複数のPCに対してミュージックコレクションを公開する際に、DAAPというシンプルなソリューションを選ばないとしたら、次善の策はすべてのファイルをセントラルサーバで一元管理してSambaやNFS経由で共有させるといった手法だろう。DAAPであれば、より少ない管理負担で同じ事ができるだけでなく、追加コスト無しでスマートプレイリストなどの付加機能を利用できる。

原文

関連トピック

最終更新:2007年07月01日 19:05