piu lentoの日々 (piu lento days)

調べたら2016年の秋にLinuxに移行したようなので、もうすぐ4年経つようだ。もちろんいいことばかりでもないが、トータルでは随分いい。僕にとっては、空気のように当たり前、かつ、自由なシステムだ。(それは当然としてｗ、)

今日書きたいのは、ディスクが減らないってことだ。システムディスクには、その時手元にあった120GBのSSDを「とりあえず」(足らなくなったら、別のにしようと思って居た)使い、85GBくらいを割り当てている(残りはスワップ(Windowsの「仮想メモリ」)領域)のだが、いまだに25GBも使ってなく、70%以上も空いている。これ、壊れる前にフルになることがあるのだろうか?ｗ

Filesystem 1G-blocks Used Available Use% Mounted on
/dev/sda1 84G 23G 57G 29% /

自分の大容量データ(写真、音楽ファイル、VirtualBoxの仮想ディスクなど)やシステムでも大きいもの(純正バックアップ(timeshift)のデータ)や書き換えの激しいもの(一時ファイル)は別のHDDに入れているけど、Windowsでは全く考えられないことだ。その頃は、自分では特に使っていないのに数年でシステムディスクがフルになって(Windowsの更新後のバックアップファイルが溜まるのだろう)、「クリーンアップ」なんてしても全然空かず、その周期でSSDを交換していた。とんでもないゴミだった。

今のPCのハードは2011年頃に組み立てたもの(本当に「Sandyおじさん」だｗ)だが、全然遅いと感じたことがない。Linuxもアプリも(僕の使い方も)軽いのだろう。

ただ、古いだけにいつも「そろそろ寿命か」と心配してはいるのだが、まだ兆候がない。ある日突然崩壊するのだろうか・・・ それに備えてスペアはあるが、そっちも古いので、いざという時に動かない可能性もあるｗ

ただ、メモリは食う。32GB入れているが、気づくと半分超えている。OS自体は全然消費しないが、ブラウザなどのアプリが肥大化している。それで、自作のメモリ使用量監視スクリプトで大食いアプリの使用量が大きくなったら通知を出し、手で再起動するようにしている。ローテクだけど、これが意外に役に立っている。以前はcgrulesengdとかいうプログラムで自動で使用量を制限していたが、今一つ効かないのと、効いてもアプリがうまく動かなくなって不便なので、自分が再起動できる時に手でした方がいいという結論になった。

なお、Spotifyは相変わらず肥大するのが急で、手で再起動するには頻繁で面倒なので、外部プログラム(自作のミニプレーヤー)でアイドル時に自動で再起動している。

PS. SSDの寿命が気になって調べてみたら、現在の残寿命("SSD Life Left")が98%で、累積通電時間は約1.8万時間(約2年)なので、トータルで100年くらい持つ計算だから、SSD内のフラッシュメモリについては心配なさそうだ。

なお、SSDの使用量の増加速度については、Linuxに移行した時はVirtualBoxの仮想ディスクを入れていたので直接の比較はできないが、当時の合計使用量が約58GBのようだったので、入れていた仮想ディスクのサイズを40GBとすると、仮想ディスク以外の使用量は約18GBとなり、今日までの増加分は5GBとなる。使用期間は約3.6年なので、増加速度は約1.4GB/年となる。このペースで単調に増えるとすれば、あと42年は持つ計算だが、果たして・・・

(5/18 6:44 少し加筆・修正)

Linuxデスクトップの鬼門の一つはEvernoteアプリ(がないこと)だ。最初からずっと困っていた。数少ない互換アプリの中ではNixNote2が一番良かったが、いろいろな問題(例: 突然(サイズのせいか複雑さのせいか)、ノートが編集不可になる・同期できなくなる)があって、近頃はweb版のEvernoteを使っていた。が、web版にもいろいろな問題(例: (かな漢字変換を止めるつもりで)ESCキーを押すとノートが閉じてしまう、Page Up/Downがちゃんと動かない、画像を挿入すると、ノートの一番下に入ってしまう、書式がおかしくなることがある)があって、いつもいまいましく感じていた。

それで、定期的にLinux用Evernoteクライアントを探しているのだが、ずっと、いいものが見つからずにいた。が、昨夜、全然期待せずに検索していたら、NixNote2(が分岐してそ)の新版(2.1.1)が出たという記事が見つかり(運のいいことに、記事の公開直後だったようだ)、ちょっと試してみたら(→ UbuntuのPPA)なかなかいい感じだ。

最初の同期は(同期するノートが溜まっていて、API実行回数の制限のために)何時間も掛かったが、概ね問題は起こらなかった(1個だけ、過去に競合したノートが同期できなかったので、削除した。あと、なぜか、突然終了したこともあった)。その後は悪くない。一番の問題だった、ノートが編集不可にならない。以前編集不可になったノートも大丈夫そうだ。もちろん、Androidの純正アプリと同期しても問題ない。分岐した版は細かい改良や修正がなされているようで、表示や設定が微妙に違い、意味・効果不明な設定がなくなっている。あと、ショートカットでノートが切り替えられるのが、web版より分かりやすくていい。

今のところの欠点は、ノート切り替え直後などでの反応が遅い(ノートが表示されるまでや、最初の文字が入力できるまで、少し時間が掛かる)程度だ。まあ、あまり期待するとあとでがっかりするので、しばらく(疑いながらｗ)様子を見ることにする。

(20:39追記) 分岐版の更新内容を見たところ、HTML tidyというモジュールが新しくなったそうだ。従来のは8年くらい前の版だそうなので、今まで起こっていた、ノートが編集不可になるなどの問題は、これが古くてうまく処理できなかったせいではないかと推測する。でも、なぜ、他の人は文句を言わなかったのだろう? 僕同様、黙って諦めたのだろうか。

PS. 他に、やっぱり長らく待っていた、Turtlの新版(0.7)も出ていた。以前は全然まともに動かなかったのだが、今度のは信じられないくらいちゃんと動いた。が、そもそも、書式の指定がマークダウンで使いにくいので却下した。ありがたいことにスマフォのアプリもあって、僕はそれも使うつもりで試したのだが、そこでもマークダウンで入れるのは余りにも実用性がなくて、使う気になれない。他に、Evernoteをインポートできないことと、画像が貼れないのも不便だと思った。ただ、Turtlは自分でサーバを動かせる(構築できる)から、仮に上記のようなさまざまな不便さが解消すれば、移行の可能性やメリットが大いにあるから、今後も注目したい。

