良くあることだが、今日は、何人かの人たちにsilver hammerしたくなった。題も概要も日付も名前も書いてない資料を配って平気な顔をしている人、そういう資料を平気で配らせる人、いつもだらだらと何事も引き延ばし、最後は時間がなくなってこっちを慌てさせ、とりあえず謝れば何でも解決すると思っている、「うすのろ」としか言いようのない人、「何か意見はありますか」と聞きはするが、実際には意見を求めてはおらず、何か言ったら逆に説教して来る人(要は、アリバイを作りたいだけ)、立場を考えれば、自分の不行き届きがすべての原因なのに、こっちにも問題はあったように言って、偉そうな顔をする人(偉いのに被害者意識)。

ま、世の中にはそういう輩の方が多いってのは分かっているので、そういうのの迷惑をなるべく被らないように、日々努力(先回り、念押し、馬鹿は無視、忍耐、諦め、などなど)するしかない。のではあるが、ちょっとMaxwellになりたい気はする。さっそく銀を集めて・・・ あ、銀だけじゃ柔らかいから、プラチナも要るかな? でも、高いから鉄でいいかな。(嘘)

参照: オリジナルアルバムの曲がYouTubeにないので、一番ましな、アンソロジーのこれを。

「その後」は、これになるのだろうか?w

 

PS. 今気付いたのだが、この曲で使っているのは、斧でなくハンマーなんだな。間抜けなことに、何十年もずーーーっと、斧をイメージしていたよ。(11/14 23:35)

  •   0
  •   0

今朝、Haru maro goroさんのブログの音楽の話を読んで元気が出たので、(Linux移行やGMBの改良が一段落したこともあって、)今日はドライブに行くと決めた。

余談: 実はずっと彼女のブログの更新を待ちわびていたのだが、RSSリーダーに更新の通知が出ていなかったので、きっと忙しいのだろうなと思って見に行かなかったのだが、昨夜か今朝に見てみたら、実は何件も投稿があったのだ。要は、Windows時代から使っていたものの、信頼性がないという札付きのQuiteRSSが駄目だったのだ。それで、QuiteRSSは即刻クビにして、新しいのを探している。

行き先は、もう1-2か月くらい前から候補にしていた、白河だ。白河の関所辺りにある、白河関の森公園を散歩し、街中の小山(友月山)を歩き、余裕があれば、とら食堂で白河ラーメンを食べ、更に余裕があれば、猫啼温泉を見物する(看板の写真を撮る程度)という案だ。

出発は7:30頃だったのだが、ガソリンを入れたので、実際のスタートは8時くらいになった。

9:40頃、公園に到着した。すごく楽だった。

道は、高根沢町までは、頻繁に左右の車線に移動する、スポーティーカーの馬鹿が2台いて目障りだった。片方はS660だったか。あと、途中に狸か猫かそれぞれか(どちらも狸柄だった)、轢かれた2匹が残されていて可哀想だった。

でも、高根沢を過ぎた辺りから快適になり、時間が経つのが速く、全然疲れなかった。ただ、やっぱり眠気は出た。那珂川町辺りの気温は7℃だったが、日射しが強くて車内は暑かった。

道端の木になっている(「沢山なっている」(「満載」とか「大漁」みたいな)状態を表す言葉が出て来ない・・・ → 「鈴なり」か。でも、僕は使わない言葉だ)柿が、とてものどかで良かった。何袋も収穫している人が結構いた。そんな柿の写真を撮りたかったのだが、結局、良いタイミングがなくて撮れなかった。

途中、猫が2匹、喧嘩したのかじゃれ合ったのか、道端に飛び出して来たので、少し慌てた。でも、道には出て来なかったので、轢かずに済んだ。賢い猫だ。

高根沢を過ぎた辺りでは"Stand by me"が、山道に入ってからは「渚のシンデレラ」が良かった。前者は、「(小規模だけど)いかにも旅行」という感じだったからだろう。とは言っても、それは僕の中でのイメージなので、分からないかも知れない。後者は、リゾートのお気楽な気分が気に入った。その頃は、道ががらがらで前後に誰もおらず、運転がとても楽で楽しくて、α波が出まくりだった気がする。

