piu lentoの日々

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

半ば疲れつつも飽きずに作っている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 マウスオーバーを追加した件を追記, わずかに修正)

ようやく正式な名前を決めた、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 若干加筆・修正)

開発中の音楽再生履歴記録・検索システム(仮)、そこそこ使えているうえに、煮詰まっているというか、完成度が高くなってきたために(それでもまだ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 追記)

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

• 検索条件のプリセットを登録できるようにする。
  • 固定のプリセットを何個か用意するのでなく、随時自分で登録できるようにする。: 今までは、どういうプリセットが要るか分からないから作るのをずっと先送りにしていたのだが、良く使う条件を登録できるようにすればいいことに気付いた。ただ、パラメータのあるもの(例: 「評価が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 修正・加筆)

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

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

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

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

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

気を取り直して、次の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)

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

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

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

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

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

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

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

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

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

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

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

ちなみに、このシステムを作ろうとしたのは、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"させてもらいたいｗ

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

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

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

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

↓

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

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

体験談的なことを書くと、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も何とかなった。(→ デモ動画) 昨日から何も変わってないように見えるが、見た目を変えてないから当然だｗ あとはやっつけ仕事で作った下回りの処理(DBへのアクセス)などをちゃんとしたい。

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

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

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

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

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

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

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

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

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

↓

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

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

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

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

先日HMVの広告で見た、Viviane Chassot(ヴィヴィアンヌ・シャッソ)という人の新作がSpotifyに入っていた。今回は丁度発売日だ。見付けてから結構日が経ったので、曲が何だったか忘れていた(「ゴルトベルク」と思い込んでいた)のだが、モーツァルトのピアノ協奏曲 第27番などだった。

それだけでは全く変哲がなく、広告を見たって待ってまで聴く気にならなかったのだが、なんと、楽器がアコーディオンなのだ。もう、それを見た時から、怖いもの見たさでｗ出るのを待っていたのだ。

今は先日書いた、再生履歴を自動記録するプログラムのプロトタイプを作っていて、そのテストがてら、今朝から聴いている。

掛ける前は、「どうせ、例によって『がっかり』のパターンだろうな・・・」(「ゴルトベルク」のピアノ以外の演奏に多い)と、全然期待していなかった。そもそも僕はアコーディオンが好きではない(嫌いでもないが、オルガン系なので余り積極的に聴かない)。

が、掛けた途端に、「これはいい!」と思った。最初の曲はピアノ協奏曲 第11番で馴染みがないし、頭はオケだけだが、アコーディオンが出る前からいい予感がした。オケ(Camerata Bern)の音がすごく綺麗なのは確かだ。相手がアコーディオンだからといって手加減している感じがしないのがいい。

で、アコーディオンが始まったら、これがなかなかおもしろくていい。アコーディオンの、暖かい、ヨーロッパの街角で演奏されてそうな(見たことはないｗ)、ちょっととぼけた音がいい。ちっと聞いただけだとヘタウマだと思いそうだが、音が絶妙だからそう聞こえるだけで、実際にはすごい腕だ。

気に入ったので聴き続けて、今は最後の曲、第27番(→ ライブでの演奏(一部): アルバム(→ プロモ)はこれよりずっといい)の終わりの辺りで、完全に気に入った。アコーディオンも悪くない。強いて言えば、最初の頃は音が少し弱い感じがしたが、聴き続けたら慣れた。アコーディオンがいいのはもちろんだが、上にも書いたように、オケがすごくいい。そして、HMVの広告にも書いてあったが、アコーディオンの音は木管楽器とすごく相性がいい。聴くまでは全然想像していなかったが、そこがすごく気に入った。

そして、選曲がうまい。収録されている曲は第11, 15, 27番で、どれも暖かい感じの曲だからアコーディオンの音が合ったのだろう。だから、第20番などは全く無理な気がする(それでも聴いてみたいし、彼女ならうまくやりそうだ)。選曲をちゃんとするのは当たり前のことなのだが、身の程知らずとか、自分の得意なところを分かってない人も多い気がする(挑戦するのは意味あるが・・・)。

