Amazonには見切りを付けた。とは言っても、別の会社に依存するのも駄目だということの実例が起こった。

9月の終わり頃に、(今年用に)去年も買った「黒猫カレンダー」をローチケHMVに注文したのだが、入荷遅延の連絡が2回来て、今週になっても発送される気配がない。それに業を煮やして、昨夜、Amazonを調べてみたら、「在庫あり」となっていた。待ち切れないので、ローソンをキャンセルしてAmazonに注文したら、さっき、もうAmazonから発送済みのメールが来た。ローソンからは、どういう訳か、「廃盤でキャンセル」というメールが来た。

という訳で、取り引き相手を固定せず、常に最良の選択をしないといけないことを実感した。

それにしても、ローソンもクソだ。。。というか、もしかして、Amazonの買い占め??

  •   0
  •   0

MusicBeeから脱却できたので、Linuxへの移行はほぼ終わりも同然なのだが、まだしぶとく残っているものがある。その一つがEvernoteだ。いつもはweb版を使っているのだが、バックアップするにはアプリを使わざるを得なく、そのためだけにVirtualBoxでWindows 7を起動するのは、クリックするだけとはいえ結構嫌だ。更に、Windowsを動かすとVirtualBoxの仮想ディスクが更新されるので、数十GBがバックアップ対象になるのも嫌だ。

それを止めたくて、しつこく代替策を探しているのだが、なかなかない。今日は、編集はWYSIWYG(グラフィカルにスタイルを設定できる)でなくてもマークダウン(HTMLみたいな感じ)でもいいからと敷居を下げて、以下の点が達成できれば良しとした。

必須

  • オープンなファイルフォーマット
  • 容易に画像を貼り付け可能 (たまに写真を貼るので)
  • クラウドベース (iPhoneと共有するので)
  • iPhoneアプリがある。(Linuxではwebでも可)
  • 安定している。
  • 安い。
  • 会社が中国・韓国などでない。

オプション

  • なるべくWYSIWYGがいいが、マークダウンでも可 (iPhoneではテキストしか入れないので)
  • Evernoteのインポートができればいい。
  • セルフホスティング可(自分のサーバで動く)ならなお良い。

そして、以下の候補が出てきた。

  1. QOwnNotes
  2. TagSpaces
  3. Dropbox Paper
  4. Thinkery

順に試したのだが、Dropbox Paper以外はどれもイマイチだった。QOwnNotesは説明が分かりにくい上にうまく動かず、TagSpacesはローカルにデータを置くので論外だし、Thinkeryはどうしても画像が貼り付けられなかった。

唯一残ったDropbox Paper(以下、Paper)は、Evernoteからのインポートをあきらめさえすればいい感じだった。実際にちょっと使ってみても、web版もiPhoneのアプリも、Evernoteよりずっと出来がいい印象だ。一言で言えば、Evernoteの(無駄にゴテゴテとしてバグの多い)鬱陶しさがない。フォーマットがおかしくなることはなさそうだし、画像も指定した場所に貼り付けられるし、Evernoteのwebからの(結構大量の)ペーストは一瞬で終わって、この場合もフォーマットの崩れはまずない(ただし、画像はペーストできない)。それから、webとiPhoneアプリ間の同期が素早いのもいい。

そして、Paperはwebからドキュメントのバックアップもできる。MS Wordやマークダウン(md)形式でダウンロードできるのだ。ドキュメント全部を一括してダウンロードすることも可能で、zipファイルになる。Zipの作成には時間が掛かるが、できたらメールが来るので、問題ない。Mdはテキストだけだが、Wordには画像も入っている。Wordなのはちょっと引っ掛かるが、ちゃんとLibreOfficeで開けるし、Evernoteの独自形式よりは10倍以上マシだろう。

あとは、Evernoteからのインポートができれば言うことないのだが、今はまだベータ版だから、正式版になったらできるようになるのかも知れない。大いに期待している。これならお金を払ってもいいと思う。さっそく、容易に移行できるもの(日記とか買い物メモやLinux移行メモ)を移行して試している。