(技術的な話題だが、過去の投稿と繋がりがあるので、こちらに投稿した)

(今年のまとめでも書こうかと思って思い返してみたら、)Linuxに移行してから1年3か月くらい過ぎていたことに気付いた。まだいくつかのTODOが残っているので、移行は完全には終わっていないし、気に入らない点はゼロではないし、Windowsを全く使わなくて済むようになった訳でもない(スキャナ(ScanSnap)を使う時だけは要るし、Evernoteアプリには不自由している)から、全く問題がないとは言わないが、移行してから随分経ったことを忘れるほどには自然に(「空気のように」)使えている。

ただ、それは僕が「UNIXが自然・普通・当たり前」で、Linuxのコマンドを使うことが苦にならないからで、一般の方でもそうだとは口が裂けても言えない。それでも、マウスで操作する(コマンドを使わない)デスクトップ環境なら、一般の方でも容易に使えると思う。(何も問題が起こらなければ、)デスクトップ環境で9割以上は事足りる。ちなみに、デスクトップを一見するだけでは(古き良き)Windowsと見分けが付かないと思う。

移行後、Windowsではいろいろな騒動があった気がするが、高みの見物がおもしろかった。使っている人たちは良く耐えていると思う。感覚が麻痺して、問題が起こるのが当たり前になっているのだろうか? そうこうしているうちに、PCを使う人が少なくなって、スマフォやタブレットに移行しつつあるようだ(にも関わらず、Windows Phoneは無事終わったｗ)。

そして、MicrosoftやAppleが、多くのユーザーが「いつもどおり普通に使える」ことの重要性を無視して、あっけらかんと使い勝手を変えて、その上、「それは新しいから正しい。みんな使いなさい」などとのたまわってふんぞり返るのは、いったいどういうセンスなんだろうと思う。

きっと、多くの信者が、突然の変更にもムカつかずに、「＊で※するには」を調べて(あるいはプログラムを作って)公開するから、世の中が何とかなっているのだろうと思う。多くの人が手間と時間を掛けて調べ・作って、更に多くの人がそれを検索して適用するのは無駄としか言いようがない。更に、その不評を知っているはずのメーカーが知らん顔をしているのは、本当に厚顔無恥としかいいようがない。

確かに、Linuxでもそういうことはあるが、レベルが違う気がする。その証拠に、Windowsでは、突然困る(例: ある朝、いつもどおりのことができなくなっていた)ではないか。Linuxでは、そういう大きな変更の前にはちゃんと注意事項が公開されるから、事前に検討・準備できたり、その更新をしないことだって可能だ。

そもそも、Linux(UNIX)では操作性(操作手順や使い方)が変わることはほとんどない。機能追加はかなりあるが、20年以上前から同じ使い方ができるコマンドなんてザラにある(まあ、Windowsのコマンドプロンプトのコマンドもそうだが、そもそも、その(MS-DOS由来の)コマンド自体がUNIXのを劣化させたものだから、論外だ。更に、数年ごとにコマンドインタプリタが変わりさえするではないか)。だから、コマンドをがらっと変えてしまった一部のシステムを除いて、操作で戸惑うことがない。更に、操作が変わってしまったとしても、ほとんどの場合には、ユーザの希望で古いものを追加する(戻す)ことが可能だ。つまり、無駄な手間や苦労とは無縁なので、「空気」になれるのだ。

僕にはいいことずくめ(というか、上にも書いたように、これが当たり前)のLinuxなのだが、まだまだ普及していない。ただ、広く普及したらマルウェアの類も増えそうで、Linuxのそれはかなり強力そうだから、単に普及すればいいものでもない。まあ、仮にそれなりに普及したとしたらセキュリティソフトも出てくるだろうから、大丈夫かも知れない。それ以外の問題は、Linuxは基本的には自分でいろいろできる・したい人のためのOSなので、一般の方がWindowsの代わりに気軽に使おうとしても、無理があることだ。その時には、有料でサポートする商売も出てくるかも知れないが、そうすると、WindowsやmacOSと同様になってしまい、目をひくようなメリットは少なそうだ。

でもまあ、OSなんて、普通に使えれば(OSのお守(も)りじゃなくて、自分のしたいことができれば)いいのだから、そこがメリットになるかも知れない。例えば、ある日突然使い方が変わるとか機能がなくなるとか、使っていたら突然長ーい更新が始まって作業ができななくなるうえに停めることもできないとか、青い画面に落ちて無意味なメッセージが出るだけなんてことは皆無だ。

だから、例えば、小さい会社などで、MS Officeは使うけど凝った使い方(例: 変なマクロを組む)はしないのなら、フリーのOffice(例: LibreOffice)は充分互換性があるので、結構なコスト(ソフトもハードも)が削減できると思う。ただ、立ち上げにはそれなりに手間は掛かるし、「お守り」(質問・トラブル対応)をする人は大変だろう。が、サポートについては、Windowsだって結構あるから同じことか。

そういえば、ミュンヘン市はLinuxに移行したのにWindowsに戻ってしまうが、政治的な問題以外に、余計なことをしたためにコストも手間も掛かり過ぎたせいもあると思う。詳しい人なら分かると思うが、「自分たちのLinux」なんて作ったら負けだ。彼らは最初から間違っていたのだ。そんなんだったら止めとけば良かったのに、まったく馬鹿げた話だ。誤ったLinux移行を進めた人もWindowsに戻す人も、みんなセンスが悪い。

というわけで、「Linux(UNIX)は古くて、先進的な機能は少ないし、進歩も余りないけど、それでいいんじゃない(先進的な機能って、どれだけ使っているの?)」というのが今の感想や意見である。

まとめ

• (多くの人にとって)OSは、普通に使えればいい(OSのお守(も)りに意味はない)。
• 過去との互換性を保持することはとても重要で、価値がある(変化自体に価値はない)。
• (おまけ) ソフトは、作ったら負け。