いやぁ、アコーディオンだからといって馬鹿にしてはいけない。あと、こういう演奏とか雰囲気だったら、まさに音楽祭に持って来いではないだろうか。一方、系統が近いとはいえ、オルガンだったらイマイチな気がする。理由はすぐには出て来ないが、そういう気がする。好みの問題は大きいだろう。

PS. 再生履歴の自動記録は、Spotifyのミニプレーヤーがかなり複雑になっていて、改造するのが面倒だったので、別にプログラムを動かすことにした。プロトタイプなので、多少効率が悪くてもいいと考えたのだ。そして、たまたま、ミニプレーヤーがSpotifyから取得した、再生中の曲情報がファイルに格納されるようになっているので、それを参照すれば概ねうまくいくことが分かった。昨日から作り出してどうにか動き出し、Spotifyで再生した曲の情報が自動的にDBに記録されるようになった。DBなので、SQLというコマンドのようなものを入れれば、自由な条件で履歴を抽出できる。下に例を示す。

自動記録したSpotifyの再生履歴を抽出した例 (評価が良くて、コメントがあるもの)

もちろん、実際に使う時はSQLを打ち込むなんて面倒なことはせず、webなどから簡単に条件を指定できるようにするつもりだ。

ちなみに、記録し出してから1日も経っていないのに、エントリ(曲・トラック)数が150近くになった。今のDBのデータ量は約65KBで、1曲辺り0.5KB未満と小さい。それでも、10万曲だと50MBくらいになるので心配はあるが、画像管理ソフト(XnViewMP)のDBは180MBにもなっていて、それでも起動や処理が遅いことがないから、大丈夫そうだ。

次は、Spotifyの検索と上述の再生履歴を統合するプログラムのプロトタイプを作りたい。Spotifyの検索結果を再生履歴の条件(例: 「1度も再生したことがない」、「評価が悪くない」)でフィルタリングするイメージだ。その後は、ミニプレーヤーに、「初めて再生する」とか「今までの評価がいい」とかいうマークを出せるようにしたい。夢はふくらんでおもしろいが、作るのは楽しいけど楽ではないｗ

PS2. 丁度、「いかにもアコーディオン」でがっかりするいい例があった。これも今日HMVで見付けたのだが、Nikola Djoricという人の「展覧会の絵」(2019)だ。これは、いかにも「アコーディオンだったら、まあ、こんなものだよね」的だ。。。 まさに、Chassotを聴く前に予想していて、外れたことだ。彼女がすご過ぎたようだ。そもそも、こちらは選曲が悪い。音が甘く・丸くて、曲に全然合ってない(僕の好みが大きいとは思うが)。 (19:20)

(19:31 加筆)

Spotifyで主にクラシックの演奏を選ぶ時に、以前聴いたかどうかと、聴いていた時はその時の感想や評価(例: 好き/嫌い)が出れば、二度手間にならなくていい※と思っているのだが、そういう機能はない(再生履歴は出るが、検索が楽ではない)。曲にコメントが記入できるといいのだが、無理だ。それで、少し前から、そういう仕組みを作りたくなって検討している。

※感想は聴くたびに変わる可能性があるが、少なくとも、「フォルテピアノ・古楽器だから駄目(「僕は嫌い」の意)」などという情報があれば「普通の演奏」だと思って掛けることがないから、二度手間にならないことは確実だし、それでフィルタリングできれば、選ぶ手間がかなり減る。こういう機能がマジで欲しいのだ。

主要な機能は以下だ。

1. Spotifyで新しい(= 過去に再生したことがない)曲を再生したら、その曲の情報と再生日時を記録する。 → 「再生履歴」
2. 曲の再生中または後に、その曲の再生履歴にコメント(感想)を記録できる。「嫌い」という情報(マーク)も記録できる。
3. Spotifyで曲を検索し、結果に出た曲に再生履歴があれば、過去の再生日や評価やコメントなどを一緒に表示する。再生ボタンやリンクをクリックすると、Spotifyアプリで再生できる。

