Archive for the ‘gmusicbrowser’ Category

プログラムの「詰め」というのは、とにかく手間と時間が掛かる。大体、中心となる部分を作るのの10倍以上の時間が掛かるのではないだろうか。プログラムを使い物にするにはどうしても必要な作業のだが、退屈だし疲れるので、余り好きではない。それでも、なかなかうまく行かなかったことを打開するような、ちょっとしたアイデアがひらめくことがあって、それが本当にうまく行った時は楽しい。だから、いじりだすとなかなか止められない。仕事と違って、納期も予算もないのが困るw

一方、世の中には、すごいアイデアを思い付いたら、素早く目を引くデモ的な物(ポップ音楽だったら、サビとかデモ版)を作って、有名になったりお金をせしめたりしたら手放して(どこかに売って)、トンズラする(あるいは、別の物を作り出す)、スマートな人が結構居るようだが、無責任で嫌いだ。確かに、いいアイデアを出せるのはすごいと思うが、「最初にちょろっと書くのは誰だって楽しいんだよ!」とか「もう少し面倒見ろよ」と言いたくなる。

という訳で、日々続けているGPMDP (Google Play Music Desktop Player)の改良(もはや改造と言った方がいいだろう)は大分いい感じになってきた。まだ詰め切れていない点や不具合や抜本的な改良案もあるのだが、おおよそ7.5割くらいの出来になって、普通に(これには「変わったことはしてはいけない」という意味もあるw)音楽を聴けるレベルになった。具体的には、GMBだけで聴いている時と使い勝手での違和感がほとんどなくなった。例えば、GMBのリモコンで操作できるので本当に便利だ。実際に、昨夜からは、(実装・修正するだけじゃなくて)GPMの曲を聴くのに使っている。

問題だったユースケース(GPMDPをどういうふうにGMBと統合・機能分担して使うか)も、作業しているうちに大分詰められた。基本的には、GPMDPは曲の検索に使い、GPMDPの再生ボタンを押したら、実際の再生や再生の操作はGMBで行おうと思っている。まだ完全にシームレスになったとは言えないが、なかなかうまく統合できたと思う。

今週はさまざまな改良や修正をしたのだが、主にGPMDPとGMB (gmusicbrowser)との連携動作(例: 曲の追加や変更の同期)に関するものなので、見た目では、先週と比べて目立った違いは余りない。大きな違いは、(実際に曲を再生している)GMBで次の曲に移ったことがGPMDPにも伝わって、曲情報やジャケット画像が更新されることだ。以下にデモ動画を置くので、興味のある方はご覧頂きたい。

画面左半分はGMBの、右半分はGPMDPのウインドウである。GMBで再生中の曲が次に変わると、少ししてから(その次の曲の取得と処理の時間: これは如何ともし難い)GMBにその次の曲が追加され(画面左下、5曲目)、GPMDPの曲情報やジャケット画像(画面右中央)が更新される。

下の動画は、力技でやっているうえに、まだバグがあって、(いつ何が起こるか分からず、)ドキドキする機能なのだが、GMB(画面左下)でリスト中の前の曲をダブルクリックして移動した場合でも、GPMDP(画面右中央)も戻るようになっている(戻るのが遅いのは愛嬌w)。もちろん、取得されている範囲で、先の曲に進むこともできる。

リストの最後(7曲目)に2曲目の曲が追加されるのはバグである。難しい。。。

冷静に考えれば、再生中の曲のGPMDPへの同期なんて、音楽を聴くには不要な機能で、本当に飾りなのだが、「おもしろそうで、不可能でないならやってみたい」という、技術者の無駄なこだわりがあって実装したw

(10/1 6:38 わずかに修正)

 

PS. プレーヤーにGMBを使ったのは正解だった。最初は単純な再生だけを考えていたので、alsaplayerなどの軽いものにしようかと思っていたのだが、機能的に不十分な点があったので、最初からGMBで試した。また、GMBはコマンドラインにPerlのプログラムを指定して実行できるという、夢(麻薬)のような機能があり、それでGMBの内部データにアクセスできるので、かなり役に立っている。もう開発は停まっているようだが、セキュリティホールになるので、公開版に入れ続けるのは難しいかも知れない。

PS2. かなりハードルが高いのだが、将来的には、GPMDPじゃなくて、ブラウザのGPMのページから直接GMBと連携できないかと思っている。GPMDPが必要なのではなく、GPMのページ内の要素にアクセスするために使っているだけなので、ブラウザのアドオンか何かでできるのではないだろうか。

同時に、可能な限り機能を外部に出して、JavaScriptの部分を減らして開発効率を向上させ、GPMのページ構成になるべく依存しないようにもしたい。

とは言え、本当にやりたいのは音楽を聴くことなので、苦労してそこまでやることもないかとも思っている。

(10/1 17:44追記) と書きつつも、(だるくてドライブを止めたため、)暇だったので、ちょっとだけ試してみた。一番最初に気になった、GPMのページ中の再生ボタンを押したらGMBに曲を送れるようにする時に必要な、ボタンのイベントハンドラを変更できるかを試した。

最初は、安直に、ローカルのHTMLでiframeでGPMのトップページを読み込んで、JavaScriptで書き換えればできるだろうと思ったのだが、駄目だった。それから、いくつかのライブラリやAJAXやjQueryまで試したが、駄目だった。

どうも、セキュリティ上の制限のようで、ローカルのファイルからGPMのサイトを呼び出すのが駄目なようだ(おそらく、元がローカルファイルじゃなくても、サイトをまたがるようなことが駄目なのだろう)。それを回避したかったのだが、できなかった。この制限は「同一生成元ポリシー」というものらしく、かなり昔からあるようだ。

それで、一旦、ローカルのHTMLを使うのは諦めて、(GPMDPを改造して使う前提で、)GPMのページ中の再生ボタンのイベントハンドラを変更できるかを試した。JavaScriptには疎いので、それすらも苦労したが、できた。getElementById()で再生ボタンの要素を探して、onclickメンバにハンドラを設定すれば良い。以下のようにすると、GPMの再生ボタンを押すと関数click_func()が呼ばれる。

var elem= document.getElementById("buttonContent");
elem.onclick= click_func;

function click_func() {...}

onclick(onClick)は属性ではないとのことで、setAttribute()で設定しても呼ばれないことに気付かず、苦労した。あと、ボタンの本来のハンドラが依然として有効(どうやっているのか不明)なのがちょっと気に入らないが、まあ、細かいことだ。

(10/2 7:08追記) その後、GPMの再生につながるボタンは山ほどあるので、それらを全部書き換えるのは現実的でないことに気付いた。それらの呼び先を修正するのも困難なので、やっぱり、低レベルなところはGPMDP(実際には、その下位のライブラリ)に依存するのがよさそうだ・・・

  •   0
  •   1

GPMDPの改良。音量の正規化の改良について考えていたら、確か、以下のようなことだったと思うが、GPMDPでなく、外部プレーヤーで再生した方がいいのではないかということになった。

  • GPMDPの構造上避けられない、曲の開始と同時に一時停止しても先頭が一瞬再生されることがある問題は、外部プレーヤーを使わないと解決できない。
  • 再生ゲインの計算のために曲のファイルをキャッシュしているのだから、そのファイルをVLCやgmusicbrowser (GMB)などの外部のプレーヤーで再生することができる。
  • 再生ゲイン対応のプレーヤーなら、音量(ボリューム)の設定やファイルにを再生ゲインを乗算しなくても、再生ゲインタグに設定するだけで、プレーヤーによって反映されるのも良さそう。
  • GPMDPは使い勝手がいいとは言えないし、リモコンを2個にしたり、2つのプレーヤー間の切り替えもしたくないので、操作性を改善する点でもGMBで再生したい。

いずれにしても、昨夜までに構想が練り上がった気がしたし、基本的なところは容易にできそうだったので、今朝、GPMの曲をGPMDPでなく外部プレーヤーで再生できるようにしようとする作業を初めてしまった。そして、確かに、再生できるようにすること自体は簡単だった。14時前には、GMBで再生できるようになった。

GPMの曲をGMBで再生

図の左上はGMBのミニプレーヤーで、右はGPMDPのウインドウである。GPMDPが再生しているように見えるGPMの曲は、実際にはGMBで再生されている。その証拠に、双方で同じ曲・アルバムになっているし、僕はこのアルバムは持っていないし、GPMDPの再生時間は0だが、GPMは0ではない。

