昨日辺りから、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

コメントを書く

名前    

メール 

URL