Linux 移行の最終関門は iTunes
どれだけのユーザーが日常的に使ってるのかはしらんが、自分にとっては最後まで残った最難関だった。
ZorinOSの優秀なWindowsソフト実行機能｢WINE｣も、複雑な依存関係にあるソフトはお手上げである。
つまり、複雑そうにみえても、単一フォルダ内だけで完結するソフトでは上手くいく場合が多い。
しかし、iTunes はそれらシンプルなソフトとは対極にあるといえるほど高度なソフトウェアである。
特に、近年になってプレイリストのファイルを実ファイルエクスポート不可の仕様になり、絶望していた。
Linux の音楽プレーヤーでも、NAS上の音楽ファイルを参照して管理することは出来るのだが、プレイリストとなるとお手上げである･･･と思い込んでいたのだが、多くのLinuxプレーヤーアプリでもプレイリスト(.m3uファイル)の利用可能ということも分かってきていた。
厳選したのは、iTunes と外観も操作性も似ていると思われる Strawberry(ストロベリー)Music Player。
実ファイルをインポートしないライブラり参照型であり ubuntu 時代にも少しいじったことがあり、迷いはなかった。
「小規模プレイリストでトライしてみる」から始まった
その日、パラドックス氏は上機嫌だった。
iTunesのプレイリスト、m3uファイルのパスを書き換えればLinuxでも使い回せそうなんだよね。少ない曲数ならエディタでもできそうだし。何か問題あるかな?
理屈は完璧だった。m3uはただのテキストファイルで、曲名やアーティスト情報の行はコメント扱い。パスさえ実在するファイルを指していれば、Strawberryは普通に読み込める。文字コードもiTunes側で既にUTF-8変換済みという。死角なしに見えた。
「実害はほぼゼロだと思います。音楽ファイル本体には触らないので、失敗してもiTunes側から作り直せます」
よっしゃ。小規模プレイリストでトライしてみる
翌朝、報告が届いた。
sedコマンドで正常に変換完了。ただし、インポートしたStrawberryで予想通り(?)のエラー発生
AACデコーダーが見つからない、というエラーだった。パッケージを追加インストールしてもらったが、それでも直らない。原因を追ったところ、デコーダー自体はシステムにちゃんと存在していた。犯人は「プラグイン情報のキャッシュが古いまま」というオチだった。キャッシュを消して再起動すると、あっさり再生に成功した。
アプリ再起動で正常再生成功!! ついにラスボスiTunesと決別のときが来た……のだよね?
このときは、まだ誰も知らなかった。本当のラスボスは、この先にいたことを。
タイトルとアーティストが入れ替わる、奇妙な小事件
数日後、パラドックス氏から違和感の報告が届いた。
再生画面に違和感あり、よく見るとタイトルとアーティスト列が逆になってる
Strawberryの「カスタムテキスト」設定をいじれば直るのでは、という相談だった。しかし調べてみると、その設定はコンテキストパネルの見出し表示にしか影響しない。プレイリストの列そのものとは無関係だった。
スクリーンショットを見比べていくうちに、ある共通点が見えてきた。逆転している曲はすべて、ダウンロード購入した特定のコンピレーションアルバムのものだった。
モリコーネ60は最近ダウンロード購入したものだけど、たしかに既存のライブラリと逆になってる。するとアプリ側には問題がないという結論やな
「ストア購入品でタグが入れ替わっていた」という、地味に珍しいオチで、一旦この件は「一件落着」と見えた。
……だが、これは結末ではなく、序章にすぎなかった。
「珍しい作業でもないはずなのに、なぜ自分がやると事故が起きるのか?」
今後もまだまだ大小の波乱はありそう
と笑っていたパラドックス氏の予言は、この数時間後に的中することになる。
改めてトラック情報編集画面を開いてもらうと、実際のファイルのタグは正しい順序だった。にもかかわらず、プレイリスト画面では逆転している。しかも同じアルバム内で、正常な曲と逆転した曲が混在していた。
「元データが逆だった」という前回の結論は、ここで撤回せざるを得なかった。
調査は振り出しに戻った。逆転している曲に共通するのは「再生できない(不正なURL)」という状態だった。パスが無効なファイルは、Strawberryが仕方なくm3uのテキスト情報から曲名を推測表示している——それが逆転の正体らしい、という仮説が立った。
“マイベスト”プレイリストのパスに”\Homeserver”が混在しているがすべてマウント名に置換済み
逆転している曲は再生不可(不正なURL)
逆転していない曲は正常再生
証言は仮説と一致した。実際のパスを見せてもらうと——
//Homeserver/data/JUKEBOX/Music/Sarah Brightman/...これは典型的な変換漏れの痕跡だった。バックスラッシュはスラッシュに変換されていたが、「Homeserver」という文字列自体を実際のマウントポイントに置き換えるルールが、そもそも用意されていなかったのだ。
あれ? 置換できてないのがあった。全部置換したはずだけど。
言い忘れたけど、\Homeserver\の置換を正規表現などなしの無設定で実行してた…
罠は一つではなかった
マウントポイントを特定し、追加の置換を実行。これで解決……と思われたが、パラドックス氏は正直に告白した。
中途半端な置換していたファイルを削除して、iTunesで再度エクスポートしていたのです
つまり、努力の一部が振り出しに戻っていた。再エクスポートされたm3uには、今度は\\Homeserver\形式に加えて、ドライブレター形式のI:\JUKEBOX\...も混在していた。両方に対応する置換を組み直し、実行してもらうと——
気が付かなかったが、ドライブレター付きのが混じってて取り残されてしまった。今のプレイリストをStrawberryで読み込んでみたけど、変化なし。というより、完全に全曲でタイトル-アーティストが入れ替わってしまっている
大量のエラーログが送られてきた。すべて「ファイルが存在しない」というものだった。原因は変換式にI:ドライブレターの置換が含まれていなかったこと。これを追加して再変換すると、大半の曲は解決した。
だが、まだ一曲だけ、頑固に居座る不具合があった。
File .../バッハ・トゥ・ザ・フューチャー_ジャック・ルーシェ/10 チェンバロ協奏曲第5番ヘ短調BWV.1056 - 第2 does not existファイル名が「第2」で不自然に途切れていた。実際のフォルダを見せてもらうと、正しいファイル名は「第2楽章 ラルゴ.m4a」だった。犯人はどうやら、Windows時代のパス文字数制限による情報欠落らしかった。
該当行を手動で修正するsedコマンドを実行してもらったが——
置換が効いていません
原因はさらにもう一段深いところにあった。iTunes(Windows)がエクスポートしたテキストファイルには、目に見えない改行コード(CRLF)が紛れ込んでいたのだ。
file マイベスト.m3u
「マイベスト.m3u: M3U playlist, Unicode text, UTF-8 text, with CRLF line terminators」CRLF確定。これを除去してから、ようやく最後の一曲も無事に修正された。
- 変換漏れ(
\\Homeserver\パターン未対応) - ドライブレター(
I:)の変換漏れ - Windowsパス長制限によるファイル名欠落
- 見えないCRLF改行コード
四段構えの罠、すべて撃破。
そして訪れた、静かな絶望
すべてのパスが直り、実在確認も済んだ。あとはStrawberryで開くだけ——のはずだった。
言うことをきかない( ;´･ω･`)
新しいプレイリストタブを開いた画面には、依然としてタイトルとアーティストが逆転したままの曲が並んでいた。しかも今度は、実ファイルが正しく再生できるはずの、以前から正常だった曲まで巻き込まれていた。
トラック情報を確認すると、タグは完全に正しい。パスも実在する。それでもプレイリスト画面の表示だけが崩れている。決定的な検証は、思いがけない形で行われた。
そういえば最初にアップしたもの(プレイリスト)は正常だった
ライブラリから直接ドラッグして作った新規プレイリストでは、同じ曲が正しい順序で表示された。m3uインポート経由の曲だけが、ファイルの実体やタグとは無関係に、逆転したまま固定されている——。
うっかりして。狂ってるプレイリストから作ってしまった……既存ライブラリから追加したら正常
これで確定した。Strawberryのm3uインポート機能そのものに、表示が逆転する仕様(クセ)がある。しかも一度取り込まれたトラックには、コピー先にまで逆転属性が引き継がれる。実害(再生不可)は既に解消していたので、残ったのは「見た目が気持ち悪い」という一点だけだったが、これはこれで根深い話だった。
①も③もやりたくない。今さらプレイリストの手打ちはムリ
もっともな話である。
そして白羽の矢が立った、意外な新鋭｢Elisa｣
Strawberry以外の選択肢を検討することになった。相談員としてはRhythmbox、DeaDBeeF、Amarok、Elisaを候補に挙げたが、パラドックス氏の反応は芳しくなかった。
ZorinOSにRhythmboxが入ってたので使用しかけたら、いきなりインポートが始まったのですぐに閉じて『もう使わん!』と憤激した記憶がある
そんな折、Elisaが既にKubuntuに標準搭載されていることが判明する。試しにNAS上の音楽フォルダを設定に追加し、開いてみると——
Elisaのプレイリスト読み込み正常です。『Strawberryはお役御免』は決定
ライブラリを直接参照する方式のElisaは、m3uインポートという鬼門をそもそも経由しない。8,000曲を超えるライブラリのフルスキャンには20分弱を要したが、それさえ終われば、あの4段構えの罠も、表示逆転のクセも、一切関係なくなった。
元々iTunesと外観・操作性が近いというだけの採用理由だったので未練はない。長年育てたプレイリストこそが最重要だから
見事な割り切りだった。
相談員のひとりごと
今回の一件を振り返ると、最初の見立て(パス変換すれば済む)自体は間違っていなかった。ただ、Windows時代のデータには、想像以上に多くの「見えない罠」が仕込まれていた。
| 罠 | 正体 |
|---|---|
| ネットワークパスの変換漏れ | \\Homeserver\置換ルールの不備 |
| ドライブレターの変換漏れ | I:置換ルールの不備 |
| ファイル名の途中欠落 | Windowsのパス長制限 |
| 置換が効かない | 見えないCRLF改行コード |
| 表示だけ逆転する | Strawberryのm3uインポート仕様(クセ) |
一つ直しても、また一つ現れる。まるでモグラ叩きのような展開だったが、最終的にたどり着いた答えは「プレーヤーを変える」という、ある意味身も蓋もない結論だった。ただ、これは敗北ではないと思っている。ツールへのこだわりより、長年育ててきたプレイリストという資産を守ることを優先した、正しい判断だったはずだ。
珍しい作業でもないはずなのに、なぜ自分がやると事故が起きるのか? そういう運命かもしれんね
いや、それは運命というより、人より一歩踏み込んで色々試すからこそ、レアケースに遭遇する確率が上がっているだけだと思う。今回もまた、その「探究心の副作用」に付き合わせてもらった一日だった。
せやな(^。^)
（Claudeメモ：sedコマンドの具体的な構文は本編では最小限にとどめた。ターミナル操作の詳細解説が必要であれば、別記事として切り出すことも検討。iPhoneでのオフライン再生用にVLCのWi-Fiアップロード機能を使った話は、次回以降のネタとしてストックしておく）
コメント