PS. 久し振りにMusicBeeのサイトを見たら、(サイトが)ダサダサになっていてすごくがっかりした。Page up/downすら効かないって、どういうこと!? MSや林檎以下じゃないか? 見栄えはいいけど、中身はとても陳腐だ。進歩もないようで、今だにGPMもSpotifyもサポートしてないの? 暗いスキンが標準なのも好みでない。

Linuxに移行する際、Windows 7で使っていた東芝のSSD (CFD S6T256NHG5Q, 256GB)は使わずに、友人Nにもらった何台かのPCの中で、Linuxの試用に使ったPC(Vision HT)のSSD(AData SX900, 128GB)を、そのまま正式なPCに移してしばらく使うことにし、将来的には(ADataより良さそうなイメージがある)東芝のに入れ替えようと思った。

その後、Linuxには全く問題ないので、昨日、そろそろ東芝のに入れ替えようか検討したのだが、結論としては、止めた。

以下に、検討内容と結果を書く。

• 残寿命(残使用可能時間) → 現実的には同等。東芝の方が長い可能性があるが、確証はない。
  • 東芝
    • 残寿命: 95% (SMART #173: ただし、意味が公表されていない値)
    • 通電時間: SMART #9 (Power on Hours): 9322時間 (388日) → 壊れるまでの通電時間: 約21年? (388/(1-0.95)= 7760日) → 残りは20年くらい?
  • AData
    • 残寿命: ほぼ100%
      • SMART #231 (SSD Life Left): 100%
      • SMART #241 (Lifetime Writes from Host): 4427= 約4.4TB? → TBW(最大書き込み量)をKingstonの同等品(SSDNow KC300)の290TBとすれば、残寿命は約98%。
    • 通電時間: SMART #9 (Power on Hours): 1752時間 (73日)
      • 壊れるまでの通電時間(推定TBWと今までの書き込み量より): 290/(4.4/73)= 4811日 (13.2年) → 残りは13年くらい?
• 発売時期 → 同等 (どちらも2013年頃)
• コントローラ → 良し悪しは判断不能だが、ADataは悪くない。
  • 東芝: HG5d (Marvell製?)
  • AData: SandForce SF-2281 (Intelも520シリーズで採用)
• 性能 → 同等だが、どちらかと言えばADataが良い。(小サイズのランダム書き込み性能がいい)
  • 東芝: 連続読み出し: 530MB/s, 連続書き込み: 490MB/s
  • AData: 連続読み出し: 560MB/s, 連続書き込み: 540MB/s

一番重要な残寿命(残使用時間)は、東芝の方が7年程度長い可能性がある。が、そもそも、このPC(あるいはSSD)をこれから10年以上も使うことは考えられないので、全く問題にはならないと思う。おそらく、それより早く、メモリ以外の部分(コンデンサ?)が壊れるだろう。

そして、買う時に結構重要なことを見落としていたのだが、東芝は寿命に関するSMARTの仕様を全く公開していないので、上に書いた値は、ユーザーが「使っていたらここが減ったから、きっと残寿命なのでは?」と言っている値から求めたものだ。 使用して値が減ったって、それが本当に残寿命なのか分からないし、減り方が均等なのかだって分からない。そんないい加減な値で寿命を推定することはできない(ところが、ある有名なソフトは、これが正しい寿命のように扱っていて、世の中ではそれが定説のようになっているから、なかなか恐ろしいものがある。噂はこうして「真実」になるのか)。 更に、東芝は、合計の書き込み・読み出しデータ量すらSMARTに出していないから、寿命に関しては何の材料もない。

自分でいいと思って買ったのだが、全く論外だった。「とりあえず作り(下請けに作らせ?)ました」的なものだ。ユーザーが何を求めているかとか、世の中の標準が何かとか全く関係ないのだろう。あるいは、ユーザからのクレームが怖くて、機能を外した(隠した)のか。東芝の中ではまともそうだった半導体部門ですら、こんな物を出して平気な顔をしていたのだから、いい加減な体質が会社全体を覆っているのかも知れない。という訳で、東芝には改めてがっかりした。

一方ADataは、TBW(最大書き込みデータ量)は公開していないが、SMARTの読み書きデータ量や残寿命の仕様を公開しているので、寿命の目安としては有効だ。

それから、SSDの寿命を縮める原因の一つであるswap(仮想記憶機能)は、メモリを大きくして起こりにくくしていたし、昨日(休止状態を諦めたから必要なくなって)止めたので、問題にならないだろう。

一つ気になるのは、ADataの容量が東芝の半分なので、使っているうちにフルにならないかということだが、現状でシステム領域の約3割(25GB)しか使っておらず、使っている感じでは、LinuxはWindowsと違って、システムディスクを食い潰す(Win7の実績: 約30GB/2年= 1.3GB/月)ことはなさそうだし、写真や音楽などのデータはHDDに入れているので、問題はないと思っている。

そして、NはもうPCなんて興味ないだろうし、詳しくもないだろうと思っていたのに、実は意外にまともなものを選んでいたので感心した。全くおそろしい子だｗ

PS. 寿命が気になったので、他のディスクの使用(通電)時間も調べてみた。

• WDC WD30EZRX (一般、ビデオ、その他用, 2013年に購入): 12000時間 (約1.3年)
• Seagate ST3000DM001 (音楽用, 2013年に購入): 11000時間 (約1.3年)
• HGST HDS5C3030ALA630 (ビデオ用, 2011年に購入): 26000時間 (約3年)

一番長いHGSTでも、まだ一般的な寿命(5年?)には余裕がありそうだ。が、Seagateのこの機種は壊れると悪評が高いので、ちょっと心配はある。僕はたまたま運がいいのか、品質の悪かった時期の後に買ったからか、これから壊れるのか。とても不思議なことに、SMARTのReallocated Sector Countは0だが、本当に正しいのだろうか。まあ、バックアップは万全なので、壊れてもきっと大丈夫だろう。。。

↓

とはいえ、ビデオはともかく、Seagateの音楽の領域が壊れると楽しみが激減してしまうし、壊れてからの復旧は結構面倒なので、早目に準備したくなって来た。 (17:02)

↓

その後、衝撃のどんでん返しがあって、近々、全HDDの交換をすることにした。詳細は追って書く。 (3/14 7:56)

結構前に着手しつつも長いこと延期していたのだが、今日で大体目処が付いたので書く。「Linuxへの移行」は、正確には、「WindowsのMusicBeeからLinuxのtinyMediaManagerへの移行」である。

移行するメタデータは、MusicBeeに登録した以下の情報である。

• 標準のタグ: タイトル、出演者、年、種類(映画、音楽、TV)、音楽ビデオの場合のジャンル、長さ、メディアのパス
• カスタムタグ: "Source"(DVD/BDなどの種類)、"Not ripped"(メディアを持っていて、PC内にないもの)など

移行するには、まず、MusicBeeに登録したビデオ情報を取り出す必要がある。しかし、MusicBeeにはDBのエクスポート機能がないため、最初はDBを解読しようとして途中までできたのだが、調査中にiTunesのXML形式で書き出せることが分かったので、その機能を使った。

次に、iTunesのXMLで記録された情報をtinyMediaManager(以下、tmm)に登録する必要があるのだが、tmmにはCSVなどからバッチ処理で登録する機能がない。しかし、メディアファイルと同じディレクトリに、ビデオ情報を記載したXMLのファイル(nfoファイル)を作ることで、その情報を読み込んで登録できることが分かった。それで、iTunesのXMLをnfoファイルに変換するプログラム(以下、変換プログラム)を作った。

変換プログラムでは、iTunesのXMLを読むために、PlistParserというPHPのライブラリを使った。あとは、XMLから読み込んだ情報を、各メディアファイルごとにnfoに書き出せば良いのだが、いくつか苦労したことがあるので、以下に書く。

MusicBeeのタグに対応するnfoの要素がないもの(主にカスタムタグ)は、tag要素に記述した(例: "Not ripped" → "<tag>Offline</tag>")。また、下記のように、すべてのメディアの種類が定義されていないため、メディアの種類はtag要素にも記述した。

nfoのsource(メディアの種類)に書くべき記号一覧が公開されていないようなので、tmmで調べたところ、以下のとおりだった。

• DVD Video: DVD
• Blu-ray disc: BLURAY
• TV: TV
• デジタルTV(地デジ): (なし)
• VHS: VHS
• LD: (なし)

それから、tmmがメディアファイルやnfoを登録する際、ファイル名に"-"や"_"のような区切り文字が2個以上入っていると、タイトルが最初の単語だけになってしまい、異なるビデオが同じものとみなされることがあるようだった(例: "test-1-a.vob"と"test-1-b.vob"が"Test 1"に統合される)。ただ、それが起こらない場合もあって、正確な規則は不明である。

(12/6 20:30 追記) nfoに情報を追加する時、iTunesのXMLから取得した値をhtmlspecialchars()でURLエンコードする必要がある場合があった。いつもではなく、場合によって不要なこともあった。理由は調べていないが、既にある子に値を上書きする時はエンコード不要(元々エンコードされているようだ)で、SimpleXMLのaddChildメソッドで追加する時にはエンコードが必要だった。URLエンコードしないと、"&"などの特殊文字がそのままnfo(XMLファイル)に書かれるため、異常なXMLとなり、tmmが読み込まない現象が起こった。

また、tmmには、scrapeといって、ビデオ(主に映画)の情報を公開DB(IMDBなど)から取得してnfoを作る機能があるので、MusicBeeに登録した情報(手で打ち込んだ)だけを使うよりは、scrapeできるものはそれでnfoを作る方が、正しい・多くの情報が格納できる可能性が高い。それで、変換プログラムでは、既存のnfoがある場合には、その情報を上書きせずに、追加情報(主にカスタムタグ)だけを追加するようにした。なお、長さは、TVなどで本編と異なる場合があるので、MusicBeeに登録した情報で上書きするようにした。なお、iTunesのXMLでの長さはms単位である。

日本語では検索できなかったので、海外で公開された映画しかscrapeできないと思っていたのだが、邦画でもローマ字で検索すればできることが分かった(例: 「セーラー服と機関銃」→ "sera fuku to"で検索)。なお、カタカナで書かれた英語の単語は、英語の綴りでヒットしない場合、ローマ字の綴りにするとヒットする可能性が高い。

scrapeの結果は、邦画の情報も全部英語で記述されており、俳優の名前などもローマ字になっている。邦画のDBがあればいいのだが、少し探した限りではないようだ。あるいは、tmmが日本語に対応していないだけかも知れない。

最終的には以下の手順で移行を行うことにして、現在実行中である。なお、"place holder"は、DVDなどの物理メディアを持っていて、PC内にメディアファイルがないものの情報だけを記録した、ダミーのメディアファイルを指す。

1. tmmで、scrapeできるものはし(place holderのビデオを除く)、ローマ字になっている邦画のタイトルを日本語に戻す。
2. 変換プログラムを実行して、各ビデオのnfoを作る。
3. 作ったnfoをtmmに登録する。
4. 登録結果を修正する。
5. place holderのビデオをscrapeし、nfoに情報を追加する。
6. scrape結果を修正する。

現在は3まで終わっている。移行で問題になりそうだった・なったことを以下に書く。

iTunes形式のXMLのサイズは、音楽ファイルの情報も一緒になっているため50MBもあって、変換プログラムで問題が起こらないか心配だったのだが、読み込みに時間が掛かった程度で、nfoの作成は一瞬で終わった(デバッグ時間は除く)。

それから、どうしてもうまくtmmに登録できない(複数の巻が同じものになってしまう)ビデオがあった。原因は不明なのだが、ディレクトリ階層が深かったようで、巻ごとにシンボリックリンクを作って浅くしたら、回避できた。

そして、今は以下のような感じでplace holderや邦画を含むビデオがtmmで表示できるようになった。Scrapeできたファイルは、アートワークやジャンルなどが表示され、出演者などの詳細情報も表示可能である。ビデオファイルがPC内にあるものは、右下の再生ボタンを押せば、VLCなどのプレーヤーで再生することができる。

tinyMediaManagerの画面

なお、tmmの問題ではないのだが、tmmからDVD(IFOファイル)を再生しようとすると、毎回アプリケーションを選択させられる。これは、LinuxにIFOのMIMEタイプが登録されていないためと思われるので、登録方法を調べて対応する予定だ。

本当は、gmusicbrowserでビデオも管理したかったのだが、ビデオと音楽では管理を別にする必要があって、改造するにしても、かなりの変更が要りそうだったので、とりあえずはtmmを使うことにした。Scrapeで詳細情報が取得できたり、ビデオの再生もできて、結構便利なのだが、検索機能が今ひとつだったり、上述のようなよく分からない挙動をすることがあるのが、ちょっと気に入らない。

↓

(12/6 20:18 追記) 移行が終わった。「何事もなく」とはまでは行かなかったが、大きな問題はなく、情報の修正などにちょっと手間や時間が掛かった程度だ。以下に、起こった問題と対処を書く。

• MusicBeeに登録していたディスク番号(タグ=Disc Number)をnfoに入れるのを忘れたので、複数枚からなるビデオの区別が付かなくなった。→ nfoのタイトルに、"[Disc 01]"のようにディスク番号を追加するように、変換プログラムを修正した。
• TVドラマやニュースのタイトルが大体同じで区別が付かない。→ ドラマの回や放送日を自動で抽出するのは難しかったので、手でタイトルに追加した。
• tmmが表示するビデオの長さ(ファイルをスキャンして得た値)は、実際の2倍になっているようだ。→ 長さは余り使わないし、scrapeして得られた本編の長さは正しいので、保留にした。

1か月以上前に開始した、CrashPlanの初期バックアップがようやく終わった。約1.4TB (開始時は1.2TBだった)を38日間でアップロードしたので、平均アップロード速度は約430KB/s(約37GB/日)となる(圧縮や重複排除機能があるから、実際の通信速度はこれより低いだろう)。

なお、平日昼間は休止していたので、稼働時はもっと高速で、平均送信速度620KB/s(5Mbps)前後だった。また、どういう訳か時々通信が停まるのだが、停まっていない時は約1MB/s程度出ていた。

CrashPlanは、Windowsで使っていたBackblazeよりは遅いのだが、速過ぎるとプロバイダの帯域制限が掛かるので(実際に、Backblazeの時は警告が来たので、通信量制限プログラムを作った)、これくらいで良しとするべきだろう。ただ、時々通信が停まるのは何とかして欲しい。

(11/24 5:19 追記) それから、「バックアップ受信」(他人からのバックアップデータを自分のPCに保存する)を無効にすると、なぜか、本来のサーバへのバックアップが停まってしまうようだ。他人からのバックアップを受け付ける意味が分からないから止めたいが、無理なようだ。ルータがあるし(あってもサーバ経由で受信するのかも)、バックアップコードを公開してないから大丈夫だとは思うが、気持ちが悪いので、受信する時間(長さ)を0分にして実質的に受信しないようにした。

面倒なのでずっと後回しにしていた、ACDSeeで付けた画像のメタデータをdigiKamに移行した。実際にはメタデータは画像ファイルに埋め込んだので、正確にはdigiKamに移した訳ではなく、「ACDSeeから脱却した」と書くのが正しい。

いろいろ検討して、以下のような手順にした。

1. ACDSeeで、ACDSeeのDBの全画像情報をXMLファイルにエクスポートする。全画像の情報をエクスポートするため、検索で全画像を一覧に出し、全部を選択して右クリックのメニューでエクスポートする。(もっとまともな方法はなかったのだろうか?)
2. XMLファイルから以下の情報を抽出する。→ 抽出するプログラムを作った(XMLファイルはPHPのSimpleXMLでデコードできた)。
   • ファイル名 → FolderとName要素より
   • キャプション → Caption要素より
   • カテゴリ → AssetCategoryList要素より
3. キャプションまたはカテゴリの付いたファイルに対して、exiftoolを使って画像にタグを設定する(埋め込む)。設定前にファイルの更新日時を保存しておき、設定後に戻す(exiftoolは更新日時を変えないのかも知れないから、実際には不要だったかも)。→ 上の抽出と同じプログラムで実施した。
   • キャプション → Descriptionタグに設定する。
   • カテゴリ → Categoriesタグに設定する。
     • 例: AssetCategoryが”Albums\日常の光景”の場合、以下のようなコマンドになる。
       • exiftool -Categories=’<Categories><Category Assigned="0">Albums<Category Assigned="1">日常の光景</Category></Category></Categories>' IMG_0333.JPG

なお、メタデータの埋め込みはACDSeeでも可能なのだが、埋め込み後にファイルの更新日時を戻す必要があり、必ずしもすべての画像に日時が入っている訳ではなく、戻らない可能性があるので自作した。

1は検討のために実施済みだったので、今日は2と3を実施した。以下に気付いた点を書く。

• 当然ながら、XMLファイルには画像ファイルのファイル名がWindowsのパスで書かれているので、Linuxのパスに変換する必要がある。これは先日のショートカットの変換と同様に、XMLファイル中に現れるWindowsのトップディレクトリを、Linuxのに置換するようにした。
• XMLファイル中の画像ファイルのパスの先頭には、ドライブ名の代わりにボリューム識別子(例: "<Local\1234ABCD>")が付いているので、削除した(この無駄な物のおかげで、HDDを交換するたびに何度も「DBメンテ」の手間を掛けさせられた)。
• XMLファイルは10MB近くあったが、問題なく読み込めた。
• digiKamでは、キャプションはEXIFのCommentタグではなくXMPのDescriptionタグを参照するようだ。ただ、それはdigiKamでは”Caption"(または「キャプション」)と表示されるのでややこしい。
• キャプションとカテゴリを埋め込む時に、ショートカットに対応する必要があると思って、ショートカットの実体(正確には、先日変換したシンボリックリンクの実体)を探して埋め込む処理を作ったが、実際には、XMLにはショートカットは登録されていなかった。
• ファイルにEXIF情報がない場合でもファイルの更新日時が戻せるように、(EXIF情報の日付を更新日時に設定するのでなく)あらかじめファイルの更新日時を保存しておいて、埋め込み後に再設定するようにした。
• 音楽ファイルのUSBメモリへの同期プログラムと同様、ファイル名の特殊文字('など)で結構ハマった。結局、その同期プログラムのエスケープ処理をそのまま使った。
• 同様に、カテゴリやキャプションもエスケープ処理した。やはり、特殊文字を特別扱いしないsystem関数が欲しくなった。
• BMPファイルにはメタデータは埋め込めなかったが、数個しかなかったので諦めた。
• digiKamの日本語訳もイマイチで、却って混乱するので、英語で使うことにした。

全約3万ファイル(メタデータを埋め込んだのは約1.8万個)を処理するのに約1.5時間掛かった。もちろん、何度もバグを直しては再実行したので、実際にはほぼ1日(昼間)掛かった。

キャプションやカテゴリが画像ファイルに埋め込まれたので、今では、ACDSeeで設定したキャプションなどの情報が、以下のようにdigiKamで表示できるようになった(右側のタブだけでなく、サムネイルの下にも出る)。もちろん、PixやXnViewMPなど、他のソフトでも表示される。

digiKamでキャプションとカテゴリが表示される。(懐かしい写真...)

これで、メタデータが特定のプログラムに依存しなくなったので、自由に付けられる。今までは、「付けてもACDSeeだけだから、無駄になるかも・・・」と、若干躊躇していたのだ。また、処理手順が分かったので、今後新たな状況になっても移行は容易だ。

(23:02 加筆, 11/24 0:14, 6:12 若干加筆・修正)

PS. 着々と減っているLinux移行のTODO。次は、MusicBeeに入れたビデオのメタデータの移行でもやろうか。今日のとちょっと似ているので楽ではあるが、面倒は面倒だ。キーワードは"nfo"。フォーマット非公開のDBを使うプログラムなんてクタバレ!

毎年のことだが、この時期になると、妙に、「早く作らないと」とそわそわする。昔だったら、うだうだしているうちに年賀葉書が売り切れたり、印刷が間に合わなくなることがあったが、今はそんな心配は要らないのに。。。

レイアウトは毎年のを使い回して、画像(イラスト)を新しく選び、文字(賀詞)と文字の色を変えた程度なのだが、結構時間を使った。イラストは、例年のように猫だ。黒猫にしたかったが、今年は丁度いいのがなかったので、日本的な猫にした。自分で描ければいいけれど、そんな能力は全くないので、他の方が描いた作品を選ぶしかない。でも、次点は黒猫のだったので、ブログ用に使った。

葉書用の絵柄は、柔らかく自然で明るい(ポップな感じもするが、使っている色が和風なせいか、そこまでくだけてない)色遣いで、新年らしくていい感じだと思う。ちょっと堅い感じがしたので、最初は選ばないつもりだったのだが、試しに配置してみたら結構いい感じだったので、採用した。新年の挨拶だし僕もいい歳なので、少し堅い方がいいだろう。黒猫じゃないけど、あの柄(白、茶、焦げ茶)も好きだ。というか、大体の猫は好きだ。そのイラストはイラストACに載っていたもので、なかなか作者のセンスがいいと思って興味があったのだが、名前が"acworks"なので、個人ではないのだろう。

これであとは、業者に発注するだけだ。ちょっと気楽になった。

ブログ用のは、ちょっと手抜きだが、シンプルに作った。本当はそのイラストを葉書に使いたかったのだが、目上の方も含めていろいろな人に出すにはどうかなと、ちょっと気が引けたのだ。どうぞ、新年にご覧下さい。

↓

のんびりしていたら、大変なことに気付いた。葉書に使ったイラストに書かれている花はタンポポのようだが、調べたら季節外れ(開花時期は3/10〜5/末頃(季節の花300より))なのだ。イラストを別のに変えるか、そのまま使うか、ペイントツールで花を消すかだが、色的に、消すとイマイチになってしまうので、消すのは良くない。調べても、正月に咲く、似たような花はない。仕方ないので、イラストを変えることにした。ガッカリと疲労。。。でも、発注する前に気付いて良かったよ。(18:30)

↓

ちょっとサビ猫のイラストを探したのだが、いい物がなく、仕方ないので、ブログ用だった黒猫を葉書用に昇格させ、3番目だった可愛いのをブログ用にした。明日発注だ。多分大丈夫だろう。(19:44)

↓

フォントを変えたり(たまには明朝体にしたくなった)、文字やイラストの大きさを微調整して、いつもの会社、イロドリに発注したのだが、近頃の僕はどこまでもうっかりしているらしく、年賀葉書でなく普通の葉書で注文してしまった。でも、それから1時間経たないうちに確認メールが来て、間違いが分かった。もし連絡がなかったら、間抜けで残念な新年を迎えるところだった。

それにしても、夜(22時近かった)だというのに、メール以外に電話までくれる熱心さに感心した。普通は、絵柄が何であろうと、「客の指定なんだから知らん」と、指定どおりにしてしまうじゃないか。とてもありがたい会社だ。ただ、「夜間の電話はなしで」という指定をしたはずだったが、葉書の種類と一緒にリセットされてしまった(ヘルプを見た時かも)のかも知れないから、不問にしたい。(11/22 22:15)

以下は余談。

数年前から、「黒猫」で画像を探すと、アニメ(元はラノベらしい)のキャラの女の子が出てくるようになった。ゴスロリみたいな服装で、古風な髪型が結構好きなのだが、さすがに使わない。そもそも、彼女は一体何なのか、いまだに分からないｗ

それから、写真は使わないことにしている。こんな子とか、出したい猫は多いのだが、会ったことも一緒に暮らしてもいないものを出すわけにはいかないと思う。イラストで人が入っているものも同様で、自分でない人間は入ってはいけないと思っている。

あと、猫のイラストで良くあるのは、ピンと立っているのだが、そういう月並みなのを描いて平気な顔して公開する人の気が知れない(もちろん、僕はそんなのも描けないけど)。特に黒猫は描きにくいせいか、そういうのが多い感じだ。

そうそう、僕は、柄がとても味わい深い、サビ猫も好きなのだが、イラストはなかなかなさそうだ。でも、実際に探しはしなかったので、来年は探してみよう。

あと、技術的なことだが、今年からLinuxに移行したので、原稿をMS Wordでなく、LibreOffice Writerを使って作った。それで、微妙に使い勝手が違ったり(業者の指示どおりにはできない)、ページサイズの指定がちゃんとできているのか分からなかったりして、最終的にちゃんと印刷されるのか不安はある。でもまあ、画面で見たら大体葉書のサイズだったし、pdfinfoで見たらサイズは去年と同じだったし、pdffontで見たらフォントは埋め込まれていると出たので、まあ大丈夫だろう。

最後に、今年からメールアドレスを書くのを止めた。随分長く書いていたのだが、賀状を見てメールをくれたという人は一人も居なかったからである。同じ理由で電話番号も数年前から書かないことにしたので、書いているのは名前と住所だけだ。技術が進むと昔に戻るのか。そのうち住所も要らなくなりそうだ。

Windowsの画像で、同じファイルを無駄にコピーしないように、ショートカットにしたものがあるのだが、それをLinuxに移す時、ショートカット中の、そのショートカットが参照しているファイル名を取り出す必要がある。

最初は、Linuxのstringsコマンドを使って自分で取り出そうとして、基本的にはできたのだが、日本語のファイル名はそんなに容易には取り出せないことに気付いて困った。その時、ふと、「もしかしたら、あの何でもできるexiftoolなら対応しているのでは?」と思って試したら、本当にできた。LocalBasePathでショートカットが参照しているファイル名が取り出せた。他に、WorkingDirectoryで作業ディレクトリが取り出せるようだ。

例:

exiftool -s3 -LocalBasePath ~/"Pictures/1961/祖父母のアルバム-001_サイズ変更.jpg - ショートカット.lnk" | nkf -u

↓

D:\Butty\My Documents\My Pictures\from old albums\1. 祖父母のアルバム\001_サイズ変更.jpg

まったく感心した。そして、この機能を使って、ショートカットをLinuxのシンボリックリンクに変換する(実際にはシンボリックリンクを新たに作る)プログラムを作り、問題なく処理できて、digiKamで表示できるようになった。

なお、変換する時には、WindowsのディレクトリをLinuxのに変換する必要もあるが、汎用にするのは結構面倒なので、ひとまず画像の変換専用ということにして、WindowsとLinuxそれぞれのトップディレクトリを固定した。

例:

ショートカットが参照しているファイルがWindowsのトップ(D:\Butty\My Documents\My Pictures)以下だったら、Linuxのトップ(/home/butty/Pictures)に変換する。

※前提として、WindowsとLinuxのトップディレクトリの実体が同じである必要がある。

(11/20 5:41 若干加筆・修正)

Linuxに乗り換えてから約1か月と10日。いろいろな問題が起こって、対処しながら使っているのだが、概ね問題ない。以下に、今までに気付いたことなどを書く(別途書いているgmusicbrowserの詳細は除く)。

Linux Mint 18 Xfce (OS, デスクトップ環境)

• デフォルトブラウザ設定がFirefoxで、Mintの設定を変えてもVivaldiにならなかった。以下の設定をして様子を見ている。→ 駄目だった(未解決)。
  • sudo update-alternatives --config x-www-browserでVivaldiを指定
  • xdg-mime default vivaldi-stable.desktop x-scheme-handler/http
• パネル(Windowsのタスクバーのような部分)にdigiKam5(画像管理ソフト)のアイコンが出ず、別のアイコンが出る(未解決)。

Dropbox Paper (クラウドメモサービス)

• 全般的に大きな問題はなく快適に使えている。古い物を除いて、ほとんどのドキュメントを移行したので、Evernoteを使うことはほとんどない。
• たまにサーバに繋がらないことがある。(WebもiPhoneアプリも)
• Evernoteのwebからのペースト時の制限
  • 埋め込み画像はペーストできない。
  • 文字サイズ・色・スタイル(斜体など)はペーストできない。 (サポートされていない)
  • チェックボックもペーストできない。番号付きの箇条書きになる。
• ドキュメントの暗号化はサポートされていない。
• 多段のインデントはサポートされていない。
• エクスポート(ZIP)ファイル中のファイル名は、ドキュメント名(=タイトル)になるのだが、タイトルに日本語などが入っている場合、タイトルの一部と通し番号になる。→ ドキュメント名の最後などに英語を含めると、判別しやすくなる。
• ドキュメント中の横線はエクスポートしたファイル(Word)に入らない。→ "---"などを使うことを検討中。
• ドキュメントのURLで他人がアクセス可能なので、流出に注意する必要がある。個別にアクセス不可に設定することは可能なようだが、全体のデフォルト設定はないようだ。
• ドキュメントのURLは、ドキュメント名をベースに作られているから、ドキュメント名の流出にも注意が必要かも知れない。ただ、全ユーザで同じトップURLで破綻しないのが解せない。隠れたログインがあるのか?
• クリップボードからの大きなサイズのペーストができない問題は、再発していない。

CrashPlan (クラウドバックアップサービス)

• 時々アップロードが停まる(下のグラフ参照)以外は問題なし。ただし、まだリストアしたことはない。
• 稼働時の平均アップロード速度: 約680KB/s (約5.5Mbps, 約60GB/日)
• 実際のパフォーマンス: 約1か月間(平日昼間は休止)で約1.4TBのアップロードが終わらず(アップロード済み: 1.3TB、残: 142MB; 約43GB/日)。
• アップロード速度の変化の例 (約18時間分。上がアップロード。アップロードのフルスケールは16Mbps):

CrashPlanのアップロード速度の時間変化

その他

• gmusicbrowser (音楽プレーヤー)
  • 基本動作は全く問題ない。音質に問題はなく(実際には、出力にはgstreamerを使っている)、ギャップレス再生でき、HDDにかなりの負荷を掛けない限り、音切れしない。
  • 以前も書いたが、プラグインのAlbuminfoは使わない方がいい。音楽ファイルを勝手に更新するので。
  • いくつかの不具合を修正済み/対処中、改良/改造中。
• Mozc (日本語変換プログラム)
  • MS IMEより良い点もあるが、良くない点もある(例: 自分で文節を調整しないと、思ったように変換できない場合があり、それを学習してくれない)。全般的には問題ない。
• Thunderbird
  • メインウインドウを2番目のディスプレイに置くと、ダイアログがほとんど2番目のディスプレイにしか出ない(未解決)。
• jEdit (テキストエディタ)
  • 日本語入力ができない(未解決)。以前はインラインでないながらもできたのだが。。。日本語を使うことは少ないので、その場合は別のエディタ(kate)を使ってしのいでいる。
• RSSリーダー
  • いろいろ試した結果、RSSOwlが良かったが、そのままではうまく動かず、以下の設定が必要だった。
    • cd /usr/lib/x86_64-linux-gnu && sudo ln -s /usr/lib/x86_64-linux-gnu/libhunspell-1.{3,2}.so.0
• 画像の管理
  • ACDSeeからの移行 (メタデータの移行)
    • 他の作業を優先しているため、進んでいない。
  • iPhoneからの画像取り込み
    • iPhone 6sのEXIFの回転情報がおかしい? EXIF情報に従って回転させると上下反転してしまう。→ 勘違いのようだ。ただし、iPhone 6sのカメラの画像は、水平に撮ると、180°回転して記録される。
• 動画管理
  • 管理ソフトはtinyMediaManagerを使う方針だが、他の作業を優先しているのと、下記の懸案事項(どうしても手間が掛かりそう)があって、移行作業は進んでいない。
    • DVDなどの実メディアを持っている(リッピングしていない)、タイトルなどメタデータだけのエントリ(placeholderと呼んでいる)をどうやってMusicBeeから移行するか。
    • MusicBeeのDBだけに格納された情報(例: ソースの種類)をどうやって移行するか。

(11/20 6:09 加筆・修正、グラフの交換)

先週、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と同じくらいの速度になったと思う。高速に動くプログレスバーは気分がいいものだ。

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

↓

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. こういうアイデアを入れて、最初に動かした時に結構うまく行くと、うれしくなる。「こいつ、動くぞ」と脳内に浮かぶかも知れないｗ

Linuxでの画像管理ソフトはXnViewMPに決めて使っていたのだが、もう一つの候補だったdigiKam(digiKam5)の方がいいことが分かった。決めた当時にdigiKamでなくXnViewMPにしたポイントは、以下だった。

• digiKamは画像ファイル名を指定できないので、(ファイルマネージャでダブルクリックした時の)ビューアになれない。
• digiKamは一括処理でメタデータやデータベースを指定するとハングする。
• digiKamはテーマの設定ができず、左側で出るツールチップの配色が悪くて見にくいのが直らない。
• digiKamはシンボリックリンクに対応していない。
• digiKamはACDSeeのキャプションに非対応。

ところが、今日、カレンダーでの画像一覧をしようとしてできないことに気付いて結構残念だったので、それができていたdigiKamを再度試し、設定を調整したり最新版に更新したら、すべて解決したのだ。

• (ビューアになれない件は、XnViewMPもビューアとしては使いにくいので、Pixを使っている。)
• 一括処理でハングする件は、なぜか直っていた。
• ツールチップの配色は、別の設定(ウィジェットのスタイル)で変えられた。
• シンボリックリンクは、XnViewMP同様、特別なsuffix(例: link)を割り当てて、それをMIMEタイプ設定に追加すれば対応できる。
• digiKam5はACDSeeで埋め込んだキャプションに対応している。

更に、digiKamはXnViewMPにはない、以下のような長所や便利な機能があるので、やっぱりdigiKam5を使うことにした。個人的には、機能や使い勝手はACDSeeに全く劣らないと思う。

• ACDSeeなどの他のアプリで設定した日本語のコメントが化けない(下図参照)。
• ブログ投稿画面やDropbox Paperに画像がドロップできる。
• カレンダーでの画像表示
• アプリ内での地図での画像表示

日本語のコメントの比較: 中央: XnViewMP(文字化け), 背景と右: digiKam5

PS. (全く関係ない話題だが、単独の投稿にするほどでもないので、ここに書く) LinuxでのエディタはjEditにした。それまではkateを使っていて、ちょっとした不満(例: インデントの仕方の違和感、検索が今ひとつ不便)がいくつかあったのを我慢していたのだが、大量のテキストのペーストでハングしたのですっかり嫌になってしまい、以前の候補で少し使っていたjEditに戻った。jEditはJavaで動くせいか結構メモリを食う(数百MB)のだが、重さは感じないし、いろいろ設定したりプラグインを入れて自分好み(WindowsのNotepad++に近い)にできたので、気に入っている。(11/3 16:56)

jEditのウインドウ

余談: 僕は、行番号は鬱陶しいから出したくないのだが、良くエラーを出して、その時、行番号で問題の場所を見つける必要があるので、仕方なく出している。

(11/4 6:14 修正・加筆)

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へのペーストがほとんどエラーになる。ベータのせいだろうか。ちょっと不便ではあるが、気を付けて使おう。→ 他のノートでも、大きいペーストは駄目になってしまった。ブラウザの再起動も再ログインも効果がない。不便なのでサポートに連絡したが、どうなるか。

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

↓

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)

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)

