ラズパイは美味しいか！？（その７）：Cover Art編

音楽を聴く時に、リスニングポジションに座ったまま楽チン操作をすることができなければここまでPCオーディオに突き進んでは来なかったかもしれないと思う。WindowsXPにてwinampを聴いていた かなり昔 の頃から、リコモンソフトをいろいろと試してきて、自分の感性にマッチするものを選択してきた。今はPCオーディオのみならずネットワークオーディオ機器の操作もリモコンアプリで行う事は世の標準環境と云っても良いのではと思う。もちろん純粋オーディオ的に見れば、無線LANの電波の影響もゼロではないので、これを排除したいという硬派もいると思うが、その点当方は至って軟派でもある。だが、ネットワークオーディオ機器の黎明期におけるこのリモコンソフトの機能と反応速度は絶望的でもあったことは記憶からは消えていない。これはDLNA/OpenHomeという簡単で便利な仕様に則ったことによる得失なのだと今でも思っている。

当方の使用するリモコンソフトもPC環境に応じて変遷してきたが、VoyageMPD環境へ移行した段階でMPD専用のリモコンソフトであるMPoD、MPaDに触れてその機能と反応速度に魅せられ続けてきた。JPLAY FEMTOを導入してからも初期段階ではあれこれと試行錯誤する日々が続いてしまったのだが、現在はJRMC/JRemoteのペアーをコントロールポイントとしてのみ使用することで機能的な部分は補えている。だが、操作感、反応スピードと言う観点からはUPnP/DLNAの制約なのだろうと推測するが決して満足できる水準とは云えない。

今般ラズパイの学習において、なつかしのMPadで改めてMPDの操作をしているが、やはり素晴らしいと思う。UPnP/DLNAの世界ではWeb UIもそれなりに主流だとは思うのだが、単純に比較すれば勝負できる土俵には無い。だが、現実としては、既にMPoD、MPaDは新たにダウンロードする事はできなくなってしまっているので、当方のように昔使っていて、たまたまアプリとして残っている、という人にしか選択肢がない。もちろん、AndroidベースのMPDリモコンアプリは存在するので、そちらの選択肢はあるものと思う。（使ったことはない）

ただ当方は、リモコン用のタブレット端末は一貫してiOSベース。従って、この環境で動いてくれなければならない。iOSに拘る理由は単に「それを持っているから」というだけの理由なのだが、以下のように並べてみれば明白なように、ここにリモコン用として使うためだけにAndroidが割り込む余地はない、、、

左からiPoD1、iPoD2、iPhone SE、iPhone 6 iPAD Mini、iPAD揃い踏み：すべて現役
、

そんなiOS世界のMPDファンを救済すべく？　新しく yaMPC というリモコンアプリが登場してくれている。現状はiPhoneを意識した画面設計だが、ホームページにはiPAD用に最適化されたものを本年度（2019年）中にリリースする予定という力強いアナウンスがある。これは内容的にはほとんどMPoD、MPaDの後継となるリモコンアプリ。ラズパイによってこれからまたこの手のリモコンソフトにお世話になることを想定すればこんなに嬉しい事は無い。Web UIやデスクトップでの操作アプリを否定する訳ではないのだが、iOSタブレットをお持ちの方は（機能限定版は無料なので）一度は試してみることをお勧めしたい。

さて、ここまでが前置き。ここから本題なのであるが、実はMPoD、MPaDでカバーアートを表示させるのにちょっと引っ掛かってしまう人が多いかもしれない。基本的な動きとしてMPDが動いているPC上のHTTPサーバーに対してカバーアートの画像を要求し、それをタブレット内にキャッシュする（なので、表示速度が極めて速い）。HTTPにて画像を呼び出すのはシンプルで簡単な仕組みなのであるが、MPoD、MPaD自身が画像を要求する為のURLを設定に基づいて生成するので、このURL生成ロジックが頭に入っていないとカバーアートを読み出せないという状況になってしまうことがある。また、Linux上で音源フォルダー内にあるカバーアート画像をHTTPでアクセスするためにリンクを設定してあげる、というちょっと一般的にはわかりにくい操作が必要なってしまう欠点がある。（この部分の仕様はyaMPCでも 全く同一なのでyaMPCを使う際でも下記の記載内容は有効）

（参考）URL生成ロジック：
「URLのプレフィクス（MPaDに登録設定したもの）＋シンボリックリンクしたフォルダー名（自動生成）」
　 ＋「アーチスト、アルバム、Folder.jpg」