が、やっぱり難航し、この時間になっても終わっていない。残っている難しいことは、以下である。

  • 次に再生する曲を途切れないようにGMBに送り続ける(今は、最初の1曲の再生が終わったら停まってしまう)。また、ギャップレス再生のためには、再生中の曲が終わる前に送る必要がある。
  • GMBとGPMDPの連携 (例: GMBの再生が終わったことを検出して、次の曲を再生開始する)
  • GMBとGPMDPの操作の統合 (例:GPMDPで一時停止したら、GMBを一時停止させる)。GMBに統一すればいいのだが、曲の検索など、どうしてもGPMDPでしかできないことがある。まだ、ユースケースの検討が充分でないので、方針が固まっていないせいもある。

でも、今日のところは、目論見どおりGMBで再生できたので、良しとする。

(気が向いたら、詳細を追記します。)

(9/24 21:35追記) どうにかこうにか、次に再生する曲をGMBに送り続けられるようになった。GMBも自分で作ったGPMDPの追加プログラムも、想定外の動きをしたりして、なかなか大変だった(おもしろかったけどw)。

GPMの次の曲を自動でGMBに追加

図の左はGMBのウインドウで、右はGPMDPのウインドウである。GPMDPのプレイリストの、現在再生中の次の曲がGMBに自動的に追加され、連続再生できるようになった。

余談: 上のジャケットの工藤静香、なんかお化けみたいだ。。。

動き出したばかりで、まだまだ荒削りで、さまざまな不具合はあるが、とりあえずは音楽が聴ける状態になったので、一段落だ。それに、(GMBの)リモコンで一時停止などの操作ができるのは、すごく便利だ。

不具合の例:

再生していると、再生中の次の曲以降も勝手にGMBに追加される。まあ、悪いことではないが、想定外の動作なので複雑な心境だ。そして、それに伴ってGPMDPの下部のプレーヤー部分は、まだ再生していない曲になってしまう。しかも、それは上側のキューの再生中(と思っている)曲とも違うのが解せない。

  • 再生中の曲: "Here comes the Sun"
  • GPMDPが再生中(と思っている)曲: "Let it be"(上部)、「二人静」(下部)

細かいことが多いので、先は長そうだw

PS. 今日からか、URLに"?hl=en"を付けても無視するようになったようで、日本語で表示されるようになってしまった。やっぱり、ネットサービスはvolatileだなあ。 ← URLの書き方を間違えていたようだったので、撤回する。 (9/25 20:26)

(9/25 22:56 わずかに修正、余談を追加)

  •   0
  •   1

先週末に、gmusicbrowser (GMB)に、デスクトップウィジェットのアルバムアートを押すと、メインウインドウをアイコンにしたり戻したりする機能を付けた。GMBは、メインウインドウを閉じた時に、タスクトレイに最小化(アイコンにする)できるのだが、タスクトレイアイコンが小さくて押しにくいので、もっと楽に操作したかったのだ。

実装は意外に難航した。普通に最小化したのでなく、タスクトレイに最小化したのを復帰させると、その前より幅が広くなるという問題が解決できなかった。それで、普通に最小化した時にしか復帰できないようにした。

そして、今朝気付いた。実際には、GMBをタスクトレイに最小化しない設定にして(その時は間違って閉じないように注意する必要がある)、普通のアイコン(小さくない)で操作すれば充分だし、その方が操作が一貫している。あるいは、メインウインドウを閉じた時に、タスクトレイでなく普通に最小化するように変更するほうが、ずっと簡単だったような気がする。それに、今気付いたが、この機能では、アルバムアートがない場合は操作できないという欠点がある。

本当の問題は、「タスクトレイアイコンが小さくて押しにくい」というだけのことだったのだから、何か押しやすいものがあれば良かった訳で、それは(既にある)普通のアイコンそのものなので、苦労して新しい機能を作らなくても良かったのだ。

まあ、折角作ったのだから戻さないでおこう。そして、後で、幅が広くなる問題を解決したい。これは、GMBの起動時にも起こることがあるので、何かがおかしいようだ。

そして、物でもソフトでもシステムでも世の中の仕組みでも、安易にいろいろな機能や施策を追加しがちだが、その前に、本当の問題をもっと良く考えた方が、複雑にならず、コストも掛からず、新たな問題も生まれないのだろうと思う。とは言え、安易に見えるけど、実際には、多くの「頭のいい」人たちがいろいろ考えた末におかしくなってしまうことも多々あるので、なかなか難しい。

PS. 世の中の仕組みなどは、実際には、「いろいろ考える」方向が意図的に異なっていて、本当の問題は分かっているけど、根本から解決する気は毛頭なく、「頭のいい」人たちの都合のいいように「解決しようとしている振り」をするように見せて、みんなを欺いていることが多い気がする。

PS2. 本題のGMBだが、昨夜、メインウインドウの閉じるボタンを押した時に、タスクトレイでなくアイコンに最小化することができるように変更した。また、閉じた時の動作設定に、従来の動作(閉じた時にタスクトレイに最小化または終了)に加えて、アイコンに最小化する動作も追加して選択できるようにした。これで、間違って閉じるを押して終了することもないし、ウィジェットでもアイコンでも押せば復帰できるから、操作も統一できた。(1/25 4:47)

設定ウインドウの追加した部分

  •   0
  •   1

GMBでアルバムアートの検索をするプラグインPicture finderは、USのYahoo!でしか動かない。Googleなどを選択しても、結果が何も出ない。

APIが変わったのだろうと思ったが、実際に調べたら、確かにGoogleの検索結果のフォーマットは変わっていた。それで、とりあえず、Googleで検索できるようにした。

新しいフォーマット(構造化されたデータのようだ)に合わせて、fetch_cover.pmを修正した。まだまだPerlは良く分からない(し、分かりたくもない)が、既存のソースから類推してやってみたら、出来た。参考までに、主要な変更点を載せようと思ったのだが、良く考えると、日本のユーザーはとても少ないだろうし、分かる方は既にやっているだろうから、止める(もし欲しい方がいらっしゃいましたら、お知らせ下さい。無保証にて差し上げます)。

日本のYahoo!にも対応したかったが、面倒だし、中で使っているのはGoogleなので、止めた。他のサイト(例: last.fmやAmazon)にも対応したかったが、やっぱり面倒なので、とりあえず、Googleだけで満足することにする。

ただ、そのGoogleにしたって、彼らの心変わりによって、いつか変更が要るようになるのだろうな。でも、出力がHTMLである限りは大丈夫だ。でも、それもそのうち変わる気がする。。。

  •   0
  •   0

 

この週末は、デジカメからの画像取り込みプログラムの改良(同一カメラで1万枚以上への対応)や掃除や散歩やドライブなど、有意義なことをしようと思っていた。

のであるが、実際には、したかったことは何もできなった。

昨日は、疲れのせいかだるかったので、家にこもってEvernoteからDropbox Paperへの移行をした程度だ。移行は、本文はコピー・ペーストでできるのだが、埋め込んだ画像はできないので、それを手作業で復元する(元のファイルがPCに残っているのはそのまま、オリジナルがあるものはリサイズして、Paperに埋め込む。ないものは、EvernoteからダウンロードしてリサイズしてPaperに埋め込む)必要があって、結構時間が掛かった。日記1個に30分くらい掛かった。全部で7本を移行して、日記の残っていた分は終わった。が、あとドライブ関係が44本もあるので、移行プログラムを作りたくなって来た。

今朝は、「今日こそは」と思っていたのだが、思わぬ落とし穴にはまった。発端はgmusicbrowser(GMB)の、次のリストだ。

Something wrong!

何の変哲もない、普通の(と言うには重複が多いがw)ビートルズのアルバムの一覧の一部に見えるが、常々感じていた不満(何が悪いかすぐに気付いた方は、ちょっとした愛好家ですね)を思い出して、余計なことを考え付いてしまった。

同じ年に出たアルバムをちゃんと発売順にできないものだろうか?

説明すると、上の図の上半分の黄色いのは"Magical mystery tour" (1967年11月発売)、下半分のごちゃごちゃしたのは"Sgt. Pepper's lonely hearts club band" (1967年6月発売)である。それぞれ同じ年に出たのではあるが、気に入らないことに、リストには発売の逆順に出ているのだ。タイトルがアルファベットの順だとM→Sなので、上のように並んでしまっているのだ。

まあ、「そんな細かいこと、自分で分かってればいいじゃん」とは思うし、今まで我慢して来たのだが、他の例では、デビューアルバムの前にセカンドアルバムが出ることもあった覚えがある。さすがにそれはどうかと思う。要は、元になったMP3の仕様(ID3)が安直で、現実に対応できていないのだ。それを見なかったことにして使い続けるのは、技術者としてはやっぱり嫌なのだ。

