piu lentoの日々 (piu lento days)

昨日の午後、プログラミングがうまく行かない時だったか、突然、なぜかクラウドストレージ(Backblaze B2)への自動バックアップに失敗したというメールが来た。Linuxでは、定期処理(cron)で何かエラーが出るとメールが来るのだ。そのうちに、同じ処理をしているこのブログサーバからも来た。

その内容は認証エラーなのだが、それまで何も問題なく動いていて、ソフトや設定を変えた訳でもなく、ログを見ても皆目見当がつかず、サーバダウンでもなく、検索しても特に出て来ず、(リトライを失敗するたびに)エラーメールが連続して来たので、ちょっと泣きたくなった(というか、何もかもを破壊したくなったｗ)。

それでも更に検索してみると、B2のAPIにバージョンがあるようで、バックアップに使っているプログラムは古いバージョンを使っているようなので、その古いAPIが廃止とか変更になったのかと想像した。

それで、Backblazeに問い合わせる他に、バックアッププログラム(duplicacy)のフォーラムにも、上述のことを含めて問い合わせた。ただ、日本だと時差があるので、すぐに回答は来ないし、そもそもまともな回答が来るのかすら怪しい。Backblazeは、以前出した問い合わせにちゃんと回答して来たから、待てば回答は来るだろうが、APIの変更だとしたら、対処してくれるかは怪しいものだ。そして、duplicacyもどうだか分からなかった。ソフト開発者は、ちゃんと対応する人も居るが、うやむやにするとか無視するとか突っぱねる人も多い。だから、がっかりしたりイライラするのが嫌で、近頃は滅多に出さず、我慢したり自分で何とかすることが多い。ただ、今回は、バックアップはかなり重要なので、駄目元で出した。

とりあえず、試行錯誤して回避策が分かって急ぐ必要がなくなったから、この件はあてにせずに気長に待つことにして、その日は寝たｗ

起きてメールを見たら、驚いた。まず、duplicacyのフォーラムでは同じ問題を見付けた人が素早く修正してくれ(メールを見たら、投稿してから2時間以内だったようだ)、正式版も更新され(修正が投稿された2時間後)、Backblazeからもサーバの修正をしたというメールが来ていた。もう、120点あげたいくらいだ。

たまにはこういうこともあるものだ。だから、諦めずにサポート依頼を出すのも、無意味なばかりではないものだ。

ここまででやめとけば「いい話」で終わるのに、いつものように毒付くとｗ、四季のある美しい国のほとんどの会社とか、デザインは美しい(自称)、アホ不思議なくらい信心深いユーザの多い会社とか、始めるのは早いけどやたらに飽きっぽくてすぐに梯子を外す、巨大な検索会社の連中に爪の垢でも飲ませたいと、今思った。

今年は市のがん検診制度を利用して、胃がん検診は胃カメラにした。今までの会社の検診では「バリウム」だったが、あれで一体何が分かるのかと思う。胃カメラは費用や時間が掛かるといっても、こうやって市ですら安く提供できるのに、会社の検診センターではしない(「知らない・できないふり」)というのは、明らかな手抜きだと思うし、良識を疑う。人数が多くて大変なのは分かるが、働いていて本当に必要な人に無意味(逆に危険すらある)な検査をして、それでいいと思っているのかと思う。

案内が来るまでは、いわゆる「人間ドック」を考えていたのだが、3-4万円も掛かる(補助は出るものの1万円程度)ので、内容を検討したら、市の制度でもそれほど不足がないので、とりあえずはそれで済ませることにした。一番大きかったのは、胃カメラができることだ。そうでなかったら人間ドックにしたと思う。笑えるのは、人間ドックでもバリウムのところがあることだ。何だかねえ・・・ 不足なのは、腹部超音波だ。自費だと6千円くらい掛かるとのこと。自覚症状がある訳ではなく、今までも毎年していた訳でもなく、半ば趣味で受けていたのでｗ、来年にした。

探したら、意外にも近くの医院でも胃カメラができるので、久しぶりに行った。電話で聞いたら、慣れない方だったようで、最初はがん検診と特定検診を全部受ける話だったのに、中身の話になって「胃カメラをお願いします」と言ったら、胃カメラだけの話になってしまっていた。それでも、ちゃんと次回(結果を聞く日)は残りを受けられる手配をしたので、問題ない。

意外だったのは、同じ「胃カメラ」でも、通常のものとがん検診のものがあることだった。がん検診のものは、費用を抑えるために生検などはしないとのことだった。自覚症状はないし、去年も問題なかったし、問題があれば知らん顔することはないだろうから、その時はまた診てもらえばいいと思って安い方にした。それから、この医院(医師)は口でなく鼻から入れるのを推しているようだった。打ち合わせの時に鼻と言われて、やっぱり痛そうだし、僕は鼻が詰まり気味で中が狭そうだからちょっと遠慮したのだが、鼻からしたいようだった。それで、鼻が駄目なら口に変更できると言っていたので、嫌な予感はしたものの、物は試しと鼻で同意した。

検査は先週の予定だったのだが、所要である病院に行ったら調子がすごく悪くなってしまい、今日に延ばしてもらった。準備の時に、看護師さんがパイプを挿してどちらの鼻の穴が通りやすそうか調べたら、どちらも入らなくて笑った。慢性鼻炎(鼻詰まり)のせいで中が狭くなっているようだ。それで口に切り替えたと思ったのだが(実際、喉の麻酔もした)、医師は鼻にチャレンジする気満々で、嫌な予感はしたのだが、さすがに止められないからやらせておいたら、意外なことに、最初に右から入れたらスルっと入った。(じゃがさんの情報で)心配していたのだが、鼻は痛くなかった。麻酔が効いたせいかも知れないが、腕がいいのだろう。

管は結構太かった。去年の口からのと同じくらいで、直径5mmはありそうだった。事前に見ていて、「これは無理だろう」と思っていたが、上に書いたようにスルっと入ってしまった。でも、喉は何度も「おえっ」となったので、鼻だからといって全く楽な訳でもなさそうだ。「おえっ」とはなったが、今回の医師は去年よりは上手だと思った。看護師さんも親しみやすくて良かった。

検査中にやたらにほめられて、少し気分が良かったｗ ただ、看護師さんも医師も、なぜか「上手ですよー」とほめてくれたが、鼻や喉に管を通されるのに上手も下手もあるのだろうか?ｗ そもそも、上手なのは医師と看護師さんだ。

検査後に画像を見た感じでは、大きな問題はなさそうとのことだった。ただ、長年のピロリ菌(除菌済み)のせいで胃壁がザラザラ・デコボコだとか、逆流性食道炎などはあった。たまにある胸焼けもそのせいとのことだった。いい薬があって、最初に連続して飲めば、あとは胸焼けの時に飲むだけでいいというのを処方してもらった。対症療法でずっと飲み続けるのは嫌だが、それならいいと思った。

そして、一番問題なのは血圧だった。医師はそれほどでもなかったが、看護師さんは結構心配してくれて、何度も測り直してくれた。去年から約1年間様子を見ていたのだが、暑くなっても下がる気配がないので、検診などが一段落したらそこで診てもらおうと思っている。今は、上が平均150mmHg前後で、結構頻繁に軽い頭痛がするようになったので、薬も仕方ない。

あと、今年から無料で受けられるという風疹の抗体検査を、先日の打ち合わせのついでにしてもらって、今日結果を教えてもらった。自分では罹った記憶がなく、予防接種もしてないのに「抗体あり」なのは意外だったのだが、かなり多い(200以上)ので、充分接種の必要がないというのがおもしろかった。はしかになったのは記憶にあるが風疹はなく、いつの間にか罹って治っていたのだろうか。風疹をはしかとか水疱瘡と思い込んでいたのかも知れない(昔は、そういうのは特に医者に行くこともなく、行っても特に検査などせず、数日間休んで寝てれば良かったので)。だから、逆にそこら辺の抗体がなくて、あとで罹ってひどい目に遭うのだろうかと今気付いた。が、まあそれもおもしろいからいい(本当に??)。

胃カメラの費用は3200円くらいだった。ただ、逆流性食道炎の薬が出たので、その費用は別に掛かった。

次回持参する大腸がんの検便の説明を看護師さんが丁寧にしてくれたのは、いくら何度もやって慣れているとはいえ、今までそんな説明なんてなかったので、ありがたかったしうれしかった。しかも、(小さくて書きにくいから、)日付を容器に書かなくても、袋に書くだけでいいという、細かい親切心もありがたかった。

結構、小さい子連れの父親(単独)が多くて感心したし、時代を感じた。あの医院は、子どもなどで混んではいるが、雰囲気が良くて、行くと元気が出るのがいい。先日行っただけでなぜか体力を奪われた大病院とはエラい違いだ。ただ、帰って食事をしたら、さすがに疲れが出て来て眠い。と言いつつ、これを書いてしまったｗ

(17:15 加筆・修正)

前の会社で、若い社員が見たこともない妙な車※で出勤して来たのを見て、何だろうと思って調べたらポルテだった。それ以来、この車を見るたびに(その人を思い出すとともにｗ)いろいろな想像をする。

※補足: 一見パッソのような感じだったので、「まあ、＊さんも(当たり前だけど)普通の車に乗ってるよね」と思って(少しがっかりして)いたのだが、良く見るとすごく妙だったので、俄然気になった。

車の概要

• 左側だけスライドドア(だけ。普通のドアなし)という、全く不思議な仕様 (同じクラスに、両側スライドドアの車種もあるようだ): こんなの見たことなかった。
• 元はパッソ(前の型)? (ちょっと見ただけでは、僕には区別ができない)
• 外見は可愛いけど、やり過ぎでない(派生種のスペイドはBb的雰囲気)ところに好感が持てる。
• エンブレムが違うタイプがあるようで、そこも謎(スペイド?)。

僕には、普通の人が「どうしてもポルテじゃなきゃいけない」と思う理由が思い浮かばない。普通のコンパクトならパッソでいいだろうし、スライドドアが要るなら両側に付いている車種の方が便利なように思う。

乗っている人を想像してみる。

• 若い、ちょっとおしゃれなお嬢さん? (実際には主婦やおばさんも居そう)
• 車にこだわりのある人(変わった仕様に惚れ込んで)
• 車なら何でもいい人(安いから?)
• 高齢のご家族思いの人?
• 不思議ちゃん??

結局、プロファイリングはほとんどできない。平均値を推測すると、「変わり者」なのかも知れないｗし、幅広く分散していて平均に意味がないのかも知れない。

それはともかく(そういうことがあるから?)、パッソに比べると親しみが湧くし、乗っている人にも興味が湧く。どういう理由で乗っているにせよ、安直にメジャーに走ってないところに好感が持てるのだ。

(21:16 補足)