公園も暑かった。気温は11°C。早くも空腹になった。駐車場はガラガラで、風は少し強かった。さっそく散歩を始め、10:30頃、入口に戻って来た。すごくいい気分だった。木漏れ日や、時々漂って来る木の匂いが良かった。公園は良く整備されていた。

余り意識していなかったのだが、紅葉が良かった。山全体が紅いという訳ではなかったが、ぽつぽつと紅や黄色の木があって、それがとても綺麗だった。僕はその程度で十分な気がした。余りにも綺麗になり過ぎると、人が多く来てうるさくなってしまうし、飽きるだろうから。

公園の売店に「小峰シロ」なる萌えキャラグッズのコーナーがあった。それ以外にも公園にゆるキャラの像も立っていたし、いろいろ頑張っているとは思う。でも、僕はそういうのは本質的でないと思うので、評価しない。

あと、なぜか「なんだんべ」という栃木のお土産(お菓子)もあった。隣の県だからか。「なんだんべ」って言葉は、確かに馴染みの気がするが、若い人は使わないだろう。

お腹が空いたので、地元産のりんごジュースを飲んだ。甘くておいしかった。でも、結構甘いので、大瓶を買って連続して飲む程ではないと思った。代わりに、地産の豚(白河高原清流豚)を使ったレトルトのカレーがあったので、2種類(中辛とトマト)買って来た。あと、なぜか、公園の片隅に相撲道場があった。

お腹が空いたので、10:50頃、とら食堂に向かった。が、11:10に着いたというのに、既に満車だった。まあ、そんな予感はしていたのだが。。。狭くはない駐車場だったが、ちょっと見た感じでは一台も停めるスペースがなかったので、素直に通過した。すごい人気だ。あれでは、仮に停められたとしても、いつラーメンにありつけるか分かったものではなかっただろう。まあ、きっと、地元の人は行かない、「有名な店」なんだろうと思った。

仕方なく、コンビニでサンドイッチを食べて、猫啼温泉に行ってみることにした。ファミマのベーコンレタストマトサンドイッチはおいしそうだったのだが、古かったようで、パンが乾いていて駄目だった。あと、家族連れが多くて、レジで妙に長い間待った。まあ、それは仕方ない。

猫啼温泉は結構遠かった(白河から30kmくらいか)のだが、残念なことに、看板の写真一枚撮れなかった。温泉(川の向こうにあったようだ)に行く道が細くて曲がりにくく、一つの旅館だけでやっているようなので、見物客がうろうろできる雰囲気ではなかったのだ。

そんなこんなで12時過ぎに帰路に着いた。久しぶりにラーメンが食べたかったので、以前から目を付けていた大田原の味噌ラーメン屋に行くことにした。帰路も道が空いていて気持ち良かった。トムトムクラブの曲("Wordy rappinghood")で眠気が倍増した。そして暑かった。冷房が要った。

途中、黒羽刑務所の横を通過したのだが、所の公開が行われていた。中学の同級生のOくんが勤めていると同窓会で聞いたが、彼も居たのかな?

14:15頃、大田原のラーメン屋(味噌屋麺吉)に着いた。遅い時間なので、さすがに空いていた。とても空腹だった。北海道辛味噌野菜ラーメンに炙りチャーシュー1枚を頼んだ。約1000円。

が、空いているのに出てくるのが遅かった。10分は待ったか。あそこはダメかも知れない(今考えると、10分なら駄目という程は長くない。おそらく、ものすごくお腹が空いていたせいで、30分くらいに感じたのだと思う。ちなみに、「ダメかも知れない」は、リアルタイムでDropbox Paperに書いたのを載せた)。野菜が多くて良かったが、全体的にはまあまあだった。スープが濃くておいしかったが、おそらくというか当然、工場から送られて来たスープなのだろう。まあ、チェーン店なのを知っていて行ったのだから、文句は言えない。言えるのは、それならせめて速く出して欲しかったということだ。