今般、ラズパイ上にArchphileをインストールしていろいろと試行錯誤している中で、このArchphileを使うとカバーアートを表示できない、という課題に遭遇して四苦八苦してしまったのだが、これはそもそもArchphileでHTTPサーバーをインストールして稼動させることができない（当方のスキルの問題もある）、ということであった。これはArch Linux特有のディストリビューション管理の問題らしいと思えるのだが、その点は全く詳しくないのでこの点を追求する事はギブアップしてしまった。

だが、今後しばらくArchphileを使ってみようと思っているので、これは大変不都合。カバーアートの表示されないリモコンアプリなんて、何とかの無いコーヒーどころの騒ぎではない。当方はカバーアートで直感的に楽曲選択するので、これがなければ極楽操作ができないだけでは済まされない。そこで、じゃどうするか？　と一旦冷静になって考えてみた。

HTTPサーバー経由でカバーアート画像を入手するということは、HTTPサーバーはどのPCで動いていても構わない。つまり今回のケースでは必ずしもArchphile上で動いている必要はなく、MPaDから他のPCのHTTPサーバーに画像要求を出せば良い筈。これを検証するため、一旦ALIX3D2ベースのVoyageMPDを同時並行稼動させて、MPaDのカバーアート参照URLの設定（IPアドレスで記述）をArchphileからVoyageMPDに変更してみた。おっけ～！

ArchphileとVoyageMPDはサーバーPC上にある全く同一の音源フォルダーをマウントして参照しているので、HTTPサーバーが異なっていても不都合は起きないのだ。さて、これはひとつの解決策ではあるのだが、率直に云えばこれでは全然面白くない。余分にVoyageMPDのALIX3D2を動かすことなどしたくはないし。であれば、音源フォルダーが置いてあるサーバーPC（当方の場合はJPLAY FEMTO用のコントロールPC兼用）でHTTPサーバーを動かせば良い、と単純思考。

ちょっとうまくいくか自信はないのだが、もしこれが成功すれば、Archphileへカバーアート要求が出されることも無いので、余分な処理をさせないという観点からも好都合ではないか？　また、サーバーPCはArchphileから見ればNAS代わりなのでそもそも稼働している前提なので、PCを追加で稼働させる必要もない。などメリットも大きいのでとにかくやってみた。

現状のWindowsベースのサーバーPC（＝Control PC）でHTTPサーバーを動かす事は簡単で普通にはIISの機能をenableしてあげれば良いだけ。もちろん、HTTPサーバー分のプロセスや負荷は想定されるのだが、MPaDはキャッシュされた画像の表示がメインなので、常にHTTPサーバーに画像要求のアクセスをする訳ではない（DB更新やキャッシュ更新要求、あるいはカバーアートのリロード要求に限られると思う＝推測）ので、この負荷はネグレクトできるだろうと考えている。

さて、IISをサービス状態にして、あとはデフォルトとなるHTTPサーバーのルートディレクトリと物理パスの設定。実はたったこれだけ！　試しにブラウザーからテスト的にサーバーPCのアドレスに対してカバーアート画像を要求してみるとスポッと表示される。いいね～いいね～簡単に実現できた！　Archphileで躓いた分、何だか棚ぼた気分。

MPaD側でのカバーアート参照URLの設定はスタティックIPの設定スタイルで：

「192.168.x.xxx:80/Music」　

と「サーバーPCのアドレス」（MPDが動いているPCのアドレスではない）を指定する。ポート番号はデフォルトなので指定しなくてもOK。次の「Music」はIISで指定したルートディレクトリ名と同一（重要）。　ルートディレクトリ名と物理パス名が同じだと案外判り易いかも。

（参考）生成されるURLの例：
物理パスの一階層下に実際の音源フォルダーを入れておく必要がある（ここではMusicFiles、これはシンボリックリンクしたフォルダー名）。以下を普通にブラウザから叩けば画像が表示されるのでIISの設定と整合性が取れているか簡単にテスト可能。（アーチスト名、アルバム名にスペースが入っていないものでテストした方が良い）

「http://192.168.x.xxx:80/Music/MusicFiles/Fourplay/Heartfelt/Folder.jpg」　

なお、この方法は（当方のケースはWindowsサーバーであったが）基本的に音源をNASに置いている場合でも、Linuxに置いている場合でもHTTPサーバーで対応させるだけなので（設定方法は異なるが）同じ考え方で実現できると思う。


4way構成の設定備忘録（2019年4月25日更新）SONY SUP-T11暫定設定値