技術的な問題以外にも、仮に上のリストの順で「全曲再生」したら、曲順がおかしくて、それこそ話にならない。

ソートに使われる発売日の情報は音楽ファイルに格納されているのだが、基本的には年だけしか格納できない。せめて月まで入れられればいいのだが、仕様上は無理だ。

それで、いくつかの案を考えた(それだけで数時間掛かった気がする)。

  1. 余り使っていないフィールド(例: Mood(TMOO), Grouping(TIT1), Rating, Discname(TSST)など)を流用する。
  2. GMBにカスタムフィールド(例:リリース日(例: "19670601"), 同じ年の時の順番(例: 1, 2))を追加する。
  3. GMBにAlbum sort order(TSOA)フィールドを実装する。
  4. GMBに他のフィールド(例: Original release time(TDOR))を実装する。
  5. 新しい独自フィールドを実装する(TXXXを使う)。
  6. GMBに2個の追加フィールド(1: リリース日、2: リリース日があればリリース日、なければ年)と、後者のフィールド(2番)を使うソート条件を追加する。

検討したところ、最後の6が残り(正確には、1-5の検討の結果、6のように2段階にしないとうまく行かないことが分かった)、「ちょっと試しに」実装に着手してしまったのが運の尽きである。半分は意外にすんなりできて、下のように、「リリース日または年」のフィールドが表示できたのだが、例のリストのソート順に反映することができなくて、(昼寝もしたけど)気付いたら外は暗くなっていて、とてもがっかりした。

「リリース日または年」が出るようになった (年はアルバム名の右の<<の右にも表示されている。上のエントリのアルバム名とリリース日は、テスト用の架空のもの)

随分時間を掛けてうまく行かない理由を調べたのだが、どこを直せばいいのか、まだ分からない。ソート時に、追加したフィールドをどうしても参照できない。この辺りのプログラムは、他と比べて今ひとつ直感的でなくて分かりにくく、GMBの暗部を見た気がした。まあ、何にでも触れて欲しくないことはあるだろうから、仕方ないね(僕のプログラムにだって、結構ある)。

試行錯誤の結果、何がどうなっているのは分からないが、どうにか、リリース日(なければ年)でアルバムをソートできるようになり、問題の"Magical-"が"Sgt. Pepper's-"の下に出るようになった。

リリース日でアルバムをソートできるようになった。

ところが、一難去ってまた一難。今度は、次のような、ちょっと困った状況に陥ってしまった。

"Baby it's you"はどこに置けば?

一番上の"Baby it's you"は、近年発売されたシングルなのだが、録音は1963年なので、入手した時に年に録音の年を入れた。これをどこに配置すべきなのか、結論が出ない。正しいリリース日にすると、初期の曲なのに最後の方に出るし、録音日にすればそれらしい場所に出るが、リリース日を入れるべき箇所に録音日を入れるのは掟破りな気がする。

規則に従ってリリース日を入れて、最後の方に出すのがまっとうなのだろうが、もっといい規則を決めたいところだ。「録音年」のフィールドを作ると、何かいいことがあるだろうか? (12/13 23:00)

"Baby it's you"の「リリース日」の解決策が見つかった。放送日をリリース日に入れることにした。ただ、シングルとして発売されたこの曲は、アルバム"Live at the BBC"に入っているのとはバージョンが違うので、調べても放送日が良く分からない。ただ、録音日は3日しかなく、そのうちアルバム版と同じ日に収録されたと推測できる。そして、もしかしたら放送されなかったのかも知れない。が、いくら考えても埒が明かないので、アルバム版の放送日とした。(12/15 5:09)

  •   0
  •   1

以前からやりたかったのだが、gmusicbrowser(GMB)のレイアウトと使い勝手を改良した。Perlで書かれたGMBのプログラムや、レイアウト設定ファイルを、見様見真似で試行錯誤して、なんとかした。主な変更点は以下のとおりである。

  • メインウインドウ (ベース= "Lists, Library & Context")
    • 現在の再生ゲインのモードを、"--"(off), "T"(トラック), "A"(アルバム)のように表示できるようにした。アイコンでも表示可能なのだが、適当な画像ファイルがなかったので、とりあえず文字にした。この部品は新たに作った。
    • 上記再生ゲインの表示を押すと、off → トラック→ アルバム → offのように順にモードが切り替わるようにした。
    • タイトルなどの文字やアルバムアートを大きくし、パーツの配置を改良した。
    • ボリュームを水平のスライダーにし、音量の値も表示するようにした。ボリュームは実際にはほとんど操作しないのだが、現在の音量が一目で分かるのはいい。
  • デスクトップウィジェット (ベース= "screenlet")
    • 再生位置のバーの右に、再生順序(シャフルなど)、フィルタ(自動プレイリスト)、キューの状態(次の曲の指定の有無、再生中の曲が終わったら停まるなど)、再生ゲインのモードを追加した。これは、メインウインドウに表示されているものと同じである。
    • 再生位置のバーの中に再生位置(時間)を表示するようにした。
    • タイトルなどの文字を大きくし、発表年も表示するようにした。
    • 文字領域の背景を不透明にした。

まだ収まりが悪いところや色がイマイチなところがあって、いろいろ直したいのだが、かなり僕の理想に近くなった。特に、デスクトップウィジェット(MusicBeeのコンパクト/ミニプレーヤーに相当)で再生ゲインのモードが表示・切り替えできるのは、MusicBeeではできなかった(要望しても対応してもらえなかった)ことで、長年の悲願だったから、結構嬉しい。

残念なのは、以下のことはすぐにはできないことだ。どれも、GMBの構造上、設定や小さい変更での対応は困難なようだ。

  • メインウインドウの曲一覧などのフォントが(設定では)変えられない。見難くはないから、とりあえずは問題ないのだが、中国(台湾?)系のフォントのようで、例えば、「福」の偏が「示」になったりしているのがちょっと気になる。
  • (特にデスクトップウィジェットで、)タイトルなどが長い場合に、複数行での表示ができない。

それでも、こうやってプログラムや設定を変えることでかなりのカスタマイズができるところは、完全にMusicBeeを超えている。特に、レイアウトの設定ファイルは独自の言語のようになっているのだが、もしそうでなかったら、こんなに自由なカスタマイズはできなかっただろう。その点は(最初は訳が分からなくて戸惑ったものの)感心している。それで、偶然にせよ、なかなかすごい「原石」を見つけたものだと自画自賛している。

あと、PerlでGUI(GTK)のプログラムが作れるのは、PHPにはできないことなので、すごく羨ましい。それにしても、どうしてPHPではできないのだろうか?

試行錯誤して、なんとか、デスクトップウィジェットでタイトルなどが長い場合に改行できるようにした。GMBがテキスト表示に使っている、GTKのLabelウィジェットのワードラップの機能を使うようにした。これには、設定だけでなくGMB本体の改造が必要だった。

アルバム画像下の曲情報は、以下のようにデスクトップウィジェットのレイアウトファイル(desktop.layout)に記述して表示している。

