Archive for the ‘gmusicbrowser’ Category

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

(ここのところ、しばらく寝不足続きで疲れたので、この週末はLinux移行関連のプログラミングは休み(のつもり))

先日からWindowsの音楽プレーヤーMusicBeeのLinuxでの代替に、gmusicbrowser(GMB)を試している。絶対的な機能の豊富さではMusicBeeに敵わないのだが、使い込むにつれ、なかなか侮れない奴だという気がしてきた。

一番のいいところは、MusicBeeと違ってオープンソースだという点だ。プログラムは比較的コンパクトだから、気に入らないところはその箇所を探して自分で改良できる。Perlで書かれているのでビルドが不要だし、インストールすら不要だから、手軽に試せる。実は僕はPerlは苦手で(何といっても読みにくい!)、今までほとんど使っていなかったのだが、昨日、初心者向けの解説ページを参考に(実は、普通の変数と配列に区別があることすら知らなかった)リプレイゲインの切り替えメニューを付けてみたら、何とかできてしまった(もちろん、それをちゃんと使える物にするには、結構手間が掛かる)。同様に、ウインドウのレイアウトもテキストファイルで書かれているので、自由に変更できる。プラグインももちろんPerlで作れる。だから、WMAやWAV対応も自分でできそうな気がしてきた(面倒だけど)。

繰り返しになるが、オープンソースでコンパクトだから、仮に開発が終わってしまっても、ちょっとした不具合は自分で直せそうだし、機能追加もできそうだ。ドキュメントは余りないが、ソースを見れば何とかなる。とにかく、要望でもバグでもいちいち作者に「お願い」するのは面倒なのだ! しかも、大抵は却下されるし、MusicBeeの作者とは指向も違っていたから、最後は頼む気も起こらなかった。

それから、便利な機能が意外に多いのにも感心した。デスクトップウィジェット(プラグイン)なんて、邪魔なだけで使わないだろうと思っていたのだが、試してみたら意外にいい。MusicBeeのコンパクトプレーヤーやミニプレーヤーの代わりになりそうだ。(MPRISに対応しているから、命令を送信するすプログラムを作れば)リモコンにも容易に対応可能だし、(実際に便利かは不明だが)任意のCD取り込みプログラムを起動することもできる。

%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-22_08-52-15-2-1

gmusicbrowserのメインウインドウ(左)とデスクトップウィジェット(右上)

 

%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-22_08-44-07-1

gmusicbrowserのデスクトップウィジェット

要は、僕ら(Unix使い)にとっての「普通」から逸れずに作られているということなのだろう。だから素直に使えるし改造もできる。Windowsのようにイライラすることはまずない。もちろん、機能不足やバグや気に入らない点はあるのだが、自分で直せる可能性があるのは、欠点を隠して余りある。こんなに魅力的なソフトが普及していないなんて、ちょっともったいないと思った。まあ、そのメリットが活かせるのはUnixのプログラマーだけなのだろうが。

(10:49 加筆・修正、16:06 わずかに修正)

PS. 今気付いたが、GMBには、音量メーターだのスペアナだのビジュアリゼーションなどの、派手だけど役に立たない要素がない。せいぜいあるのは、上に書いたデスクトップウィジェットや、通知の表示程度で、それだってオプションだ。それから、もちろんのことだが、最大化して起動したり、ウインドウを閉じても終わらない(設定で可能)ということはない。それらは、僕にとって、GMBの好感度を高める一因になっているようだ。(13:35)

PS2. 気が向いたので、ちょっと話は逸れるが、Unixの文化なり思想についてちょっと書く。僕の経験や理解では、Unixでは「派手は糞」だ。できるだけ「静かに」すべきなのだ。まあ、昔はGUIなんてなかったから、そうするのは、(コマンドラインの)プログラムの出力程度だったが、とにかく、無駄なメッセージはだらだら出さないのが常識だった。極端な(でも、ごく普通の)例では、処理が成功しても、(問題がない限り)何も出さない。もちろん、うるさく出すように指定されれば(普通は"-v"(verbose)とか"-d"(debug)などのオプション)、言われたとおりいくらでも出す。どっかの窓とか林檎の会社の作法とは全く異なる。

あとは、「普通とか常識を守る」だ。とにかく、外側(例: 起動方法、表示・データ入出力の仕方、設定ファイルの書式)に関しては、作法に従ってプログラムを作る。そうじゃないのは、糞(=イケてない・ダサい)だ。これもどこぞの会社とは全く逆だ。

ではなぜ、一見アナーキーにも思えるプログラマーたちにそんな堅苦しいことを押し付けているかというと、ひたすら作業効率を上げるためだ(と僕は理解している)。ユニーク(独自)なのは、プログラムの内容だけで十分で、見てくれなんて無意味だし、使い勝手は普通が一番。そうしておけば、例えそのプログラムを使ったことがなくたって使えるし(覚えておく必要があるのは、どんなプログラムにも、簡単な使い方とかオプション一覧を出す"-h"(help)というオプションがあることと、manコマンドでマニュアルを表示することだけ)、他のプログラムと組み合わせることで、いくらでも機能を拡張できるのだ。