14:50頃、店を出た。自宅まで約40kmなのだが、疲れや眠さで結構辛かった。行きとはえらい違いだ。でも、道は、時々軽く煽られるけど、全体的には長閑でいい感じだった。ただ、コンビニでトイレに行く度に(飲み切らない)飲み物や食べ物が増えるのが理不尽だった。トイレで鏡を見たら、なぜか髪の毛がぼさぼさで、嫌だった。

17時頃、無事帰宅した。キーボードを打つのが重く感じられるほど疲れた。

約9時間、217km。写真を70枚も撮った。

screenshot_2016-11-13-16-45-45_4278664893_v2

家(左下)→東→北→白河→東→(猫啼温泉)→南西→大田原→南西→家

不思議なのは、ちょっと白河に行っただけだったのに、何でこんなに時間が掛かったんだろうということだ。楽しかったからいいけど、どこかで居眠りでもしていたのかと思う程だ。確かにトイレは多かったし、うたた寝もしたが、何時間も費やす程ではないだろう。竜宮城に行っていたのか、あるいは、車のスピードが光速に近くなって、時間の進みがおかしくなったのだろうか?w (実際には、猫啼温泉が結構遠かったのと、光速高速を使わなかったのが効いたのではないか。)

車の走行距離は4万kmを超えたが、実に調子良く走っていた。帰りの山道では、まさに水を得た魚のようだった。行きはのどかに走ったのだが、帰りはなぜか「スイッチが入ってしまった」区間があった。

でも、実は、全く問題がない訳でもなく、先週の月曜の朝にエンジンが掛からなくて、ひやっとした。バッテリーが寿命のようだ。早く交換したいのだけど、その後は問題ないのと、届くはずの誕生月のクーポン(オイル半額)を待っていて、まだ交換していない。

IXY Digital 3000IS(ラーメンはiPhone 6s)で撮影

 

PS. 先日、白河高原清流豚のレトルトカレーを食べたのだが、トマト味も中辛もイマイチだった。ルーはおいしかったのだが、肝心の肉が堅く、味も特になくて駄目だった。まるで、子供の頃食べた牛肉大和煮の缶詰、あるいは、給食の鯨肉のような食感と味だった。いや、そっちのほうが良かったかも知れない。一体、試食したのだろうか? 地域のうりにするなら、もう少し真面目に作って欲しい。(2016/11/30 20:12)

  •   1
  •   4

以前からやりたかったのだが、gmusicbrowser(GMB)のレイアウトと使い勝手を改良した。Perlで書かれたGMBのプログラムや、レイアウト設定ファイルを、見様見真似で試行錯誤して、なんとかした。主な変更点は以下のとおりである。

  • メインウインドウ (ベース= "Lists, Library & Context")
    • 現在の再生ゲインのモードを、"--"(off), "T"(トラック), "A"(アルバム)のように表示できるようにした。アイコンでも表示可能なのだが、適当な画像ファイルがなかったので、とりあえず文字にした。この部品は新たに作った。
    • 上記再生ゲインの表示を押すと、off → トラック→ アルバム → offのように順にモードが切り替わるようにした。
    • タイトルなどの文字やアルバムアートを大きくし、パーツの配置を改良した。
    • ボリュームを水平のスライダーにし、音量の値も表示するようにした。ボリュームは実際にはほとんど操作しないのだが、現在の音量が一目で分かるのはいい。
  • デスクトップウィジェット (ベース= "screenlet")
    • 再生位置のバーの右に、再生順序(シャフルなど)、フィルタ(自動プレイリスト)、キューの状態(次の曲の指定の有無、再生中の曲が終わったら停まるなど)、再生ゲインのモードを追加した。これは、メインウインドウに表示されているものと同じである。
    • 再生位置のバーの中に再生位置(時間)を表示するようにした。
    • タイトルなどの文字を大きくし、発表年も表示するようにした。
    • 文字領域の背景を不透明にした。

まだ収まりが悪いところや色がイマイチなところがあって、いろいろ直したいのだが、かなり僕の理想に近くなった。特に、デスクトップウィジェット(MusicBeeのコンパクト/ミニプレーヤーに相当)で再生ゲインのモードが表示・切り替えできるのは、MusicBeeではできなかった(要望しても対応してもらえなかった)ことで、長年の悲願だったから、結構嬉しい。