3回目の車検なので、ディーラーに行って来た。車には問題なく、ブレーキ液、LLC、発煙筒の交換程度で済みそうだ。ちょっと気になっていたのだが、ブレーキパッドは意外にもまだ大丈夫なようだ。走行距離は約54500kmで、まだ交換したことがないのだが、随分もつものだ。きっと、(通常時は)車間を充分開けてなるべくブレーキを踏まないようにして、赤信号の前などは、後ろに車が居ない時は惰行しているせいだろう。

ブレーキパッドの減りについては、仮説(もしかしたら定説なのかも)あるいは謎がある。同じスピードから停まるのでも、ゆっくり減速した方が減らない気がする。スピードが同じならエネルギーも同じなので、ブレーキの減りも同じはずなのだが、何かが違うようだ。結構な謎だ。

減り量が加速度に関係するとすれば、強く踏む(急に停める)ほど減りが大きくなるだろう。そういう点では、全然得意でないのだが、物理の力積で考えると、車のスピード(→ 運動量: mvのv)を急に(後述の力積: F⊿tの⊿tが小さい)減らすと力積(→ F⊿tのF)が大きくなるから、ブレーキに掛かる力が大きくなって減るのだろうか? → 式で書いたら分かった気がする。やっぱり、加速度が関係しているようだ。(← 実際には誤りだった。6/25 7:35の追記を参照のこと)

運動量と力積の関係: m⊿v =F⊿t (mは質量) より、
F = m⊿v/⊿t (⊿v/⊿tは加速度)
→ 速度vの変化時間⊿t が小さいほど(加速度は大きくなり)、力Fが大きくなる。

(6/25 7:35追記) その後、ブレーキパッドの減り量は、掛ける(踏む)力の大きさだけでなく、力を掛ける(た)時間にもよるのではないかということに気付いた。例えば、弱く掛けても長時間掛け続ければ減り量が大きくなるということだ。すると、上の式ではF⊿t がその力と掛けた時間なので、結局、減り量はm⊿vによることになる。

つまり、一番最初の「エネルギーも同じなので、ブレーキの減りも同じはず」の考えどおり、同じスピードなら減りも同じになりそうだ。ただ、減りに非線形性があって、強く掛けると減りが速く(または遅く)なる可能性もあるが、それについては調べないと分からない。が、理論上は、同じスピードを停めるなら、停まるまでの時間(急ブレーキかそうでないか)に関係なく同じ減りと言えそうだ。

更に余談だが、質量が小さいほど力Fは小さくなるので、軽い車のブレーキは減りにくいだろう。つまり、軽さは正義なのだｗ あとは、停まりながら(例は書かないが何らかの方法で)車を軽くするとブレーキの減りも減るだろうが、なかなか現実的ではない(爆)。ロケットのような話か。

もう一つ上の式から言えるのは、急加速(加速度が大きい)すると力Fが大きくなるので、(当然ながら)燃料を食う。この時も、軽い車ほど燃料消費量の増加は少ない。やっぱり、軽さは正義なのだ。

ただ、同じ式から軽さにはデメリットもあることも分かる。同じ力を受けた場合に、軽い物ほど加速度が大きくなるのだ。例えば、大型トラックに追突された場合、普通車より軽自動車の方が吹っ飛びやすいってことか(加速度の大きさと吹っ飛ぶのは違う気もするが、ダメージとしては似たようなものか)。

これを緩和するには、ブレーキと同じく現実的でないが、追突される直前に(何らかの方法で: 地面に杭を打つ?)車を重くすればいい。仮に車が充分に重くなって、衝突しても動かなければ、加速度は0だ。果たしてそれで乗員が無事かは疑問だが、そもそも停車していて加速度が0なら動かないので大丈夫という話になる。本当に?? → 普通の車だと(戦車や装甲車の類でないと)、ぺちゃんこになって駄目でしょう。残念。。。

あとは、エンジンブレーキの使用量の差が効くのだろうか。ただ、僕の場合、面倒なので、停まる時にシフトダウンはあまりせずにニュートラルで惰行するから、エンジンブレーキは関係ない気もする。これに関係するのは車の摩擦係数で、エンジンブレーキを使わなくても効くが、まあ、それほど大きくはなさそうだ。

他の可能性としては、仮に完全に停まる場合には1回ごとの減りが同じだとしても、ゆっくり減速するのを習慣にしていると、結果的に長期的には停車する回数が減る(その間に信号が変わるなど)ためにブレーキの減りが少なくて済むことはありそうだ。これは結構おもしろい。

それはともかく、毎回そうなのだが、代車の軽の質の向上に感心した。質といっても無駄な高級「感」などではなく、走行性能である。乗るたびに良くなっている気がする。今回はワゴンRの「ハイブリッド」(本物かは不明ｗ)だったが、あれならコンパクトカーの出る幕はなさそうだ。確かに、安全性は普通車に比べたら劣るのだろうが、まあ、運の問題もあるし、僕は「適宜」でもいいかなと思う。僕が「とりあえず」車を買うことになったら、(安いのであれば、)そこら辺で手を打つだろう(まあ、どちらかと言えばアルトの方が趣味だがｗ)。他人にも勧めたいが、安全性の懸念があるので、敢えてはしない。

出だしや巡航では全く不満はない。出だしでは、軽くアクセルを踏むだけでいつの間にか60km/hくらい出ていて、後ろの車と距離が付いていることが多かった。モーターアシストのおかげか、全然うるさくならないので、スピードが分からないせいもありそうだ。もちろん、小さくて軽くて取り回しやすいのはいい。

