Archive for the ‘PC・技術’ Category

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

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

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

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

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

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

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

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

  •   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でのクラウドバックアップサービスが大体決まった。そもそも選択肢はほとんどなかったのだが、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

画像取り込みプログラムはちゃんと動くようになって、完成したと思っていたのだが、それについての投稿をしようとした時点で、思わぬ問題(の可能性)が見つかって、あと少しの状態である。それが、MusicBeeからgmusicbrowserへの移行に気を取られて中断しているのだが、現時点での話を書く。

当初から希望していた取り込み手順は、以下のとおり。

  1. カメラやスマフォをPCに接続すると自動認識されて、取り込みウインドウが出る。
  2. ウインドウには、前回以降に撮影された画像だけが表示される。
  3. 取り込みボタンで、それらを取り込める。
  4. 取り込んだ画像は、画像の撮影年月日の名前のディレクトリ(例: "2016/2016_10_21")に格納される。
  5. 取り込んだファイルの最終更新日時は、撮影日時になる。

絶対に落とせない点は以下のとおり。

  • 取り込んだ画像は、カメラに残す。(間違ってPCで消してしまっても、カメラのストレージがフルになって消さない限り、オリジナルが復活可能なので)
  • それでも、前回取り込んだ画像は再度取り込むことはない。(自分で取り込む画像を1枚ずつ選択するのは論外)
  • 取り込んだ画像は、画像の撮影日の名前のディレクトリ(例: "2016/2016_10_21")に入る。
  • 取り込んだ画像の最終更新日時は撮影日時になる。(EXIFの情報でも十分なのだが、最終更新日時を使うとPNGも同じ扱いができるので、便利)

もちろん、それらを実現できる既存のプログラムを探したのだが、なかった。特に、「前回取り込んだ画像は再度取り込むことはない」と「画像の撮影日の名前のフォルダに入る」と「最終更新日時が撮影日時になる」をすべて実現できるものはなかった。

それで、作ることにした。もちろん、全部自分で作ったわけではなく、主要なところは以下の既存のソフトを使った。

  • gphoto2 : カメラからの画像取り込み
  • exiftool : 画像ファイルの処理 (撮影日時の抽出など)

これだけ書けば十分ではあるが、ちょっと苦労・工夫した点を書く。

gphoto2には新しい(取り込んでいない)画像だけを取り込むオプション(--new)があるが、効かない場合がある(例: iPhone)ので、それは使わずに、自分で実装した。取り込み済みファイル一覧を保存しておいて、取り込みのたびに、カメラ内の画像一覧と比較して、新しいものだけを取り込むようにした。

なお、ファイル一覧のサイズが大きくなり過ぎることを心配したが、現在のところ問題なさそうだ。1000-2000枚(正確な数は数えていない)の一覧ではサイズは100KB未満である。

この時、複数のカメラを持っている場合、画像ファイル名(例: "IMG_0123.JPG")が重複する可能性があるので、カメラの製品名とシリアル番号からカメラの識別記号を生成して(シリアル番号をそのまま出すのは嫌だし長くなるので、CRC32でダイジェスト値を生成した。例: "1234567890")、カメラ別にファイル一覧を保存するようにした。

gphoto2は取り込んだ画像の保存先を指定できないようなので、撮影日の名前のフォルダに移す処理は、exiftoolを使って自分で作った。exiftoolは、移す先に同じ名前のファイルがあるとエラーになって中断するので、同じ名前のファイルがあった場合の処理を追加した。

この時、上述のとおり、別のカメラとのファイル名の重複の可能性があるので、ファイル名にカメラの識別記号を追加するようにした(例: "IMG_0123.JPG" → "IMG_0123_1234567890.JPG")。

それから、デジカメでは問題ないが、スマフォ(例: Android)からは関係のないファイルが一覧に来ることがあるので、取り込むファイルの種類(MIMEタイプ)を指定して、フィルタリングするようにした。

更に、Nexus 4はファイル名が長過ぎてgphoto2のファイル一覧のフォーマットが崩れてしまうことがあるうえに、画素数が入っていないことがあるので、それへの対応も追加した。