実現方法を考えたところ、1は自作のミニプレーヤー(minisp)を改造すればできそうだ。2は再生履歴の管理プログラムを作ることになる。3は、Spotifyの検索プログラムを作る必要がある。基本的には、web版Spotifyのようなイメージだ。そこに再生履歴の情報も合わせて表示する。SpotifyのAPIは公開されているので、面倒ではあるが、作るのは不可能ではない。

更に検討したところ、再生履歴の管理プログラムの再生履歴のデータをどのように格納・管理するかが問題になった。かなり多くの曲を再生し、それらが全部登録されるから、CSVのような普通のファイルでは処理が遅くなったり壊れたりして破綻しそうだ。

最初は、曲ごとに別々のファイルに再生履歴を格納することを考えたのだが、考えているうちに問題(この方式では一つのキー(= ファイル名)でしか高速な検索ができない)に気付いたり、(仕事でもないのに)いちから全部(例: ファイルフォーマット、作成・処理・管理)自分で作るのは馬鹿らしい気がして来た。それで、まずは近い用途の既存のプログラム(音楽などの管理プログラム)を使って手を抜くことを考えた。重要なことは、外部から(GUIでなくコマンドラインで)データの追加・変更ができることと、カスタムフィールドが追加できることだ。

以下に検討した候補の概要と結果を示す。

• 音楽管理ソフト
  • × gmusicbrowser: 音楽プレーヤー
    • 現在、音楽ファイルの管理と再生に使っており、カスタマイズ(改造)もしている。
    • 曲情報を格納するファイルが一つ(CSVのようなもの)なので、曲数が多くなると破綻する。
    • 将来性が疑問(開発・サポートが終わっている)。
    • Perlで書かれているので改造や保守が大変。
  • △ Beets: 音楽管理ソフト
    • 試用の結果、使用可能なことが分かった。ただし、若干の細工(ダミーファイルをインポートするなど)が要る。
    • GUIはなく、コマンドラインのみ(webは貧弱)。
    • 拡張性が高い。
    • まだ完成していない感じ。
    • Pythonで書かれているので(以下略)。
• 汎用コレクション・ライブラリ管理ソフト
  • × GCstar: 汎用コレクション管理ソフト
    • Perlのバージョンの問題か、うまく動作しなかったので却下した。
  • × Data Crow: 汎用メディア管理ソフト
    • コマンドラインでの実行はできなさそうなので却下した。
    • Javaで書かれている。。。
  • × BiblioteQ: 汎用ライブラリ管理ソフト
    • Linux用パッケージが壊れているので却下した。
    • ドキュメントが貧弱。
    • コマンドラインはなさそう。
  • × Tellico: 汎用コレクション管理ソフト
    • コマンドラインでは書籍しか登録できないので却下した。
• その他
  • × tinyMediaManager: 映画の管理ソフト
    • 既に動画ファイル・DVDなどの管理に使っている。
    • ほぼ動画専用(映画の管理に特化した機能が多い)
    • この用途には若干の細工(ダミーファイルをインポートするなど)が要る。
    • コマンドラインは不明。
    • エントリ追加後の再スキャンが面倒。
  • △ calibre: 電子書籍管理ソフト
    • 既に電子書籍の管理に使っている。
    • コマンドラインでの操作が可能。
    • 試用の結果、使用可能なことが分かった。
      • ただし、音楽を書籍として扱うのは無理があるのと、ちょっとした問題(GUIが起動していないと、コマンドラインでの登録時に無駄な待ちが生じて遅い)がある。

試行錯誤して、Beetsとcalibreで再生履歴の管理ができそうなことが確認できたのだが、結局、実質的にはそれらの主たる機能でなく、DBの機能を(うまく誤魔化しながら)使っていることに気付いた。DB以外にGUIが使いやすければ便利だが、calibreは音楽は目的外なので最適化できず、BeetsにはGUIはない。

