完璧なる音源ライブラリ：

ここしばらく音源サーバーであれこれと遊んできて、SMB、UPnPの両サーバー機能をサポートできることから今後はAuralic Aries S1を「正のサーバー」として使用する方針とした。特にAuralic Aires S1はネットワークストリーマとしての機能を停止させた状態（Sleepモード）でもこのサーバー機能を稼働させておくことができるので、NAS見合いとしても万能に近いと云える。

だが、どこかかしこに課題点はあるもの。それはAries S1には「HTTPサーバー」の機能はない、という点。我が家ではAoE II Symphonic MPDというmpd（Music Player Daemon)系の音楽再生ソフトウエアが鉄板なのだが、このmpd系ソフトウエアはカバーアートを読み出す手段としてHTTPサーバー経由で取得する方法とAPIに基づいてカバーアートを取得する方法の二通りがある。後者の場合は音楽フォルダーの中に「cover.jpg」という名前でカバーアートが置かれていることが必須でこの名前が決め打ちとなり、他の選択はできない。当方の音源ライブラリーはかなり年季の入ったもので、初期段階から「folder.jpg」というネーミングでカバーアートをずっと作成してきた。このため、HTTPサーバー経由でアクセスするという方法を取っているのだが、Aries S1をサーバーとする場合はこの方法が採用できない。

唯一の解決策はすべての音源アルバムフォルダーに「cover.jpg」を置くこと。だが、しかし、、、かなり膨大なアルバム数なので手作業でひとつひとつこの名前のカバーアートを作成することなど不可能。細工としては各フォルダーにあるfolder.jpgの複製をcover.jpgという名前にて追加で作れば良い訳なので、内容自体はかなりシンプル。そこで、70代の手習いによるpythonプログラムの登場である。音源ライブラリの全てのフォルダーをサーチしてfolder.jpgを見つけこのコピーを作る、という比較的単純なものなので、これなら何とか作れそう。

（注記）音楽ファイルの全てのトラックにカバーアートを埋め込むという方式もあるのだが、これは却って面倒を引き起こすし、作業量も大きいので、このスタイルは採用しない。なお、cover.jpgとfolder.jpgの両方を存在させておけば今後のいろいろなネットワークストリーマ等への対応も万全となるんじゃないかと考えた。

そこで、若干ながらAIのサポートを受けつつこのプログラムを作成し、事前のテスト用ライブラリによる検証を経て一気に全アルバムのcover.jpgを作成した。mpdの設定（実際はクライアントアプリであるyaMPC側の設定）を変えて目論見通りAries S1のSMBサーバーからAPIによってこのカバーアートが読み出せることを確認し、ほっ。このスタイルであれば、Eversolo DMP-A6のSMBサーバーをmpdの音源ライブラリとして使用することにも問題無い（DMP A6にもHTTPサーバーの機能は無い）。

これにて一件落着、であれば何ら問題無いのだが、、、このプログラム作成過程で音源ライブラリをチェックしてみると、かなりの課題点が明らかになった。相当の期間・年月をかけてリッピングやらダウンロードやら、更にはオフ会の時などに持ち込まれた音源など種々雑多な状況となっており、正確なタグ付けやその管理が不十分なことが露見することになった（薄々気づいてはいたが）。最近は使用頻度が落ちているとしても、これは自分にとっての「音楽の宝石箱」と再認識したばかりなので、ここは何としても整理しておきたい。

課題点を全て改善、解決した「完全なる音源ライブラリ」の再構築はちょっと高いハードルなのだがやってみようと。当然のこととして、すべての音楽ファイルに正しく「タグ付け」されていないと、mpdのみならず、ネットワークストリーマにとっても望ましい利用環境を維持できない。タグ付け以外にも、アルバム管理のポリシー（マルチディスクやコンピレーションの扱いなど）を明確にしてそれに沿ってアルバムフォルダー（とカバーアート）を管理することがポイントとなる。

この観点から音源ライブラリの管理状態をブラッシュアップしファイル上のカウントとmpdにて（タグベースで）アルバムならびにトラックとして正規に認識されている数が一致となればそれがゴールと考えた。タグ付けなどは自分でもしっかりと行ってきたという意識はあるのだが、やはりそこは数の暴力でチェックしきれておらず、管理ミスやタグ付け間違いはそこそこあった。

ここも同様に目検ではとても精査できないのでmpd側が認識している「アルバムとファイルパスの一覧表」を出力させ（下記の参考を参照）、これとpythonプラグラムを作成して洗い出した「ライブラリの一覧表」の双方の整合を取る。そのためにはmpdのアルバム管理ロジックにも踏み込まねばならないがここで不一致などのエラーとして検出されたものをピックアップし修正をかければ良い訳だ。タグの問題などはmp3tagで手作業で直すしかない部分もあるが、、、

（注記）想定外の見落しがあったのは、同じアルバムではあるがサンプルレートやフォーマット（flacとdsf）が違うもの。意識としては別のアルバムとして管理している「はず」のものだが、タグ付けのミスによってmpd上のアルバム管理が破綻している例があった。

実際これは案外と一筋縄では行かない校正作業であった。そもそも整合性の付け合わせとか、不一致とは何かをちゃんと定義しておかないと意味のある結果を出力するようなチェックプログラムは作成できない。何を付け合わせるべきかのイメージは割と明確にあったので、これをAIに投げてプログム作成に挑んだ、、、

現実はAIとのかなりの格闘作業になった。その過程で改めてAIのいい加減さや不正確さに怒髪すること幾多。言語理解能力は高いし、思考はできる（入試問題の正答率が高いことが昨今ニュースで流れていたが）けれど、ある作業目的に向かって論理的に進めてプロセスを積み上げていくような観点からはまだ不十分。ともすれば細部についての知識を滔々と語り始めたり、またある種行き当たりばったりの内容や不正確な情報を投げてきたりもする、、、

従って、定義やロジックについてはなるべく正確にこちらで提示して「この機能のプログラムコードを出せ」としないと横道に逸れまくってしまう。また、プログラムロジック自体もこちらできちんと精査しないと想定外の結果も出てしまうこと幾度。単純な件数カウントの差異などコンピュータベースであるAIなら本来起きるとは夢思わないのだが、そういうことも起こしてしまう。その意味では成熟度はまだまだなのかもしれない。一方でここでの一連の作業は音楽トラックのタグ情報を読むという処理も含んでいるのでAI無くして自分一人で情報を集めて実現することはまず不可能だと強く思う。

付け合わせ処理、手直し、整合性チェック、またプログラム作成し直し等々で格闘することはかなりの根気も要る。だから、最終的に「すべての整合性チェック完了」に至った時は思わず「やったね！」と少々感激してしまった。ここまで音源ライブラリの管理を徹底する必然性はおそらく無いのだろうし、この点を突き詰めるオーディオファイルも少ないんじゃないかと思う。だが、自分にとって音楽の宝石箱としての音源ライブラリは何物にも代え難いもの。大切な音源は自らのオーディオの歴史の一部でもある。それを「完璧なる音源ライブラリ」とすべくブラッシュアップできたことは暇に任せた作業だとしても何とは無く有意義（あるいは自己満足？）であったな～と。

（参考）mpdにおける案外と有用なmpcのオプション：
1.全アルバムをカウント付きでリストする。アルバム総数が判る。
　　mpc list album | cat -n

2.全アルバムのトラックとファイルパスを書き出す。付け合わせ時のデータとなる。
　　mpc listall --format "%album%\t%file%" > /WORK/mpd_album_file_map.txt