欠点としては、(ATはずっと昔からそんな感じなのだが、)中間加速の時だけ、キックダウンしてもうるさくなるだけでもたつくことくらいだ。この点では是非MTにしたい。それでも、難しいことを考えず、余裕で運転できるのはいい。降りる時に気付いたのだが、意外にもドアがかなり重そうで、随分安全そうな感じがした(本当かどうかは不明)。あと、アイドリングストップは全力で止(や)めて欲しい。そのうち、そういうハッシュタグ(#stop-idling-stop?)でもできないものか? 仮に買うとしたら、ないものに限る(なんてこと言ってるから、選択肢が減るのだがｗ)。

あと、オーディオも(ラジオも)カーナビもないのに、なぜかヘッドアップディスプレイのスピードメーターが付いていたのだが、意味あるのだろうか? 元々のメーターが中央に寄っていて見難く(そのせいで、しばらくスピードが分からなかった)、その代わりになるからいいが、それならメーターを普通の場所に付ければ充分な気がした。あと、最初、メーターに"D"と出ている(写真中央付近)のが"0"(km/h)に見えて、HUDに出しているから"0"にしているのかと誤解した。

それから、代車のエアコンは(新車らしいにも関わらず)今の車と同じくらい効かないｗ だから、帰納的に(?)僕の車のエアコンには問題なさそうなことが分かった。

帰路、すごく懐かしいスカイラインがあった。小学生の頃、見た気がする。「ケンメリ」なのだろうか(その頃は全然詳しくなかったので、分からない → 調べたら、燃料タンクの蓋の位置から、その次の「ジャパン」のようだ)。ナンバーも当時の感じ(栃57)だから、ずっと乗っているのだろうか? 廃車せずにいればそのままなのか。当時の車らしく、タイヤが分厚かった。さすがに僕でも、少し薄い方がいいと思った。あと、仕方ないことだが、ボディなどに少し錆が出ていた。

ディーラーはいつものようにアットホームで良かった。先日所要で行ったある病院(人の問題だけではないが、行くだけで疲れ果てる※)とは全然違う。あと、担当のおじさんは、「そろそろ乗り換えはどうですかー?」などと聞くなんて野暮なことをしないばかりか、相変わらず「アルトワークスはサスが硬過ぎるから勧めない」と言っていた。いつもながら、そこが問題だｗ それにしても、普通の店なら、たとえ硬過ぎて実用性が皆無だって、「本格的な走りができて速いですよー」とか勧めて来るだろうに、本当に正直なところにいつも参っている。そこが彼の技なのかｗ

※金曜にその病院に行ったら(僕の治療などではない)どうにも調子が悪くなって、昨日はダウンしていた。そのため、昨日予定していた胃カメラを延期した。今朝も回復したとは言えなかったので、車検を延期しようか迷ったのだが、頑張って行ったら元気が出た。

PS. 無事終わって、さっき引き取って来た。整備費用が意外に高く、約3.6万円(税込み)だった。10万円持っていけば(自賠責や税金などを合わせても)お釣りが来るだろうと高をくくっていたのだが、あっさり超えた。「結構高いですね」と口から出そうになったが、止めた。普通の店なら絶対に言うが、それほどその店を信頼しているのだ。

調べてみると、高かったのはLLCの部品代(液の代金)で、6000円(1500円/l)だった。確かに、この分がなければ10万円で足りて、想定内だった。LLCの交換は自分では無理だ(やればできるが、やる気はしない。手間以外にリスクも高い)。まあ、7年で交換したので、1年当たりでは約千円と安いものだ。他の料金はリーズナブルだった。明細を見るまでは、「発煙筒が高いのかな(3千円くらいかと思った)。自分で買えば良かったか、失敗したな」と思っていたが、そんなことはなく、千円未満だったｗ ただ、消費税が高く、3千円近かった。秋からは更に上がるのかと思うと、遊民としては溜息しか出ない・・・

ちなみに、いつものように、帰る時にはブレーキが効きすぎて(代車よりずっと効くので、そう感じる)戸惑った。あと、代車に比べて意外に加速が悪かったｗ おそらく、代車は感じが良く分からないからテキトーにアクセルを踏むので、加速し過ぎていたのだろう。ただ、当たり前のことだが、「軽さ」は代車の方が確実に上だった。これはもう、どうしようもない。それにしても、自分の車に戻って感じた、シートや運転席のフィット(タイト)感とか、ギアがスコっと入るのは快感だった。

(13:37, 14:09 わずかに変更+加筆; 19:22 終わった件を追記, 題を少し変更; 6/25 7:35 ブレーキの減り量の考察について訂正)

やっぱり、役人てのは平均値としてはクソアホ無能揃いだということを確信した。

ニュースで、茨城県の読みがなを30年以上も誤ったままにしている役所の話を読んだが、その画像を見て、それよりもムカつくことに気付いた。

画像の赤丸はそのニュースに元々付いていたもの。下の茶色は僕が気付いたものだ。

30年以上も読みがなすら直せさないところでも、元号は一瞬で直せるすのか。

どこを見て仕事をしているか(いや、そもそも仕事なんてしてないのだろう)が良く分かる。全くアホかバカかだよ。「お前らにやる金なんてない!」と言いたい。何が「マスターデータが誤っている」、「会員が多い」だよ。元号だって同じことだろうが。その論理なら、未だに「昭和」で出せよ。クソが!

(2番目) 以下は6/12に書き掛けたものの、全くおもしろくないので止めたものだが、ついでに出す。

悪いことがない振りをしていれば、すべてうまく行くのか。自分で書かせた報告書を「読んでいない」と威張って受け取らなければ、それが指摘しているであろう問題までなくなるのか。

おもしろい論理だ。小学生レベルだな。いや、小学生に失礼かも知れない。

そして、その問題が発現する頃にはリタイアして悠々自適で知らん顔? それなら本当に問題は起こらないね。彼らだけには。

とにかく、気楽にお仕事をしている連中につける薬はない。

でも、そういう時に作ったものには結構高い確率でバグが潜んでいるので、喜ばしいばかりでもないｗ

半ば疲れつつも飽きずに作っているMlhi(音楽再生履歴・感想の記録・検索システム)のwebの見た目を改良できたので、結構進んだ気がした。とはいえ、それは、SpotifyのミニプレーヤーにMlhi対応機能を組み込むための準備なので、実際にはそれほど進んでいない。というのは昨日の話で、今日は更に進み、ミニプレーヤーにMlhi対応機能を組み込んで動き出した。いろいろ改良したいことはあるが、「一段落」している。

昨日からの作業は、ミニプレーヤーに対応機能を組み込むための準備とその実装である。いろいろな機能を組み込みたいが、「ミニ」なので表示に使える面積が小さい。そこで、何をどのように表示するかの検討が重要だ。

今回組み込もうとした機能は、以下である。

• 評価の表示
• 再生履歴の表示
  • 再生回数
  • 完奏率

評価はwebと同様にアイコン(♥など)と色でいいが、再生履歴は、回数と完奏率を別々に出すのではスペースを食うので、減らし方を考えた。デザインは全く素人だが、その代わりに(結果的に)工学的に考えた。

スペースを節約するため、表示する部品を一つにするとすると、2つの情報を1つにすることになるので、2次元とか3次元的な表示になるのだろう。最初は、マークの形と色で表すとか小さな円グラフにするとかを考えたが、どうも今ひとつだった。完奏率は、やっぱりwebの棒グラフが見やすい。それで、ミニプレーヤーを眺めながら考えているるうちに、再生位置のバー(プログレスバー)が目に付いた。これがうまく使えれば、スペースとしては全く問題ない。そして、プログレスバーの下に完奏率の棒グラフを並べることを思い付いた。この時、再生回数はグラフの色で表すのだ。早速、イメージ図を描いて検討した。

なかなか良さそうな感じなので、試してみることにした。ただ、いきなりミニプレーヤーに入れるのは大変だし、駄目だった時に疲れ果てるので、試しにwebに入れてみた。すると、結構いい感じにできたので、採用することにした(webもこの表示に変更した)。ついでに、以前からやりたかったのだが、アイコンなどへのマウスオーバーで値(評価の値や再生回数)を出せるようにした(図上方のベージュ色の四角は、完奏率にマウスオーバー)。再生回数を表示しないようにしたので、なおさらこの機能が必要になったのだ。

あとで気付いたのだが、棒グラフでの表示方法は、以前から謎だったYouTubeでの良い評価率の表示(なのだろうかと、今推測している)に似ている。棒を細くするところは、まさにそのものだ。

Webのいいところは、ページの表示内容をプログラムで書けるので、ある値の色やその段階がどのようになるか試しに表示させられることだ。これで色や計算式を調整・確認した。のだが、例によって思わぬ間違いがあった。再生回数から色への変換式に対数を使ったのだが、PHPのlog()は自然対数(普通は"ln()"と書くと思っていたのだが、log10()があるし、数学ではlogとlog₁₀だから、僕の思い違いかも・・・)で、想定していた常用対数(底が10, "log10()")でないために、実際には変な値になっていた。それでも、対数や色は細かく確認できない(やればできるが、それらしかったので正しいと思い込んだ)ために気付かなかったのだが、ミニプレーヤー(計算にはbcというプログラムを使ったので、自然対数しか使えない)に組み込んだ時にwebと色や係数が違うことでようやく気付いたｗ

上に少し書いたが、再生回数を色で表すために数値を色に変換する処理が必要で、これにも少し苦労した。最初は、グラデーションの方法・式(検索するといろいろ出てくる。が、ほとんどはRGBで計算していて、HSVでなくていいのかなと思う)で無段階にする(例: サーモグラフィーのようなイメージ)ことを考えたが、そこまで細かく色が判別できる訳ではないし、その必要もないし、グラデーションでは常に期待する(好きな)色が出る訳ではないので、好きな系統の色を選んで10段階(色)にすることにした(今はとても便利で、色チャートのサイトがいっぱいあって、いくらでも色が選べる → 例1, 例2)。ただ、それでも問題はあって、使い続けると曲の再生回数が無限に増えるので、いつかはオーバーフローして「最大」の色ばかりになってしまうことだ。色数を固定したままそれを防ぐには、何らかの方法で再生回数を色に割り当てる(対応させる)必要がある。

再生回数の最大値は、将来は例えば100回とかにもなるだろうし、一方で、常に「1回」という曲もあるだろうから、最大値との比でのリニアな変換にしたら、全体としては再生回数の多い曲は少なく、ほとんどの曲は小さい値だろうから、(少ない回数を薄い色に割り当てた場合)ほとんど見えなくなってしまう。それで、標準偏差で再生回数の分布を求めて「何とか」(ここには特にアイデアはなかったｗ)できないかと思ったのだが、使っているDBのSQLiteにはその機能がない。自分でSQLを書けば出せるが面倒なので止めて、ふとひらめいた対数を使うことにした(音量は対数表示することから連想したのだと思う)。対数を使うことで、小さい値の変化は拡大され、大きい値では圧縮されるので、結果的に幅の広い再生回数の違いが見やすくなるはずだと考えた。音で言えば、レベルメーター(今は滅多に見ないが・・・)の棒の長さを色にすることに相当する。この対数が上に書いたものである。

その変換は、基本的には、DBに記録された曲のうちで最大の再生回数を求め(この機能はSQLiteにもある。こういうのが一発でできるところが、DBの深みにはまる原因なのかも知れないｗ)、それと対象の曲の再生回数の比の対数で色の番号を決めている。どういう訳か、実際の変換式は複雑になったのだが、その理由はすっかり忘れたｗ おそらく、対数には0を与えられないとか、値域(色の番号)を0から9にするとか、そういう理由だったと思う。

ちなみに、最大の再生回数を求めるにはちょっとしたSQLを実行する必要があって、そのためのプログラムを作る必要があると思い、疲れているので「またかよー(一体、いくつ作ればいいんだ?)」とうんざりな気分になったのだが、曲をSpotifyとDBから検索するために作ったプログラム(webで検索に使っているもの)にそのSQLの判定部を「適当に」(= "1 order by played_cnt desc limit 0,1")入れたらできてしまったので、ちょっと驚いた。自分では全く想定していなかった用途に使えるのはおもしろいけど、結構怖い。こういうところからセキュリティホールが生まれるのかも知れない。

ここまでが昨日の話(log/log10の誤りに気付いた話とSQLの話を除く)で、今日、ミニプレーヤーに組み込んだ。久し振りのTck/Tk(どう考えても仕様が狂っている・・・)や肥大化したシェルスクリプト(調べたら、約1万行になっていた・・・)に手こずったが、さっき、何とか動き出した。

早速使ってみると、満足するどころかすぐにいくつも文句が出て来るｗ 例えば、完奏率の棒グラフの色が鮮やか過ぎて目障りだとか、コメント(せめて有無)も見たい(→ とりあえず、コメントがあればアイコンを出し、マウスオーバーで出るようにできたが、間抜けな場合もあるｗ: 6/20 16:39 → 暫定対応した。: 6/22 8:41)とか、webと同様にマウスオーバーで値を見たい(→ それほど手間が掛からずに追加できた。: 6/20 12:34)などだ(我ながら、全くわがままだ)。もちろん、アイコンのクリックで評価などの値を設定したいとか、GMBのミニプレーヤーにも組み込みたいなどの希望・予定はあるが、次の段階の話だ。

以前苦しんだフォントと同様に、色も奥が深く、webと同じ値でもミニプレーヤーでは違って見える。おそらく、大きさ(面積)や背景や周囲の色によるのだろう。鮮やか過ぎたものは、とり急ぎ渋目の色に変えたのだが、この辺りはじっくり調整する必要がありそうだ。(こういう時に、変更したい箇所で右クリックすると色チャートが出て変更できたりすると便利だが、さすがにそれは全くもって無理だｗ)

(6/20 7:43 加筆・修正; 6/20 12:34, 16:39 マウスオーバーを追加した件を追記, わずかに修正)

音楽プレーヤ(GMB)に表示されたSex Pistolsのアルバム(1977)のジャケットを見て、ふと思った。(天ぷらみたいにｗ)「ボロクソ」の語源は"bollocks"なのかと? が、調べたらそういう話はまったく出て来なかったので、偶然の一致のようだ。まあ、「一致」とは書いたものの、意味は同じゃないしね。でも、ちょっと残念だｗ

ちなみに、僕はこのバンドが全然好きじゃない。近年、調子は悪かったものの時間には余裕があった時に、「いろいろな音楽を聴いてみよう」と思って、レンタルしたり買いまくった時期があって、その時のものだ。そもそも、買うのも無駄だと思って散々迷った挙句にレンタルしたくらいだｗ ただ、偶然ではあるが、このバンドに居たらしい人のバンド(Public Image Ltd)が大昔に出した、"Compact disc"(1986)(元々からなのか、いろいろな形態があるからなのか、今は"Album"と呼んでいるようだ※)というアルバムは結構好きだ。学生の頃、店頭で見て、名前以外は何も知らなかったものの、いかにも人を喰ったようなタイトルや、ジャケットがいい感じだったので、買った。

※今、Spotifyでこのアルバムを見てみたら、ジャケット画像は"album"なのにアルバム名は"Compact Disc"になっていて、なかなか不思議だ。あと、Discogsを見たら、このアルバムには"Cassette"もあるようで、こういう(しょうもないことで遊ぶ)のは結構好きだｗ

あと、まったくどうでもいい(良くない)ことだが、このバンドの名前の最後に"."は付くのか付かないのか(彼らのサイトやWikipediaにはなく、Spotifyや僕の取り込んだCD(のデータ)にはある)、気になって夜も眠れなくなりそうだｗ

ついでに話を戻すと、"bollocks"は"bolloc"の複数形ではなく、元からsが付くようだ。これはこの単語が指す物から来ているのだろうか? 世の中に謎は多いｗ

ようやく正式な名前を決めた、Music listening history and impressions "Mlhi" DB (音楽再生履歴と感想の記録・検索システム※)に、先日やる気が出てしまったgmusicbrowser(GMB)対応機能にを追加しようと作り出し、さっきようやく動き出したのだが、気付いたら一週間経っていたｗ

※日本語の名前は今考えたので、やけに長いうえにダサいｗ

まあ、見た目はほとんど変わらない(そういうふうに作ったので)。GMBで再生した曲は再生の都度DBに記録され、履歴webに出る。Spotifyと同様に完奏率が出るし、評価やコメントを付けることもできる(それ以外の細かいことはまだだが)。

GMB対応に伴うDBの構成変更の内容が確定していなかったのと、うっかりDBを壊すのが怖いので、今はテスト用のDBを使っているが、もう少ししたら本物に切り替えたい。

それから、Spotifyでもそうしたのだが、再生した曲のDBへの登録を外部プロセスでなく、GMB本体(Spotifyではミニプレーヤー)に組み込んだ。これもまだできたてで怖いのだが、外部プロセスの場合、再生開始してからDBに登録されるまで30秒近く掛かっていて、いつも「遅いなあ、まだかよ」と思っていたのが、瞬時に(数秒以内に)登録されるようになったのが大変気持ちいい。これなんだよ! (と、ひとりごつｗ)

以下に、少し実装の話を書く。

• 以下のような流れでGMBの再生履歴をDBに登録する。
  1. GMBで曲の再生を開始する。
  2. GMBはDB登録プログラムにトラックIDを指定して、「再生開始の登録」として起動する。
  3. DB登録プログラムは、GMBからDbusで曲情報を取得して本システムのトラックIDを生成し、再生開始日時と再生回数をDBに登録(それぞれ、追記、加算)する。
  4. 最初に再生する曲の場合、主な曲情報(タイトル、アーティスト名など)と完奏率、評価、コメントなどもDBに登録(転記)する。
  5. その曲の再生が終了する。
  6. GMBはDB登録プログラムにトラックIDと完奏率を指定して「再生終了の登録」として起動する。
  7. DB登録プログラムは完奏率をDBに登録(加算)する。
• GMBの曲のトラックIDは、MD5で音響指紋のハッシュを求め、それをBase64(base64url)で短くしたものにした。
  • 今は、仮にGMBの曲がSpotifyと同じものでも関連付かないが、将来は(ISRCへの変換・対応テーブルのようなものを作って、)同じ演奏を関連付けられるようにしたい。
• 本システムでは複数種類のトラックID(例: ISRC, Spotify, GMB, 音響指紋)を混在して使うが、それらをプリフィクスで区別(URLのスキームのような感じ)するようにしている。
• GMBでのジャケット画像は当然ながらローカルのファイルだが、近頃は(リモートの)webページと(ローカルの)file:スキームは混在して使えないようなので、画像ファイルをsym-linkで仮想的にwebサーバの配下に置き、リモートのファイルとして指定している。馬鹿らしいが、サーバの設定では対処できなかったので、そうした。GMBの演奏がSpotifyと関連付けられるようになれば、Spotifyの画像を参照することもできるが、それも馬鹿らしい。
  • なお、ジャケット画像が曲のファイルに埋め込まれている場合もあるが、それを表示するには、抽出して一時ファイルを作ることになって管理が煩雑になるので、現在は使っていない。
• GMBは、内部に曲の再生開始と終了時に実行される関数があり、しかも、終了時に完奏率を計算してくれるので、事前に「面倒だ」と思っていたのが馬鹿らしいほど、手間が掛からずにさらっと組み込めた。
  • また、今までの再生履歴を記録してくれていたのもありがたい。ただ、今までにファイルを移動したりして履歴が消えてしまったものがあるのが残念だ。今後は本システムを使うことで、そういう問題を防げる。
• DBには2つフィールド(カラム)を追加した。音楽プレーヤspecificなトラックIDとアルバムIDである(後者は念のために追加したが、まだ使っていない)。将来的には、現在あるSpotfify専用のトラックIDとアルバムIDを廃止して、こちらだけにしたい。

思わぬ利点は、今までは、GMBはSpotifyと違って評価が付けられない(実際にはできる)とか再生履歴が残らない(上記のとおり、実際には残る)とかコメントが書けない(実際には書ける)などの理由で(要は、見やすくないとか手軽に更新できないのが面倒だったようだ)、余りGMBで聴かなくなっていたのだが、これができてから、(テストの意味もあるが、)俄然使う気が起こったことだ。将来的には、SpotifyとGMBをシームレスに(シャフル)再生できそうな(したい)気がして来て、夢にはまったく限りがないｗ

BTTFで言えば、やっと落ち着いたと思っていたら、またドクが来て、「未来に道は要らない!」とか言われて引き戻されるようなものだｗ

あと、やけに長いコメントが入っている曲が見付かったりする(CD-DBに入っていたのが取り込み時にそのまま入ったのだろうが、今まで全然知らなかった。 ← 実際にはコメントに購入日を記載した時に気付いたはずだが、すっかり忘れていた)のは、おもしろいのはもちろん、今までは不便で活用できなかった情報が生かせそうな点もwebでの履歴表示のいいところだ。

これでもまだ83%といった感じだが、大分落ち着いてきた。でも、プログラム中に山ほど"TODO"があるので、なかなか先は長い。そういうのは普段は何もないのだが、突然牙を剥くので(早速、ここに載せる画像を追加する時に出たｗ)まったく油断できない。

(6/17 19:46 若干加筆・修正)

時々、なぜか、(意識高そうに見える)しょうもないものを流行らせようとする技術系の人が居る。この前はマストドンとかいう名前すらクソダサイのがあったが、今日はマークダウン(以下MD)だ。やれやれ。

Wordが面倒だからMDを使おうとか、「お前、何も分かってないな」だ。MDこそ面倒だ。Wordをテキトーに使う方がずっと楽だ。それに、誰も使いたくてWordを使って居る訳じゃない。

これを読んだ普通の人が、(まあ、滅多に居ないと思うが)「よーし、僕もMD使っちゃうぞー!」とか思ってやりだしたら、ただでさえ低い日本の生産性はさらに低下するだろう。まあ、それでも個人の趣味で使うならいいが、最後にとんでもないことが書いてあって、この人に技術的なセンスはないと確信した※。

MDをPDFに変換してビジネスの書類にする??

は? アフォですか?

無理なうえに無意味・無駄だ。こいつは何も分かってない! そもそも、PDFに変換するならMDなんて使う必要も意味もないし、仕事の書類なんてさまざまな書式があるのに、それに合わせられないし、一番問題だと思うのは、PDFなんかにしたら、データが再利用できないことだ。MDと違ってそれっきりで、FAXと同じだ。それでいいの?? アナタノアタマハショウワデスカ?

蛇足だが、「じゃあどうするの?」と言われたら、僕ならこうする。

Wordで出す必要があって、書式が決まっていて(定形の書式)、何度も出す必要があって、しかも、自分で打ち込むのが厄介なら(こんなことは滅多にないが)、そのWordドキュメントを作るプログラムを作る。書類ごとに変わる箇所だけをテキストで書くとかフォームに打ち込んでそのプログラムに通せば、Wordができるようにする。これこそ楽ちんだ。何度も出さないなら、テキトーにWordで書けばいい。これの何が大変なのか? あと、なぜかPDFで出す必要があって、書式が自由なら、EvernoteとかLibreOfficeでいいよ。書式が決まっているなら上と同じだ。その他は自分で考えろ(ただし、MD以外でね)ｗ

※この人の経歴を見ると「うーむ・・・」と思わされるが、やっぱりそうだった。

(6/16 18:36 スマフォで認証ダイアログが出て鬱陶しいので、元記事のリンクの仕方を変更)

Jayson Gillhamのラフマニノフのピアノ協奏曲 第2番を聴きながら、例のDBに感想を書いていて思った。(第2楽章について)

オケもピアノもちょっと溜めが足りない(あっさりしている)感じ。

の「『溜めが足りない』とか『あっさりしている』って何だろうかね」と。

他には、近頃良く使う「わざとらしい」もある。楽譜に書いてあるのかないのか(ない気がする。テヌートのようなのは書いてありそうだが、少し違う気もする)、音楽用語があるのかないのか(これはあると思う)、分からないし、あってもなくてもどっちでもいいが、そう思った理由を自分で分からないので(いや、分かっては居るが言葉にできないだけなんだと思う。更に言えば、この、「文字」として書く時に問題になっているだけで、自分の感情としては理路整然としていて、何も不明なことはない。当たり前だが)、この表現は果たして正しいのか、ちょっと不安、というか、疑問に思った。この「正しい」というのも難しい。おそらく、「みんなが使っている」という意味だろうか。でも、別に他の人が使ってなくたって気にしないから、全く不安ではない。が、他の人に全く伝わらなかったら困るから、そこが「不安」となる。

いずれにしても、おもしろいのは、「曲がいい」ことは感じることだ(もう何百回も聴いているから、当たり前のことだ)。だからこそ、「なんでそういう風に弾くかな」(あくまでも個人的な感想ｗ)と思ってしまうのだ。

書いてから少し考えたら、

自分でしか読まないなら、他人に分かる表現である必要はない。

が、

あとで自分で読んで分かる表現で書かないと、意味がない。

のが難しいと思った。上記の「溜めが足りない」などはまだいいが、例えば、その時の気分を率直に書いて(すごく良かった時に)「!!!」とかじゃ余り意味がないし、かといって、自分しか読まないのに長々と書くのは面倒なので、そこはうまい方法(技術)があるといいと思う。例えば、"."を押すだけで、その時の気持ちが記録できるといい。

そういうのが、配信などでの「評価」(例: ★の数、Thumbs up/down)に繋がっているのかも知れない。それだけでは足りないが。

鋭意寄り道しながら開発中の音楽再生履歴記録・検索システム(仮)の横道の、gmusicbrowser(GMB)で再生した曲も履歴DBに入れようと四苦八苦準備している中で出たこぼれ話。

そもそもは、GMBで各演奏(録音, 曲)を区別する値「トラックID」は、音響指紋をハッシュ(ダイジェスト)処理で短くしたものを使う方針にした時、有名なハッシュ処理方式のMD5の結果が32文字と長いのが気に入らなくて、何とかしたいと思ったのが発端である。そんな、とても細かい話が書いてあるので、読まれる方はほとんど居ない気はするが、(いつものように)僕の整理のために書く。

まあ、そもそも、トラックIDは曲名などではないので、手で打ち込んだり目で見て何かする(読む)ことはないし、長いとはいっても音響指紋自体ではないので1つが数KBになる訳でもないから、それによってDBのサイズが肥大化することもないので、完全に好みの問題だ(有名な林檎のオジさんがやってそうな話かもｗ)。

なぜ"CRC48"がないのか?

はじめに目を付けたのはCRCである。ただ、僕が使っているPHPには32ビット(8文字)のCRC32しかなく、どうも心許ない気がした。具体的には、ID(曲数)が増えた時に重複(「衝突」)しそうな気がした。とは言え、僕はこの分野に詳しくないので、本当に32ビットで不十分なのかの確証はない(理論上は、32ビットでは約40億(2³²-1)通りの表現ができるが、重複(冗長性)を持たせているだろうから、現実的にはもっと少なそうだ。それでも、数万曲だったら完全に余裕だろう。ただ、ハッシュの表現範囲がどうやって決まるのかが分からないので、特定の使い方で範囲が狭くなるのなら安心できないと思った)。まあ、これも全く気分的な問題だ。

探すと、64ビットのCRC64(16文字)はあった。が、それは少し長く、僕としては12文字くらいのが欲しかった。それは"CRC48"というべきものなのだが、いくら探してもほとんど出て来ない。調べると、ハッシュ値を短くする方法が分かったので、それでCRC64を48ビットに短くできた。最初は単純にマスク(≒除算または剰余)して短くすればいいのかとは思ったのだが、詳しくないので、安直なことをしてハッシュの強度が下がる(→ 衝突しやすくなる)のが嫌なので、丹念に調べた。結局は普通にマスクしても問題なさそうだった。念入りにするには、長いハッシュを分割してXORする方法があった。

それにしても、CRC48がないのが不思議だ。Stack overflow(コンピュータ技術者のQ&Aサイト)でも、「結構要る」という意見もあった(UUIDに使うらしい)。全く不便だ。

音響指紋計算プログラムfpcalcの隠れオプション-hashの不思議

CRC48を探したり試行錯誤しているうちに、音響指紋の計算に使っているfpcalcに、探していたものそのものかも知れないオプションがあることが分かった。それが-hashで、検索してもほとんど出て来ないので、知っている人は少なそうだ。

これを指定すると、音響指紋の値に加えて、音響指紋のハッシュ値も出てくる。この値があまりにも妙なので、うなってしまった。この値を使うと、同じ演奏(録音)が分かる可能性がある。ただ、残念ながら、常に分かるとは限らない。

同じ演奏(録音)のハッシュ値は同じか近いことがあるが、全く違うこともある。全く同じファイルなら同じだが、リマスターや単にベスト盤に入っているだけで異なってしまうことがあった。逆に、リマスターでもオリジナル版でもモノラル版でもレコード版でも同じ値になったりもした。同じ演奏で値が違う場合も、最後の桁が1だけ違う場合もあったし、特定の桁が思わせぶりに違う場合もあった。以下にその例を示す。

• "Bohemian Rhapsody": b04cb826 (リマスターでないベスト盤), 904cb826 (リマスターとそうでないオリジナルアルバム)
• "Crazy Little Thing Called Love": d434a0ae (リマスターでないオリジナルアルバムと新しいベスト盤), d400a0ae (リマスターでないベスト盤), d42ca02e (リマスターのオリジナルアルバム)

謎の挙動だ。それぞれの桁に意味があるような気がして、それを突き詰めるのもおもしろそうだったが、いつも同じ動きをしないと不便なので(僕としては、同じ演奏ならすべて同じ値になるか、同じファイルでない限り、全部別になって欲しい)、使うのは見送った。そもそも、同じ演奏(録音)かどうかは音響指紋の間の「距離」で確率として表すとのことなので、ハッシュは簡易的に似た演奏を見分けるにはいいだろうが(-hashオプションを紹介しているページには、重複したファイルを減らす使い方が書いてあった)、IDとして使うのは良くなさそうだ。

SHA-3(というかWikipedia)に騙されたｗ

CRC48に落ち着き掛けたのだが、厳密に言えば、CRCはハッシュではないし、自分で勝手に短くするのが気に入らず、任意の長さで出せる標準的なハッシュ方式を探した。すると、SHA-3はそれができるとのことだったので、プログラムをダウンロードして48ビットで試してみたら、エラーになった。調べたら、最短ビット数(224ビット)が決まっていた。あと、任意でなく数とおりしか指定できなかった。任意の長さにできるというのは、確かWikipediaで見たのだが、鵜呑みにするのは良くないと実感した。今回はちゃんと確かめたから良かった。もしかしたら、プログラムを変更すればできたのかも知れないが、中身がチンプンカンプンだった。

MD5を短くする。

SHA-3は諦めたものの、「短いハッシュ」で調べているうちに、Stack overflowで目から鱗のアイデアを見付けた。Base64エンコーディングで文字数を減らすのだ。ハッシュ値は普通は、"10f280198c517c830fa302c4e1bcca7b"(MD5の例)のように16進数で書く。これは元々は数値なので、Base64で表せば短くできるのだ。簡単に言うと、16進数は0-9とa-fしか使わないが、Base64はもっと多くの文字を使うから1桁で示せる値が多いので、短く書ける(桁数が減る)。

MD5は128ビットと数が大きいので手こずったが、できた。元は32文字だったのが"EPKAGYxRfIMPowLE4bzKew"のように22文字で表わすことができ、10文字も短くできた。希望は12文字くらいだったが、(今はobsoleteになっているけど)実績あるハッシュ処理を使うことで、衝突の心配が皆無になるだろうから許せると思い、今に至る。これで、いつでもGMBで再生した曲をDBに登録できる(屏風の中から虎を出してくれたらそのプログラムを書きさえすればねｗ)。

なお、この方法でCRC64も12文字にできる(基本的には、数値なら何でも可)ので、途中まではそれを使おうとしていたが、CRC48を止めたのと同じ理由でMD5の方が良さそうだったので乗り換えた。

(6/11 6:09追記) ちょっと思い付いて調べたら、SpotifyのトラックIDも僕と同じ22文字だった(アルバムIDも同じ)。これもBase64みたいな表記なので(例: 7oYN5pKRoFiVLoDFK6R3O1)、元はMD5のような長さの値なのだろう。偶然の一致だけどおもしろい。ハッシュ値だとしたら、何の情報を元にしているのか興味あるところだ。そして、(これは想像だが、)ID数が数億になるとCRC64では不足するのかも知れない。もちろん、使い切るまで衝突しない訳ではないので、ある程度の余裕が要ると思う。その点で、MD5にしたのは正解だったのではないか。

それに引き換え、(前にも書いたが)マイナンバーは脆弱だ。個人の番号は10進数で12桁なので全く余裕がない。当てずっぽうな値でも有効になるだろうし、(おそらくありえないがｗ、)長く使われ続けると不足するので、将来は死んだ人の番号を使い回す羽目になると思う。素人でも分かるくらいのしょうもなさだ。そのうち、そういう問題の解消を名目にしてまた新しい仕組みが(利権の確保とともに)生まれるのだろう。役人連中は楽だね。

似たようなことはISRCにも言える。12桁と短いうえに、区分されていて使える数が少ないから、いつかは破綻するし、年を2桁で表記するからとても古い録音は扱えないし(例えば、"19"は1919年なのか2019年なのか? まあ、仕組みができてから録音されたものを登録するスタンスなのだろうが・・・)、2100年以降は使えない。始まったのは2000年以降と推測するが、だとしたら日本の役所並みにお粗末だ。

ちなみに、確認と評価のため、音響指紋のMD5でGMBに入っている全曲(約1.5万曲)のトラックIDを生成してみたところ、90組くらい同じIDが出たが、衝突ではなく、元が同じ演奏(例: 重複したファイル、タグを変えたものとオリジナル、(ごくまれに)収録アルバムが異なる同じ演奏)のためだったので、本来の目的が達成できていることが分かったし、問題なくIDに使えることも分かったので安心した。あと、大量の曲ファイルに重複がほとんどなかったのには、我ながら感心した。なお、音響指紋の計算(fpcalc)が意外に遅く、大量の曲の処理には結構時間が掛かった。

心なしか、ものすご〜く本題から外れている気がするし、ちょっと買い物に行くのにハマーとかモビルスーツに乗るようなくらいやり過ぎな気がしないでもないが、趣味だし、いろいろな知識が得られたので良しとしようｗ

(6/11 5:41, 6:09 わずかに加筆・修正、追記; 6/11 10:32 わずかに補足)

開発中の音楽再生履歴記録・検索システム(仮)、そこそこ使えているうえに、煮詰まっているというか、完成度が高くなってきたために(それでもまだ8割くらいか)、いくら作り・直してもキリがなくて(しかも、劇的にすごくはならない)疲れたので、ちょっと脇道に逸れて、先日書いたgmusicbrowser(以下GMB)との連携・統合の一部の、GMBの再生履歴を取って記録することを試してみた。

まあ、GMBで再生している曲情報を取ること自体は全く簡単で、Dbusインタフェースを使えば目をつぶってもできたくらいだが(実際には少し手こずった)ｗ、その先が大変だ。

先日も書いたように、再生している曲・演奏・録音(以下「演奏」)が「何か」を特定(同定)することが難しい。なぜ同定が要るかというと、GMBでもSpotifyでも同じ演奏を再生したら、同じ演奏の履歴として記録したいのだ。片方で再生したらもう片方とは別扱いになるのでは全く無意味だ。

そして、上記のGMBから取れる曲情報は、曲名、アーティスト名、アルバム名などで、それだけあれば充分だと思われるだろうが、実際には不十分だ。例えば、以下のような問題がある。

• 同じアーティストが同じ曲(だけど実体が異なる)を何度も演奏/録音/発売した場合(例: ライブ、再録、リミックス、シングル/アルバム版、リマスター)、それらの区別が付かない。: 例: John Lennon "Give peace a chance" (通常版と"Shaved fish"中の短縮版)
• 同じ演奏だけど微妙に曲名などが異なる場合、同じ演奏と判定できない。: 例: "Somebody To Love"と"Somebody To Love - Remastered 2011"
  • 逆に、何度も演奏/録音/発売した場合に微妙に曲名を変えてくれると、1番目の問題が緩和できる。: 例: 「かもめが翔んだ日」と「かもめが翔んだ日(スタジアム・バージョン)」
  • 「ファジー判定」のような仕組みがあるといいのかも知れないが、今度は上のような微妙に曲名を変えてくれた別演奏が同じになってしまいそうだ。
  • CDをPCに取り込んだ時に使ったCDDBの曲情報と、Spotifyの情報が異なる場合もあるし、自分で記述を変更した場合もある。
  • 日本のアーティストでは、表記が日本語かローマ字かの違いも問題になる。

そこで、先日も書いたように、各演奏はISRCで区別し(ISRCのないものは別扱いにする)、ある演奏がどのISRCに対応するかを音響指紋で識別しようと考えた。音響指紋と演奏を照合するためのシステムは、AcoustIDとMusicBrainzを使うことにした(無料で使えるのはこれらしかないため)。

手順は以下である。

1. GMBの演奏(ファイル)の音響指紋を計算する。: fpcalcコマンド
2. その音響指紋をAcoustIDに送り、演奏に紐付けられたMusicBrainz ID(以下MBID)を得る。
3. 得られたMBIDでMusicBrainzからISRCを得る。

全くシンプルで、すぐにでもできそうに見える。確かに、それほど時間が掛からずに作れた(でも疲れたｗ)。が、ちょっと試したらとんでもなかった。以下のような問題が噴出した。

• ある音響指紋に対して、実際とは異なる演奏(候補)が出てくることが結構ある。: 確率的なものなので仕方ない。
• AcoustIDに登録されていてもMBIDがない演奏が結構ある。: ボランティアベースだから仕方ない。。。
• MBIDがあってもISRCがない演奏が結構ある。: ボランティアベースだから仕方ない。。。
• 登録内容(例: 曲名)が誤っている演奏がある。: ボランティアベースだから仕方ない?? 気付いたら修正しろってこと?
• MusicBrainzのアクセス制限(アクセス頻度)が厳しく(最大 平均1回/秒)、それを破らないように、間隔をおいて何度も検索すると時間が掛かる。: 無料だから仕方ない。。。
  • 素行の悪いアプリは公表されてアクセス制限されるようなので、なるべく規則を破らないようにしないといけない。
  • AcoustIDにも同様に制限があるが、まだ緩い(最大 平均3回/秒)。

まさに、「聞いてないよー!」の世界だｗ

それでいろいろな工夫をしたが、現時点では、完全な自動処理(演奏の同定)をするのは難しい感じだ。以下に、したことと起こった問題を書く。

• (MusicBrainzに情報がない場合に、)曲情報(曲名、アーティスト名など)でSpotifyを検索する。演奏時間やリリース年などでフィルタリングを厳しくする。
  • 最初の問題(同名曲の区別ができない/微妙に違う名前の曲が同じと判定できない)が起こる。
  • ライブ版がアルバム版と認識されることがある(曲名などが同じで、たまたま演奏時間が近い場合)。
  • "Various Artists"が幅広くマッチしてしまう。 → 無視するようにした。
• (MusicBrainzの誤情報に備えて、)MusicBrainzで得られたISRCでSpotifyを検索して正当性を確認する。
  • Spotifyにない演奏が結構ある。SpotifyにあってもISRCがない演奏もあるうえに、MusicBrainzでもSpotifyでも複数のISRCがある演奏もある。そもそも、曲情報の表記が異なることがあるので、判定すら難しい。

ちょっと見た感じでは、多くの(2/3以上?)普通の演奏では問題なく動いている(→ 出力の例)のだが、たまに間違うのはやっぱり気に入らない。

他の問題として、MusicBrainzではリマスターやレコードの演奏などが全部通常版(例: CD)と同じに区分されている(Spotifyは、基本的に最新の1種類しかない。リマスターがあればそれだけになるし、当然ながらレコード版はない)。これは、技術だけでなくポリシーの問題も絡むので、すぐにはどうすればいいかが決められない。リマスターやレコードを通常版と別扱いにしたいこともあるし、そうでない場合もあるのだ。

AcoustIDとMusicBrainzはイマイチなので使わなくてもいいのかと思ったが、そうではない。それ以外に有効な手段がないので、やっぱり音響指紋での識別をした方がいい。その点で、Spotifyが音響指紋を提供してくれると一番ありがたいが、そうも行かない。今のところは、(リアルタイムでの)完璧な同定は諦め、バッチ処理でGMBとISRCの対応表を作って、その結果を「見て」修正するのがいい感じだ。ただ、GMBには1.5万曲くらい入っているので何とも大変そうだし、時代遅れな気がする。

次善の策として、SpotifyにはなくてGMBでしか再生できない演奏についてだけ対応表を作って、その内容を確認することが考えられる。それなら2500曲以下と大分減るが、そういう演奏はISRCがないものも多いので、別の問題(ISRC以外の何で演奏を区別するか)がある・・・

できそうでできないのは、SpotifyのAPIの音楽分析アルゴリズム(演奏の「活発さ」や拍などが分析されて公開されている)でGMBの演奏を分析して音響指紋の代わりに照合に使うことだ。でも、SpotifyのAPIではローカルファイルの分析はできないと思うし、Spotifyのアルゴリズムは公開されていないので、自分で実装することもできない。

もう一つ、最後の手段としてあるのは、仕舞い込んだCDを引っ張りだして、その中に記録されているであろうISRCを取り込むことだ。これが一番確実ではあるが(こうなると分かっていたら、最初からやっていただろう)、ISRCが入ってないものもあるだろうし、レンタルのものはできないし、そもそも、面倒だからやりたくないｗ

てな訳で、またしても(普通の人には全くどうでもいい)泥沼にはまり込んだ今日この頃・・・

↓

(6/9 7:15追記) 昨夜、寝る直前に思い付いたのだが、IDとして各演奏に固有の識別記号を割り当てたいので、曲ファイルのダイジェスト(ハッシュ)値(例: MD5)をIDに使ってみたい。ただし、普通にファイルのダイジェスト値を使うと、それはタグ(例: 曲名)を変更しただけでも変わってしまって不便(タグを変えるとファイルとIDが合わなくなってしまう)なので、音響指紋のダイジェスト値を使うことを考えた。

ファイル名などをテーブルに記録して、そこでの通し番号などでIDを割り当てることもできる(GMBの方式)が、ファイルを移動したり名前を変えたらテーブルを更新しなくてはならないから不便だ。それを解消するために、曲のファイル自体にIDを持たせたい。そのためには、ファイル内(例: タグ)にIDを記録するか、ファイル名にIDを付加するか、上記のようなファイルの特徴をIDにするのがいいだろう。

IDをファイル内に記録する場合、既存のファイルすべてに記録する必要があって面倒なうえに、内容が変わらないのにファイルが更新されるのは嫌だし、今後、ファイルを追加するたびに忘れずにIDを記録しなくてはならないので煩雑だ。

ファイル名にIDを付加する(デジカメ画像の管理で実施している)のは簡便だが、既存の多くのファイル名を変えるのは好ましくない。例えば、GMBへの曲の登録をし直す必要があって、現実的でない。また、ファイルを追加するたびにIDを追加しなくてはならない煩雑さもある。

ファイルの特徴をIDにするのであれば、ファイル自体には何もしなくていいうえに、ファイルの中身を変更しない限り、あらかじめ決めた手順(計算)によっていつでも同じIDが得られるから便利だ。

音響指紋は、その名のとおり、(ファイルに格納された)音の特徴(だけ)に基づいているので、タグは無関係なはずだ。実際に試してみたら、本当に、タグを変えても音響指紋とそのダイジェスト値は変わらなかった(当たり前のことだが、結構うれしかった)。なお、当然ながら、異なる演奏は別の(音響指紋・)ダイジェスト値になった。ただし、同じ演奏でも、通常(CD)版とリマスター版やレコード版の音響指紋は異なったので、結構敏感なようだ。

この方式なら、IDはファイル(の中身の音)に固有だし、生成にも再現性がある(同じ音のファイルに対してはいつでも同じ値が生成できる)。ただ、音質や雑音などの条件が異なると「同じ演奏」でも同じIDにはならないが、そこは諦める(そもそも、GMBの中では重複した演奏(ファイル)は極力排除しているから、大きな問題ではないと思う。あるとすれば、リマスター版やレコードをオリジナル(CD)と同じと扱うかどうかの類だ)。

逆に、ダイジェスト値に衝突(偶然の一致、重複)が生じて、別の演奏に同じIDが割り当たる可能性はある。ただ、広く使われている方式でも(ハッキングを除いて)そういう問題が起こったという話は聞かないので、確率は低そうだ(また、音響指紋のデータは短いので、指紋の小さな変化でもダイジェスト値に反映されるから衝突は起こりにくそうだと想像するが、確証はない)。万が一衝突した場合は、(どうにかしてそれが検出できたとすれば、)IDに子番号を追加すればいいのではないかと思っている(と書いたものの、IDをテーブルなどで一元管理しないので、IDを生成した時点では衝突は分からなそうだ・・・ が、下に書いた変換テーブルで対応できるかも知れない)。

また、ISRCへの変換は変換テーブルで行う。その時に、重複した同じ演奏のIDに一つのISRCを割り当てることで集約できそうだ。

再生履歴DBでは、当初は、同じ演奏であっても、GMBのもの(音響指紋からIDを生成)とSpotifyのもの(ISRCからIDを生成)とは別のものとして記録するが、上記ISRCへの変換テーブルができたら、履歴などの情報を自動的にマージ(統合)したい(実際には、記録されたデータ自体は変更せず、DBの機能を使って統合されているように見せたい)。

と、またしても夢は膨らむのであったｗ (そして、例によって落とし穴が待ち構えている?)

(21:06 わずかに加筆・修正; 21:19 題の誤りを修正; 6/9 7:15 追記)

プログラミングに熱中したりしているうちに2か月くらいドライブしていないことに気付き(→ 前回)、一段落したし疲れたりちょっと飽きたりもしたので、気分転換に行きたくなったのと洗車をしてモチベーションが上がったこともあってｗ、昨日行った。やっぱり行き先には迷ったのだが、花(あやめ、あじさい)は微妙に時期が合わないし見飽きた感もあるので、地図で偶然目に入った、福島県西郷村の堀川(ほっかわ)ダムに、純粋に走りに行った。僕はダムには興味はないのだが、ドライブの行き先としては丁度いいことが多い。具体的には、道が整備されている(細くない)ことが多く(しかも、楽しい道のこともあるｗ)、自由に入れ、駐車場があり、トイレがあり、DQNや変な人が少なく、静かで、滅多に混雑せず、無料なことだ。

8時頃出発した。9時頃、道の駅矢板に寄った。概ね快適だったが、いつものように眠くなった。

(前の投稿に追記したが、)出て少しして、ハンドルの下部にキズか汚れがあるのに気付いた。前日の洗車で付けられたようだ。白っぽかったので、工具や金具で擦られたのかと思った。道の駅で濡れ雑巾で拭いたら落ちたので、汚れだったことが分かったのだが、それまでは、運転しながら爪で擦っても取れなかったので、「傷だったら消えないから困るなあ」と結構嫌な気分だった。あの店は最低だ。なぜ、ガソリンスタンド(の整備と店員)はこうもクソなのだろうか？

途中にバカなBMW 1シリーズが居た。前の会社の(その車種の)奴のようにムダな加速をしつつ左右にうろちょろしていた。そんなことをしても必ず信号で追いつくから笑えた。そういう1シリをこの辺りで何度か見たことがあるから同じ人なのか、1シリは＊＊揃いなのか、何かコンプレックスでもあるのか、単に若いだけなのだろうか。

10時頃、那須塩原の7-11に寄った。遅いトラックも居たが、それまではすごく気持ち良かった。隣に停まって居たEN400というアメリカンのバイクが意外に小さくて、好感が持てた。反対側では、都会の切れるビジネスパーソンみたいな雰囲気のショートボブのお姉さまがワンボックスに乗っていた。

地図で見て期待してルートに入れた、那須と白河の間の山道(栃木・福島県道290号)が予想以上に楽しかった。分岐するところが唐突で通過しそうになったが、何とか入れた。道が広くて僕には丁度良かったし、平日のせいか、滅多に車が居なくて存分に楽しめた。いつもはなかなかできないことだが、ギアを小まめに切り替えながら、低目のギアで高目の回転数を維持して走るのが気持ち良かった。あの車のエンジンは意外にストレスなく回るからいい。そして、何度か書いているが、軽い車は制御しやすくて大正解だと思う。

山道は涼しく(でも、エアコンを切るとちょっと暑かった)、鳥(うぐいすだったか)が鳴いていた。ツツジも少し咲いていた。見晴らしがいいところもあった気がするが、運転に熱中していたので一気に走り抜けた。

なお、なおきさんがそうしていると聞いてから、僕も、こうやって走りに集中する時(他に、家でも作業に集中している・はまっている時ｗなど)は音楽を停めるようにしている(近頃は、「垂れ流すことに意味があるの?」と思いつつあるし、無音の静けさも結構好きだし、脳内での再生もいいと思っている)。

11時頃、到着した。運転に熱中して我慢していたせいでトイレに行きたかったのだが、なぜかトイレの扉に鍵が掛かって居て焦った。開け忘れたのか、事務所の人が巡回中だったせいか(それで、事務所に行っても誰も居なくて頼めなかった)。でも、多用途トイレは開いていたので、ほっとした。

1時間近く散歩した。ここでもうぐいすが鳴いていた。気温は24℃とそれほどでもなかったが、日射しのせいで暑かった。

ダムのオーバーフローの口らしい部分の形がすごかった。上に書いたようにダム自体には興味はないが、こういうものには興味が湧く。全くあり得ないことだが、もし僕にこういうのを作れ(設計しろ)と言われても、途方に暮れて逃亡するだろうｗ あと、万が一、豪雨で放水している時にここに引きこまれたら絶対に助からないと思うと、恐ろしい気がした(高所恐怖症のせいもあるがｗ)。

そういえば、今流行りらしいダムカードの入った箱(実体は郵便受け)が、なぜか分かりにくいところに置いてあった。「一人一枚」と書かれていたが、放置されている感じだったので、中にカードは入ってなさそうだった。基本は事務所でもらうということなのかな。

散歩をして満足したので、帰ることにした。お腹が空いたので、途中で蕎麦屋に寄ろうと思ったのだが、どうも面倒なので(例: 混雑、煙草、愛想の悪い店員、気難しい店主、マズい)、その手前にあった7-11でおろし蕎麦を食べた。ここは見覚えがあって、前にも昼食にしたところだ(調べたら去年の夏だった)。その時は暑かったが、昨日はそれほどでもなかった。レジは公明党の党首みたいな感じのおじさんだった。店長だろうか？

食べていたら、男子中学生が千円札5枚くらいを握りしめて店に入り、少ししてGoogle Playのカードを手にして出てきた。ちょっと現代の闇を感じたが、今は普通のこと? 昔だったらゲームのカートリッジみたいなものなのかな。そういえば、当時の僕は千円札を3枚くらい握りしめてレコードを買いに行ったっけ。

結構疲れたので、帰路は手軽に高速にした。楽だし快適だった。14時頃、無事帰宅した。往路の半分の1.5時間くらいで帰れた。長時間乗ったせいか なかなか疲れた(起きたらふくらはぎが痛い)が、気持ち良かった。いつものように車は快調だった。そろそろ車検だ。総走行距離は約54500km。

約190km、約6時間
IXY Digital 3000isで撮影

(19:46 修正、編集時に欠けた箇所を復活)

先日亀裂を見付けてもらった、右上の奥歯を治療(今回は切削(と言うのか?)と型取り)してもらった※。削ったら、ひびは1本(一箇所)ではなく、奥歯の、上下逆さにした風呂椅子の脚(あるいは、指輪の石を留める爪)のようになっている部分を挟んでもう1本あった。これまでは歯の間で見えなかったのだろう。あるいは、削る前に「虫歯」と言われた箇所(黒い線になっていた)がこれだったのかも知れない。

※ありがたいことに、前回と同じ、若くてちゃんとした歯科医師だった。

それを見て、その歯の見えないところに深い亀裂がないかと心配になったが、ヒビは誰にでも起こるから、(他の歯にもあるかも知れないし、)隠れていてもすぐには問題にならないと言われた。が、ここについては、下手をすればその「脚」が折れる可能性もあるとこのとだったので、見付けてもらって良かった。それで、その「脚」を削った。

なお、さっき歯を磨いたら、長年気になっていたその歯の辺りのピリピリが起こらなかった。治療直後で一時的に消えているだけかも知れないからぬか喜びは禁物だが、ちょっと(結構)期待できそうだ。

歯科のあと、気が向いたのと、汚れが結構ひどくなって(とは言っても、遠目には綺麗だったｗ)、乗る時にモティベーションが下がるので、洗車することにした(洗車は延ばして軽くドライブに行こうかとも思っていたが、モティベーションの低下が結構なものだったので洗車にした)。事前に調べて候補にした2箇所のうち、webの案内(作業内容の説明)がちゃんとしているところにした。ただ、長年の経験からそういうのと実際は違う(まず同じことがない)のは分かっていたので、手洗いで料金が手頃なところで決めた。ガソリンスタンドなので何となく心配はあったが、洗車くらいではまず大きな失敗はないと思って行った。(実は、その時点で大きな失敗だったのだがｗ)

行くと、珍しくセルフでない店で、ポンプ(と言うのか?)の近くに店員が2人居たのだが、邪魔にならないように店の前に停めても誰も来ない。この時点で結構がっかりした。いつものディーラーだったら即座に出て来るのだが・・・ 来ないので、僕が出て歩いて行って頼んだ。どちらもバイトの感じで、片方の男が洗うようだった。バイトだから駄目と決め付ける気はないが、webには(その系列店の)有資格者がやるみたいなことが書いてあったので、「あっ(察し)」だった。まあ、そのバイトが有資格者の可能性はあるし、そもそも「資格」とか言ったってあてにならないから、どうでもいいと割り切って、店内で待っていた。

少しすると、もう片方の女性店員が来て、コーティングを勧められた。「来たな」と思った。6000円だそうだ。そういえば、最初にも、男が「+300円でコーティングできます」とか言っていたが、それはどこへ消え去ったのか。この調子では、仮に6000円のを頼んだら、もっといい(長持ちする?)のがあるとか言って2万円くらいのを勧めて来るのだろう(渡されたパンフにあった)。

僕は、コーティングでは前の車で酷い目に遭った(何も知らなかったので、納車直後に大手チェーン店(「自動後退」とか言われている)で掛けたら、塗装が削れたようで、時間が経ったら表面がザラザラになり、劣化が速かった)し、コーティングなんてたかが知れている※(逆に、塗装に悪いのではないか)と思うし(その証拠に、今のは何もしてないけどまだそれなりに綺麗だ)、やるにしたって、「なんでガソリンスタンドでやる必要があるの?」と思ったので断った。が、どうにもしつこくてなかなか帰らず、3回くらい断ってようやく帰っていった。普通、説明の途中でジェスチャー付きで「いいです。」ってきっぱり言われたら止めるよね??

※コーティングは塗装ではないので、直射日光や雨でなくなってしまうだろう。ガラス質のコーティング(これは一種の塗装ではないか)というのもあるが、本当にちゃんと施工できるのかと思う。いずれにしても、洗車しなければやっぱり汚くなるから僕には同じことだし、そこまでして塗装を「保護」したい気持ちが理解できない。そこそこ綺麗ならいいと思うのだが。

と思いきや、また来た!

今度はエアコンのガスだ。効きが弱くなっていたとか言って、ガスとオイル交換を勧めてきた。「通常は1.3万円が今回は1万円になる」とか言っていた。効きが弱い気はしていたが、それは最初からで、車の構造によると思っていたし(実際、今日の帰路では充分涼しかった)、やるにしたって、やっぱり、「なんでガソリンスタンド(略)?!」と思ったので、断った。が、やっぱりしつこかった。今度も3回くらい断って、彼女の気が済んだら帰っていった。

全くのアフォだと思った。学習能力がないのかノルマが厳しいのか。。。 その時は気付かなかったが、奥に社員とか店長のようなオッサンが居たので、そういう「売り込み活動」をしないと怒られるのかも知れない。今は大変だよね・・・

いずれにしても、こんなにクソな売り込みは久し振りだ。いつもガソリンはセルフだし、ディーラーだって、こっちから「交換した方がいいですかね?」と言っても「まだ大丈夫です」とか言うことすらあるところなので、今回は結構ムカついた。いくら温厚な僕でもｗさすがに途中でブチ切れたくなったが、そうしても何もメリットはないし、おもしろくもなくてこっちが疲れるだけなので止めた。手慣れた人は、こういう時に店員を手玉にとってテキトーに弄んで、コーヒーとか出させたりして、でも「じゃあ次に」とか言ってやらず仕舞いにして楽しむのだろうが、さすがにそういう腕はないｗ せいぜい、ここのネタにするくらいだ。

こういう手口で、ガソリンを入れるだけに来たのにうかつに「無料点検」を頼んでしまって、オイルからタイヤまですべて交換されてとんでもない金額をむしり取られる上客(カモネギ?)が生まれるのだろう。そんなことしているから、よほど酔狂な人以外はセルフに行くようになったのではないかと思うのだが、本人(経営者)は分かってないようだ。まったく馬鹿だ。

洗車は(売り込み込みでｗ)45分くらいで終わった。予想どおり、洗車料金がwebとは違っていた。約2000円(税抜き)だった。Webでは車種ごとのクラスで料金が書いてあったが、一つ上になっていた。まあ、これも想定内なのでいい。(僕はこういうのも想定していたし、高くなってもたかが知れているから聞かなかったけど、)そもそも、普通は最初に料金を言うよね。そういえば、最後にまた、ガソリンが安くなる会員カードの作成を勧められた。だから、もういいって!!!!

帰路にふとサイドミラーの腕を見たら、わずかに拭き残しがあって少し汚れていたので、がっかりした。Webではちゃんと拭き上げるとか書いてあって、そういうことはなさそうな感じだったが、こちらの過剰な期待だったのか? 僕としては、別に汚くなければいいからいいけど、広告には嘘ありだ。

次に洗車することになったら、もう一つの候補か別のところにしたい。そのもう一つのところは車屋(系列的な名前はあるが、それぞれ独立した店のようだ)で、webがちょっといい加減だったので、今回は止めた。ただ、作業はちゃんとしているかも知れないし、ここまでしつこい売り込みはないと思うから、それだけでもいい。それに、(再び)洗車くらいではまず大きな失敗はないから、仮に駄目でも大丈夫だｗ あとは、次回ディーラーに行ったら、有料で洗車だけやってくれるか聞いてみたい。それが一番いい。

てな訳で、個人的な感想は以下である。

敢えて言おう、ガソリンスタンド(の売り込み)はカスであると!

今思ったが、洗車は客集めの道具なのかも知れないな。45分(標準は25分と書いてあった)も掛けて2000円前後では割に合わないのだろう。だから、何か他にも注文を取らないと損になってしまうと考えるのだろう。だが、そこが浅はかなんだよ! そうやって押し売りして嫌な気分にさせたら、その客はその店にも系列店にももう来ないから、結構な量のガソリンと(もしかしたら)整備作業がなくなるだろう。知り合いにも「あそこはしつこい」とか言われるだろうし、ここにもこうやって「ガソリンスタンドは」などと書かれて同業他社にも影響を及ぼすかも知れないから、長期間とか広い目、全体的に見れば、押し売りの方が割に合わないと思う。大体、何時代の売り方だって話だ。

(19:22 わずかに加筆・修正)

PS. このしょうもないスタンドは更にやらかしていた。まあ、細かいことだけど、ハンドルの下に汚れを付けていた(ワックスのような灰色だった)。今日(6/4)運転していて気付いて、もしや傷付けられて知らん顔されたのだろうかと思って(昔は良くあった)、雑巾で拭いて落とせた時までは結構嫌な気分だった。作業者が気が付かなかったのだろうが、無料サービスじゃないんだから、洗車に来た客の車を汚さないってのは当たり前ではないのだろうか? そして短時間だって嫌な気分はさせないで欲しい。 (6/4 14:44)

音楽再生履歴記録・検索システム(仮)を作りながら使っていると、いろいろなアイデアが浮かぶ。作ることや使っている時にバグが出て急いで直すｗのには結構疲れているが、アイデアを出すのはおもしろい。そういうものの例を書く。

• 検索条件のプリセットを登録できるようにする。
  • 固定のプリセットを何個か用意するのでなく、随時自分で登録できるようにする。: 今までは、どういうプリセットが要るか分からないから作るのをずっと先送りにしていたのだが、良く使う条件を登録できるようにすればいいことに気付いた。ただ、パラメータのあるもの(例: 「評価がN以上」)はどうするかとか、考え過ぎると進まないｗ
• 曲・アルバム・アーティストの評価方法: 「ある曲(・アルバム・アーティスト)の好き/嫌い加減」をどうやって数値にするか。
  • 曲1: 評価※ × 平均完奏率: 好きなら最後まで聴くし、嫌いな曲は途中で飛ばすので。ちょっと試してみたら、そこそこ合ってそうな感じだった。
  • 曲2: 評価 × 平均完奏率 × 再生回数: 好きなら繰り返し聴くので、上よりいいのかも知れない。
    • → 両者を比較してみたら、今のところ、どちらも大差なかった。

    • 

      評価×平均完奏率

      

      左×再生回数

      
      
  • アルバムやアーティスト: そのアルバムやアーティストの曲(演奏)で、評価が付いているもの(付いていないものは"0"にせず、除外する)の平均を取ると良さそうだ。それ以外に、最高・最低もおもしろそうだ。
    • ※評価の値は、最初はシンプルに「好き」(1)/「嫌い」(-1)だけにしようと思っていたのだが、DBの設計時に、いろいろ入れられるので「せっかくだから」±5にした(実際には整数なら何でも入る)。結果的には、自分でも「好きだけど『大好き』ではない」みたいな状態が表せて便利なことが分かったし、上のような使い方をするには数値が好都合だった。
• 嫌いな曲の自動スキップ: Spotifyでリコメンドされて掛かってしまった嫌いな曲を手で飛ばすのが面倒なのだｗ
  • 評価を元に: Spotifyの「嫌い」を設定するのが面倒だし、付けられない場合もあるので、上記の評価値が悪い曲(演奏)やアーティストは自動で飛ばす(検出したら自動で「次の曲」にする)。ただし、場合によっては聴きたいこともあるから、猶予を持たせたい。でも、そのたびにダイアログを出すのも鬱陶しそうなので、いい手が要る。
  • ブラックリスト (アーティスト、曲、作曲家・・・): 新しいDBを作るのもいいし、曲ごとにそういうフィールド(例: "Hate", "Don't play")を作るのもいい。
  • 悪い評価を付けたら、その場で自動的にスキップする。: (今思い付いた) これは便利そうだ。今は、飛ばす前や後にこのシステムのwebで悪い評価を付けて、なおかつ、Spotifyで「嫌い」が付けられるなら付けるので、二度・三度手間になっている。
• 音量正規化(再生ゲイン)の補正、タイトルなどの上書き(修正)
  • ミニプレーヤーに入れた、自作の音量正規化処理の結果がイマイチ(例: 音が大き過ぎる)な場合の対処のために、手で調整した音量の補正値を(DBに)記録できるようにして、その値がある時はそれで音量を補正する。
  • タイトルやアーティストや初出年も、自分で修正して(DBに)記録した内容を表示できると便利そうだ(Spotifyが間違っていることがあるので)。ただ、webとかミニプレーヤーにしか出せないので、本当に意味があるのかという気もする。
• Spotifyからの評価の取り込み
  • Spotifyで「好き」/「嫌い」にした曲を取るAPIはないが、「好き」にした曲は「ライブラリ」(曲一覧が取れる)に自動的に入り、ラジオで好きにした曲はプレイリスト("Liked from radio")に入る。好きでもないのにライブラリに入れることはないので、ライブラリに入っていること= 「好き」として良さそうだ。
  • 随時「好き」を設定するので、この処理は自動で定期的に行わなくてはならないうえに、本システムで付けた評価とうまくマージしなくてはならないのが面倒だ。
• gmusicbowser(配信でない曲のプレーヤー)との連携・統合
  • 曲の自動登録など、Spotify(のミニプレーヤー)でやりたいこと(今、外部プログラムでやっていること)は技術的には充分に可能だが、トラックID(演奏を一意に識別する記号)をどうするかという問題が大きい。(処理は重いけど)すべての曲の音響指紋を計算してISRCを検索して付けておくのが一番良さそうだが、ISRCのないもの(例: ライブの録音)もあるから、話は単純でない。などと考え過ぎると、やっぱり進まないｗ
    • → ちょっと試してみたら、AcoustID(音響指紋)とMusicBrainzのサービスを使えば、基本的にはISRCを取れることが分かったのだが、「スパっ」とは行かないことが分かった。AcoustIDが登録されていない演奏はあるし、ひとつのAcoustIDでMusicBrainzのIDが多数出て来るものもあり、更に、前に書いたように、ひとつのMusicBrainzのIDに複数のISRCが登録されていることがあって、容易にISRCを特定できないことが多いのだ(これでは、gmusicbowserで聴いた演奏とSpotifyの演奏がマッチしないことが多いだろう)。まさに「なんだかなぁ」だが、フリーのサービスだから仕方ない。そういう時は、こっちがcontributeしなくてはいけない(のが建前だ)。
• Evernoteとの連携
  • 実現できそうな案はないが、このシステムに書いたコメントなどをEvernoteに(あるはその逆)転記しないで済むようにしたい。Evernote(Nixnote2)からこっちに飛べるリンク(URI)のようなものを作るといけそうではあるが・・・ → あ、webにならすぐにできるじゃん! → いや、そうじゃない。単純に飛ぶのでは何が書いてあるか分からないから、Evernoteにコメントを埋め込みたいのだ。

Spotifyのミニプレーヤーのプログラムが複雑なうえに、作ってから時間が経ってしまって中身を忘れているので、このシステムを組み込む(「ミニプレーヤーをこのシステムに対応させる」が正しい)のが億劫なのだが、自動スキップや音量正規化の補正は外部プログラムでもできそうなので、手軽に試せそうだ。

アイデアを考えてもすぐに試さずに考えて(「温めて」)いると、アイデアだけでなく実際の使い方も良く考えるので、いい方法(例: 簡単に実現できる)とか更にいいアイデアに繋がるのがおもしろい。すぐに作り出すのもおもしろいけど、無駄になることが結構多いのも興味深い。考えるうちに、「なんだ、これいらないじゃん」と、不要なことに気付く機能すらある(こういう時は手間が省けるので、「マジで」嬉しいｗ 結局、僕はプログラミング自体やパソコンだの計算機に張り付くのが好きではないのだろう。知らんけど。だって、そもそも画面を注視したりキーボードを叩くことが目的じゃないからね。僕にしてみれば、上に書いたことを「やって」と指示したらすぐにできるものがベストだ)。

そして、このシステムは、最初は「まだ聴いたことのない演奏を手軽にSpotifyで検索する」ために作ろうとしたのだったが、検索機能の充実はそっちのけで自動スキップのようなアイデアに夢中になっていたり、検索にしたって、「嫌いなアーティスト・演奏は出て来ないようにしたい」と思っている(いた)ところを見ると、僕がいかに「嫌いな曲は少しでも聴きたくない!」、わがままな奴かが分かったのも、おもしろいｗ

PS. そもそも、システムの名前をちゃんと決めなくてはと思っているのだが、なかなか付かない(ただ、何も呼び名がないと不便なので、自分では"Tih DB" (Tih= Track info. and history)や"Tih web"などと呼んでいる。: 名前からも分かるように、基本的にはSpotifyを中心としたシステムではない)。ここまで決まらないものは珍しい。それだけ、コンセプトが確定してない、やりたいことが多いってことだろうか。まあ、音楽は奥が深いからね。

PS2. 別の(まじめな?ｗ)意味でのこのシステム作りでの大きな収穫は、DB(SQLite)とJavaScriptに抵抗がなくなったことだ。どちらも全く得意ではなく「ちょっと使える」程度だが、躊躇せず(「重い腰」を上げなくてもいいｗ)使えるようになった。DBは便利だとすら思って、他にもいろいろ使いたいほどだし、webはJavaScriptを使わないとできないことが多い(正確には、使わなくてもやればできるけど、ページ遷移が生じて鬱陶しくなるし、効率が悪くなってしまう)ので、仕方なく多用している。

PS3. 書こうと思っていたけど書けなかった、Spotifyの検索などのAPIがしょうもない件については別途書きたい。

(20:49 修正・加筆)