calibreを用いた音楽再生履歴の管理(プロトタイプ)

そこで、だましだまし他用途のアプリを使うのでなく、直接、DBと管理ソフトを使うことを考えた。ただ、(特にコマンドラインで)DBを直接操作するのは面倒な(そんなことが目的じゃないので、やってられない)ので、「ぱぱっ」と使えるものを探した。それほど詳しく調べていないのだが、多くは基本的にはSQLを自分で打ち込んで操作するもの(詳しい人用?)のようだったが、DB Browser for SQLite(以下、DB Browser)だけは簡単に使えそうな感じだったので、試してみた。

すると、確かにすごく簡単にDBを作成・操作できて、すぐに試用・評価が始められた。これはすごく推奨できる(対象者はとても限られるがｗ)。DBはSQLiteなので、当然、(GUIでなく)コマンドラインでの操作も可能だ。SQLiteはDBのファイルが単一なのが気になるが、DB用に処理を最適化しているはずだから、曲数が多くなっても破綻しないことが期待できる(実際に使用例は多い)。

DB Browser for SQLiteを用いた音楽再生履歴の管理(プロトタイプ)

ただ、calibreのGUIの手軽さは捨て難かった。しかし、この用途では、できればアルバム中の曲をまとめて扱いたい。例えば、感想を曲ごとだけでなく、アルバム全体にも付けられるようにしたい※。それはcalibreではどうしても無理だった(複数の本に共通するコメントが付けられないため)。逆に、DBを使えばできそうな気がした。

※これは、クラシック音楽の楽章(= 各トラック= 上記の「曲」)ごとでなく、曲(全部の楽章)全体に対して感想を書きたいからなのだが、良く考えると、アルバムには複数の曲が入っていることが多いから、アルバム全体に感想を付けるのも最適ではなく、任意の曲をまとめて扱える方がいいようだ。管理や操作が煩雑になりそうだが、DBを使うのであれば、アルバム全体の感想と同様に実現できる。ただ、そこまで凝らなくてもいい気もする。

実際に試してみたら、ちょっと苦労したもののできた。DBの「テーブル」というものを2つ作り、片方には曲(トラック)の、もう片方にはアルバムの情報を格納し、双方を結びつける情報(例: 「アルバムID」)を両方のテーブルに格納しておき、SQLでそれらを統合すればいい。図示するのが難しいが、統合の例として、トラック情報のテーブルとアルバム情報のテーブルの中で同じアルバムIDを持つものを同じアルバムとし、同じアルバム中の各曲にアルバムのコメントを追加し、主要な情報だけを出力した場合を以下に示す。

両方のテーブルにアルバムID(図中の"album_id")を格納し、それを用いて同じアルバム中の曲を抽出できる※。アルバムID以外に双方で重複する情報は格納されていない。

※書いていて気付いたのだが、このデータ構造は、ある曲(トラック)が複数のアルバムに含まれることを想定していないので、もう少し検討が要りそうだ。やっぱり、アルバム単位での処理をしないほうが現実的なのかも知れない。

この処理のためのSQLは以下のようになった。

select t.title, a.album_artist, a.album_title, t.disc, t.track,
t.rating, a.album_comment, t.comment
from album a, trk_info_hist t
where t.album_id = a.album_id
order by t.album_id, a.album_title, disc, track;

DB BrowserのGUIは、機能は充分だが見た目や使い勝手は「まあまあ」で、calibreには劣る。が、この画面を使うのは管理とか保守の場合だけ(Spotifyの曲の検索画面は別途作る必要がある)と思われるから、これでいいのかも知れない。ただ、上に書いたように、実際にはアルバム全体のコメントは最適でないとか不要な気もして来たので、もう少し考えてみたい。

→ 考えたところ、以下のようにすれば良さそうだ。