時は流れて、LinuxはUnixの一種といえども、段々そういう思想が薄れて来ている気がするのが、ちょっと寂しい。(16:45)

  •   0
  •   0

いろいろな苦労と発見の末、デジカメからの画像取り込みプログラム(スクリプト)の初版ができた。いろいろ改良したいことはあるが、とりあえず、落とせないポイントをすべておさえて、ちゃんとデジカメやスマフォから取り込めるようになったので、一安心だ。それについて詳しく書きたいのだが、風邪のせいかだるくなって来たので、その前に、画像より100倍重要な音楽プレーヤーについて、再び書くことにする。

以前も探したのだが、もしかして見落としがあるかも知れないと思って、さっきまで散々探していた。が、やっぱり、(僕にとって)MusicBeeを置き換えられるものはLinuxにはない。もちろん、どれも曲は再生できるし、それなりの画面は表示されるのだが、必要な機能(例: 自動プレイリストやギャップレス再生)が抜けていたり、あっても貧弱だったり、使いにくかったりするのだ。

試したうちではClementineが筋がいいように感じたのだが、なぜか、再生と表示がおかしくなってしまったので却下した。AmaroKは次点とは言えども論外で、それ以外は論外未満だ。

個々のアプリについて書くと長くなるから、以下に、全体を通して受け入れ難かったポイントを書く。

  • 音飛びする。
  • 再生がおかしい(リピートでないのに、何度も同じ曲が掛かることがある。表示と再生の曲が違う)。
  • 曲間にギャップができる。
  • 曲が認識されない、認識される曲が少ない。
  • 曲の順番が滅茶苦茶に表示される。
  • 自動プレイリスト機能がないか貧弱。
  • 通知の表示や音などが鬱陶しい。
  • ウインドウを閉じても終わらない。終わる設定がない。
  • 操作が直感的でない。マウスのボタン操作が微妙で、誤操作を誘発する。
  • 設定ができないか、項目が貧弱。
  • 表示がしょぼい。デザインの趣味が悪い。
  • (英語圏のアプリなのに)アーティスト名やタイトルの"The"が無視されずにソートされる(例: ビートルズがBでなくTのところに出る)。

無いものは仕方ないので、当面はMusicBeeを使うが、ClementineやAmarocKを試した時に、「やっぱり、ネイティブは便利でいい」感じがしたので、諦めずに探し続けよう。

それにしても、Linux陣営は、各自が好き勝手に作ってないで、共同でいいものを作ったほうが絶対に得策だと思うのだが、きっと、みんな「俺様」だから無理なんだろうな。KDEだのQtだのGnomeだの、各種流派の主張や長所はあるんだろうけど、そんなことより、数は少なくても質の高いアプリを作った方がいいと思う。「『ちょっと作ってみた』から出す」時代はもう終わっているのだ。こんな調子では、LinuxがWindowsに勝つ日は来ないかも知れない。今はいいチャンスだと思うのに。。。

その後もしつこく検索していたら、いくつか追加候補が見つかった。その中で良さそうなものを試したが、どれも肝心な点(特に、音飛びとギャップレス再生)が駄目だった。まともに動かないものもあった。それから、何となく感じるものがあって、試すまでもないと思っていたgmusicbrowserをダメモトで試したら、意外に良かった。MusicBeeの機能が全部ある訳ではないし、いろいろ荒削りではあるが、基本機能がちゃんとしていて可能性があるので、いろいろ試している。(10/18 6:37)

%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-18_05-51-23-1-2

約1日間、gmusicbrowser(略してGMB。MusicBeeはMBなので、不思議なつながりがある)で試しに音楽を聴いているのだが、聴くだけなら全く問題はなかった。シャフルで聴いていたので、ギャップレス再生については分からないが、音飛びは全く感じなかった。それで、GMBに不足している以下の重要な機能が何とかなれば、移ろうと思っている。

  1. CDの取り込み
  2. CDDBで曲情報やアルバムアートを取得して、取り込んだ曲に付ける。
  3. 取り込んだ曲の再生ゲイン(音量)の計算
  4. 特定のプレイリストの曲を、デバイス(USBメモリ)に同期する。
  5. 同期と同時に、MP3へのフォーマット変換と音量の正規化を行う。

ところが、1-3について随分しつこく探したのだが、これというものがなかった。取り込み速度が遅過ぎたり、アルバムアートが取れなかったり、再生ゲインができなかったりというのばかりだ。

でも、よく考えると、僕はもうCDから脱却したので、頻繁に取り込むことはないだろうから、それらの機能はあまり重要ではなく、取り込む時だけMusicBeeを使えばいいのかも知れない。もう少し考えよう。

あと、4と5ができるプログラムはまだ探していないが、なければ自分で作ろうと思っている。

それから、GMBはWindows系のフォーマット(WMAとWAV)に対応していないのだが、それについては、FLACに変換すれば問題ないと思っている。それらは全部で8600曲、210GBくらいあるのだが、待てば終わるだろうから大きな問題ではない。(10/20 0:06)

  •   2
  •   2