その後、Paperに問題点が見つかった。大きいサイズ(といっても1MBはない)のペーストをすると、その後、Paperへのペーストがほとんどエラーになる。ベータのせいだろうか。ちょっと不便ではあるが、気を付けて使おう。→ 他のノートでも、大きいペーストは駄目になってしまった。ブラウザの再起動も再ログインも効果がない。不便なのでサポートに連絡したが、どうなるか。

どうも僕は、バグ出しのスキルがあるようだw

Paperのサポートから回答が来て、キャッシュをクリアしろとか、ブラウザの問題を疑っていた。しかし、別のブラウザ(Firefox)でも起こったので、そうではない。それで、エラーが起こった時にVivaldiのコンソールに盛大にエラーが出ていたので、そのログを送った。さて、直るのか。まあ、せいぜい、「大き過ぎてペーストできません」というメッセージを出すようになる程度の気がする。(11/3 22:08)

その後、分割してペーストするのに慣れたのか、Dropboxが修正してくれたのか、ペーストがうまくいくようになった。

なお、以下の機能はペースト・使用できないが、あらかじめ意識して使えば大きな問題ではない。それよりも、機能が必要最低限なのはいいし、フォーマットが崩れにくくなるから、いいことだと思う。

  • 埋め込み画像 (ペースト不可)
  • 文字サイズ・色・スタイル(フォント指定、斜体など) (サポートされていない)
  • チェックボックス → ペーストすると番号付きの箇条書きになる。
  • インデント (サポートされていない)

(11/4 5:50)

(11/3 5時 わずかに加筆; 7:25, 8:08,22:08 大きいペーストの問題を追記; 11/4 5:50 加筆)

PS. Evernoteのバックアップ以外にWindowsを起動する理由は、同じく定期バックアップの時にブログをPDF化するためのAcrobatだったのだが、先日、Firefoxでまともに動くwebのPDF化アドイン(だかアドオンだか拡張機能だかプラグインだか分からないけど、何でもいいよw)、PDF Creatorを見つけたので、Paperが問題なく使えれば、Windowsを起動する機会は(紙をスキャンする時以外)ほとんどなくなりそうで、大変喜ばしいことだ。(11/3 8:56)

早くもPDF Creatorが動かなくなってしまったので、今はChromeのPDF Mageに乗り換えた。これはVivaldiで動かないのが残念だ。(11/12 20:05)

  •   0
  •   2

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

(いけ好かないブロガーの題より)

Window10、大規模アップデートの配信が決定。3D性能を大幅強化 (ママ)

近頃は押し売りが流行っているのか。3Dって、そんなに需要があったっけ? 一家に一台、3Dプリンタでもないだろうに。MSはこれから流行らそうとしているのか。あるいは、Windowsを使う「クリエーター」がそんなに居るのか。

なんでだかは分からないが、とにかく本質を見失っている。そして、みんなそういうのに振り回されて、「Windows 10 ***版で***するには/しないには」なんて記事やアプリが増えるのだろう。もちろん、そういうのはLinuxでもあるが、Windowsのは多過ぎるし、変更が頻繁過ぎるし、そもそも変更の必要性が疑問だ。そんなにいつも苦労させられるのなら使わなければいいのにと思うが、他に手軽に使えるOSはMacの以外にないから、どうしようもないのだろう。

そのMacにしても、つまらない改良だか「進歩」だかなんだか知らないが、OSの名前を変えたりファンクションキーなんて取るに足らないものをなくして胸を張っているのは片腹痛い。笑いのネタにすらならない。しかも、エスケープキーまでなくすなんて、全く分かってない。意識高い系の集団が、「僕ら最先端でかっこいいでしょ」って、内輪受けしているだけだ。そして、それをありがたがって使う人たちが沢山居るのが信じられない。

いい加減、下らないテクノロジー遊びは止めろと言いたい。

PS. 元ネタの題は誤っている(正しくは"Windows")のだが、まとめサイトに出ているのはこういう類が多い。まとめサイトでなく、元の掲示板に間違って投稿されているのだろうが、「もっと落ち着けよ!」って言いたい。

(10/29 7:31 若干加筆・修正)

  •   0
  •   0

久しぶりにCuRAZYから。あそこは基本的にはおもしろいんだけど、近頃は意識高い系のネタがあって、ちょっと鼻白むことがあるけど、たまに「なるほど」と思うものがあるから、止める気にはならない。