• 「演奏」ごとに「演奏ID」を割り当てる。
  • 演奏IDは同じ演奏なら同じ値にする。
    • 「同じ演奏」とは、例えばクラシック音楽なら一曲(全部の楽章)である。ポップ音楽の場合は曲ごとに別々にしたり、アルバム全体で一つにすることが考えられる。
• 演奏IDの値は演奏ごとにユニーク(異なる)であれば何でも良い。
  • 例えば、一組の演奏を構成する曲(トラック)の最初の曲IDとする。
    • 今は、曲IDにはISRCを使おうとしている。
• トラック情報テーブルで、曲ごとに演奏IDを格納する。
• 演奏全体に対する感想などは、例えば、以下のいずれかのように格納する。
  • その演奏の最初のトラックに格納することにし、データ抽出時あるいは使用時に、それを演奏全体に対するものとして扱うようにする。: この場合、最初のトラックへの感想と全体への感想の区別ができない。
  • 「演奏テーブル」を作り、そこに演奏全体に対する感想などを格納するようにする。

上記の「演奏テーブル」を作らない場合のようにすればアルバム(または演奏)ごとの管理が不要にできるので、トラック情報テーブルだけで良くなる(「演奏テーブル」を作れば、より「正しく」かつデータ量の点で効率的になるが、管理が煩雑になる)。

なお、効率の点ではDB Browser(とsqlite3コマンド)を使うのが一番良かった。速度もデータサイズも最短・最小だった。ちなみに、calibreもBeetsも、内部ではSQLiteを使用している。calibreはデータサイズが大きく、速度も遅い。

DB BrowserでcalibreのDBを見てみたら、やたらにテーブルが多くて無駄に複雑な気がした。それでデータサイズが大きくなっているようだ。その点ではDB Browserを使うのがいい感じだ。ただ、calibreにもいい点はある(例: 機能が豊富: とはいえ、それが今回の用途には余り有効でない)ので、判断が難しい。

さらっと書いて来たが、題で触れたように、僕はDB(RDB= リレーショナルDB)やSQLが大嫌い・大の苦手で、ずっと避けて来た。というのは、RDBはセンスが悪い(≒ クソ)※と思うことと、SQLの構文がクソ(昔は全部大文字だったし、いつも、「"select"とか"where"とか何なんだ!」って思う)だからだ。仕事で必要な場合は仕方なく使ったが、自分から使おうと思ったことはない。しかし、さすがにDBが必要な・適する用途が出て来たので、使う羽目になりそうだ。

※大昔、RDBは表形式(Excelみたいな感じ)でデータを格納(正確には関連付ける?)することを最初に知った時、どうもおかしい(「は? そんなんでいいの? それが"DB"??」、「古臭い!」)し、分かりにくいと思った。一方、(近頃流行りらしいNoSQL DBの一つの)Key-Value型(あるいは連想配列)のデータ格納方式は分かりやすいから大好きで、昔から愛用していた(自分でも、何度も簡単な仕組みを作った)。だから、今だったらNoSQLなら馴染み易いのかも知れない(でも、実際に調べると訳の分からないことが多そうだ)ｗ

更に全くの余談を書くと、その「大昔」に、いくつかの選択肢があった(確か、他はWordとExcelだったか・・・)中でRDB(製品名は全く分からない: dBase3?)を選ばなかったら、上記のような ほんの基礎的な知識すらなかったので、その時に「今までやったことがないから」選んだのは正解だったと言える。

それから、そもそも、これからSpotifyで新規の曲(演奏)をどのくらい再生するのかも気になっている。もうそれほど多くの新規の曲(演奏)がSpotifyに入らない・再生しないのであれば、手間を掛けて作る価値は少ない。ただ、Spotify用以外にも、自分の感想の記録にはなるから、その点では価値はありそうだ(その時には過去の記録を引っ張り出して転記する作業が必要で、それはそれで大変だし、自動化などできないｗ)。