Archive for the ‘PC・技術’ Category

音楽再生履歴記録・検索システム(仮)を作りながら使っていると、いろいろなアイデアが浮かぶ。作ることや使っている時にバグが出て急いで直す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 加筆・追記)

  •   0
  •   0

動作確認や修正や暇つぶしに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の再生履歴記録・検索システム(仮)が大分できて来た。まだまだやりたいことは多いし、修正・改良すべき点も多いが、一段落した感じだ。

見た目が前回とほとんど変わらないのが残念だが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

今回の趣味の開発でいろいろ困っては小技を見付けて対処しているのだが、一番困るのは、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

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

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

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

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

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

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

気に入ったので聴き続けて、今は最後の曲、第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度も再生したことがない」、「評価が悪くない」)でフィルタリングするイメージだ。その後は、ミニプレーヤーに、「初めて再生する」とか「今までの評価がいい」とかいうマークを出せるようにしたい。夢はふくらんでおもしろいが、作るのは楽しいけど楽ではないw

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

(19:31 加筆)

  •   0
  •   1