昨日辺りから、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. 同期終了後に２つの一覧を比較し、同期したファイル一覧にないファイルを削除する。
• 削除機能の基本動作は問題なかったが、ファイル数が多い場合に使用メモリ量や負荷が高くなる可能性があるので、要注意だ。

実装後、この同期プログラムで作成した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%程度まで上昇した。

ここまでやって大分良くなったし、プログラムもなかなか本格的になったのだが、まだまだ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 再生ゲインタグがない場合とアルバムアートのサイズが小さい場合について更新)

音楽プレーヤーと並んで重要な、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では動かなかった。

疲れたので、この週末はプログラミングは休むつもりで居たが、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の方が数十個多かった。どうしてかは良く分からないが、誤差の範囲だろうし、少ないよりはいいだろうｗ いや、実際には、デジタルなので誤差はないはずなのだが、まあ、聴いた時におかしければ対処するから問題ない。そのためにも、オリジナルのファイルは残しておくのだ。

あと、どういう訳かアルバムアートが出ない曲が結構あったので、手で登録したり、なぜか再生ゲインが入ってない曲があったので再度計算したり、同じアーティストでも微妙に異なる綴り(例: "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)

↓

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

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

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

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

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

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

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

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)

画像取り込みプログラムはちゃんと動くようになって、完成したと思っていたのだが、それについての投稿をしようとした時点で、思わぬ問題(の可能性)が見つかって、あと少しの状態である。それが、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番台で急ぐ必要がないので、なかなかやる気が出ずに居る。忘れて使っているうちに、「あれ? 取り込めない?」とか思って慌てるパターンかも知れないｗ 時間が経つと、既存のデータ構造を変更するのが大変になるので、早目に手を打った方がいいのではあるが。。。

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

昨夜、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)