【親は監督でなく観客になろう】心から参考にしたい成功の秘訣8選

最初の水木しげるの言葉、「しないではいられないことをし続けなさい」がいい。ていうか、僕は子供の頃からそうだったので、「やっぱりそれで良かったのか」と、今更ながら安心している。

今だって、(眠かろうが疲れようが、おもしろい)プログラミングをしないでは居られないw ブログだって、別に義務とか習慣で書いている訳ではなく、書くのが止められないのだ。

PS. 残念ながら、ピアノ(演奏)はそうではなかったが、まあ仕方ない。自覚はあるから、納得しているし。

  •   0
  •   2

昨日辺りから、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でのクラウドバックアップサービスが大体決まった。そもそも選択肢はほとんどなかったのだが、CrashPlanにすることにした。

必要な条件は、以下だ。

  • 容量無制限
  • 転送速度が遅過ぎない。
  • (現在のBackblazeに比べて、)費用が高過ぎない。

約1週間、CrashPlanとAltDriveを同時に動かして、使い勝手を比較した。その結果、以下のことが分かった。

  • AltDriveは転送速度がかなり遅い。CrashPlanの1/2程度しか出ず、遅過ぎる。以下は、約6日間の転送データ量から求めた、(私の環境での)実転送速度である。なお、平日の昼間はPCを止めていたので、連続稼働時よりも遅いことに注意が必要である。
    • AltDrive: 24GB/日 (278KB/s)
    • CrashPlan: 55GB/日 (637KB/s)
  • どちらも、なぜか転送を止めている時間がある。特に、CrashPlanは頻繁に接続が切断されている。それがなければ、もっと高速になるのだが。
  • どちらもJavaで書かれており、Linux Mintで問題なく動いた。CPU負荷やメモリ使用量は、どちらもそれほど高くない。
  • UIはCrashPlanの方が綺麗だが、使い勝手はどちらも同様である。
  • AltDriveは若干安定性が悪い(バックアップが停まって再開しないことがあった。その時、アプリはハングしていた)。
  • CrashPlanの状態表示は余りあてにならない。例えば、転送が停まっている時でも、最後の速度が表示され続けている。

BackBlazeのB2というストレージサービスも検討したのだが、以下の問題やリスクがあるので止めた。

  • B2用のバックアッププログラムが要る。: 自分で用意することになるのだろうが、音楽や画像などと違って気が抜けない。
  • データの暗号化は自分で行う必要がある。: これも気が抜けない。
  • バックアップ実行間隔の設定が難しいし、バックアップ中はPCを止められない。
  • 料金が従量制なので、どのくらい掛かるか読めない。

※なお、BackBlazeはWineでは動かなかった。

  •   0
  •   0

疲れたので、この週末はプログラミングは休むつもりで居たが、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

市内の公園で爆発騒ぎ。自分だけでなく、自宅まで燃やしたようだ。その公園は遠いけど、ちょっと散歩に行ってみたいと思っていたところだ。やっぱり、この街も、「地方だから安心」とは言えなくなって来た。。。

デジカメ(IXY Digital 3000IS)の電池が寿命らしく、充電してもすぐに警告が出るようになったので、交換した。もう7年も使ったのだから、確かに寿命なのだろう。ちなみに、Amazonは値段は安かったのだが、「偽物が届いた」という書き込みが多かったので、ヨドバシにした。偽物を売る店を放置しているようでは、全く買う気が起こらない。

ヨドバシは、留守でも受け取れるようにとメール便にしたのだが、昨日注文して今日届いていたので、結構感動した。やっぱり、(少なくとも僕の中では)Amazonは終わりだ。慢心は良くない。特に理由がない限り、商品の検索とWishlistでの商品メモ機能だけを使うことにしよう。

もちろん、ヨドバシだって、未来永劫この良さが続くはずはない。要は、「気に入った」とか思って特定の団体に入れ込まないことが重要なのだろう。団体には人間以上に心がないので、こっちが気に入ってもそうでなくても全く関係なく、彼らの都合で変わるのだ。

僕らに必要なのは、そういう団体の裏をかくような、ずる賢さとか強さとか柔軟性なのだろう。

  •   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