ここまでは、(GUI関係を除いて)10/16にできたのだが、その後、問題(の可能性)に気付いてしまった。カメラを長く使って、撮影した画像が1万枚以上になると、ファイル名が最初に戻るのである(例: "IMG_9999.JPG"の次は"IMG_0001.JPG")。親ディレクトリが異なっているから区別可能なのだが、一覧を取り込んだ際に親ディレクトリを無視してしまうので、特に、取り込み済みファイル一覧で重複してしまう。

それに対応するため、いくつかの案を考えた。

  1. 親ディレクトリ名もカメラ識別記号の生成要素にする。
  2. 保存するファイル名に撮影日時を追加する。
  3. 保存するファイル名に親ディレクトリ名(の一部)を追加する(例: "100")。
  4. 取り込み済みのファイル名と重複していたら、ファイル名に通し番号を追加する。

今は案1と3が有望である。が、かなり長く使っているCanonのデジカメですら、まだ番号は3000番台で急ぐ必要がないので、なかなかやる気が出ずに居る。忘れて使っているうちに、「あれ? 取り込めない?」とか思って慌てるパターンかも知れないw 時間が経つと、既存のデータ構造を変更するのが大変になるので、早目に手を打った方がいいのではあるが。。。

PS. 前の投稿の画像は、このプログラムを使って取り込んだ。

  •   0
  •   0