HBtrk_info= 8Text(font= 'Noto Sans CJK JP Regular 10',
color=black, opacity=1,

width-chars=32, wrap=1, wrap-mode=word,
markup="$title
<span size='xx-small'>\n\n</span>
$artist<span size='xx-small'>\n\n</span>
$album ($year)")

下線部で最大幅とワードラップを指定しているが、これをサポートする機能をGMBに追加した。GTKを良く理解せずに作っているので、最大幅はピクセル数で指定したいができておらず(そのため、文字数によって、右側に微妙に空白ができたり、ウインドウの幅が広がったりする)、文字の大きさや空行(無理に作っている)の高さなど、いろいろ改良・調整したい点はあるが、とりあえず、やりたいことができたので、うれしい。(11/9 23:53)

空行の高さは、タイトルなどの各項目を別のLabelにして、パディングを指定して縦に並べることで解決した。ただ、最後の要素(アルバム)にはパディングを指定しなくても隙間が空くのが謎だ。

また、右側の微妙な空白は、width-charsを指定しなければできないことが分かった。ただ、その場合、max-widthやmaxwidthを指定してもウインドウの幅が広がることがあるのが謎だ。(11/10 6:22)

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-10_06-03-57

行間を改良

HBtitle= 8Text0(font= 'Noto Sans CJK JP Regular 12', color=black, opacity=1, \
width-chars=32, wrap=1, wrap-mode=word, \
markup="$title")
:
VBmain = Cover(yalign=0, forceratio=1,hover_delay=1, \
hover_layout_pos=.5w x w,hover_layout=play_controls) \
8HBtb_ind HBtitle 4HBartist HBalbum

思わぬ欠点が見つかった。ウインドウのサイズが広がった後に、行数が少なくなると、下の方が空いて間抜けになってしまう。ちょっと調べたところでは、gtk_widget_set_redraw_on_allocate()で直りそうな感じだが、さてどうだろう? (11/10 19:46)

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-10_19-43-56

間抜けな状態

更に試行錯誤したのだが、なかなか広がったウインドウは小さくならない。そこで、次善の策として、アルバムアートと曲情報の部分で余白を吸収するようにしてみたら、今までよりはマシになった。また、どういう訳か、アルバムアートが段々大きくなることがあったので、サイズを厳密に指定した。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-10_22-02-22

余白が目立たないようにした。

HBcover= Cover(minsize=250, maxsize=250, forceratio=1, \
hover_delay=1,hover_layout_pos=.5w x w,\
hover_layout=play_controls)
:
VBmain = _HBcover 8HBtb_ind _VBtrk_info

こういう試行錯誤って、GMBやGTKやPerlをもっとちゃんと勉強すれば効率良くできるのだろうが、趣味なのでそこまでの気力は出ない(もし、PHPでGTKが使えるのなら、俄然やる気が出るのだがw)。逆に、いろいろつまずいたり、回り道・寄り道しながら自分の希望を叶えていくのがおもしろいと思う。そして、仕事じゃないから最短経路をとる必要はなく、こういう遊びがかえって仕事のヒントになることもあると思う。(11/10 22:17)

(Labelウィジェットのワードラップ機能が今ひとつのせいなのか、)改行時に文字列右側にできる無駄な空白が嫌なので、ちょっと頑張ってTextViewウィジェットを使えるようにして、解決した。

ただし、どういう訳かTextViewの背景色を設定することが難しいようなので、とりあえず全体を白にした。それでも、どういう訳か微妙に色が違っていた(TextViewがわずかに黒くなっていた)ので、それに全体を合わせた。が、それでもまだ合わないようだ。あと、上下に広がったウインドウが狭まらないのは相変わらずである。そこら辺は今後の課題としても、かなり良くなったのは確かだ。

あと、TextViewにしたことで、曲名などをマウスで選択してコピーすることができるようになった。これもMusicBeeで叶えてもらえなかった(「ホットキーでできるからいいでしょ」と言われた)ことなので、感慨深いものがある。

ただし、曲名とアーティストとアルバム名をそれぞれ別の要素にしているので、コピーも別々にしかできない。とある理由(TextViewの中では、フォントサイズを容易に変更できない)で別々にしたのだが、できれば何とかしたい。でもまあ、選択・コピーできないよりはずっといいだろう。

ちなみに、デスクトップウィジェットのレイアウトファイル(desktop.layout)でのTextViewの指定は、以下のようになる(タイトル表示の部分)。

HBtitle= 5TextView0(font= 'Noto Sans CJK JP Regular 12', \
color=black, bgcolor=lightgray, minwidth=200, maxwidth=250, \
wrap-mode=word, markup='%t')

(11/11 21:18)

ちょっと苦労したが、曲名とアーティストとアルバム名を同じTextViewに入れられた。insert_with_tags()を使い、TextViewの中でフォントサイズを指定するようにした。これをTextViewのサブクラス"SongInfoView"と名付け、以下のような指定で曲情報が出るようにした(フォント指定は未実装)。

HBsong_info2= 5SongInfoView(font= 'Noto Sans CJK JP Regular', \
color=black, bgcolor=lightgray, minwidth=200, maxwidth=250, \
wrap-mode=word)

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-11_23-15-12

全部の曲情報を一度で選択できるようにした。

まったく"The long and winding road"だが、いろいろアイデアが出て楽しい。(11/11 23:22)

選択はできるが、Ctrl-Cではコピーできないというオチがあった。右クリックでメニューを出して"Copy"を選択すれば可能なので、キーを登録すればいいのだろう。やっぱり長い道のりだw (11/11 23:51)

ショートカット(あるはアクセラレーション)は有効にならず、広がったウインドウは、どうしても縮まない。前者は、どうもOSレベルの設定が関係しているようだ。もちろん個人の設定ファイルもあるようだし、「デスクトップ環境」なのだから、その方が筋がとおっているのだが、アプリだけで手軽に対処するのが難しいし、ログインし直さないと試せないので面倒だ。そして、後者は深い謎だ。八方手を尽くしたが、どうにもならなかった。GTKをちゃんと勉強しないと駄目かも知れない。

そして、昨夜からの収穫は、(外見上は)本当に微妙な修正だ。タイトルなどを一度にコピーできるようにした時に、行間が数ピクセル広がってしまったのを直した。なんか、大昔、LaTeX(って知ってる方はいますか?)で資料を書いて、微妙なところを何度も直して(印刷して紙を無駄にして)、最後にできた紙(の内容でなく外見)を見て悦に入っていた頃の雰囲気を感じているのだが、なんとも複雑な気分だ。まあ、僕は賛同していないが、神は細部に宿るのかも知れないし、趣味だからいいよねw

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-12_17-39-53

行間を調整

そして、何度もくどいのだが、(謎はあるものの)こうやって自分でちょっとプログラムを書いて自分好みに自由に改造できるのは、ありがたいし楽しい。ただ音楽を聴けるだけじゃなくて、その道具に手が入れられるようになったのは、常に歯痒かったMusicBee/Windows時代に比べるとすごい進歩だし、結構感激している(酔ってるせいもあるが)。これは、GMBの基本思想が良く、オープンソースにしてくれて、今の実装が悪くない(Perl自体が読みにくく、コメントは少ないけど、まあ酷くはない)ことに加えて、スクリプト言語(Perl)/Linuxベースであることもある(やっぱり、腐り切った窓でC#なんて使ってられない)。そして、こういう機会を与えてくれた、gmusicbrowserの作者のQuentin Sculoには本当に感謝している。いつか、改良・変更部分を整理して提出したいと思っている。(11/12 18:28)

ここからはいつものディスになるのだが、僕がMusicBeeを止め(られ)た原因は、作者の(勝手な)方針について行けなかったということだ。作者本人が個人で作っているのだから、何をしたって自由なんだろうけど、ただ、他人の意見を余り聞かず、ソース公開せずに他人の力をほとんど借りようとせず、Windowsにべったり固執し、全く必要がなくメリットが感じられないことを「改良」して、バージョンアップしたと言って悦に入っているのは、MicrosoftやAppleのように筋が悪いし、もし彼がソフト技術者だったら、「終わっている」と思う(一言で言えば、ガキだ)。途中まではいい方向に進んでいたし、機能的には他を寄せ付けないのに、とても残念である。(11/12 18:42)

試行錯誤の結果、デスクトップウィジェットのサイズ(特に高さ)が行数に応じて縮まるようになった。ごく当たり前に、ウィジェットのresize()メソッドに小さ目のサイズを指定すれば縮んだ。以前にも試したのだが、ウィジェットのnewの中から呼んだのが失敗して、それでresizeは使えないと思い込んでいたのだ。どうも、newが終わらないとうまく動かないメソッドがあるようだ。もちろん、newの中でresizeなんてするのは良くないのだが、GTKやGMBでウィジェットのメソッドの呼び出し順序が良く分かっていないので、newの時に描画する文字列を設定することになって、結果的にresizeもしている。(11/14 22:31)

その後、ワードラップでの改行の高さが若干高く(広く)て下の要素との区切りと見分けが付きにくい場合があったので、微妙に改良した。更に、プレイリストやアルバム中の何曲目を再生しているかを、"3/10"のように表示できるようにした。(11/18 21:52)

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-18_21-48-21

微妙な改良

 

※まずいないとは思いますが、もし、日本語が読めてGMBを使っていて、「ここの投稿を参考に改造したいけど、詳細が書いてなくて今ひとつ分からない」という方がいらっしゃっいましたら、可能な範囲でお教えしますので、お知らせ下さい。でも、プログラミングのスキルがあることが前提です(申し訳ないですが、「コピペでなんとかしたい」という方は駄目です)。そして、そういう方は、自分でできてしまうような気がします。(11/10 19:31)

(11/11 10:14 わずかに修正, 11/12 追記)

  •   0
  •   1

先週、GMB(gmusicbrowser)の音楽ファイルの同期プログラム(sync-music)の高速化のアイデアがひらめいたものの、疲労や多忙ややる気がでなかったりで、なかなか実装できなかったのだが、昨日と今日で何とか作り込めた。途中では期待したほどの結果が出ず、がっかりしかけたのだが、その原因が分かって、最終的には期待以上の結果になった。

高速化の内容と効果

  1. 音楽ファイルのタグ情報を、GMBから同期プログラムに渡す。→ ファイルのタグ情報をsoxiやexiftoolなどの外部プログラムを使わずに取得できるので、その分高速になる。
    1. GMBでの同期開始時に、同期対象のファイルの同期に使うタグ(アーティスト、アルバム名、トラックの再生ゲイン、埋め込みアルバムアートの有無)の値をCSVに入れて、同期プログラムに渡す。
    2. 同期プログラムは(音楽ファイルを開かずに、)CSVの内容から、同期先ディレクトリ、音量調整量、アルバムアートの埋め込みの必要性を判断する。
  2. アルバムアートが埋め込まれているファイルには、アルバムアートを埋め込まない。→ アルバムアートを縮小して埋め込まなくて済むので、その分高速になる。

結果(ポップス全10677曲、非実行(エンコード・ファイルコピーを行わない)での同期= 全く更新がない場合を想定した所要時間):

  • オリジナル(V1): 93秒 (8.7ms/ファイル)
  • 高速化後(V2): 8秒 (0.75ms/ファイル)

先週の「今の数倍〜10倍高速になりそう!」の目論見を超えて、

約12倍速となった!

(ただし、非実行で速度を比較したので、上記2番の成果は反映されていない)

更新がない場合に8秒なら許せるし、MusicBeeと同じくらいの速度になったと思う。高速に動くプログレスバーは気分がいいものだ。

高速化ってのは、「血のにじむような」というと言い過ぎだが、まあ、堅く絞った雑巾から更に水滴を絞りだすようなところがある。実際、「これ以上は無理」と思えても、更に良くなることがあって、そこがおもしろいのだが、結構精魂を使い果たす傾向はあるw

V2のその他の機能の実装と動作確認と修正が終わり、さっそく車で使っているUSBメモリに同期しているのだが、そのメモリ(Lexar 128GB)が激遅で、エンコードしたファイルを書き込むのにものすごく時間が掛かって、並列処理も高速化も台無しというオチになった(爆) もしかしたら、メモリが壊れ掛けているのかも知れない。(11/5 16:24)

USBメモリへの同期は(11/6の)明け方に終わっていた。約11時間(3.8秒/ファイル)掛かった。(エンコード時に)PCのSSDに対して書き込む場合には約1秒/ファイルだったので、このメモリは約4倍遅かった。そして、実行ログを見たら思わぬ不具合が起きていた。同期したファイルの一部を削除していたのだ。バグかと思って調べても、なかなか原因が分からなかったのだが、結局はWindowsのファイルシステム(VFAT)の異様な仕様のせいであることが分かった。一つは、ファイル名の最後の"."を無視するのと、もう一つは、ファイル名の型(大文字/小文字)を無視するというものだ。以下に例を示す。

  • "The Journey Continues..."というディレクトリを作ると、実際には"The Journey Continues"ができる(最後の"..."がなくなる)。
  • "WINK MEMORIES"というディレクトリが既にある場合に"Wink Memories"というディレクトリを作ってもエラーにならないが、実際には既にある"WINK MEMORIES"に統合されてしまう。

前者は意味不明だし、後者はいまだにそんな古臭い仕様を残しているのに呆れて頭に来る(笑えるさすがなことに、高慢な意識高い林檎社のデスクトップOSも、Unixがベースなのにわざわざ型を無視していたっけ)。一般人は大文字と小文字の区別ができないとでも思っているのか? 今使っているのはLinuxだが、互換性維持のために、そういう下らない仕様も実現しているのだろう。

問題に対処して確認していたら、ドライブに出ようと思っていた時間(7:30頃)を過ぎてしまった。そして、疲れたので、今まで寝ていた。動作確認を兼ねて、午後には出掛けたいな。(11/6 11:45)

結局、GMBの改良(のための試行錯誤)をしているうちに億劫になって、ドライブには行かず仕舞いになったが、駐車場でエンジンを掛けて再生確認して、問題なかった。音もアルバムアートも出た。何となく音質が悪い気がしたが、ヘッドフォンで聴いた時には問題なかったので、疲れとか気のせいだろう。これでひとまず、音楽のWindows(MusicBee)からLinux(GMB)への移行は完了だ。あとは、おいおいGMBに細かい改良をして行こう。

でも、その前に、写真(画像)のLinuxへの移行(ACDSee → digiKam)を完了させたい。(11/6 17:33)

(11/5 18:21 加筆, 18:43 誤りを修正, 11/6 11:45 加筆, 12:58, 15:17 加筆修正, 17:33 車での確認結果他を追記)

 

PS. 途中で余り高速化できなかったのは、並列化処理の検討不足だった。並列化の時は、複数のファイルを同時にエンコードするのだが、同時に実行している数が最大値に達した場合に、更に処理を開始するには、どれかが終わるまで待つ必要がある。待つ時、一定の時間間隔でどれかが終了したかどうかを確認するのだが、その間隔が500msと長かったために、高速化が妨げられていた。

まあ、実際にはエンコード(数秒掛かる)するので、500msでも問題ないのだが、ファイル数が多くて更新がほとんどない場合にはかなり効いてくる。

PS2. こういうアイデアを入れて、最初に動かした時に結構うまく行くと、うれしくなる。「こいつ、動くぞ」と脳内に浮かぶかも知れないw

  •   0
  •   1

MusicBeeからgmusicbrowser(GMB)への移行は、かなり終わりに近く、もうMusicBeeは関係なくなって、GMBに閉じた話になっている。ただ、いつものことだが、ゴールは見えると遠ざかるもので、動作確認でいろいろな問題が出て来て、なかなか終わらない。予想外にも今日はほとんど全部使ってしまったのだが、あと少しでようやく本物のUSBメモリで試せそうな感じだ。以下に、つまづいたことを書く。

全体的な動作確認

ファイル名のクォート("や`や/などの特殊な文字を無効にする処理)がまだ不完全だった。これの対応はどうも場当たり的で良くないので、根本的に別の方法にした方がいい気がする。同期プログラムからOSのコマンドを呼ぶ(system()など)時に、ファイル名をシェルに解釈させないようにすれば、クォートしなくてもうまく行くように思うので、あとで何とかしたい。(が、そう思っていて実際にやったことは少ない・・・) → シェルに特殊文字を解釈させないようにする方法はないようなので、簡単には行かなそうだ。system()などを使わなければいいのだろうか? (23:28)

詳細な動作確認-エンコードしたファイルの確認

音量の正規化が全く駄目だった。再生ゲインはピーク値で決まっている訳ではないので、ファイルからピーク値のタグを抽出して、それで音量を調整しても駄目で、トラックの再生ゲインのタグの値で調整すべきだった。ffmpegにはタグに書かれたトラックの再生ゲインで音量を調整する機能がないので、soxiで(アーティスト名などのタグと同時に)トラックの再生ゲインのタグを抽出して、その値からffmpegに指定する音量の値を計算することにした(再生ゲインのタグがない場合は諦めるが、実際には、すべての手持ちファイルには再生ゲインのタグが入っている/入れるので、問題はない)。なお、exiftoolは処理が遅いので、基本的には使わないことにした(soxiで文字化けする場合は諦める)。

今、何となく、エンコードと音量の正規化にはffmpegでなくsoxを使った方がいい気がして来たので、あとで考えよう。soxが文字化けするのはMP3だけだろうから、その時だけ特別な処理をすれば良さそうだ。→ 残念ながら、soxはアルバムアートの埋め込みができないので、使えない。(23:25)

ポータブルHDDにポップス全曲(約1万曲)を同期して確認

処理が遅過ぎた。最初の同期では、1万曲をエンコードするのに約4時間掛かった。全部エンコードしたのだから仕方ないのだが、エンコードしない場合(更新ファイルの確認のみ)にも遅かった。1万曲で約1000秒(17分)掛かった。いろいろ調べたところ、上に書いたように、exiftoolが遅かった。それをsoxiに換えたところ、約10倍高速になった。ただし、soxiはMP3の再生ゲインタグを抽出できないので、その場合はexiftoolも使うことにした。

また、下に書いた、子プロセスの終了判定がうまく行かないために入れた処理も遅かったのだが、原因が分かったので省けた。現在は、(エンコードしない場合)1万曲で約100秒(1.7分)で済むようになった。これでもまだ遅い気がするので、あとで何とかしたい。

その他に、ファイル名のクォートの問題も再発したし、タグからアーティスト名を抽出する処理にバグがあったりもした。

それから、GUIのキャンセルの検出処理がうまく行かなかった。子プロセスの終了を判定する関数(pcntl_waitpid())が期待どおりに動かず、かなり手こずったのだが、結局は、それに渡すプロセスIDが異なっていたことが分かった。

なお、最初の同期(エンコード処理)時のシステム負荷なども調べたので、以下に書く。

  • CPU使用率: 約80% (同時処理数=5)
  • CPU温度: 約60℃
  • メモリ使用率: 約20%
  • GMBの音切れ: なし
  • 同期対象ファイル一覧のサイズ: 約1.5MB
  • 結果のログのサイズ: 3.7MB
  • ディスク使用量: 約55GB/約1万曲

使用率80%で動かし続けると、さすがにCPU温度が上がって、ファンが少しうるさくなる。でも、BIOSにファン回転数の調整機能があるようなので、安心だ。ファイル一覧のサイズは思ったより小さくて、同期プログラムなどは問題なく動作した。ただ、ログをエディタ(kate)にペーストしたらハングしてしまったのには、結構がっかりした。

その他の問題

  • キャンセル(処理の中止要求)の検出のためにzenityのプログレスの終了を待つつもりが、全部の子プロセスを待っていて、並列処理しているエンコードプロセスの終了でキャンセル処理してしまった。
  • [GMB] 再生中に再生ゲインがoffになることがあるようだ。メニューの表示と実際が合っていない。原因不明なので、追って調査する。
  • [GMB] 再生するだけでファイルが更新されて、同期対象になってしまう。プラグインalbuminfoが自動的にジャンルを更新しているので、一旦、albuminfoとartistinfoを使うのを止めた。あとで更に調査して修正したい。
  • [zenity] LANG=Cで起動して、日本語のディレクトリを選択すると、出力が"?????"になる。→ zenityは日本語(LANG=ja_JP.utf8)で起動することにした。
  • [zenity] プログレスのウインドウのサイズが大きくなる。原因不明。文字列(ファイル名)が長過ぎるからか。

今後

少し使ってみて、不要にファイルが更新されないことを確認してから、実際に車で使っているUSBメモリに全曲を同期して、カーナビで再生できることを確認したら、終了となる予定。ただ、上述のように、改良したい点もあるので、ゴールはもう少し先になりそうだ。

その後、いろいろ良さそうなアイデアが浮かんだので、これが完成する前に第2版に着手しそうだ。最もいい考えは以下だ。

この同期プログラムをGMBから呼ぶ時に使っているexportというプラグインには、曲のファイル名や情報をCSVやM3U形式で書き出す機能があるのだが、(必要ならそれを改造して)同期の時に使うタグ情報(アーティスト名、アルバム名、トラックの再生ゲイン値)を書き出せば、音楽ファイルのタグを読む必要がなくなるから、今の数倍〜10倍高速になりそう!

それから、もし上が駄目でも、次の案もいい。

今は音楽ファイルのタグは外部プログラム(exiftoolやsoxi)で抽出しているが、実はPHPのライブラリでも取得可能だ。php-getid3というライブラリはいろいろなフォーマットに対応しているから使えそうだ。これを使えば、外部プログラムを呼ばなくて済むので、数倍高速になる可能性が高い。

更に、もし外部プログラムを使わないで済めば、特殊文字のクォートが不要になるので、プログラムが「マトモ」になる。ただ、ffmpegは必ず使うので、特殊文字の展開をしないsystem()関数を作る必要はある。

そして、そろそろプログラムの改良や修正が怖くなってきた(間違ったら戻れない)ので、GitやSVNのようなバージョン管理システムを入れようかと思っている。→ ローカルだけで使うのであれば、Gitがとても楽なことが分かったので、それにした。GUIはSmartGitを試している。(10/31 22:55, 11/1 6:39)

  •   0
  •   0

昨日辺りから、MusicBeeからgmusicbrowser(GMB)への移行に関して残っていた、USBメモリなどのデバイスに曲を同期(転送)する機能を作る作業が捗って、基本機能がほとんどできた。

機能概要は以下のとおり。(MusicBeeのデバイス同期機能にならった)

  • 転送対象: GMBの管理している曲。特にフィルタ(=自動プレイリスト)の結果の曲。
  • 転送先: USBメモリなど (Linuxのディレクトリなら何でも可)
  • 転送時の処理: MP3でないファイルはMP3に変換して転送する。
  • その他: 同期先にあって同期元にないファイルは削除する。

どのようにGMBに組み込む(連携させる)か、いろいろ考えたのだが、GMBのexportプラグインを改造することにした。これには多くのメリットがあった。

  • プラグインなので、(外部コマンドを自分で起動するなどせずに)GMBからシームレスに起動できるようになった。
  • GMBのプレイリストをファイルに保存する機能があるので、それを使って、同期対象のファイル一覧を作れる。(当初は自分でプレイリストを保存する手順が必要かと思っていたのが、不要になった。)
  • 外部コマンドを呼ぶ機能もあるので、それにならって、実際に同期を行う外部プログラムを起動できる。
  • 設定機能もあるので、同期機能の設定を作る時の参考になる。

それからいろいろ検討した結果、以下のような作業・処理手順を実現することにした。

  1. デバイス(USBメモリ)を挿す。
  2. GMBで、同期対象のプレイリスト(フィルタ)や曲を右クリックして、"Sync to directory"を選択する。
  3. (以下の処理が終わるまで、GMBは待ち状態になる。)
  4. 同期プログラムは、指定された曲に対して、以下の処理を実行する。
    1. その曲が同期先(デバイス)にある場合には、何もしない。(同名だが内容が違う場合に備えて、ファイル名以外にタイムスタンプでも判定する: ホストの日時 > メモリの日時 → 転送する)。
    2. その曲が同期先にない場合、曲のフォーマットがMP3でなければMP3にし、トラックの最大値を統一する(例: -0.9dBになるように、データを増幅する)。同時に、再生ゲインのタグを除去して、同期先にコピーする。
  5. 同期プログラムは、同期先にあって同期元にないファイルを削除する。

ある程度実装した後、以下の問題が見つかったので、対処した。

  • GMBは同期プログラム(外部プログラム)の終了を待たない。→ 同期結果が分からない。→ 同期するプログラムで、途中経過や結果のダイアログを出すことにした。
  • 同期元のトップディレクトリは一つでないので、それを元に同期先のトップディレクトリを設定してはいけない。→ 同期するプログラムで、同期先のトップを指定するようにし、トップ下のディレクトリは曲のタグ(アーティスト、アルバム)から生成するようにした。
  • どうやって同期先のトップディレクトリの指定をするか。→ GUIプログラムzenityでファイル選択ダイアログを出すことにした。
  • 元のファイルにトラックの最大値(REPLAYGAIN_TRACK_PEAKなど)がある場合は、改めて最大値を求めずにそれを使えばいい。
  • SOXでは日本語のMP3のタグ(アーティストなど)が文字化けする。→ ffmpegを使うことにした。
  • カーナビでアルバムアートを表示させたいので、MP3にアルバムアートを埋め込む必要がある(埋め込まないと、カーナビには表示されないため)。→ オリジナルのディレクトリからアルバムアート(cover.jpgなど)を探して、縮小してMP3に埋め込むことにした。
  • 処理(特にMP3へのエンコード処理)が遅い。→ とりあえず、ffmpegを2スレッドで並列化した(-threads 2)。本当はファイルごとに別プロセスで処理するといいのだろうが、結構面倒だ。→ その後、MP3には-threadsは効果がないことが分かったので、止めた。(10/28 5:53)

以下、実装時の細かい話を書く。

  • 同期先のファイル名は、同期元のファイル名のsuffix(拡張子)を"mp3"に置換して生成している。が、今思えば、タグから作っても良かったかも知れないし、通し番号でも良かったかも知れない。
  • ファイル名によっては、特殊な文字("や()など)が入っているため、外部コマンドに渡す際にファイル名をクォートする処理が必要だった。
  • 同様に、USBメモリはVFATなので、同期先のファイル名中の、VFATで使えない文字は"_"に変換するようにした。
  • 再生ゲインタグの抽出にはexiftoolを使った(-s2)。ffmpegでも可能だが、exiftoolの方が速かったためである。
  • FLACとMP3では再生ゲインタグの名前や記法が異なるので(下の例を参照)、両方に対応した。
    • FLAC: REPLAYGAIN_TRACK_PEAK: 0.921652
    • MP3: User Defined Text               : (replaygain_track_peak) 0.921652
  • 同期元に再生ゲインタグがない場合に最大音量を求めるのには、ffmpegを使った(-af volumedetect)。この場合は、エンコードの前に追加処理として行うため、処理が遅くなる。
  • ffmpegでの音量の正規化は、loudnormフィルタがちゃんとしているようだが、車で聴くのにそこまでする必要はないため、MusicBee同様、volumeフィルタで最大値を設定することにした(例: volume=-0.5dB)。← volumeに指定するのは絶対値でなく増減なので、最大音量近くを意図して-0.5dBを指定するのは誤っている。(10/29 18:29)
  • 再生ゲインの計算は単純な最大値ではないようなので、元のファイルに再生ゲインタグがない場合は、警告を出して、正規化を諦めるようにした。ffmpegでloudnormフィルタを使えば求められるが、それにしてもGMBで再生ゲインを求めたファイルと音量差ができると考えたからだ。そもそも、元のファイルはすべて再生ゲインタグを入れている前提なので、問題は生じないはずである。(10/29 18:29)
  • 不要なタグの削除は、エンコード時にffmpegで行った。(例: -metadata REPLAYGAIN_ALBUM_GAIN=)
  • 少しでも小さいファイルサイズで音質を良くするため、MP3は可変ビットレート(例: -q:a 3)でエンコードした。ちょっと聴いた限りでは、音質に問題はなかった。品質に3を指定した場合、平均ビットレートは約180kbps程度になり、ファイルサイズはFLACの1/5程度になった。
  • アルバムアートの埋め込みも、エンコード時にffmpegで行った。
  • アルバムアートの埋め込み前に、convertコマンドを使って256x256画素にしている。元のサイズがそれより小さい場合は処理しないようにしたいが、今はいつも処理している。→ その後、縮小のみをする方法が見つかったので、元のサイズが最小サイズより小さい場合は、拡大しないようにした。(例: -resize "256x256>") (10/29 18:35)
  • 上述のように、ffmpegでさまざまな処理を一気にしているため、ffmpegを起動するコマンドラインがかなり長くなった。
  • 同期先にあって同期元にないファイルの削除は以下のようにしている。
    1. 同期の前に、同期先のファイル一覧を取得する。
    2. 同期中に、同期またはスキップしたファイル一覧を保存しておく。
    3. 同期終了後に2つの一覧を比較し、同期したファイル一覧にないファイルを削除する。
  • 削除機能の基本動作は問題なかったが、ファイル数が多い場合に使用メモリ量や負荷が高くなる可能性があるので、要注意だ。

実装後、この同期プログラムで作成したMP3ファイルがカーナビで再生でき、アルバムアートも表示されることを確認した。

以下、操作時の画面キャプチャを示す。

最後に、同期機能に関して以下のような残件はあるが、現在のところ、GMBに大きな問題はなく、この先にもあるとは思えないので、MusicBeeからGMBへの移行は完了したと考えてよいだろう。

  1. 同期プログラムのオプションを実装する。
  2. exportプラグインの設定画面で同期のオプションを設定できるようにする。
  3. 細かい調整・高速化
  4. 全体的な動作確認
  5. 詳細な動作確認
  6. 実際に使っているUSBメモリにフル同期(全曲を同期)してみる。
    1. 所要時間を測る。
    2. 使用メモリ量を測る。
    3. カーナビで再生を確認する。

上の1, 2を実装し、同期中のファイル名を表示し、同期結果に実行ログも表示できるようにした。(10/27 21:46)

3の高速化について、ffmpegのマルチスレッド指定(-threads)は効果がなかったので、複数ファイルのエンコードを同時に実行できるようにしてみた。すると、曲にもよるが、6ファイル(プロセス)を同時に処理した場合には、約3-4倍高速になることが分かったので、6プロセスでの並行処理を採用することにした。以下に、いくつかの測定結果を示す。(CPU=Core i7-2600, 転送元=HDD, 転送先=SSD)

・ポップス 28曲 (Blondie, FLAC, 125MB)

  • 1プロセス: 112s → 4s/曲, 1.1MB/s
  • 2プロセス: 65s → 2.3s/曲, 1.9MB/s
  • 4プロセス: 39s → 1.4s/曲, 3.2MB/s: 1プロセスの約3倍速
  • 6プロセス: 29s → 1s/曲, 4.3MB/s: 1プロセスの3.9倍速

・クラシック 6曲 (ブロンフマン, FLAC, 313MB)

  • 1プロセス: 81s → 13.5s/曲, 3.9MB/s
  • 2プロセス: 49s → 8.2s曲, 6.3MB/s
  • 4プロセス: 34s → 5.7s/曲, 9.2MB/s: 1プロセスの2.4倍速
  • 6プロセス: 26s → 4.3s/曲, 12MB/s : 1プロセスの3倍速

なお、6プロセス同時の場合、CPU使用率は75%程度まで上昇した。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-10-28_21-42-49-1

ここまでやって大分良くなったし、プログラムもなかなか本格的になったのだが、まだまだ9.75合目程度で、完成までにはもう少しある。そして、ここからは結構辛い。。。(10/28 22:25)

 

PS. これが完成して気が向いたら、他の改良・修正(主なものは以下のとおり)と一緒に作者に送ってみようかと思っている。(僕からすれば、)寄付よりはいいかなと思う。

  • 再生ゲインモード(off/album/track)の切り替えを(設定画面でなく)メニューで行えるようにした。(頻繁に使うため)
  • 「今の曲が終わったら停止のon/off」を行う内部コマンドを追加した。(リモコンで行いたいため)
  • 設定の"Remember playing position between sessions"をonにしている時、次回起動時に再生を開始しないようにした。(文面通りにした)
  • Queueの"Stop after this song"がonの時、再生終了後、次の曲に進む(ただし、停止のまま)ようにした。(次回の再生時に次の曲に進める手間を省くため。MusicBeeに合わせた)

そして、オープンソースプログラムは自分でいろいろ改良・修正できるので、やっぱりすごくいいと思う。そして、GMBはプログラマーにとって、最高の音楽プレーヤーだと思う。

(23:30 加筆・修正; 10/27 5:35 少し加筆;10/28 5:53 ffmpegの-threadsについて追記;10/28 22:25 並列処理について追記; 10/29 7:24 わずかに修正; 10/29 18:35 再生ゲインタグがない場合とアルバムアートのサイズが小さい場合について更新)

  •   0
  •   1

疲れたので、この週末はプログラミングは休むつもりで居たが、Linux移行作業は進めていた。しかも、気付いたら、散歩や掃除などの予定していたことを何もせずに、プログラミングしていて日が暮れていたという体たらくである。

が、そのおかげで、MusicBee(MB)からgmusicbrowser(GMB)への移行がかなり捗った。MB関連で残っていたのは、以下である。

  1. 音楽ファイルの管理の移行
  2. デバイスとの同期
  3. GMBのリモコン(I/Oデータ USB-IRUNIT2)対応

それらのうち、1と3ができた。

まず、音楽ファイルの管理の移行での問題点は以下だった。

  1. GMBはWAVとWMAをサポートしていないので、一覧に出ず、再生できない。
  2. MBのカスタムタグのGMBへの移行。

WAVとWMAの件は、基本的には単純で、それらをFLACに変換すれば良い。なお、それら以外にGMBのサポートしていないフォーマットは使っていなかった。

手順としては、MBの自動プレイリストでWAVとWMAのファイルを抽出(検索)して、それらに対してフォーマット変換を行った。ちょっと面倒だったのは、変換したファイルをサブディレクトリに入れたかったのだができなかったことと、WAVには再生ゲイン(その曲の音量の最大値のようなもの。いろいろな曲の音量を揃える時に使う)の値が入っていないので、変換後に計算する必要があったこと程度だ。

サブディレクトリについては、おそらく、MBの変数を使えばできたのだろうが、入力画面には出ず、どうせヘルプドキュメントもなく、調べるのが面倒だったので、同じディレクトリで我慢した。WAVなどが同じディレクトリにあっても、GMBはそれらを認識しないのだから、自分でディレクトリを見ない限り、問題はない。

その量は膨大で、約8600個(約220GB)もあり、全ファイル数の半分以上だった。変換には4スレッドで約5時間掛かった。FLACに変換後のサイズは約70GBだった。なかなか気持ちよく圧縮された。もちろん、HDDにはまだ余裕があるし、何かの間違いがあるかも知れないので、元のファイルは消していない。なお、WMA(ロスレス)からFLACへの変換がロスレスなのかちょっと心配はあるが、どっちにしても聞き分けられないので、問題はない。この処理によって、念願だった、GMBでビートルズの曲が聴けるようになった。

なお、再生ゲインの計算は約2000ファイルに対して実施し、約30分掛かった。

次に、カスタムタグの移行を行った。カスタムタグは、MBだけの特別なタグで、基本的にはファイルに書き込まれていないので、ファイルを移しただけではGMBは認識しない。また、ファイルに書き込んでいるカスタムタグでも、GMBは「やれば表示できる」程度で検索やソートには使えないので、何らかの対応をする必要がある。それにはいくつかの方法があるのだが、以下のようにした。

  • 値が1/0のタグ (例: 「この曲を無視する」)
    1. 自動プレイリストで、対象の(値が1の)ファイルを検索する。
    2. ファイル一覧を通常のプレイリストにエクスポートする。
    3. それをGMBでインポートして、その中の曲に対して、GMBのラベルを設定する。
  • 値が任意のタグ (例: 購入日)
    • いい解決策がなかったのだが、幸い、音楽ファイルではタグも対象のファイル数も少なかったので、手で、一般的なタグであるコメントに追記した。
    • ビデオファイルにはいくつかのカスタムタグがある(例: ソース)のだが、GMBはビデオが扱えないため、別アプリで対応する必要があるので保留にした。

なお、プレイリストは、MBの設定では"M3U(#EXT)"形式で、絶対パス・UNIX形式でエクスポートし、エディタでパスを修正した。M3U(#EXT)形式でないと、GMBではインポートできない。ファイルの先頭に"#EXTM3U"が必要なようだ。なお、UNIX形式にしても、パスの先頭にドライブ名が残るなど、そのままでは使えなかった。相対パスにしても、ドライブが複数あるためにパスが間抜けになっていて、便利ではなかった。この辺りは、もう少し何とかすべきだろうが、Windowsでしか動かないプログラムに求めるのは酷だろう。

それから、余計なファイルを削除したり無効化したり、タイトルなどが文字化けしたファイルに対応した後、ファイルの過不足のチェックをした。概ね問題はなかったのだが、移行前後のファイル数に若干違いがあった。全体としては、GMBの方が数十個多かった。どうしてかは良く分からないが、誤差の範囲だろうし、少ないよりはいいだろうw いや、実際には、デジタルなので誤差はないはずなのだが、まあ、聴いた時におかしければ対処するから問題ない。そのためにも、オリジナルのファイルは残しておくのだ。

あと、どういう訳かアルバムアートが出ない曲が結構あったので、手で登録したり、なぜか再生ゲインが入ってない曲があったので再度計算したり、同じアーティストでも微妙に異なる綴り(例: "the"と"The")のせいで別人に扱われているのを、手で修正したりした。

リモコン対応は比較的楽だったが、問題点は以下だった。

  • どうやってリモコンとGMBをつなぐか。
  • GMBにないコマンド(今の曲が終わったら停止のon/off)をどうするか。

リモコンとGMBの接続には、以下の方法がある。

  • キーボードのシミュレーション (MBでやっていた方式)
  • MPRIS2
  • DBus

キーボードのシミュレーションはいろいろと面倒なので、却下した。例えば、キーを送る前にGMBのウインドウを探したり、ウインドウマネージャのホットキーを無効にしたりする必要がある。

次に、MPRIS2とDBusはどちらでもいいのだが、GMBにないコマンドを追加する可能性があったので、メッセージの仕様に自由がある(仕様がない)DBusにした。DBusだと、GMBのRunCommandコマンドでほとんど何でもできる一方、MPRIS2は(下位ではDBusを使っているのだが)、仕様にあるコマンドが少なくてできることが余りなく、わざわざ規格を決めたメリットがあるのか、ちょっと疑問だ。

リモコンのキーを読んでDBusで送信するプログラムは、以前試しに作ったものがあったので、改良程度でできた。ただ、思わぬ問題が起こった。リモコンのキーを押すと、ウインドウマネージャが終了するらしく、ログアウトしてしまうのだ。

この原因は良く分からないのだが、おそらく、リモコンのキーがキーとしては滅茶苦茶(文字でなく、バイナリデータ)なので、ウインドウマネージャが誤動作して落ちるのではないかと思う。検索したら、運良く対処方法が見つかった。xinputというコマンドで、リモコンを除外すれば良い。除外するには、リモコンのデバイス名などを調べる必要があった(USB接続なので、デバイス名が変わる可能性があるため)ので、ちょっと手間が掛かった。udevadmやlsusbといったコマンドを使った。

(2016/10/29 7:06 追記) しばらく使っていると、xinputでの除外設定が解除されてしまうようなので(以前あった、xmodmapで変更したキー配置が戻るのと同様か?)、XOrg (X Window Systemのサーバー)の設定にリモコンを無視する設定を追加して、恒久的な対応をした。以下に設定例を示す。

/usr/share/X11/xorg.conf.d/10-evdev.confに追加:
 Section "InputClass"
   Identifier "bad device"
   MatchProduct "I-O DATA DEVICE,INC. USB-IRUNIT2"
   Option "ignore" "on"
 EndSection

なお、リモコンはudevというプログラムでLinuxに自動的に登録されるのだが、デフォルトでは管理者(root)以外はアクセスできない。そのため、リモコンを認識した後で、他人もアクセスできるようにする処理をudevに設定を追加した。

それからリモコン関係の機能追加をした。まず、面倒だと思っていた「今の曲が終わったら停止のon/off」コマンドをGMBに追加した。「今の曲が終わった後の動作の指定」のコマンドはあったので、それのコピーと修正(現在の状態を元に、新しい状態を設定する)でできた。更に、Windowsでやっていた、リモコンの電源ボタンで休止する機能も付けて、リモコンは完璧になった。

今気になっているのは、あるプレイリストを再生中に別の曲が入ってしまう問題である。例えば、ポップスのプレイリストを聴いているのに、途中でクラシックが入ることがあった。やっぱり原因はわからないのだが、GMBの設定で、「現在の楽曲は常にプレイリストにある」と「最新の楽曲」をoffにしてみたら、今のところ再発していない。それにしても、どちらも意味不明な訳ではあるが、自分でやる気はしないので、文句は言わない。ただ、設定がなくて英語にできないのが、ちょっと不便だ。Linuxのデスクトップアプリは、OSの言語設定に合わせるのが流儀なのかも知れない。

もう一つ気になっているのは、戻れる曲数に限度があることだ。1曲程度しか戻れない。シャフルしているせいだろうか。まあ、戻ることは滅多にないので、問題ではない。

という訳で、残ったのはデバイス(USBメモリ)との同期だけのはずだ。それについては、方法を考えた。基本的には、soxというオーディオファイル処理プログラムと、デバイスとホスト間のファイル同期処理(デバイスにないファイルだけを転送する)を併用すればできそうだ。

もちろん、ファイル同期プログラムは世の中にいくつもあるのだが、以下の特別な処理が必要なので、使えない。

  • デバイスに転送する時に、MP3でないものをMP3に変換する。
  • 再生ゲインを恒久化する(タグの数値でなく、データ自体を増幅する)。
  • 再生ゲインのタグを除去する。

ファイルの同期はデジカメでもやったので、それほど難しくないだろうから、あとは実装するだけだ。

そして今は、MusicBeeでなくgmusicbrowserで音楽を掛けている。VirtualBoxとその上のWindows 7を動かさずに済むようになったおかげで、メモリ使用率は12%程度に減り、平常時のCPU負荷も2%程度に減った。全くいいことづくめだ。更に、GMBに再生ゲインの切り替えメニューを追加できれば、差し当たっては言うことは何もない。最高の音楽プレーヤーのできあがりだ。

その後やる気が出て、GMBに再生ゲインの切り替えメニューを追加できた。先日試しに作ったコードがそのまま使えた。今は設定するだけで、現在の状態(off/アルバム/トラック)は表示できないが、結構便利になった。あと、ダウンロードしたソースだとなぜか英語表記になっていて、更に都合がいい。(23:44)

20161023-gmb-add-rg-1

その後、ちょっと苦労したが、なんとか再生ゲインの切り替えメニューに現在の状態を表示できた。まったくPerlは判じ物で、どうなっているのか理解できないが、便利なのは認める。(10/25 4:15)

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-10-25_04-13-07-1

  •   0
  •   0