残念なのは、以下のことはすぐにはできないことだ。どれも、GMBの構造上、設定や小さい変更での対応は困難なようだ。

  • メインウインドウの曲一覧などのフォントが(設定では)変えられない。見難くはないから、とりあえずは問題ないのだが、中国(台湾?)系のフォントのようで、例えば、「福」の偏が「示」になったりしているのがちょっと気になる。
  • (特にデスクトップウィジェットで、)タイトルなどが長い場合に、複数行での表示ができない。

それでも、こうやってプログラムや設定を変えることでかなりのカスタマイズができるところは、完全にMusicBeeを超えている。特に、レイアウトの設定ファイルは独自の言語のようになっているのだが、もしそうでなかったら、こんなに自由なカスタマイズはできなかっただろう。その点は(最初は訳が分からなくて戸惑ったものの)感心している。それで、偶然にせよ、なかなかすごい「原石」を見つけたものだと自画自賛している。

あと、PerlでGUI(GTK)のプログラムが作れるのは、PHPにはできないことなので、すごく羨ましい。それにしても、どうしてPHPではできないのだろうか?

試行錯誤して、なんとか、デスクトップウィジェットでタイトルなどが長い場合に改行できるようにした。GMBがテキスト表示に使っている、GTKのLabelウィジェットのワードラップの機能を使うようにした。これには、設定だけでなくGMB本体の改造が必要だった。

アルバム画像下の曲情報は、以下のようにデスクトップウィジェットのレイアウトファイル(desktop.layout)に記述して表示している。