昨夜、PCのメモリを増設した。今のマザーボード(ASUS P8H67-Vに実装できる最大の量の32GB (DDR3-1600, 8GBx4)にした。既存の16GB(4GBx4)は撤去して、全部交換となった。

新しいメモリは、調べたところ、安くて評判も悪くなかった、Silicon PowerのSP016GBLTU160N22DA (8GBx2)を2組にした。約1.3万円だった。ちなみに、このPCを組み立てた2011年には、8GB(4GBx2)で約9000円だった。メーカーが違うから正確には比較できないが、大分安くなったようだ。

ケースを開けたら、1枚のメモリはCPUクーラーのヒートシンクの下だったので、「CPUクーラーを外さないと駄目か?」と嫌な予感がしたが、そのまま無事に取り外せた。ただ、CPUクーラー周辺はケーブルが密集していて、作業には神経を使った。取り付けは30分くらいで終わった。

無事に起動し、BIOSで32GBがちゃんと認識された。なお、メモリの仕様はDDR3-1600だが、1333MHzで認識されていた。おそらくBIOSの設定で変えられるのだろうが、僕自身は1333で何も問題を感じておらず、これを買う時も1333を探していた(が、安いのはなかった)ので、そのまま使うことにした。

今気付いたのだが、2枚ペアになったメモリはペアのメモリスロットに挿すべきだった。でも、もうどれがどれか分からないし、面倒だし、問題は起こっていないので、止めておく。

寝る前にメモリテスト(MemTest86)を起動して、起きてから調べたら、エラーはないようだが画面が崩れていた。これは、以前(去年のことなのに全く忘れていた)と同じ現象で、MemTest86のバージョンを新しくすれば直るようなので、今日の出勤前に最新版を起動させようと思う。

もちろん、Linuxも無事に起動した。ただ、休止できるようにするのに手こずった。休止する時、メモリはスワップ領域に保存されるので、メモリを増やしたらスワップ領域も増やさないと駄目なので、(スワップパーティションを拡げるのが面倒なので)スワップファイルを作ったのだが、休止できなかった。

それで、スワップファイルでは駄目かと思って、GPartedでスワップパーティションを拡げたのだが、それでも駄目だった。どうやら、休止の準備をするプログラムの一部(元のPCのWi-Fiのものと、自作の、USB 3.0で勝手に復帰しないようにするもの)がエラーになっていたからのようで、修正したら休止できるようになった。だが、それまでは問題なく動いていたのに、なぜ今になって駄目になったのだろうか? 謎はあるのだが、まあ、ちゃんと動いたから良しとする。

そして、当然ながら、増設後のメモリの空き容量は大幅に増えた。それまでは使用率が約50%(空き=約8GB)だったのが、今は23%程度(空き=約24GB)で、想定どおりである。

ところで、少し前までは、このメインPCはもう5年も使っていて、そろそろ寿命だろうから、Linuxに移行後(来年辺り)に買い換えるつもりでいた。でも、いろいろ調べたり考えたりして、何もなければ使い続けることにした。

その理由は、以下である。

まず、良く「PCの寿命は5年」と言われているが、そうでもないという情報(説)があったことだ。このページではPCの故障に関する論文が紹介されていて、確かに使用開始から5年辺りまでは故障数が増え続けるが、それ以後はそうでもないとのことだ。

そして、意外にも、HDDよりCPUの方が故障しやすいという情報が載っている(論文は1990年代のもので、かなり古いのだが、昔のHDDの方が今より丈夫だったとは思えないから、まだ意味はあると思う)。僕も、HDDの故障が一番ありそうだと思っていたのだが、どうやらそうでもないようだ。

それはともかく、HDDのような機械部品やコンデンサは、時間と共に劣化するのは確実なので、いつかは壊れるだろう。それについては、次のように考えた。

仮に何かの部品が壊れて使えなくなったとしても、家にはもらったPCが何台もあって、(それらは古いとはいえ、)全部が同時に壊れてどれも使えなくなる可能性は0に近いから、壊れたらそれらを一時的に代わりに使って、部品交換や買い替えすればいいのではないかと。

そして、交換部品を注文するのは、代わりのPCでも、急ぐなら会社のPCでもスマフォでもできる。どれも駄目とかとても急ぐ場合には、本物の店に買いに行けばいい。通販で買う時のIDやパスワードはパスワードマネージャの暗号化データになっているので、ストレージ(HDDやSSD)を適切にバックアップしていれば復旧可能だ。

よって、ストレージの動作状況(SMARTの値: これもあてにならないという情報はある)を監視しつつ、随時バックアップしていれば、大きな問題は起こらないと考えた。

そもそも、PCを買い換えたり組み立ててるのはおもしろいけれど、とても面倒だ。作業自体も最良の物を選ぶのも面倒だ。さまざまなリスクがあるから、必要がなければやりたくない。

そういう訳で、このPCには、完全に壊れる(部品が連続して壊れるなど)か、性能の限界に達するか(これはあり得ないだろう)、僕が飽きるまで頑張ってもらうことにした。そして、Windowsよりはましになったが、VivaldiやVirtualBoxはメモリを食うので、快適に使える期間を少しでも長くするため、メモリを増やしておこうと思ったのだ。増やすのは今でなくても、実際に困ってからでいいのだが、DDR3規格は古いものになっているので、時間が経つと値段が上がったり入手困難になりそうな気がしたので、早目に交換することにした。

 

PS. 関係ないが、今使っている画像管理ソフトXnViewMPからは、ブログ投稿への画像のドラッグ・ドロップができず、不便だ。ソフトごとに一長一短だな。

PS2. 最新のMemTest86でチェックしたところ、問題なく終了していた。一安心。(10/21 19:39)

PS3. その後、なぜか、休止後の復帰時に状態が戻らずに再起動するようになってしまった。BIOSの更新も含めていろいろ試したが駄目で、Ubuntuのコミュニティでようやく対処方法が分かった。どうやら、OS(カーネル)の起動時のパラメタがおかしくなってしまったようで、/etc/default/grubに休止データの保存先(スワップ領域)を設定してから起動時のgrubの設定ファイル(/boot/grub/grub.cfg)を作り直したら直った。スワップ領域を拡げた時にスワップ領域のデバイス名が変わって、その設定が無効になってしまったのだろう。でも、確かに昨夜までは復帰できていた気がするのだが、それは気のせいだったか。。。(10/22 8:13)

  •   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

今日は、午後にデジカメからの画像取り込みプログラムを完成させようという意気込みだったのだが、思わぬ道草をしていて、まったく進まなかった。発端は、「パスワード入力なしでLinuxを休止させたい」というわがままだった。

もちろん、普通のデスクトップLinuxは、休止ボタン(アイコン)をクリックするだけで休止する。しかし、僕のではVirtualBoxが動いているので、そのまま休止させると、VirtualBox上のWindowsが壊れることがあるため、休止する前にVirtualBoxを閉じる(状態を保存する)必要がある。その仕組みは以前作ったのだが、休止するコマンドはスーパーユーザでないと実行できないため、休止のたびにパスワードを入れる必要があった。でも、毎回そんな面倒なことはしたくないので、何とかしたかったのだ。

調べたら、sudoコマンドの設定ファイルに、パスワードなしで実行できるコマンドを記載すればいいことが分かって、さっそく対応して快適になった。それでいい気になって、今度は、Windowsの時にはリモコンで休止できたのを、Linuxでもやりたくなってしまった。これは結構難しい。というのは、リモコンは基本的にMusicBeeの制御用なので、今は(論理的に)VirtualBoxにつながっているから、Linuxからはキーを取得できないのだ。

どうするか考えた。それで、リモコンを一旦Linuxで受けて、休止以外のキーをVirtualBoxに転送しようと思い、WindowsでMusicBeeにリモコンを渡すのに使っているプログラムEventGhostのWebserverプラグインを使い、LinuxからNW経由でhttpでリモコンの情報を渡せばいいことが分かり、実際に試したらできそうなことが分かった。しかし、買い物帰りに、たった1個のキーのために全体的に仕組みを作り変えるのが面倒になり、別の案を思いついた。

リモコンは今までどおりWindowsで受けて、休止のキーだけはLinuxに渡すのだ。で、NW経由で受け渡すのがまっとうなのだが、たった1個のキーなので、それすら面倒なので、共有ファイルを使うという荒業を使った。EventGhostで、休止のキーを受けたら、Linuxとの共有ディレクトリに特定の名前のファイルを作り、それに「休止が要求されたよ」ということを書き込む。Linux側は、定期的に共有ディレクトリを見て、その休止要求のファイルがあったら、そのファイルを削除して、休止処理を実施するのだ。

簡単な仕組みなのですぐにできたのだが、変なところにはまってしまった。なぜか、Linux側の休止要求監視プログラムを止めるとVirtualBoxも止まってしまうのだ。どうしてかは未だに理解できないのだが、プロセスの親子関係に起因する、良くあることなので、試行錯誤して直した。

なんてことをやったり、別な改良やトラブル対応をしたり、食事したりしていたら、もうこんな時間になってしまった。プログラミングしていると、時間が経つのがすごく速くて驚く。でも、まあ、Windowsと同じように、リモコンのボタンを押すだけで休止するようになったので、気分爽快になった。

というところで題につながる訳である。実際には、題を考えている時にこの曲が掛かっていて、とても懐かしかったらなのであるが。まあ、実際にはキール(未だに見たことすらない)で乾杯なんてしたことないし、当時はビールのCMで流れていたので、「ビールで乾杯」と思い込んでいた。今にして思えば、バブル崩壊後なのに、なぜか景気が良かった気がする。

 

PS. ついでに、Linux Mintへの暫定移行後、約1週間使って気付いたことを書く。

  • 移行後、全くWindows PCを起動しなかった。データさえあれば、どのPCであろうが関係ないということだろう。
  • Linuxのカレンダーアプリには、ろくなのがない。Thunderbirdがイマイチなのだが、それ以上のものはない。中でもKOrganizerは最悪だった。
  • Web版EvernoteとNixNote2の相性は最悪だ。Webで書いたノートをNixNote2で開くと文字化けしてしまって、直らない。Webで開いても化けたままだ。
  • Vivaldiはウインドウに勝手な装飾をしている。タイトルバーや右上のアイコン(閉じるなど)まで変えるのはセンスが悪いと思う。しかも、変えたデザインは余り良くなく、そのせいで(枠に影がつかなくなって)、Vivaldiのウインドウが重なった時に上下の区別がつかなくなって、不便だった。これは設定の「通常のウインドウを使用する」をonにすれば普通の状態になる。それにしてもひどい日本語訳で、意味が分からなかった。
  • FirefoxもChromeも、まともにwebをPDF化できるアドオンがなくなってしまった。それで、ブログページのバックアップはWindwosのAcrobatに頼るしかない。
  • Linuxに、Windowsのような「最近使ったファイル」がないのが、意外に不便だ。ただ、ちゃんとした実装は結構難しそうだ。
  • (10/16 18:26 書き忘れていたので追記)ブログサーバにログインするのに、TeraTermなんて腐ったソフトじゃなくて、ごく普通のLinuxのターミナルからsshコマンドでできるのは、ものすごく当たり前のことなんだけど、Windowsのせいで長らくできていなくて、我慢を強いられていたことだったので、結構感動した。「あ、もう変なアプリは要らないんだ!」って。いや、空気のように当たり前のことなんだけどね・・・
  •   1
  •   1