Archive for the ‘日記’ Category

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

 

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

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

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

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

  •   0
  •   0

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

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

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

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

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

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

  • 以下のような流れで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をシームレスに(シャフル)再生できそうな(したい)気がして来て、夢にはまったく限りがないw

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

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

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

 

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

  •   0
  •   2

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

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

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

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

は? アフォですか?

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

 

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

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

 

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

 

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

  •   1
  •   0

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

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

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

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

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

 

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

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

が、

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

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

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

  •   0
  •   0

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

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

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

なぜ"CRC48"がないのか?

はじめに目を付けたのはCRCである。ただ、僕が使っているPHPには32ビット(8文字)のCRC32しかなく、どうも心許ない気がした。具体的には、ID(曲数)が増えた時に重複(「衝突」)しそうな気がした。とは言え、僕はこの分野に詳しくないので、本当に32ビットで不十分なのかの確証はない(理論上は、32ビットでは約40億(232-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)に騙されたw

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に登録できる(屏風の中から虎を出してくれたらそのプログラムを書きさえすればねw)。

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

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

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

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

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

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

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

  •   0
  •   1

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

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

先日も書いたように、再生している曲・演奏・録音(以下「演奏」)が「何か」を特定(同定)することが難しい。なぜ同定が要るかというと、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を得る。

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

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

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

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

  • (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が入ってないものもあるだろうし、レンタルのものはできないし、そもそも、面倒だからやりたくないw

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

(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の機能を使って統合されているように見せたい)。

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

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

  •   1
  •   0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

  •   0
  •   1

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

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

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

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

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

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

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

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

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

と思いきや、また来た!

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

  •   0
  •   0

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

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

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

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

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

 

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

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

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

(20:49 修正・加筆)

  •   0
  •   0

ISRC(International Standard Recording Code)は音楽の演奏(正確には録音)固有の識別記号で、世の中のレコードでもCDでも何でも、同じ録音なら同じ値で示せる。つまり、コンピュータの文字ならUnicode、日本の何か良く分からないシステムwならマイナンバーのようなものだ(どこかに書いてあった)と信じていたのだが、そうではなかったようだ。。。

というのは、今日、何の気なしに(という訳でもなく、別件の確認がてら)、開発中のシステムの再生履歴のページを見ていたら、表面的には何もなかったのだが、デバッグ情報に見慣れないメッセージが出ていたのだ。そして、再生履歴を確認したら、確かに再生したのに履歴に出ていない曲があったのだ。

その直接の原因は、どうも、「変なプレイリスト」を再生したからのようだ。いや、そもそもSpotifyなので、変なものはできないはずなのだが、海外の団体が作ったせいか、含まれている曲(の属性?)が日本には合っていなかったようなのだ。

更に詳しく書くと、そのプレイリストで再生した曲には他の曲同様にISRCが付いているのだが、それでSpotifyを検索しても出て来ないのだ。それではと、その曲の題名やアーティスト名で検索したら、ISRCが異なるものが出て来た。それだけなら、まあ、リマスターとかリミックスの可能性があるのだが、検索の結果はその1曲だけで、出て来なかったISRCの曲は含まれていないのだ。更に、MusicBrainzで検索したら、なんと、その曲には6個ものISRCが付いていた・・・ これって、ある人に6個のマイナンバーが付いていて、しかも、普通に検索しても分からず、それぞれ別の人に見えるのと同じことだ・・・ 破綻してるよ!

ちなみに、問題のプレイリストは"80s Classic Hits"で、曲は、Bon Joviの"You Give Love A Bad Name"(アルバムは"Slippery When Wet", 1986)である。「変な」ISRCはNLF059290010で、Spotifyで一般的らしいのはUSPR39402224だった。もちろん、それぞれSpotifyのIDも違う。Spotifyの検索API(Search for an Item)のwebでも出て来ない。ただ、SpotifyのIDから生成されるURLを指定すればちゃんと表示・再生できるので、日本では不可という訳ではないようだ。そして、MusicBrainzでは同じ曲(演奏)の扱いだ。もちろん、この曲だけでなく、変なのは他にもある(→ PS3)。

まあ、いろいろな可能性はあるだろうが、いろいろな国や地域のレーベルがいい加減なことをして、(その国や地域での)再発なのに新たなISRCを割り当ててしまったのではないか。システムを検討する時に参考にしたビートルズは厳密に管理されているから分からなかったが、普通のバンドではそこまで手が回らないのだろう。それは理解できるが、

全く困る!

これでは、何をもって、「この曲は聴いた」と判定すればいいのだ。曲の題名などでの判定なんて、全くできない。さまざまなバージョン違い(初出、再録、ライブ、リミックス・・・)があるからだ。もちろん、CDの型番なんて更にひどい。

という訳で、ISRCを曲(演奏)のIDに使っている、今作っている音楽再生履歴・評価管理システム(仮)の根幹が揺るいでしまった。実際にはISRC以外もIDとして使えるように考えていたので、全く無意味になった訳ではないが、結構ガクッと来た。

 

PS. まあ、西洋だからってものすごくちゃんとしている訳ではないってことだ(それでも日本よりはマシだと思うがw)。Unicodeだって、実際には妥協の産物のおぞましいもので(それでもJISやSJISやEUC、その混在よりはずっとマシだろう)、前にも書いたが、さまざまな似たような文字がてんこ盛りだ。

PS2. ISRCが駄目だとして、代わりをどうすればいいのか考えても、いい代替は浮かばない。現時点ではMusicBrainzのIDが一番まともだが、使うのは気が進まない。今はいいが、継続性に疑問があるからだ。

(5/29 13:25追記) 以前考えて保留にしているのは、音響指紋というものを使うことだ。簡単に言えば、その名のとおりだw 今はいろいろなプログラムが出ているようなので、計算するのは容易だ。ただ、計算が少し重いので気軽にはできないのと、その値をISRCのように短く表すことができない(MusicBrainzだと、アップロードしたものは短く表せるようだ)のと、公開DBがそれほどない(無料なのはMusicBrainz程度?)のが問題だ。

いずれにしても、なぜかMusicBrainzに依存するみちばかりで、ちょっと躊躇している。

まあ、MusicBrainzのサービスを使わなくても、指紋は演奏の同定だけに使うことにして曲情報はSpotifyやMusicBrainzやDiscogなどから(今は必然的にSpotifyになる)適宜取得するなら、MusicBrainzに依存しなくても行けそうではある。指紋を短くするのは、MD5とかCRCなどでダイジェスト処理すればできるから、(短くしたあとで重複しなければ、)それほど大きな問題ではないかも知れない。

この方法のメリットは、今回の問題のように、同じ曲なのに複数のISRCが振られていても、指紋は一緒になるはずなので、必ず(本当かなあ?)同じ曲だと分かることだ。

なんかいい感じがして来た(でも、今までの経験から、必ずどこかに落とし穴があるんだろう)w

さっそく落とし穴があった。Spotifyのような配信サービスでは、合法的に曲のデータ(ファイル)が取得できないから、自分では指紋が計算できない。サービス提供元が指紋を提供してくれるか、MusicBrainzなどの公開DBでISRCなどを使って検索して取得するしかない。

やっぱりMusicBrainzか・・・

指紋の取得元を特定のサービスに限定しないように作ればいい気もしたが、指紋の計算方式にはいろいろあるから、それは無理そうだ。この場合は指紋をDBに保存せずに、常にサーバから指紋を取得ればいいのかも知れないが、それにも欠点はある。

PS3. 他の「変な曲」は、これが問題に気付いた原因なのだが、ISRCでSpotifyを検索すると曲情報は出てくるが、その内容がおかしいのだ。形式的には正しいのだが、やっぱり元のプレイリストが「変」だったようで、そのプレイリストで再生した時の情報とは異なる曲しか出て来ない。例えば、検索で出て来た曲は、再生した時のものとはSpotifyのアルバムIDやトラックIDが異なっている(そして、普通に検索してもこれらが付いている曲は出て来ない)。そのために、僕の再生履歴DBの曲とマッチしなくて、再生履歴に出なかった。

こういう曲はISRCで検索できるからまだマシで、異なっている情報のうち、再生履歴DBにないもの(例: 曲再生用URL)はDBの内容(例: トラックID)で修復(補完)して表示できるようにした。ただ、DBにない情報は無理なので、例えばジャケット画像は出せず(「何か」出せばいいのなら、検索で出たものを使えばいいが、例えば、その曲が入った別のアルバムが出てしまう可能性もある)、そこが歯抜けになってしまう。

PS4. その後、Spotifyの検索API(Search for an Item)でISRCでの検索がまったくできなくなってしまったので、APIの機能が変わったのか(まだ、ドキュメントではできることになっている)、もともとあった不具合の影響が増大したのかも知れない。 (6/5 7:17) → 結局、この問題(ISRCで曲が検索できない)は、SpotifyのトラックIDで検索することで回避した。つまり、SpotifyのISRCはあてにならない(検索で出ないことがある)ようなので、そもそもSpotifyの曲なのだから、SpotifyのトラックIDで曲を検索すれば何も問題はなかったのだ。灯台下暗しとか、コロンブスの卵とでも言うのだろうか。 (6/5 19:51)

(6/5 7:17 加筆・追記)

  •   1
  •   1

動作確認や修正や暇つぶしにSpotifyの再生履歴記録・検索システム(仮)のページを眺めていたら、なかなかおもしろいことがあった。単にテストのために思い付いて入れたのだと思うが、(ビートルズの)"Sgt. Pepper's"での検索結果を見ていたら、本物以外に数多くのカバーがあった。

それは当然だから驚きもしなかったし、ほとんどは「いかにも『カバーしてみました』」って感じで全然興味が湧かなかったのだが、数が多いのに感心して下まで見ていたら、2作、目をひくものがあった。一つはある意味恐ろしい問題作w、もう一つは感心するくらい良かった。こんなに幅広いとは、さすがビートルズだ。

まず、「問題作」は、大場久美子のカバー(シングル)、"Sgt. Pepper's Lonely Hearts Club Band"(1979?)である。そもそもこの人がこれを歌う意味や理由が不明だったが、「怖いもの見たさ」で聴いてみた。が、あえて書こう、

ひどい・・・ 下手過ぎる。

数秒ではなかったが、(記録によれば)1/3くらいで止めた。もちろん、評価を-5(最低)にした。なんでこれが発売されているのか謎なレベルだ。そういえば、これの入っていたベスト盤の曲目を見て、「あれ? 『狼なんて−』とか、ヒットがあったはずだが・・・」と思ったあとで誤解に気付いたのだが、大場久美子は「コメットさん」ではあったが、石野真子ではなかったのだ(もちろん、浅田美代子でもない)w 石野には大変失礼なことをした。

気を取り直して、次のAndy Timmonsという人のカバーアルバム(ビートルズのと同じ曲目+1)、"Andy Timmons Band Plays Sgt. Pepper"(2011)を聴いてみたらなかなか良かったので、通して聴いた。一つだけ残念な曲("Being for the Benefit of Mr. Kite")※はあったが、それ以外はどれも好意的に聴けて、全体的にはとても良かった。

※残念だった理由は、この曲は大好きな曲なので期待して聴いたら、最初は良かったのに途中から"I want you"になって だらだらしてしまったからだ。本人としてはそうしたかったのだろうが、この曲はきびきび・活発で簡潔なところがいいのに、どろどろしてしまうのはちょっと違うと思った。

そもそも、なぜこれにひかれたのかは分からないが、ジャケットの雰囲気で期待させられたのだと思う。良くあるカバー作は、オリジナルを下手に真似てとてもセンスが悪いのだが、これは全くそうでなく、ストイックに、演奏したいからしたというような雰囲気が出ているところがいい。

石野真子とAndy Timmonsが並ぶ、シュールな再生履歴

※↑ 投稿時に酔っていたのだろうか、「大場久美子」と書くべきところを「石野真子」と書いていた。本当に混同していた証拠だ。申し訳ないので、訂正せずに恥を隠さないことにする。 (5/28 20:04)

という訳で、このシステムの検索機能はまだまだ開発途上ではあるのだが、それでもいろいろ遊べることが分かって「ご満悦」であるw それ以外に、昨夜、やっぱりテストや好奇心で検索結果を見ていたら、今まで聴いたことがないラフマニノフのピアノ協奏曲第3番の演奏(Lukas Vondracekのエリザベートコンクールでの演奏, 2016)が見付かって、早くも本来の用途に役立ったから、改良すれば便利になりそうだ。※

※これを書くのに、その演奏が誰の何だったか調べようとしたのだが、履歴検索はまだ手軽にできなくて(SQLの一部を打ち込むので、気軽に日付で検索するなんてことはできない)ちょっと苦労したけど(日記やDBブラウザを見れば一発だが、意地で使ってみたw)、ちゃんと見付かった。

  •   1
  •   0

SpotifyのRelease Radarで新作を聴いていたら、中に竹内まりやの「ドリーム・オブ・ユー~レモンライムの青い風~」(1979)が入っていた。そういえば、近頃入ったというのを読んだのを思い出した。もちろん曲は懐かしかったが、ジャケットを見て更に懐かしくなった。

竹内まりや "UNIVERSITY STREET" (1979)

テニスのラケット! そして、ファイル(みたいなの)! まさに絵に描いたような女子大生だ。そして、ポニーテールと白いTシャツがいい。(実際に見たことはないが、)昔の都会にはこんな女子大生が大勢居たらしいけど、見事に絶滅したねぇw 呼び方もJDなんて味気もセンスもないものになってしまったな。

 

PS. (典型的な女子大生の写真やイラストを見て)当時から不思議に思っていたのだが、これだけの物しか持たずに済んでいたのだろうか? ファイルみたいなのは教科書数冊のこともあるが、それ以外の教科書や資料やノートや筆記用具は要らないのだろうか。文系の学生は授業が少なくて、そういうのは余り要らなかったのだろうか。あと、スマフォや携帯電話やゲーム機など(それらは当時はラケットだった??)は当時はなかったがw、お金や定期券や、女性なので化粧品などは不要だったのか。今となっては謎が多いw

  •   2
  •   0

Spotifyの再生履歴記録・検索システム(仮)が大分できて来た。まだまだやりたいことは多いし、修正・改良すべき点も多いが、一段落した感じだ。

見た目が前回とほとんど変わらないのが残念だがw、7割くらいはできた気がする。それにしても、いつものことだが、体感で半分を超えると、ぐっと進みが遅くなる。できあがるにつれて、完成度を高めるために作業量が増えるうえに、動き出して使ってみると新しいアイデアが出てくるので、更に作る量が増え、そのために修正や動作確認をする時間も雪だるま式に増えて、逃げ水のようにゴールが遠くなる。

前回からいろいろやったのだが、見た目のインパクトが大きいものは、ボタン一発でSpotifyの再生履歴が出せるようになったことだろうか。前回は再生中の曲だけだったのを、(DBのコマンドを駆使して)指定した数の過去に再生した曲を取れるようにした。もちろんSpotifyアプリでも出るが、自分で作ったので随分使いやすい。例えば、評価やコメントをあとから手軽に書けるようになった。他には、webなので、タイトルなどをコピーできるのは誰にでも便利な気がする(もちろん、web版Spotifyでもできるが)。

あとは「できたてのほやほや」(でまだ満足に動かないw)のアルバム表示機能も便利だ。検索結果や再生履歴に表示されている曲のアルバム名をクリックすると、そのアルバムの曲が全部表示される(書くと当たり前の機能ではあるな・・・)。他に、Spotifyのアルバムやトラックへのリンクも表示するようにしたので、日記やブログで参照するのも楽になりそうだ(ミニプレーヤーでは簡単だが、アプリだとメニューを数段階移動しないと取れない)。

逆に、苦労して作ったけど意外に使っていないのは再生機能だ。これはアプリで充分だ。でも、そのうち検索機能(これが一番の目的なのだ)が充実したら使うかも知れない。

そして、今日の夕方くらいから、聴きながらコメントや評価を付けたり過去の感想を転記したりして、実際に使っている。自画自賛だが、なかなか便利だ。最初はそれらはDB管理アプリ(DB browser)で入力・修正していたのだが、段々使う機会が減って来た。

残件で大きいのは、ミニプレーヤーとの連携(履歴や評価のアイコンを出す、手軽に履歴を付ける、コメントを書くなど)だ。それから検索のプリセットの作成(今は検索条件にSQLの一部を打ち込んでいるのを、いくつかのパターンから選べるようにする)だ。

作っていて思い付いたのは、Spotifyのリコメンドでない、「自分のリコメンド」(履歴と評価をもとに、自分の好きな曲だけを選んで掛ける)を再生できるとおもしろそうだ。そこまでは行かなくても、意味があるかは別として、このシステムに自分のプレイリストが作れる。将来、別のプレーヤー(gmusicbrowser)とも連携できたら、プレーヤーをまたいで再生できるようになるからおもしろそうだ。

もう一つのアイデアは、嫌いな曲が掛かったら即座に自動で飛ばす機能だ。これはすごく便利そうだw ただ、たまに気まぐれで聴きたい時もあるだろうから、ある程度の猶予時間が要りそうだ。

ちなみに、このシステムを作ろうとしたのは、Spotifyをより便利にしたいこともあるが、自分の再生履歴や感想を記録するためでもある。だから、Spotifyに特化したものやべったり依存するものを作ろうとしている訳ではない。仮に将来、Spotify以外のサービスに乗り換えたとしても、記録した情報は使いまわせるようなデータ構造にしている。ただ、そのサービスにSpotifyのようなAPIがないと、再生した曲の自動記録はできないので、そこが結構重要だ。更に、配信サービスを止めたとしても、いいと思った曲の記録は残っているから、買うなどすれば聴くことができる(DBにはそれぞれの曲のISRCを記録しているので、何らかの形で配布されていれば、その演奏が聴けるはずだ)。

なお、最初に少し心配していたDBのサイズだが、文字しか入れていないので当然ではあるが、とても小さい。今までの約2週間で940曲くらい記録したが、DBファイルのサイズは320KB程度なので、1曲あたり300バイト前後だ。ずっとこのペースで行くとすれば、1年では2.5万曲くらいになり、サイズは7MB程度で済みそうだ。なお、定期的にバックアップや"vacuum"というコンパクト化の処理も行うようにした。

 

PS. 作っていて思ったが、Googleなどのサーバには、こんな感じで、各ユーザのいろいろな履歴がまさに山のように記録されていて、すごいAIがあれば(きっとあるんだろう)何でも分かってしまいそうだ。技術的にはおもしろいけど、僕はなるべく"Let me out"させてもらいたいw

でも、それとは関係ないけど、Googleの画面作り(配色・配置)は嫌いじゃないw このシステムのwebページの雰囲気が似ているのは、そのせい(好みの近さ)かも知れない。特に似せているつもりはないが。そして、ダークモードは大嫌いだw

  •   1
  •   0

以前から何回か触れていた、「実質ガッキー」と言われていた椎木という人がYouTubeを始めたというので、当然ながら酷評はあったものの、観てみたら、頭の1秒未満で「駄目」という結論に達した。

僕は、訳もなく世間から叩かれてしまっている人には、判官贔屓のように「頑張って」と言いたくなる(今までに何回かここに書いた。例えば沢尻や昔のJRスキーの人(川口)だ)のだが、彼女には全く起こらない。やっぱりセンスがないんだろうな。だって、例えばイチローのような国際的な有名人でもないのに、頭っから

Hi everyone♡

はないだろう。もう、1秒未満(0.3秒くらい?)で耐えられずに止めて、Thumbs downを押したよ(キャプチャを見ると、実際には数秒は観たようだ)。まあ、可愛い(かどうかは意見が別れるだろうが)かも知れないが、センス・能力がない。これを観てもらいたい相手を分かってない。いい歳して、「なんか作ればきっと受けるだろう」という安易な気持ちで作ったのではないだろうか。いや、逆にとんでもない数のThumbs downをもらいたくて作ったのかも知れない。それなら大成功だ(観た時はUp: 433/Down: 1.1万で、downはすぐに千増えた)。

いずれにしても、まったくもったいない。だから、これを機に忘れるということもなく、これからも冷ややかな目で見つめ続けたいと思う次第だw

 

(5/28 20時 追記) 本当かどうかは分からないが、彼女は留学経験がないとのことだ。なるほどと思った。それが本当なら僕の違和感の一因だと思う。留学は必須でもなんでもないと思うし、そもそも、英語(=道具)が話せること自体に意味も価値もないとも思うけど、彼女は、真に必要で英語を話したことがないし、それ以前に、英語圏(西洋)の考え方を分かっていないのだろう。だから、日本人しか見ないYouTubeなのに英語で挨拶してしまったのだと思う。

とは言え、僕だって留学したことなんてないし、英語圏(西洋)の考え方を分かっているか まったく怪しいものだがw

 

PS. 今思ったのだが、こう思う理由は、この人は確かにしょうもないけど、決して、「CDで握手/投票」なんてクソみたいなことをするほど世の中を舐めていないからかな? あとは、烏合の衆よろしく何百人もで徒党を組むことなどせず、自分で悪評を引き受けているのは、数少ない認められる点だろう。だから「とりあえず観た」のかも知れないw

(5/22 7:34 誤りを修正)

  •   1
  •   0

今回の趣味の開発でいろいろ困っては小技を見付けて対処しているのだが、一番困るのは、JavaScriptからPHPが呼べないことだ。もちろん、外部プログラムも実行できない。実際には、それができたらブラウザが危険極まりないものになってしまう(ActiveXみたいな話?)からあり得ないのだが、僕の今の用途では、是非ともJavaScriptやHTMLからPHPや外部プログラムを実行したいのだ。

というのは、例えば、曲の評価の変更のユーザ操作はHTMLとJavaScriptでしか実現できないが、変更した値をDBに書き込むのはPHPや外部プログラムでしかできない。まあ、JavaScriptでライブラリを探して使ってネット経由でDBのサーバにアクセスすることはできるのかも知れないが、大掛かりになってしまう気がする。

そういう時、基本的には、JavaScriptやHTMLからリンク経由で別の保存処理をするページに飛び、その時に必要なデータを引き渡す。飛び先のページではまずPHPが動くので、渡されたデータをDBに書いたり外部プログラムで処理することができる。

そのデメリットはページが変わってしまうことだ。大昔はそういうのばかりだったが、今はページ遷移なしで処理するのが当たり前になっている。見栄えだけならいいが、ページの状態を全部引き継ぐことができないのが問題だ。今回はSpotifyの検索結果(結構大きくなる)を引き継ぐのが面倒だ(遷移するたびに検索し直すのは無駄だし遅くなる)。検索結果を引き継ぐのは不可能ではないが、中間ファイルが必要になるだろう。

そこでいろいろ考えたら、2つの方法を思い付いた。最初に、HTMLのiframeを使う方法を思い付いた。PHPや外部プログラムの機能が要る処理、例えば、データを保存するのに別のページに飛ぶことは必要だとして、今のページも残せる方法を考えたら、iframeが使えた。以下のような流れになる。

  1. データを保存する契機になる。
  2. iframeにデータを保存するURL(保存するデータも一緒に)を指定して開く。(実際には、このURLは自分自身で、引数を特別なものにして行う処理を指定している)
  3. そのURLでデータの保存が実行されるが、結果はiframeの中に(小さく)表示されるので、今のページはそのまま残る。

JavaScriptを使えば一定時間後にiframeを閉じることができるので、下の方に小さく作っておけば、見た目のインパクトも少ない。

しかし、その後もっと簡単な方法に気付いた。JavaScriptでデータを保存するURLを指定して開くのだ。これなら結果は表示すらされない(しかも、JavaScriptで結果が受け取れる)ので、まったく楽だ。昔流行った"AJAX"らしい(今はfetchという機能がいいようなので、それを使っている)。この場合は以下のような流れになる。

  1. データを保存する契機になる。
  2. fetchでデータを保存するURL(保存するデータも一緒に)を指定して開く。(上と同様に、このURLは自分自身で、引数を特別にしている)
  3. fetchでURLの結果を取得して処理を開始する。

ただ、これの問題点は、URLを開いた(処理を実行した)結果を待てないことだ。fetchの中では結果は受け取れるが、fetchを実行した側はそれが終わるのを待つことができない(fetchが開始したことが分かるだけ)。それで、fetchの中(URLを呼んだ節。スレッドのようなもの)でfetchが終わった後に結果に対応する処理を行う必要がある。JavaScriptが非同期なための手間だ。

でもまあ、この(AJAX)の方法に気付いたおかげでiframeすら不要になって、Spotifyプレーヤーでの再生開始やDBのアクセスなどが手軽に(とは言え、実際のプログラムは、実行したい処理を自分自身(のプログラム)で行うにも関わらず、ネット経由で再び起動されたりするので、ものすごく煩雑だし効率も悪い)できるようになったのはありがたい。

ただ、僕としては、そもそもそういうことをネット経由でやるのが気に入らない。もっと普通のやり方があるのかも知れないので、おいおい考えてみたい。まあ、全部JavaScriptで書く(例: Node.jsとかElectronとか)のがそれなのかも知れないが、非同期は「普通」じゃなくてすごく疲れるからねぇ・・・

  •   0
  •   0

あれから寝食を忘れてw作っていて、web(検索画面)が大分いい感じになって来た。何をどう良くしたのか、思い出したり調べて書くのも面倒だが、僕的には随分良くなった気がするw 例えば、評価を色の濃さで出す(図中の♥マーク)とか、平均「完奏率」(最後まで聞いたか)※を棒グラフで出すとか、前の投稿に書いたが、再生をwebでなくSpotifyプレーヤーでできるようにしたとか、トラック情報を開閉できるようにした辺りだ。まだまだやることは多いが、それなりの形にはなって来た。

※「「完奏率」(最後まで聞いたか)」は少し誤解しやすいので補足すると、1曲を最後まで聴いたら1、途中で止めたり飛ばしたら0なのではなく、止めたり飛ばした時点までの再生時間の曲の長さに対する割合が1回の完奏率になる。例えば、半分まで聴いたら0.5である。その合計を再生回数で割ったものが平均完奏率である。

プログラミングしていると時間がすぐ過ぎるし、おやつはもちろん食事も面倒になるから、ダイエットになるうえにお金も掛からないおから、いいことづくめだね。ってなんか、シャレにならないけど、そんなことはないよw これからの人は、みんなプログラミングするみたいだから、メタボになる心配はなさそうだね。頑張ってね!(爆)

(5/19 20:58) その後もいろいろ改良していたが、見た目は劇的には変わっていない。Spotifyは、どうしてか、クラシック音楽の作曲者をアーティストに入れてしまうので、ミニプレーヤーでしているのと同様に削除するようにしたことと、「現在再生中の曲」をボタン一発で出せるようになった(の中央上部の"Now playing")のと、評価をスライダーで設定する(図の右下)UIができたくらいだ。もちろん、普段はスライダーは出ていないし、評価を変えたらアイコンも色も変わるよ!w (→ デモ動画)。HTML5のおかげで、こういうの(inputのrangeというのを使った)が手軽に(とはいえ、何度も書くが、HTMLだのJavaScriptは苦手なのでそれなりに苦労したがw)できるようになってありがたい。

今は、コメント欄もトラック情報や評価と同様にアイコン(ボタン)を押すと開いて入力できるようにしようとしているのだが、UIの概形ができたところで力尽きているw 不思議なことに、余り考えずに「これだとどうなるかな」とテキトーに作ったら、「こうなったらいいね」っていう感じに入力欄が開いたので、何かの奇跡かと驚いた。 ← イマココ(ってやつ)w

 

体験談的なことを書くと、SQLはなかなか馬鹿にできない。なんというか、僕から見れば「しょうもないもの」だったのだが、ちゃんと完結していて、(苦労して)使いこなすとかなりいろいろな検索や処理ができることが分かった。DBの基本のトランザクション※も便利だ(普通にプログラムを作るのでは実現が面倒なことが、1行でできたりする)。どういう経緯で今の状態に至ったのかは知らないが、最初からこういうのを考えて作ったのならすごいことだ。ただ、今使っているSQLiteはとっつき安いのはすごくいいものの、他に比べて若干機能が少ないので、凝ったことをしようとすると手間が増えるのが残念だ。

※トランザクションの例: 「DB中の、名前がAのデータの要素bの値が10より小さかったら+1して書き込む」が1行でできる。しかも、この1行(SQL)の処理は不可分なので、複数プロセス間での競合が起こらない。あるプロセスが読み出して+1して書き込む前に他のプロセスが+1して書き込んでしまうなんてことがない。

あと、以前も書いた気がするが、PHPとJavaScriptとHTMLを同じファイルに書くので、ちょっと見てもなんだか分からないし、それぞれ文法が違うからいつも間違うし、その部分がいつ実行されるのかを誤解するし、文字列を囲むレベルが増え過ぎて囲むのに使える文字がなくなったりして、かなり厄介だ。一番不便なのは、JavaScriptからPHPの機能が呼べない(あるいは、戻れない)ことだ。よく考えれば当たり前(実際には、PHPからJavaScriptを呼ぶことだってできない)なのだが、そこが何とかできると楽になると思う・・・ だから、サーバ側も全部JavaScriptで書く例が増えているのかも知れない(ここはよく分からない)。

(5/20 22:09) コメントのUIも何とかなった。(→ デモ動画) 昨日から何も変わってないように見えるが、見た目を変えてないから当然だw あとはやっつけ仕事で作った下回りの処理(DBへのアクセス)などをちゃんとしたい。

コメント設定機能も動き出した。

 

それから、SQLiteへのネット経由でのアクセスは、rqliteというもので可能なようなことが分かった。その他に、socatとsqlite3コマンドを使って自分で実現することも考えられた。後者は全く面倒で安定性に欠けるから論外だが、前者は何となく筋が良さそうだった。が、他にも同様に「自分」に通信する必要があるもの(例: Spotifyでの再生)があるので、ひとまず保留にした。

 

(5/17 21:00 完奏率について補足; 5/19 20:58 現状を追記; 5/20 22:09 現状を追記)

  •   0
  •   0

先日から始めた、Spotifyで聴いた曲を自動で記録し、検索結果と一緒に表示する仕組み(一言で何と言うのか、まだ迷っている)のプロトタイプが動き出した。画面(web)は以下のような感じだ。プロトタイプなので、トップは太古の「ホームページ」wのように、余りにもシンプルだ。検索結果は少し(結構)凝って、(力技でw)それなりにした(まだ細かい問題は多い)。

もちろん、主目的の再生履歴が出るようにした。再生した日時(自動で記録される)はもちろん(今は最初の日時のみ)、評価(今はDBに手入力する)が♥(好き)や✘(嫌い)で出るし、コメントも出る(これも今は手入力)。そして、ジャケット画像やアルバムや曲のリンクを押すと、ちゃんと再生できる(今はまだSpotifyのwebプレーヤーに飛ぶだけ → Spotifyのプレーヤーアプリで再生できるようになった → デモ動画)。

全体的な構成の概要は以下のとおりである。

Spotifyプレーヤーミニプレーヤー・リモコン
 ↑                         制御                |
 |                                               ↓
 |        再生曲情報の自動記録 ← (再生曲情報ファイル)
 |再生         ↑↓
 |指示   DB (SQLite)
 |          ↓再生履歴
検索画面(web)  ⇔  Spotifyサイト
                     検索(API)

検索条件の指定方法は模索中だ。今は、Spotifyの条件(これが結構使えない・・・)と再生履歴の条件を別にしている。後者は、なんとSQLの条件式を入れるようにしている(画面上部の"History search"の欄を参照)。今はこの方がいろいろ試せるからいいのだが、将来的には「再生したことがない」/「−ある」といった、プリセットのようなものを選択できるようにしたい(画面中の式は「再生したことがあるアルバム中のトラック」の例)。

RDBのSQLにはなかなか苦労したが、大分使えるようになった。慣れれば便利な感じだ。でも、泥沼のように奥が深いようだw それ以外にも山ほど考え・試行錯誤・工夫・苦労した話があるし、「とりあえず」や"TODO"も山ほどあるwので、あとで書きたい。まずは作るだ。

その後、大分改良できた。検索結果が多い場合に画面がとんでもないことになるので、どうしたらいいものか考え、(良く見るが)開閉ボタンでアルバム中のトラック情報を表示・非表示できるようにした。アルバム情報の下の"♪"を押すとトラック情報一覧が出て、再度押すと消える。(→ デモ動画)

やる前は、大の苦手なJavaScriptを使うのが嫌なので、何とか別の方法がないか考えていたのだが、なかなかなくてJavaScriptでやらざるを得なくなった。もちろん、(僕の技術で)できるのか分からなかったが、その前に検索ページからSpotifyプレーヤーで曲を再生するために使った方法(なかなかトリッキーなので、あとで書きたい)がヒントになったので、意外に容易に「それなり」にできた。

こういうのは、世の中に出回っているいろいろなライブラリを使えば簡単なのだとは思うが、そもそも、何が一番使いやすいのかも分からず、選んで使うのに慣れるまでが大変な(気がする)ので、自分で「適当に」作った。きっと、どこかに落とし穴があるに違いないw (5/15 17:32)

 

(23:51 システム構成を追記; 5/15 10:40 Spotifyプレーヤーでの再生のデモ動画を追加; 5/15 17:32 トラック情報表示の件を追記)

  •   0
  •   0

ニュースに「10%の食塩水1kg作るのに必要な塩と水は? 大学生が「%」を分からない絶望的な日本」というのがあって、どうももやもやした。僕も間違える気がするのだ。

というのは、これは昔からある引っ掛け問題で(小学校の頃に引っ掛かったか教わって、それ以来、苦手意識がある)、最後に1kgにしなくてはならないので、単純に1Lの水に食塩100gを入れるのでは間違いなのだ。でも、化学の実験はともかく、日常生活ではそれで充分な気がする。

誤差を計算すると、

  • 正しい場合: 10% (正答: 900gの水に100gの食塩)
  • 誤答の場合: 1Lの水に100gの食塩を入れた場合、9%
  • → 誤差率: -10%

なるほど。意外に誤差が大きいようだ。でも、大きな問題はない気がする(ちゃんとした料理だとそうでもないのかな)。

あと、正答を転記して思ったのだが、この%は重量率なのか容積率なのか不明ではないか。全部gだから重量率なのは自明なのか。そこで引っ掛かる人も居そうだ。細かくチェックするならちゃんと書けって言いたい。それに、「水900g」ってすごく違和感がある。器でなく秤で測るの? 濃度を室温に無関係にしたいのか。

それから、そもそも食塩が水に10%も溶けのるかという疑問もある。調べたら、常温で20%以上溶けるようなので問題なかったが、どうも、問題以前にこういうところでつまづいてしまいそうだw

PS. このニュースの題は今ひとつ適切でない。本文を読む限り、大学生が食塩水の問題を解いた訳でない(解いたのは中学生のようだ)のだ。近頃はこういうのが多くて、そこにももやもやする。あと、全角スペースは使うなとあれほど(略)w

  •   0
  •   0

先日、前回から一か月おいて歯科に行った。随分混んでいるようだ。前回は、左上の奥歯の詰物(金属)と歯の境目に穴が開いているので、セラミック(保険外)か金属(保険)のどちらにするか決めるように言われた。保険の金属はどうも良くない(今回のように、境目から虫歯になってしまう)感じなのでセラミックがいいのだが、ダメ元でレジン(保険)は可能か聞くことにして行った。

その日はなぜか寝不足だった。そのせいか、なぜかハイな感じになっていて、椅子に座るなり、衛生士さんにレジンが可能か聞いた。いつもは聞かれるまで待つのだが。すると、範囲が大きいから無理とのことなので、セラミックにした。

ここまでは想定範囲内だったのだが、ここからが予想外だった。なぜか、ディスプレイには(左でなく)右上の奥歯の写真が出されていて、歯科医師(前回の院長から変わり、息子のようだ)は、「右上奥歯の根本に亀裂があるので、そこを治す」と言った。

はい?

(確かに右は僕も気になっていたけど、)話が全然違うんですが。。。 結構驚いたし、(上述のように)寝不足でハイだったので、いつもと違って少しキツく反論した。前回の写真の確認などをしてもらって、左も要治療なことを分かってもらった。

ただ、謎なのは、前回はちゃんと左の奥歯の金属の写真で説明されたし、右も、写真を見ながら縦筋は割れではなさそうだから様子見という話を聞いたのに、どうして、今回は右の治療になっていたのだろうか。そういう記録があったのだろうが、それはいつ誰が書いたのか。前回の院長がトチ狂っていて言動が一致していないということ?? あとで記録を書いた時に、忘れたとか疲れとかでどっちか分からなくなって取り違えた? いずれにしても結構恐ろしい。こういう感じに医療ミスが起こるのかも知れない。何も言わずにいたら、別の歯を抜かれてしまったとかいうトラブルがあるのも分かる。

そして、セラミックと金属の選択でレジンは無理という話も右のことだったと思われたので、改めてレジンが可能か聞いたら、可能だということだった。もちろん耐久性は劣るとは言われたが、(僕の期待どおりになったので、)聞いてみて良かった。なお、右は削る範囲が大きいのでレジンは駄目だそうなので、セラミックにすることにした(今は昔より広くレジンが使えるようになっていることを読むが、それは都会とか最先端の話だし、常にそれが正しい・可能な訳でもないだろうから、ここで頑張ることはしなかった)。

結局、前回診てくれた院長がボケていた駄目だったようで、その時の鋭い衛生士さん※(と僕)だけが正しかった訳だ。

※今回と同じ人だったかは不明。雰囲気は同じような気がしたが、言動が違う気もした。寝不足のせいで、今ひとつ分からなかったw

というか、

あのジジイなんとかしろ!

すごく意外だが、こんなこともあるようだ。ただ、今回の歯科医師は若いせいか技術がありそうで、手際良く、丁寧に確認と説明をしながら治療してくれたので、最終的には安心した。次回も彼だといいのだが・・・

最後に、偉そうにも教訓めいたことを書けば、人は必ず間違えるので、それを前提に行動しないといけない。だから、患者も可能な限り考えて確認しないといけない。「言われたとおりにしていれば問題ない」なんてことは全くない。なんかのドラマで「私はミスしない」とかのたまう医師が居たようだが、アホかバカか、「出直して来い!」だ。そんなのに掛かったら却って怖いよ。

 

PS. 寝不足のせいでボケていて、隣の治療室(板で区切っているだけ)の衛生士さんの声が大きくて、その「型取りますねー」とかいうのが僕に言われているように勘違いして、数回「はい」と返事してしまった。こっちの衛生士さんは ちょっと驚いていた感じもしたが、無視していた。そこは微妙にいいような悪いような気がした。でも、若い頃と違って、このくらいでは全く恥ずかしく感じないw

PS2. レジンにできたおかげで、今回の治療費は2千円未満と、激安で済んだ(彼らにしてみれば、全然元が取れないのだろう)。

PS3. 気付いたら、保険の金属の詰物は2個だけになっていた。以前はかなり多かったが、長年掛けて(悪くなるたびに)セラミックやジルコニアやレジンに交換したおかげで、光るところが大分減って いい感じだ。

PS4. 一見関係ないが、秋のブロンフマンのコンサートは諦めた。冗談のようだが、セラミックの歯と同様の料金なので、歯を優先することにした。さすがに両方は使い過ぎだ。それに、前にも書いたが、今はルガンスキーくんが一番好きなのだ。そして、今はまだ、彼の方がコスパがいいw

  •   0
  •   0

どうしてか分からないが、同じアパートに、妙にタイミングが合う家族が居る。訳あって僕はその人たちが大嫌いだから全然見たくないのに、外出する時などに油断していると、必ずと言っていいほど出くわすのだ。

例えば、夕方、買い物に行く時、彼らの物音も声も聞こえないから、「今日は大丈夫だな」と思って部屋を出ると、それまで影も形もなかったのに突然降って湧いたように、なぜか帰宅して来るのに出会って、がっかりする具合だ。

大嫌いなら無視すればいいと思って、そうしようと思っていのだが、朝、やっぱり突然会った時に、向こうから挨拶されてしまって、仕方なく返した。更に弱いことに、その母親がいつも連れている子(幼児)までちゃんと挨拶してくるのだ。近頃は顔を覚えられたようで、笑顔で挨拶して来る。そんなことをされたら無視なんてできやしない。うるさいガキは嫌いだが、悪いのは親なのだ。馬鹿な親のせいで本人は常識を知らないだけなのだから、嫌な目に遭わせるのことはできない。

そもそも、なぜ大嫌いなのかというと、彼らが在宅している時は、年中、ドタドタ足音だの物音がして、すごく気に触るのだ。足音は、子どもの運動会のようなのだけでなく、親のものもある感じだ。物音は何か不明だが、こっちまで振動が伝わって来ることがある。どうしたら、そんなに頻繁に大きな音を立てる機会があるものかと思う。

子どもの足音にはムカつくが、子どもに罪はなく、悪いのは親なのでどうしようもない。毎日、「早く出て行って(引越して)くれ」とか、小さいパイナップルを放り込んでやりたいとか、いろいろひどいことを念じているが、まあどうにもならない。

そういえば、少し前に、外出する時に、ブチ切れていたので、「今度うるさかったら怒鳴りこんでやろう!」と思って、その家族の部屋をちらっと睨んだら、ベランダに、子どものものと思われる、小さい服(良く分からないけど、おむつカバーみたいなもの)が干してあって、それを見たら意気消沈してしまい、「彼らには悪気はなく、子育てなどで彼らなりに苦労しているんだろうから」などと思ってしまった(実際には、いくら悪気がなくても迷惑は迷惑だし、苦労しているのは彼らだけじゃないし、本当に苦労しているかすら不明だ※)。全くあまちゃんだ。まさに、

鬼の目にも涙

だw それで、とりあえずは大家に苦情を言おうと思っては居るのだが、電話すること自体が面倒だし、藪蛇になるかも知れないし、効果があるかどうかも疑問なので、いつも延期している。

※とは言え、僕らはまだしも、高齢者は古い知識と偉そうな言動で嫌がらせ(ありがた迷惑)をするようだし、都会では保育園を建てようとしても反対運動に遭うようだし、まあ、苦労はしているんだろうとは思う。そこに、家での物音にまで文句を言われたら、「あぁ・・・」ってなるだろうなと思うと、やっぱり無碍にはできなくなってしまう。

  •   1
  •   0