piu lentoの日々

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