HBtrk_info= 8Text(font= 'Noto Sans CJK JP Regular 10',
color=black, opacity=1,

width-chars=32, wrap=1, wrap-mode=word,
markup="$title
<span size='xx-small'>\n\n</span>
$artist<span size='xx-small'>\n\n</span>
$album ($year)")

下線部で最大幅とワードラップを指定しているが、これをサポートする機能をGMBに追加した。GTKを良く理解せずに作っているので、最大幅はピクセル数で指定したいができておらず(そのため、文字数によって、右側に微妙に空白ができたり、ウインドウの幅が広がったりする)、文字の大きさや空行(無理に作っている)の高さなど、いろいろ改良・調整したい点はあるが、とりあえず、やりたいことができたので、うれしい。(11/9 23:53)

空行の高さは、タイトルなどの各項目を別のLabelにして、パディングを指定して縦に並べることで解決した。ただ、最後の要素(アルバム)にはパディングを指定しなくても隙間が空くのが謎だ。

また、右側の微妙な空白は、width-charsを指定しなければできないことが分かった。ただ、その場合、max-widthやmaxwidthを指定してもウインドウの幅が広がることがあるのが謎だ。(11/10 6:22)

%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-11-10_06-03-57

行間を改良

HBtitle= 8Text0(font= 'Noto Sans CJK JP Regular 12', color=black, opacity=1, \
width-chars=32, wrap=1, wrap-mode=word, \
markup="$title")
:
VBmain = Cover(yalign=0, forceratio=1,hover_delay=1, \
hover_layout_pos=.5w x w,hover_layout=play_controls) \
8HBtb_ind HBtitle 4HBartist HBalbum

思わぬ欠点が見つかった。ウインドウのサイズが広がった後に、行数が少なくなると、下の方が空いて間抜けになってしまう。ちょっと調べたところでは、gtk_widget_set_redraw_on_allocate()で直りそうな感じだが、さてどうだろう? (11/10 19:46)

%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-11-10_19-43-56

間抜けな状態

更に試行錯誤したのだが、なかなか広がったウインドウは小さくならない。そこで、次善の策として、アルバムアートと曲情報の部分で余白を吸収するようにしてみたら、今までよりはマシになった。また、どういう訳か、アルバムアートが段々大きくなることがあったので、サイズを厳密に指定した。

%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-11-10_22-02-22

余白が目立たないようにした。

HBcover= Cover(minsize=250, maxsize=250, forceratio=1, \
hover_delay=1,hover_layout_pos=.5w x w,\
hover_layout=play_controls)
:
VBmain = _HBcover 8HBtb_ind _VBtrk_info

こういう試行錯誤って、GMBやGTKやPerlをもっとちゃんと勉強すれば効率良くできるのだろうが、趣味なのでそこまでの気力は出ない(もし、PHPでGTKが使えるのなら、俄然やる気が出るのだがw)。逆に、いろいろつまずいたり、回り道・寄り道しながら自分の希望を叶えていくのがおもしろいと思う。そして、仕事じゃないから最短経路をとる必要はなく、こういう遊びがかえって仕事のヒントになることもあると思う。(11/10 22:17)

(Labelウィジェットのワードラップ機能が今ひとつのせいなのか、)改行時に文字列右側にできる無駄な空白が嫌なので、ちょっと頑張ってTextViewウィジェットを使えるようにして、解決した。

ただし、どういう訳かTextViewの背景色を設定することが難しいようなので、とりあえず全体を白にした。それでも、どういう訳か微妙に色が違っていた(TextViewがわずかに黒くなっていた)ので、それに全体を合わせた。が、それでもまだ合わないようだ。あと、上下に広がったウインドウが狭まらないのは相変わらずである。そこら辺は今後の課題としても、かなり良くなったのは確かだ。

あと、TextViewにしたことで、曲名などをマウスで選択してコピーすることができるようになった。これもMusicBeeで叶えてもらえなかった(「ホットキーでできるからいいでしょ」と言われた)ことなので、感慨深いものがある。

ただし、曲名とアーティストとアルバム名をそれぞれ別の要素にしているので、コピーも別々にしかできない。とある理由(TextViewの中では、フォントサイズを容易に変更できない)で別々にしたのだが、できれば何とかしたい。でもまあ、選択・コピーできないよりはずっといいだろう。

ちなみに、デスクトップウィジェットのレイアウトファイル(desktop.layout)でのTextViewの指定は、以下のようになる(タイトル表示の部分)。

HBtitle= 5TextView0(font= 'Noto Sans CJK JP Regular 12', \
color=black, bgcolor=lightgray, minwidth=200, maxwidth=250, \
wrap-mode=word, markup='%t')

(11/11 21:18)

ちょっと苦労したが、曲名とアーティストとアルバム名を同じTextViewに入れられた。insert_with_tags()を使い、TextViewの中でフォントサイズを指定するようにした。これをTextViewのサブクラス"SongInfoView"と名付け、以下のような指定で曲情報が出るようにした(フォント指定は未実装)。

HBsong_info2= 5SongInfoView(font= 'Noto Sans CJK JP Regular', \
color=black, bgcolor=lightgray, minwidth=200, maxwidth=250, \
wrap-mode=word)

%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-11-11_23-15-12

全部の曲情報を一度で選択できるようにした。

まったく"The long and winding road"だが、いろいろアイデアが出て楽しい。(11/11 23:22)

選択はできるが、Ctrl-Cではコピーできないというオチがあった。右クリックでメニューを出して"Copy"を選択すれば可能なので、キーを登録すればいいのだろう。やっぱり長い道のりだw (11/11 23:51)

ショートカット(あるはアクセラレーション)は有効にならず、広がったウインドウは、どうしても縮まない。前者は、どうもOSレベルの設定が関係しているようだ。もちろん個人の設定ファイルもあるようだし、「デスクトップ環境」なのだから、その方が筋がとおっているのだが、アプリだけで手軽に対処するのが難しいし、ログインし直さないと試せないので面倒だ。そして、後者は深い謎だ。八方手を尽くしたが、どうにもならなかった。GTKをちゃんと勉強しないと駄目かも知れない。

そして、昨夜からの収穫は、(外見上は)本当に微妙な修正だ。タイトルなどを一度にコピーできるようにした時に、行間が数ピクセル広がってしまったのを直した。なんか、大昔、LaTeX(って知ってる方はいますか?)で資料を書いて、微妙なところを何度も直して(印刷して紙を無駄にして)、最後にできた紙(の内容でなく外見)を見て悦に入っていた頃の雰囲気を感じているのだが、なんとも複雑な気分だ。まあ、僕は賛同していないが、神は細部に宿るのかも知れないし、趣味だからいいよねw

%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-11-12_17-39-53

行間を調整

そして、何度もくどいのだが、(謎はあるものの)こうやって自分でちょっとプログラムを書いて自分好みに自由に改造できるのは、ありがたいし楽しい。ただ音楽を聴けるだけじゃなくて、その道具に手が入れられるようになったのは、常に歯痒かったMusicBee/Windows時代に比べるとすごい進歩だし、結構感激している(酔ってるせいもあるが)。これは、GMBの基本思想が良く、オープンソースにしてくれて、今の実装が悪くない(Perl自体が読みにくく、コメントは少ないけど、まあ酷くはない)ことに加えて、スクリプト言語(Perl)/Linuxベースであることもある(やっぱり、腐り切った窓でC#なんて使ってられない)。そして、こういう機会を与えてくれた、gmusicbrowserの作者のQuentin Sculoには本当に感謝している。いつか、改良・変更部分を整理して提出したいと思っている。(11/12 18:28)

ここからはいつものディスになるのだが、僕がMusicBeeを止め(られ)た原因は、作者の(勝手な)方針について行けなかったということだ。作者本人が個人で作っているのだから、何をしたって自由なんだろうけど、ただ、他人の意見を余り聞かず、ソース公開せずに他人の力をほとんど借りようとせず、Windowsにべったり固執し、全く必要がなくメリットが感じられないことを「改良」して、バージョンアップしたと言って悦に入っているのは、MicrosoftやAppleのように筋が悪いし、もし彼がソフト技術者だったら、「終わっている」と思う(一言で言えば、ガキだ)。途中まではいい方向に進んでいたし、機能的には他を寄せ付けないのに、とても残念である。(11/12 18:42)

試行錯誤の結果、デスクトップウィジェットのサイズ(特に高さ)が行数に応じて縮まるようになった。ごく当たり前に、ウィジェットのresize()メソッドに小さ目のサイズを指定すれば縮んだ。以前にも試したのだが、ウィジェットのnewの中から呼んだのが失敗して、それでresizeは使えないと思い込んでいたのだ。どうも、newが終わらないとうまく動かないメソッドがあるようだ。もちろん、newの中でresizeなんてするのは良くないのだが、GTKやGMBでウィジェットのメソッドの呼び出し順序が良く分かっていないので、newの時に描画する文字列を設定することになって、結果的にresizeもしている。(11/14 22:31)

その後、ワードラップでの改行の高さが若干高く(広く)て下の要素との区切りと見分けが付きにくい場合があったので、微妙に改良した。更に、プレイリストやアルバム中の何曲目を再生しているかを、"3/10"のように表示できるようにした。(11/18 21:52)

%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-11-18_21-48-21

微妙な改良

 

※まずいないとは思いますが、もし、日本語が読めてGMBを使っていて、「ここの投稿を参考に改造したいけど、詳細が書いてなくて今ひとつ分からない」という方がいらっしゃっいましたら、可能な範囲でお教えしますので、お知らせ下さい。でも、プログラミングのスキルがあることが前提です(申し訳ないですが、「コピペでなんとかしたい」という方は駄目です)。そして、そういう方は、自分でできてしまうような気がします。(11/10 19:31)

(11/11 10:14 わずかに修正, 11/12 追記)

  •   0
  •   1

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

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

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

  •   0
  •   1

Thunderbirdのアドレス自動補完は、宛先間違いが起こりやすいので、offにしていたつもりだったのだが、全く気づかないうちに昨夜失敗してしまった。まあ、相手はDropboxのサポートで、Ccに自分を入れたつもりが自分の会社メールを入れた程度で実害がなかったのが幸いだったが、会社でメールを見てびっくりした。

それで、気づかないうちにonになっていたのか、Linuxでは設定を忘れていたのだろうと思って、さっき設定を確認したら確かにoffになっていた。不思議に思っていろいろ確認したら、アドオンのCardBook(住所録)にも同じ設定があって、それで補完が働いていたことが分かった。それをoffにしてThunderbirdを再起動して、ようやく解除できた。

ものすごく腹立たしい。全く出来損ないとしか言いようがない。アドオンだって本体の設定は読めるだろうに、何で読まないのだろうか。それとも本当に読めないのか? あと、設定しても反映されずに、再起動が必要とかのメッセージも出ず、自分で気付いて再起動しないと駄目ってのも、能無しのやることだ。とにかく気に入らない。

一応書いておくが、僕はThunderbirdが好きで使っている訳ではない。逆に、そのいい加減な仕様が嫌いなくらいだ。でも、他にまともなメーラー、予定表、住所録がないから、仕方なく使っているのだ。もし、何かいいのがあったら、有料だって(高過ぎなければ)使うつもりで居る。

  •   0
  •   1

近頃はパイナップルとか言うのが流行っているらしいけど、昔の鼠先輩との違いがあるのか、そこだけが知りたいw

  •   0
  •   1

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に画像がドロップできる。
  • カレンダーでの画像表示
  • アプリ内での地図での画像表示
%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-11-03_14-12-48-1

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

 

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

%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-11-03_16-59-04_v1

jEditのウインドウ

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

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

  •   0
  •   0

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

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

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

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

  •   0
  •   0

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

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

必須

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

オプション

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

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

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

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

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

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

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

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

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

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

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

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

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

(11/4 5:50)

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

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

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

  •   0
  •   2

MusicBeeからgmusicbrowser(GMB)への移行は、かなり終わりに近く、もうMusicBeeは関係なくなって、GMBに閉じた話になっている。ただ、いつものことだが、ゴールは見えると遠ざかるもので、動作確認でいろいろな問題が出て来て、なかなか終わらない。予想外にも今日はほとんど全部使ってしまったのだが、あと少しでようやく本物のUSBメモリで試せそうな感じだ。以下に、つまづいたことを書く。

全体的な動作確認

ファイル名のクォート("や`や/などの特殊な文字を無効にする処理)がまだ不完全だった。これの対応はどうも場当たり的で良くないので、根本的に別の方法にした方がいい気がする。同期プログラムからOSのコマンドを呼ぶ(system()など)時に、ファイル名をシェルに解釈させないようにすれば、クォートしなくてもうまく行くように思うので、あとで何とかしたい。(が、そう思っていて実際にやったことは少ない・・・) → シェルに特殊文字を解釈させないようにする方法はないようなので、簡単には行かなそうだ。system()などを使わなければいいのだろうか? (23:28)

詳細な動作確認-エンコードしたファイルの確認

音量の正規化が全く駄目だった。再生ゲインはピーク値で決まっている訳ではないので、ファイルからピーク値のタグを抽出して、それで音量を調整しても駄目で、トラックの再生ゲインのタグの値で調整すべきだった。ffmpegにはタグに書かれたトラックの再生ゲインで音量を調整する機能がないので、soxiで(アーティスト名などのタグと同時に)トラックの再生ゲインのタグを抽出して、その値からffmpegに指定する音量の値を計算することにした(再生ゲインのタグがない場合は諦めるが、実際には、すべての手持ちファイルには再生ゲインのタグが入っている/入れるので、問題はない)。なお、exiftoolは処理が遅いので、基本的には使わないことにした(soxiで文字化けする場合は諦める)。

今、何となく、エンコードと音量の正規化にはffmpegでなくsoxを使った方がいい気がして来たので、あとで考えよう。soxが文字化けするのはMP3だけだろうから、その時だけ特別な処理をすれば良さそうだ。→ 残念ながら、soxはアルバムアートの埋め込みができないので、使えない。(23:25)

ポータブルHDDにポップス全曲(約1万曲)を同期して確認

処理が遅過ぎた。最初の同期では、1万曲をエンコードするのに約4時間掛かった。全部エンコードしたのだから仕方ないのだが、エンコードしない場合(更新ファイルの確認のみ)にも遅かった。1万曲で約1000秒(17分)掛かった。いろいろ調べたところ、上に書いたように、exiftoolが遅かった。それをsoxiに換えたところ、約10倍高速になった。ただし、soxiはMP3の再生ゲインタグを抽出できないので、その場合はexiftoolも使うことにした。

また、下に書いた、子プロセスの終了判定がうまく行かないために入れた処理も遅かったのだが、原因が分かったので省けた。現在は、(エンコードしない場合)1万曲で約100秒(1.7分)で済むようになった。これでもまだ遅い気がするので、あとで何とかしたい。

その他に、ファイル名のクォートの問題も再発したし、タグからアーティスト名を抽出する処理にバグがあったりもした。

それから、GUIのキャンセルの検出処理がうまく行かなかった。子プロセスの終了を判定する関数(pcntl_waitpid())が期待どおりに動かず、かなり手こずったのだが、結局は、それに渡すプロセスIDが異なっていたことが分かった。

なお、最初の同期(エンコード処理)時のシステム負荷なども調べたので、以下に書く。

  • CPU使用率: 約80% (同時処理数=5)
  • CPU温度: 約60℃
  • メモリ使用率: 約20%
  • GMBの音切れ: なし
  • 同期対象ファイル一覧のサイズ: 約1.5MB
  • 結果のログのサイズ: 3.7MB
  • ディスク使用量: 約55GB/約1万曲

使用率80%で動かし続けると、さすがにCPU温度が上がって、ファンが少しうるさくなる。でも、BIOSにファン回転数の調整機能があるようなので、安心だ。ファイル一覧のサイズは思ったより小さくて、同期プログラムなどは問題なく動作した。ただ、ログをエディタ(kate)にペーストしたらハングしてしまったのには、結構がっかりした。

その他の問題

  • キャンセル(処理の中止要求)の検出のためにzenityのプログレスの終了を待つつもりが、全部の子プロセスを待っていて、並列処理しているエンコードプロセスの終了でキャンセル処理してしまった。
  • [GMB] 再生中に再生ゲインがoffになることがあるようだ。メニューの表示と実際が合っていない。原因不明なので、追って調査する。
  • [GMB] 再生するだけでファイルが更新されて、同期対象になってしまう。プラグインalbuminfoが自動的にジャンルを更新しているので、一旦、albuminfoとartistinfoを使うのを止めた。あとで更に調査して修正したい。
  • [zenity] LANG=Cで起動して、日本語のディレクトリを選択すると、出力が"?????"になる。→ zenityは日本語(LANG=ja_JP.utf8)で起動することにした。
  • [zenity] プログレスのウインドウのサイズが大きくなる。原因不明。文字列(ファイル名)が長過ぎるからか。

今後

少し使ってみて、不要にファイルが更新されないことを確認してから、実際に車で使っているUSBメモリに全曲を同期して、カーナビで再生できることを確認したら、終了となる予定。ただ、上述のように、改良したい点もあるので、ゴールはもう少し先になりそうだ。

その後、いろいろ良さそうなアイデアが浮かんだので、これが完成する前に第2版に着手しそうだ。最もいい考えは以下だ。

この同期プログラムをGMBから呼ぶ時に使っているexportというプラグインには、曲のファイル名や情報をCSVやM3U形式で書き出す機能があるのだが、(必要ならそれを改造して)同期の時に使うタグ情報(アーティスト名、アルバム名、トラックの再生ゲイン値)を書き出せば、音楽ファイルのタグを読む必要がなくなるから、今の数倍〜10倍高速になりそう!

それから、もし上が駄目でも、次の案もいい。

今は音楽ファイルのタグは外部プログラム(exiftoolやsoxi)で抽出しているが、実はPHPのライブラリでも取得可能だ。php-getid3というライブラリはいろいろなフォーマットに対応しているから使えそうだ。これを使えば、外部プログラムを呼ばなくて済むので、数倍高速になる可能性が高い。

更に、もし外部プログラムを使わないで済めば、特殊文字のクォートが不要になるので、プログラムが「マトモ」になる。ただ、ffmpegは必ず使うので、特殊文字の展開をしないsystem()関数を作る必要はある。

そして、そろそろプログラムの改良や修正が怖くなってきた(間違ったら戻れない)ので、GitやSVNのようなバージョン管理システムを入れようかと思っている。→ ローカルだけで使うのであれば、Gitがとても楽なことが分かったので、それにした。GUIはSmartGitを試している。(10/31 22:55, 11/1 6:39)

  •   0
  •   0