piu lentoの日々

先日から渡辺真知子を見直している。今朝も、彼女の歌が掛かったら、「やっぱりいい!」と思った。他の「うまそうに」歌うポップス系の人たち(個人的な印象なので、例示は止めておく)と違って、本当にいいのだ。どういうことかというと、本物(≒ ちゃんとしたクラシック系の人)だと思えるということだ。具体的には、声の質と量が豊かで深みがあって魅力的なのだ。別の言い方をすれば、「お腹の底から声を出している」かも知れない。あと、(下品でなく)明るく色っぽい感じに歌うのもいい。

そして、今はどういう歌を歌っているのか気になった。が、その先が問題で、今はSpotifyでいくらでも聴けるのに聴いてはいないし、これからも聴く気は起こらないだろう。

というのは、確かに彼女の歌唱は手放しで褒めたいくらいいいのだが、近頃の曲が僕の好みかは疑問で、おそらくそうでないからだ。実際、昔のアルバムを聴いても、ヒット曲以外はグッと来なかった。(そういえば、大好きな「かもめ―」の「スタジアムバージョン」とかいうのだって、イントロだけで「いい曲に余計なことすんな!」と思ったくらいだ)

ピアニストに例えれば、技術も表現もすごくいいんだけど、僕が好きな曲を弾いてくれない人のようなものだろうか。本人は弾きたい(歌いたい)から選んで(作曲して)おり、それはその人の表現(まあ、営業的なものもあるかも知れないがｗ)そのものだから、いかんともし難しい。

まあ、今後、Spotifyでリコメンドされて掛かることはあるだろうし、その時に気に入る可能性もあるから、気長に構えることにする。

拙作のSpotifyミニプレーヤー(minisp)の話である。

僕は外国の音楽を聴くことが多いので、Spotifyアプリの言語設定を英語にしている。それでminispもそのまま英語表記にしていたのだが、演奏者の名前については、日本のポップ音楽の時は、日本語で書いた方が見やすい気がしていた(なお、英語モードにしていても、日本のポップ音楽の曲名やアルバム名は日本語で出る)。例えば、前の稿で書いた渡辺真知子は"Machiko Watanabe"じゃなくて、やっぱり「渡辺真知子」の方が見やすいし適切だろうと思って、何とかしようとしていた。

が、その「日本のポップ音楽の演奏者だけは、名前を日本語で書く」という機能を実現するのは結構難しかった。どうやって日本のポップ音楽の演奏者を判別するかが問題だった。最初はMusicBrainz(フリーの音楽情報DB)の演奏者情報を使おうとしていたのだが、フリーのためか、登録されている情報が使いにくい(英語圏以外の人名が現地語で書かれている(例: ルガンスキーは"Николай Луганский"): DBの情報としてはすごく正しいことだが、使いにくい)とか一貫性がない(例: 抜けがある)などの問題があって、うまく使えなさそうだった。仮にそこが何とかなっても、そもそも「日本の演奏者」を判定するのが困難だったので、ずっと保留にしていた。

が、先日、SpotifyのWeb APIが使えるようになり、それで取得できる演奏者情報の中にジャンルがあり(なぜか、曲にはない)、運のいいことに、日本のポップ音楽の演奏者のジャンルには"japanese"とか"enka"とか"kayokyoku"とかいう単語が含まれていることが分かったので、それで判別することにした。なお、ISRC(曲の録音の識別記号)の先頭の2文字で「日本の録音」であることが判別可能なので、それを使うことも可能なのだが、仮に外国の演奏者の日本録音盤があった場合(ないとは思うが・・・)に誤判定になるので止めた。

少し苦労したが、うまく行った。が、思わぬ伏兵が居た。日本人のクラシック音楽の演奏者だ。その人たちのジャンルにも"japanese"が入っているので、名前が日本語で表記される。例えば、内田光子だ。それも一貫性があっていいのだが、個人的には、世界的なクラシック演奏者は英語で書く方が適切だと思っているし、オリジナルCDでも英語なので、ここは英語にしたい。

幸い(というか、どういう訳か)、日本人のクラシック音楽の演奏者には"japanese"とともに"classical"という単語が入っているので(例: "japanese classical performance")、その場合には英語表記にすることにした。

余談: (日本の曲だけを演奏している訳でない)クラシック音楽の演奏者のジャンルに国の情報を入れるのは、ちょっと差別的(昔の、「日本人のクラシックだよ()」という嘲笑を感じる)な気がするが、まあ、Spotifyはそういうポリシーなのだから仕方ないし、今は便利だから良しとする。でも、個人的には、入れるのであれば、「出身地域」などのようなフィールドの方が適切だと思う。が、いろいろな問題や文句が出そうなので、無理そうだ。

更に調べたら、ユジャ・ワンやチョ・ソンジンのジャンルには、国籍を示す単語は入ってなかった。どういうことなのか理解に苦しむが、考えても仕方ない。まあ、Spotifyでなく、レーベルがデータを作ってSpotifyに渡していて、その作り方の違いなのかも知れない。実際、ソン・ヨルムのジャンルは空だった。

という訳で、とりあえずできたが、(僕のわがままのせいで)いろいろな判定が多くなってプログラムが複雑(正確には「肥大化」)になっているのが気に入らない。あと、上の判定はやっぱりいい加減なので、今後、思わぬ落とし穴が見つかりそうだ(例えば、日本のポップ音楽だけを演奏する外国の演奏者が居たら、一体どうなるのか?? あと、宇多田ヒカルはどうなんだ? → ジャンルに"japanese r&b"が入っているので、日本語で出るはず)。

技術情報: SpotifyのWeb APIで、例えば曲情報の言語(例: 日本語/英語)を指定して取得する方法はあまり資料には書いてないが、可能だ。カテゴリーのブラウズにならって、要求のURLにlocale引数を追加すればいい。例えば、Spotify IDがxxxxの曲のトラック情報を日本語で取得するには、URLを以下のようにする(太字部分を追加)。

GET https://api.spotify.com/v1/tracks/xxxx?locale=ja_JP

これは公開情報でないので、いつまで使えるかは不明だが、単に資料の記載漏れと思うので、大丈夫だろうと思う。

先日、Spotifyが仕様変更(ローカルなhttpでのSpotifyアプリの制御・情報取得機能の廃止)したために、対応に追われていた。というほどまじめにやっていた訳ではなかったが、それまで動いていた機能(再生位置の表示)が、ある日(7/21頃)アプリを再起動したら、突如として駄目になって慌てたのは確かだ。検索してみたら、他にも引っ掛かった方が居て、フォーラムの投稿がいくつか見つかった(例:  "[IMPORTANT] SpotifyLocalAPI not working #254")。

実は、今回のことは最初から予想していたので、「勝手なことをしやがって! ク○が!」などとは全く思っていないｗ 「意外に早かったな・・・」程度だ。そもそも、非公開の機能を勝手に使っていたこっちが悪いので、それを彼らが予告なしに無効にしたって、文句を言う筋合いはない。

が、再生位置の表示がないとどうにも不便なので、何とかしなければならなかった。根本的な解決策(公式のWeb APIを使うこと)は既に分かっていたのだが、資料を見るとどうにも面倒な感じなので、できれば避けたかった(前もって書くが、こういう手抜きが後々どうにもならなくなることが多い)。

それで、とっつきにくいWeb APIは後回しにして、まずは、小手先(あるいは、子供だまし)の対処をした。再生位置(時間)は分からないが、新しい曲の再生が開始されたことは分かるので、開始した時からの経過時間を表示する(要は、1秒ずつカウントアップする)ようにしてみた。見た目はそれらしいが、中身は誤魔化しもいいところだ。

それにする前に他の案も検討したのだが、どれも駄目な(手軽にはできない)感じだった。例えば以下である。

• アプリのウインドウに表示される再生位置の数字を(プログラムで)「読む」。: 検索してもそんな便利な物はなく、無理っぽかった。やるなら、画像認識が要りそうだ。ちゃんとできればいいが、さすがに毎秒やるのは重そうだ。
• アプリとウインドウシステム(X Window System)のサーバ間の通信を傍受する。: どれが何か判別不能だった。どうも、数字は文字でなく画像として表示している感じだった。
• アプリのログやメモリを読む。デバッガ(gdb)でアプリの変数を読む。: やっぱりできなかった。ログには書かれていなかった。デバッガなんて、使い方を思い出せなかった・・・
•  ブラウザでwebプレーヤーを表示して、その数字を読む。: メモリが無駄になるので、却下した。
• アプリとSpitifyのサーバとの通信を傍受する。: やっぱり判別不能だった。TLSで暗号化しているだろうから、そもそも無理だろう。

誤魔化し策は結構簡単そうな気がしたが、実際に作ってみると意外に大変だった。まず、再生を一時停止してもカウントアップが停まらなかったしｗ、アプリで再生位置を変えても(プログレスバーでのジャンプ)反映されないし、アプリの起動時に曲の先頭でなければ、その曲の最後までずっとズレたままだ。

かなり試行錯誤して、一時停止とジャンプについては何とか対処できた。後者は、アプリのコンソール出力やログに情報が出る("Flush driver"の行)ので、それを使った。しかし、起動時の再生位置の反映は無理だった。そうでなくても、どうしても1-2秒の微妙なズレが出て、気分が悪い。そればかりか、この対処を入れたら、アプリどころかシステムまで不安定になってしまった。ウインドウシステムが不意に落ちてしてしまうのだ。ログを読むのにFIFOを使ったのが良くなかったのだろうか?

さすがに観念して、Web APIを使うことにして、調べた。やっぱり、認証(OAuth)が面倒だった。資料の書き方が今一つ分かりにくいのか(例えば、認証の方式が3つもある)、僕が慣れていないだけなのか、最初はどうすればいいかさっぱり分からなかったが、試行錯誤するうちに分かってきた。

確かに、Spotifyアプリの再生位置は、Web APIの"Get Information About The User's Current Playback"で取得できる。APIを使うこと自体は簡単なのだが、認証が大変だった。"Authorization Guide"を読んで、途方に暮れた。。。 が、ここで引き下がる訳にも行かないので、何とかした。もちろん、APIを使うための既存のプログラムもいくつかあるのだが、この認証が特殊なために簡単には使えなそうだったので、自分で作った。

何が特殊かというと、「古き良き」パスワードが全く使えないのだ。Spotifyにアクセスするアプリを最初に使う時は、必ず、ブラウザでSpotifyのサーバで認証(ログインやアプリのアクセスの許可)をしなければ、アクセスするための情報(トークン)が取得できないのだ。Googleのアプリパスワードような逃げ道すらない。ユーザにとっては安全でありがたいのだが、こっちの身にもなって欲しいｗ

ブラウザを使うこと以外に、Spotifyでの認証後に、指定したサーバにリダイレクトされる(ページがジャンプする)ので、それも何とかしなければならない。なぜかというと、そのページのURLにAPIアクセスのためのトークン(正確にはトークンを得るための情報)が入っているので、アプリはそれを取得しなくてはならないのだ。アプリを動かすのにサーバも要るのかって話で、全くやれやれだった。

更に試行錯誤するうちに、以下のことが分かった。

• リダイレクトはPC内でローカルに済ませられる(Spotify社からアクセスされる訳ではない)ので、サーバは外部になくてもいい("localhost"は駄目なようだが、正しいドメイン名があればいいようだ)。
• リダイレクト先のページの内容は何でもいい。ブラウザに表示されるが、(Spotifyの人でなく)自分が見るので、綺麗でなくても良く、空白だっていい。アプリがそのURLが取得できればいい。
• そのため、リダイレクト先のページを出すサーバは、まともなwebサーバである必要はない。リダイレクト先のURLを取得できればいい。

それで、以下のように実現した。

• リダイレクト先のURLは、自分のドメインに架空のサブドメインを付けたものにする。(例: dummy.piulento.net)
• その架空サーバのIPアドレスは、ドメインに関係なく、宅内LANのローカルなアドレスになるようにPCに設定する(この前の宅内サーバの経験が役だった)。
• ページを出すサーバは、認証をする時だけsocatというコマンドででっち上げる。ブラウザがトークンを含んだURLを要求して(送って)来るので、それを読んでアプリに渡し、ブラウザには、適当な応答(例: "HTTP/1.1 200 OK"と「認証に成功した」っていうメッセージ)を返す(この程度ならPHP自体でもできるが、最初から作るのも面倒なので、socatを使った。なお、ncコマンドも使えるが、ブラウザに表示できないので見苦しい)。
• 一度認証を通せば、あとはそのトークンの有効期限が切れる頃に更新用情報を使って更新できる(この時はブラウザ不要)ので、そのための情報を保存しておく。
• また、APIへのアクセスにはアプリ自体の認証情報(あらかじめ、Spotifyのサイトで作っておく)も必要なので、ファイルに保存しておく。
• この処理は、本体とは別のプログラムで実現した。そのプログラムは、従来の再生情報取得処理が作るのと同じ形式(ローカルhttpでアプリから取得した情報の形式)の情報ファイルを作成するようにして、本体の変更がなるべく少なくなるようにした。

おそらく、上を読んだ方の99.9%は理解できないと思う。そんな、死ぬほど面倒なSpotifyの(OAuthの)認証ではあったが、そこを突破したら、あとはスルッと動いた。そして、結果は以下のとおりで、見た目は何も変わらないが、以前のように再生位置が表示できている。

Spotifyの仕様変更(廃止)に対処して、再び再生位置を表示できるようにした。

なお、今回作った再生情報取得プログラムは、bashでなくPHPで作った。さすがに、あの七面倒な認証をbashでやれるとは思えなかったので、テストプログラムを作る時からPHPにした。PHPにしたら、すごく作りやすかった。追って本体も書き換え(作り直し)たいが、現状の動作に大きな問題がある訳ではないので、あまりやる気が出ないｗ

ついでに、Web APIでは再生位置をジャンプさせることも可能なので、それを利用して、Dbusではできなかった再生停止機能(全く普通の「停止」です)も実現した。一時停止の後に曲の先頭にジャンプするだけだが、昔から欲しかったので気分がいい。

SpotifyのWeb APIにはいろいろ機能があるので、暇つぶしに遊ぶのには良さそうだ。ただ、以前も書いたように、Thumbs up/downする機能がないなど、どうも詰めが甘い感じで、そこがちょっと残念ではある。でも、GoogleやAmazonなんて、APIを公開してすらいないから、千倍はまともだと言えようｗ

あと、問題だと思っているのは、アプリに固有の認証情報が要るため、アプリを配布する時にはその情報が外部に取り出せないようにしなければならないが、それは至難の技なので、アプリ流通の妨げになるのではないかということだ。例えば、インストール時にブラウザでユーザに登録してもらうとかがいいのか? それもかなり面倒だが、Electronのような、ブラウザをアプリ化する仕組みなら、ユーザー登録処理に統合できそうだ。あとは、やはりアプリとブラウザが混ざっている状態を使って、アプリのインストール時にバックグラウンドで勝手に登録してしまうとかか(これは禁止されそうだが・・・)。

Spotifyだけ特別なことをしている訳ではないが、やっぱり面倒だ。

PS. ふと思ったが、アプリの認証情報をどうやって隠すかという問題は、アプリを配布しなければいいのだろう。Web APIはブラウザなどで動くアプリでの利用を主な対象にしているのではないか。今はそういうのが当たり前だし。ただ、僕のようにちょっと作ってみた人が配布しようとすると、かなり大変だ。

PS2. Spotifyアプリの再生状態取得APIにはどうしても気に入らない点がある。どうして、同じコンピュータの中で動いているSpotifyアプリの状態を知るのに、数千kmも先にあるであろう、Spotifyのサーバにアクセスする必要があるのだろうか?? 1回だけならまだ許せるが、再生位置をリアルタイムで知ろうとすれば、少なくとも毎秒アクセスしなくてはならない。

データ量は微々たるものだが、情報取得のために、毎回、(通信プログラムを起動して、)サーバに接続しなおすなんてオーバヘッドが大きくて、センスが悪過ぎる。しかも、アプリも状態をリアルタイムにサーバに送っているのだろうから、2倍の距離を行き来している。確かに、今は回線や機器が高速だから効率の悪さに気付くことはないが(逆に、これでまともに使えているのが不思議なくらいだ)、本質的にひどい仕様だと思う。廃止されたローカルなhttpの方がずっと良かった。この点は大いに文句を言いたい。 (21:38)

↑

気になったので少し調べたら、Spotify自体も再生位置(時間)は「誤魔化し方式」を採用しているようだ。というのは、SpotifyアプリからSpotifyサーバへの通信が頻繁でなく間欠的だからだ(再生開始時に大量にアクセスがあるが、その後は時々ちょっと通信する程度)。もし、リアルタイムに現在の状態(再生位置など)を送信しているなら、間欠的ではおかしい。確かに、一時停止や再開した時にその情報を送信していれば、再生位置はサーバ側で適宜計算(推測)できる。

ただし、再生中に通信が途絶えたら、サーバに状態を送信できないので、再生位置はおかしくなるだろう。だが、Spotifyは基本的に、ネットに接続された状態(オンライン)での再生を前提としているので大きな問題はない。けれど、オフラインでローカルに保存された曲を再生する時は状態が送信できないから、再生位置を取得できなさそうだ。が、今はオフラインのことは考えていないから問題ない。

そうすると、最初に諦めた「誤魔化し方式」も全く駄目ではなかったようで、改良すればNW効率を改善できそうだ。具体的には、Web APIと併用すれば、問題点(起動時の位置が0でない場合)が克服できそうだ。ただ、再生位置をジャンプさせたことの検出はできるだろうか? いつものようにしつこいが、考えるのはおもしろい。 (7/25 5:55)

ちなみにSpotifyのwebプレーヤーも誤魔化し方式で、アプリでのジャンプや一時停止など、再生状態の同期には対応していない。意外にザルだったｗ (7/25 6:02)

↓

上に書いたように、誤魔化し方式の改良版を実装した。再生開始時や定期的(10秒ごと)にWeb APIを使って再生位置を取得し、その後は1秒ずつ再生位置を加算していく。また、再生位置をジャンプさせた時には、再生開始時と同様にDbusにメッセージが来るので、それを契機にWeb APIでSpotifyサーバから再生位置を取得して修正する。

これにより、Spotifyサーバと通信する頻度を約1/10に減らすことができた。なお、理論的には定期的な再生位置の調整は不要なのだが、実際には誤差が蓄積して、本当の再生位置からずれることがあるので、した方がいい感じだ。ただ、Web APIで取得できる再生位置も本当に正しい保証がないので、余り意味がないのかもしれない。 (11:25) → 誤差の蓄積と思ったのはバグだったようで、定期的な再生位置の調整が不要になって、Spotifyサーバとの通信を最小限にできた。 (7/26 13:08)

あれから、まだ手持ちの曲を掛けていない(車内は除く)。聴きたいアルバム・曲(例: ビートルズ、Rushの"Power windows")は時々頭の中に浮かぶが、「疲れそうだ」(特にRush)とか思って、つい、SpotifyのDaily mixやラジオにしてしまう。クラシックも疲れてたら同じで、特定の曲でなく、Daily mixに逃げてしまう。こんなことはGoogleでは全くなかったから、まったく末恐ろしいサービスな気がする。

その選曲を吟味してみると、「『ベスト』ではないのだが、すごくいい線を突いている」ので感心する。

何がいいかというと、僕の好きな曲はまず外さない(実際には抜けはあるだろうが、聴いていて不満に思わせない)。例えば、洋楽だったら"The Power Of Love"など、ヒューイ・ルイス&ザ・ニュースの曲は必ず入れているｗ が、一方で、「あんだけ嫌だって言ったでしょ!」ってのも入れてくる。例えば、プリテンダーズの曲(名前は忘れたが、いつも同じ(複数の)曲)だ。「あのお姉さんは嫌いじゃなかったけど、歌はそんなに好きゃないんだよっ!」 って、何回もスキップとかThumbs downなどの意思表示しているのだが、どうしても許してくれないようだ(クラシックだったら、なぜかリヒテルが必ず入る)。それから、重複も多い。異なるDaily mixやラジオで同じ曲が掛かることが多い。いくら好きだって、そんなに何回も聴きたくはないよ・・・

まあ、そういうことはあるけど、アーティストのラジオ(例: カーズ、ELO、クイーン)なんて、Thumbs upが平気で何個も連続するから、やっぱり、「分かっている」のだろうと思う。繰り返しになるけど、そこには感心するし、Spotifyには音楽好きの(しかも真っ当に詳しい)人が多いのではないかと思う。

ただ、上に書いたことから分かるかも知れないが、聴いていると、どうも変化に欠けると感じるのは確かだ。が、それは、僕のわがままだと思う。「嫌いな曲は聴きたくないけど、(僕にとって)楽しい曲はいろいろ(新しいのも含めて)聴きたい」なんて、向こうに伝えた訳じゃないし、それを伝えたって、(「僕が嫌いな曲」の定義が明確でないのだから、)同じ結果になりそうではないか(そういう設定があればいいが、今はない)。

ただ、初めて聴く曲で、イメージ(先入観)を覆して、「おっ!」と好きになるものは余りないので、僕の好みにブレがない(何かの筋(一本ではなさそうｗ)が通っている)のと、当時から今まで結構幅広く聴いていたことが分かった感じなので、そこはおもしろい。

最後に、全然話が変わるが、Spotify制御ツールをいろいろ改良して、今や「Spotifyのミニプレーヤー(Mini Spotify)」という位置付けになった。今日は、アルバムや曲などのURLをクリップボードにコピーできるようにしたり、リモコンのないPCで使う時のために、Spotifyの再生制御(再生/一時停止、前・次の曲)ができるようにした。Tcl/Tk(wish)の機能は意外に充実していたので、実装は意外なほど容易だった(でも、時間は掛かったｗ)。

なお、再生制御機能はいつも要る訳ではないので、起動時に指定しなければ無効(右の画像)にするようにした(ウインドウの表示がうるさくなるのが嫌なので)。あとはマウスホイールで音量の変更がしたいが、疲れたので今週は止めた。

↓

暇だったので、マウスホイールでの音量調整機能を追加した。

ジャケット画像の上でホイールを回すと、音量を調整できる。音量変更時にはジャケット画像の右下に音量(%)を表示し、少し(1.5秒)したら消すようにした。 Tcl/Tk(wish)はいろいろ癖はあるものの、かなりのことができる。

なお、(現在の)SpotifyアプリはDbus経由での音量変更はサポートしておらず、また、どういう訳か、xdotoolで音量変更キー(Ctrl+Up/Down)を送っても音量変更できないので、PulseAudioのpactl set-sink-input-volumeコマンドで(システム全体でなく)Spotifyアプリの音量を変えている。

Spotifyアプリだけの音量を変更するには、あらかじめ、pactl list sink-inputsコマンドでSpotifyアプリのsink-inputのIDを調べておく。また、Spotifyアプリの再起動後にはIDが変わるので、再取得するようにした。

なお、外部(主にSpotifyアプリ)でSpotifyアプリの音量が変更されることもあるので、定期的(4秒ごと)に、pactl list sink-inputsコマンドでSpotifyアプリの音量を取得して同期している(音量を差分で調整するなら不要だが、上限(100%)・下限(0%)で制限したかったので、取得している)。こういう付加的な処理が多くなり、結構重い感じ(実際にはそうではないが)になっている(そのため、Spotifyアプリの音量の取得は間隔をおくようにした)。

そういうのは好きではない。SpotifyアプリがDbusをちゃんと実装したりローカルHTTPインタフェースを充実させたり、PulseAudioがもう少し使いやすいインタフェースを持っていれば、解消するのだが・・・ (7/12 18:44)

SpotifyのDaily mixを聴いていると、いろいろな発見がある。ほとんどは、昔、TV(多くはCM)やラジオなどで聞いたけど、名前も演奏者も分からない曲が何か分かることだ。今日だけで、以下のように、何曲も分かった。

• "Born To Be Wild"はSteppenwolfの1968年の歌のようで、意外に古い。カバーした人が居たのだろうか?
• "Mellow Yellow"という歌があったようだ(これは聞いたことはない)。Donovanで1967年。昔のとても甘い飲み物(Mello Yello)はこれに由来するのか?
• Billy Idolの"White Wedding - Pt. 1" (1982)という曲(彼の名前も)が「いかにも」で、普通は反感を持つのだが、なぜかかっこ良く思えるｗ
• "Always Something There to Remind Me"という、懐かしい曲。Naked Eyesの1983年の歌だそうだ。
• スローな"Right Here Waiting"はRichard Marxの1989年の歌だそうで、すごく懐かしい! サビしか知らなかった。雰囲気がTOTOやForeigner風なので、そこらかと思っていた。
  • この頃、大学の友人のWくんと、新横浜であったキリンのコンサートに行った。確か、誰かを誘うつもりで券を買ったが駄目だったので、代わりに彼を誘ったのだ。Richard MarxとBilly Idolも出てた気がする。メインはジェフ・ベックかスティーブ・ルカサーだった。 ← リンク先によれば、ベックもルカサーも出ていたが、Billy Idolは出ていなかった。すっかり忘れていたが、チャック・ベリーも出ていたようだ。何か弾いてた気がする。そういえば、全部の演奏の音がとにかくうるさかったのに閉口した。あと、終わった後で駅まで延々と続く行列にも閉口した。
• "YES MY LOVE" (1982): 矢沢永吉は好きではないが、いい歌はあるし、歌も演奏もちゃんとしている。良く居るテキトーな歌手よりずっといい。(これは単なる感想。彼の歌は、知らなくてもすぐに分かる。)

こういう(再)発見はGPMでもなくはなかったが、ここまで頻繁かつ感動的ではなかった。やっぱり、その人が聴いたとかThumbs up/Likeした曲などで好みを認識する能力がすごいようだ。

さっき、ダウンタウン・ブギウギ・バンドの懐かしい「港のヨーコ・ヨコハマ・ヨコスカ」 (1975)を聴いて思った:

今は、「ちょっと前なら憶えちゃいるが、＊年前だと分からねぇなあ。あんた、一体なんなのさ」って偉い人が沢山いるねぇ

と。そして、僕ですら、上のように何十年も前のことを思い出せるのに、そういう方たちは一体、どんな都合のいいオツムをしているのだろうかとｗ

その後もSpotifyに飽きることはなく、Google Play Music (GPM)の支払いの継続を止めたので、移行済みとなった。前回も書いたが、あれからも手持ちの曲は掛けていない。連続2週間になる。ビートルズなんて手持ちで聴けるのに、わざわざSpotifyのプレイリストで聴いたりしたこともあった。GPMとは違って、なぜかは分からないが、随分居心地がいいようだ。個人用のリコメンド("Your Daily Mix")などの選曲がいいのが大きいのではないだろうか。

Spotify制御ツールの改良にも飽きることがない。もう、大きな改良はない(やりたいことはあるが、面倒なので保留している)が、細々とした改良や突然見つかるバグ修正を(慌てて)している。

昨日は、ちょっと思い付いた機能を追加した。先日、クラシック音楽の演奏者名が作曲者になっていたら、それを除外して2番目の演奏者名を表示するようにしたのだが、その機能を発展させて、曲名やアルバム名に作曲者名が入ってなかったら、曲名に追加するようにした。面倒な割には誤動作もあるだろうから止めとこうとは思ったのだが、知らない曲で気になるものの作曲者を一目で知ることができれば便利だと思ったのだ。

まず、除外した時点で作曲者(の可能性の高い人)は分かっているから、それを保存しておく。ただし、フルネームを出すと長くなってしまうので、姓(モーツァルトなら"Mozart")だけを抽出するようにした。もちろん、AIのような最先端技術を使った訳ではなくｗ、泥臭い方法でやった。単に、名前の最後の単語が姓だとみなしている。なお、演奏者名を作曲者であるかを調べるための「作曲者リスト」には姓は大文字で記載されているので、それと組み合わせればもっと精度を上げられそうだが、今はやっていない(そもそも、姓が複数の単語ということはあるのか?※ "="で繋がっている人はそう?)

読み返していて、問題に気付いてしまった。作曲者が最初の演奏者になっていなかったら、この機能は起動しない。しかも、この場合は作曲者が分からないから、本当にAIが要りそうだ(実際にはDBでいいが)・・・ やっぱり止めとけば良かったなｗ まあ、Spotifyのアプリだと作曲者が見られるので、どうにかして、それを取り出せればいいとは思う。

(13:32追記) が、そうは問屋が卸さなかった。仮に、作曲者がない時は検索などをして出すとすると、ポップ音楽にも付いてしまうことになって、それはかなりイタい。ポップスには付けないようにするには、曲のジャンルを正確に知る必要があって、やっぱりAIの出番?ｗ ちょっと思い付いた「名案」は、実際にはなかなかうまく行かない(うまく行くようにすると本末転倒になってしまうこともある)ってのは良くあることだが、これもそうだった。この件は、今の「ちょっと残念」な仕様が一番いいようだ・・・

(14:25追記) ※かなり脱線するが、「姓は必ず一語か」という件は、きっと違うだろう。この機能の主な対象にしている欧米のクラシック音楽作曲家なら、その確率は高いだろうが、そんな決まりはないはずだ。今、作曲家リストを見たら、「ヴォーン・ウィリアムズ」(Vaughan Williams)は姓であることが分かって愕然とした(さあ、どうしよう)。他にも、リムスキー=コルサコフもそうだし(作曲家リストでは"-"で繋がっているので、こちらは問題にならなそうだ)、作曲家ではないが、カラヤンの"von"は姓の一部なのかも知れない。姓がない地域もあるし、逆に長い姓を使うところだってあるだろう。日本だって、姓は複数の単語が空白なしで繋がっている場合があると考えることもできる。そういう余計なことを考えるのも、結構おもしろい。

次に、既に作曲者名が曲名やアルバム名に入っていたら(例: "Mozart: Piano Concerto No.21")、改めて追加するのは無駄なので、それを検出するようにした。そして、どちらにも入っていなかったら、曲名の頭に"Mozart: "のように付ける。

苦労したのは、名前に言語特有の特殊な文字(例: ドヴォルザーク: "Dvořák"。そういう文字を一般的に何というのか不明)の記述の仕方がいろいろあって、検索がうまく行かなかったことだ。いろいろ試していたら、iconvというコマンドに、そういう文字をASCII(普通のアルファベット)に変換する機能があることが偶然分かって、使ってみたらすごくうまく行った。無事、ドヴォルザークは"Dvorak"になって、検索でマッチするようになった。

作曲者名をタイトルの前に追加

改めて書くが、このプログラムは、Pythonのような最新の言語なんて使っていない。古臭い、シェルスクリプト(bash)とTck/Tk(wish)だ。道具は(ある程度のものなら)何だっていいんですよｗ でも、OSがLinux(UNIX)だからできたのであって、Windowsでは決してできなかっただろうし、やる気も起こらなかっただろう。それほどWindows(Microsoft)は酷いものなのである。

更に余談だが、上のように、今は"Dvořák"のようなおかしな文字列を何も考えずに表示できているのを見ると、何とも感慨深い。昔は苦労した。フォントがないとかエンコーディングがどうのこうのとか、プログラミング言語だって、そのままではエラーになったり文字化けして処理できないとか・・・

(13:51追記) 上記の「言語特有の特殊な文字」を一般には何というのか調べたら、結論は出なかったが(おそらく「特殊文字」だろう。人名なら、多くは「ダイアクリティカルマーク」だろう)、おもしろいページ「特殊顔文字に使われている謎の文字よ、お前は一体何者なのか」を見つけた。僕はまだまだ甘ちゃんだったよ。そんな変な文字(例: "ਊ")を曲名や人名に使われたら、このプログラムは一体どうなってしまうのかと、ちょっと不安になったｗ

別件だが、確か上の機能の確認中に、思わぬバグに悩まされた。ある曲の情報が表示できなかった。調べたら、曲名に"が含まれていたせいだった。そればかりか、その曲には'も入っていて、かなり極悪だった。ちなみに、その曲は初めて聞いた曲だったのだが、タルティーニという人の

Violin Sonata in G Minor "Devil's Trill"

だった。まさに悪魔の仕業だったｗ 特にシェルスクリプトでは、同じ文字列に"と'が同時に入っていると、小手先の対処では済まないので面倒なのだが、泥臭い手法でどうにか対処した。

「悪魔のトリル」に悩まされた。

細かい話だが、どう面倒なのかとどうやったかの説明を書く:

シェルスクリプトでは文字列は"または'で囲む(例: "Amadeus Mozart")。だから、文字列の中にそのいずれかが入っている場合は、記述が面倒になる。どちらか一方なら、もう片方で囲めばいい(例: 'Piano Concerto No.26 In D Major, K.537 "CORONATION"')からいいが、今回のように両方入っていたら、「どうしましょう?!」になってしまうｗ

一般的には、""の中では\を前に付けて\"のようにすればいいのだが(例: "Piano Concerto No.26 In D Major, K.537 \"CORONATION\"")、それも一筋縄では行かず、\を何個も書く羽目になることがある。おまけに、シェルスクリプトでの文字列は、代入などをすると、どういうわけか\"が"に戻ったりするので(この辺りの仕組みはちゃんと調べれば分かるのかも知れないが、ちゃんとした言語ではないので、そこまでまじめに接していない)、気が抜けない。

今回は、曲名などは特定の記号に囲まれていたので、それを別の記号に変換し、更に、曲名などの中の"は別の記号に変換して、処理中に変わらないようにし、表示の直前に"に戻すようにした。我ながら大変泥臭い。きっと、もっとスマートな方法があるのだろうが、僕は分からない。そもそも、PHPで書き直そうと思っているくらいだし、そうでなくてもシェルスクリプトはプロトタイプ用とか「ちょっと作る用」の扱い、靴で言えばサンダルのようなものなので、ちゃんと動けば泥臭くてもいいと思っている。

それから、プログラムの名前を変えるなら"minispot"にしようと思ったが、調べたら既に2件あったので、"minisp"がいいかなと思っている。でも、変えるのは面倒なので、本当に変えるかは未定だ。そもそも公開するつもりがないので、何だっていい。単なる自己満足だ。

(12:33 修正・加筆、14:11 加筆など)

PS. Spotify制御ツールの規模が予想外に肥大化していた。サイズは108KB、3049行にもなっていた。まあ、現代のアプリに比べれば雀の涙、「なにそれホコリ?」程度だが、最初は軽い気持ちで作ったのに、うーむとしか言いようがない。そして、そんなシロモノがまともに動いているのだから、大したものだｗ なお、他に、Tcl/Tk(wish)の初期設定プログラムもあり、そちらは27KB、850行程度だった。 (14時)

近頃はSpotifyにどっぷりと浸かってしまっており、調べたら、この一週間、手持ちの曲を全然掛けてないことが分かった(制御ツールを開発していたせいもあるだろう)。それで、今までの感想を書いてみる。

いい点

• "Daily mix"(毎日更新される、各ユーザ専用プレイリスト)が優秀。
  • ポップ音楽(海外と日本のリストが別になっている)は僕が良く聴く80年辺りが中心になっていてうれしいし、クラシック(ポップのリストとは別になっている)も、いつのまに覚えたのか、「展覧会の絵」とかモーツァルトとかバッハとか、好きそうな作曲家・曲が多い。
  • リストの数は日が経つと増えるようだ(今は4個)。
  • これはGoogle Play Music(GPM)にはない。"I'm feeling lucky"が近いが、1個しかないし、掛けるたびに内容が変わるし、好きじゃない曲も多かったので、選び方がイマイチだった。
  • "Discover weekly"(毎週更新と思われる)もある。こちらの内容は結構チャレンジングで、例えば、知らないし好きでもないフランスの人の曲が沢山掛かったりする。これがDaily mixと違うところにあるのは、例によって謎仕様ｗ "Discover"だから別扱いにしているのだろうが、"For you"とかいう場所にまとめてくれればいいと思う。
• "Like"と"Remove"ボタンが増えた。
  • Likeはいいと思ったら押すようで、結局、Save(「お気に入り」)と同じなのかも知れない。一方、Removeは嫌いな時に押すようで、曲だけでなく、演奏者を一括して掛けないようにできるのがうれしい。
  • が、出ない場合も多いうえ(Daily mixの時だけ出る?)にThumbs up/downが出る場合もあって(こちらはラジオだけで出る?)、依然として謎仕様ｗ
  • 素直に、「この曲みたいなのをもっと掛けて/あまり掛けないで」っていうボタン(例: "+1"/"-1"とかThumbs up/down)をいつも出せばいいのにと思う。

欠点

• 「俺ら東京さ行ぐだ」がねえ! 吉の歌は全然ねえｗ
  • GPMにはあるので、これは残念。まあ、外で聴きたくなったらYouTubeで聴けばいいだけだし、そもそも、脳内で再生するので充分だｗ
• 発売年が違う場合もある。
  • 実際には誤っている訳ではなく、ベスト盤やリマスターの発売年などになっている。GPMでは、誤っていたりオリジナル盤でも再発の年になっていることもザラなので、それよりはずっといい。
• いろいろな謎仕様
  • 彼らは音楽には強くても、技術面やUIなどのセンスはそうでもないような感じで、なんか手一杯な感じ。そういうところは惜しい。

その他

• 今日、病院での待ち時間に聴こうとしたが、室内で電波が弱かったのかキャリアの障害かで、ホーム画面すら表示できなかった。そういう時には弱い。
• 手持ちの曲もシームレスに再生できればいいと思うが、さすがにそれは無理だろう。GPMのように、曲をサーバにアップロードできるようになればできそうだが。
  • → Spotifyのサーバにアップロードじゃなくても、外部サーバにある曲を登録して、Spotifyで再生できるようになるといいと思った。

上に書いた要望をSpotifyのフォーラムに書くこともあり得るのだが、過去のログを見ると、大抵、「ありがとう、検討します。」とかで終わっているので、止めている。

あと、Spotifyには関係ないが、Spotifyで聴いて思ったことを少し。

• Romanticsのダサさ。いつも、あの、「いかにも80年代」(と、若い人がディスるよう)なセンスのない服装が頭に浮かぶ。調べたら、まだ活動しているようだ。
• Huey Lewis & the Newsは(曲にはよるが)鉄板なのに対し、Pretendersやホール&オーツやWham!はなんか惜しい・・・ いや、Pretendersは惜しいどころか、あの女性の顔が頭に浮かぶだけで、それ以外はいいことがない。いつもスキップするのに、しつこくリストに入っているｗ こちらもまだ活動しているようなので、それはさすがだ。
• Ringo Starrと工藤静香は常にパス! 全然好きになれない。あと、The whoやBob Dylanとかも。弊害が怖い(例: 本人だけでなく、関連する人まで再生されなくなる)ので、今は曲ごとにスキップやRemove(上述)するだけだが、そのうち演奏者でRemoveしそうだ。
• 昨夜、ポゴレリッチの「展覧会の絵」(1997)を聴いてみたら、(彼らしくなく)意外にまともで感心した。まとも過ぎてちょっとおもしろくなかったが、音がかっちりしているのは良かった。見直した。
• 彼の前に聴いた、Charles Pillowとかいう人(?)のは全然良くなかった。どういう趣旨かは分からないが、曲が丸くなっていて、僕には単なるBGMにしか聞こえなかった。

(題は英語ではない。「力技はいいよね(いや、本当は駄目なんだけどさｗ)」のような意。 たまたま"Power of love"が掛かっていたので思い付いた。)

先日のSpotify制御ツールV2はその後も止まらずに進化を続けて、今日、概ね、今までの不満が解消できた(内部的にはとんでもないことになっているのだが、それでもちゃんと動いて問題なく使えているので、暫定的に良しとしている)。とりあえず、外観を。

大幅改良後のSpotify制御ツール V2 (別名: 「Spotifyミニプレーヤー」?)

もう、「Spotifyミニプレーヤー」と言ったほうが適切かも知れない(が、名前を変えるのが面倒で、そのままにしている)。いったい、前回から何を変えたのかすっかり忘れているのだが、調べてみると、以下だった。

• 細かい見栄え(例: 行間、文字サイズ、ウインドウサイズ)の調整
• 起動時にSpotifyアプリが起動してなかったら、自動で起動する。
• ジャケット画像をクリックすると、Spotifyアプリを前面に表示する。
• (リモコン経由でなくても)アイコン(ウインドウ内のボタン)を押せば、「この曲の後に停止」を設定できるようにした。
• 曲情報欄の高さが狭いことがある問題の修正。
• ウインドウの表示位置を起動時に指定できるようにした。
• 「正しい演奏者名」の表示
• 再生位置(時間)の表示

今日までは、ずっと細かい調整が主だった。そして、今日、最後の２つをなんとか実装できた。

その前に、外観(UI)について少し書く。(画像中央右辺りを)ちょっと見ると、ESPカードを思い浮かべそうだが、かなりの試行錯誤の結果だ(もちろん、苦労したから結果がいいと言うつもりは毛頭ない。駄目なら駄目で仕方ない)。この辺りは、再生状態("♪")と、「この曲の後に停止」("∥")と、音量正規化("≂", 従来は"RG"だった)のインジケーターとボタンがある。

音量正規化のボタンは、ON/OFFの区別がしやすいように色を付けていた(→ 例)のだが、その色が問題だった。どんな色も気に入らない(しっくり来ない)のだ。その理由は分からないのだが、ウインドウ全体がモノトーンなのに、一箇所だけ色が付いているのと、アルバムのジャケットの色とかぶったりするからかと思う。さまざまな淡色を試したのだが、これという色がなかった。が、「この曲の後に停止」をボタンにする時に、ふと気付いた。色は不要だ(黒の濃さにすればいいのだ)と。

同様に、ボタンの外観は、最終的に、画像(アイコン)ではなく、文字にした。Linuxに入っているいろいろなアイコンを試したが、これというのがなかった。作ればいいのだが、それは面倒だったので、文字を探した。Unicodeの文字コード表でさんざん探して、押した時の動作、あるいは、現在の状態を予想できそうなものにした。

意図せず林檎系の意識高さを醸し出してしまっているのが悔しいが、我ながら、まずまずだと思っている。

ついでに、曲情報欄の高さが狭いことがある問題とその解決方法について書いておく。曲情報(題名、演奏者名、アルバム名、年)は、転載する時に全部を一度にコピーしたいので、一つの領域(textウィジェット)に書いている。そして、読みやすくするために、タイトルの文字の大きさを大きくしたり、行間を増やしたりしている。各テキストを書き込んだあと、曲情報欄の高さを丁度良くするために、実際に表示されている高さを求めて設定する。ところが、文字の修飾(特に行間)は高さの計算に含まれないようで、普通に高さを求めても低くなってしまう。それが狭くなった原因だった。それを解決しようと、ちょっと高目にしようとしても、textウィジェットの高さは行数でしか設定できないので、丁度良くはできない。1行多くするといい時もあるが、高くなり過ぎる場合もある。

そこで、苦肉の策を生み出した。textウィジェットのデフォルトのフォントサイズを1px(またはpt。どちらかは不明)にしたのだ。そうすると、1行の高さは1画素程度(とにかく小さい値)になるので、高さを細かく指定できるようになる。もちろん、そのままでは読めないが、書き込む都度、本来のサイズを指定すれば良いのだ。これも一種の力技だろう。表示に使っているTck/Tkの内部のことを考えると、極小フォントに対応させるために何か無駄な処理が起こっていそうだが、とりあえず、大きな問題は起こっていないので、良しとしている。

「正しい演奏者名」の表示は、Spotifyの数少ない問題点の一つへの対処だ。どういう訳か、Spotifyがクラシックの曲の作曲者をその演奏の演奏者にしてしまうのが、ずっと気に入らなかった。例えば、モーツァルトのピアノ協奏曲の演奏者を"Wolfgang Amadeus Mozart"にしていたりするのだ。涼しい顔して! これだけは全く許せない。

さっき思ったのだが、SpotifyのDBには「作曲者」の格納領域(フィールド)がないからこうなっているのかも知れない。今からでもいいから、直して欲しい!

それをどうにかしてみた。細かい話は飛ばすが、最後は力ずくでやった。まず、前回も書いた、"xesam:url"というプロパティから取得できる曲情報ページで、その曲の演奏者リストを取得してみた。当然、その最初も作曲者になっていることが多かったので、それを何とかするためにいろいろ考えたのだが、次のようにした。

演奏者が「(有名なクラシックの)作曲家」なら、無視する。

噴飯物ではあるが、まあ、他の方法(例: アルバムアーティストを使う)よりはましだと思う。そして、ある人が「(有名なクラシックの)作曲家」かどうかは、あるwebページに列挙されていた作曲家一覧からデータを作った。

道義的にどうかとは思うが、確か、データ自体には著作権はないので、法的な問題はないだろう。

正しい演奏者を調べる(推測する)手順は、以下である。

1. その曲の曲情報ページから演奏者リストを取得する。
2. 演奏者リストの最初の人から順に(有名なクラシックの)作曲家一覧内にあるかを調べ、あったら、その人は無視する。
3. 最初に残った人が、その曲の「正しい演奏者」だとみなす。

この方法だと、作曲も演奏もする人(例: ラフマニノフやバーンシュタイン)が演奏した曲の結果がどうなるか恐ろしいものがある(「想定外」)のだが、それよりも、僕が普通に聴く曲(演奏)で演奏者が正しくなる確率の方が圧倒的に高いはずなので、この方式を使ってみることにした。やっぱり実装には苦労したが、以下のようにうまく動いている(赤枠内を比較すること)。

正しい演奏者名を表示するようにした。(左: 本ツールでの修正後("Richard Goode")、右: Spotifyアプリ("Ludwig van Beethoven"))

最後の、再生位置(時間)の表示は、一見、飾りのように思えるのだが、僕には意外に重要だ。「この曲の後に停止」を作ったのと関係があるが、例えば、曲を聴きながら何か(例: 出勤、家事)をする必要が起こった場合、残りの長さに応じて、最後まで聴くかすぐに止めるかを判断するのに必要なのである。

実装は面倒だった。しかも、大変醜くてものすごく気に入っていないのだが、曲がりなりにも動いているので、「今は良し」としている。が、いつか、問題が起こりそうなので、あとでちゃんとしたいと思っている。

何が良くないかというと、Spotifyのアプリは、Dbus(MPRIS)経由では、現在の再生位置(時間)を取得できない(いつも0が返って来る)ので、別の方法でそれを取る必要があって、その方法が汚いのである。

いろいろ調べて、Spotifyのアプリに含まれている、HTTP(web)での制御機能を使って、現在の状態(その中に、現在の再生位置(時間)も含まれている)を取得することができることが分かり、実際に取れた。が、制御ツールはシェルスクリプトなので、再生位置(時間)を更新するたびに、wgetという、webコンテンツを取得する外部コマンドを呼び出すのである。今は1秒に1回呼んでいる。それがとてもおぞましい。。。 (が、そもそも、シェルスクリプトなんて外部コマンドを呼びまくりなのだから、この程度で苦しくなったら即座に窒息してしまって生きて行けないだろうから、気にしなくていいのかも知れないｗ)。

その点では、本体をシェルスクリプトで書くのを止めて、PHPに移行したい気持ちもある。上の件以外にも、JSONなどの解析を全くテキトーにやっているし、大規模になったせいもあって、プログラム自体を書くのにも結構手間が掛かるので、僕としては心苦しいことだらけなのだ。PHPを使えば、HTTPでの通信は自分でできるし、外部コマンドの呼び出しはかなり減らせるし、文字列の解析・処理はお手のものだし、プログラムだってかなり書きやすくなるから、いいことずくめだ。が、今動いているものを作り直すには結構な勇気とパワーが要るので、なかなかできないだろうな・・・

てな訳で、最初や下の画像のように、プログレスバーで再生位置を表示することができた(数値(現在位置/全長)でも表示したいが、標準の機能ではできないし、今は疲れてしまったので、あとでやりたい)。めでたしめでたし。

再生位置はちゃんと合っているよ。

↓

再生位置の数値も入れられた。ただし、文字の背景を透過にするのは面倒なのでやっていない。そこがちょっと不満ではあるが、まあいいことにする。

再生位置(時間)の数値も入った。

余談: 「ゴールデン・ハーフでーす」って題は今でも古く感じない(今の若い人も言いそう)のだが、彼女たちが先進的だったのか、まあ世の中なんてそんなものなのだろうか?ｗ そもそも、当時、こんなふざけた題のレコードなんて出して、風当たりがすごくなかったのか、ちょっと心配になるｗ

↓

いろいろ調べたら、丁度いいプログラム(リンク先の"Based on frame and label"の"a progress meter")が見つかり、ちょっと改造して使ってみたら、すごくいい感じになった。

再生位置(時間)の文字の背景を透過にできた!

それにしても、そのプログラムも「力技」でやっているのだが、ほんのちょっとしたものなのにすごく良く働くので、感心している。 (6/17 19:55)

(6/17 8:06 加筆・修正, 10:37 再生位置の数値を入れられた件を追記, 19:55 再生位置の文字の背景を透過にできた件を追記)

Spotify制御ツール(今は、「Spotifyのミニプレーヤー」の方が近いかも知れない)の見た目を改良して、元々の目標にかなり近づけられた。そのために、表示に使うプログラムを入れ替えた。それで"V2"とした。

目標としていたGMBのミニプレーヤー(これも自分でレイアウトを作った)に近くなり、幅が狭くなったのでコンパクトになった。

表示用プログラムを何にするか迷った。今まではyadというのを使っていたが、今ひとつ機能が低いし使いにくい。最初の版ではかなり無理をしたが、それでも、曲情報を1行に表示するしかなく、書式を工夫したのだが、どうしても見難くて気に入らなかった。今ならElectronを使うのが普通なのだろうが、JavaScript(Node.js)は使いにくくて大嫌い(GPMDPの改造でうんざりした)なので、避けたかった。次は軽いブラウザを考えた。ただ、今回必要な、(人の操作でなく)外部のコマンドなどで表示の更新ができるものはほとんどなく、uzblというのしかなかった。

uzblを試してみたのだが、開発中のせいか、どうも今ひとつだったので、更に検討したところ、大昔(1990年代)に最初に発表された頃に(確か、「UNIXマガジン」の紹介を読んで知ったのだと思う)ちょっと触った程度でどうも気に入らずにほとんど使わなかった、Tcl/Tkという言語が丁度良さそうなので、使ってみた。恐るべきことに、今でもLinuxでちゃんと動き、機能・仕様もそれなりに更新されているようで、まあまあ使えた。

(今回の開発においては、)Tcl/Tkの良い点は、すごく手軽に描画できるのはもちろんなのだが、標準入力からコマンドを読み込んで描画できることが一番大きい。というのは、Spotifyの挙動やリモコンからの要求に従って処理を行う本体プログラム(bashを使っている)から、文字列としてTcl/Tkのプログラム(コマンド)を出力することで描画できるので、本体を(訳の分からない)Tcl/Tkで(苦労して)書かなくても済むのだ。そのおかげで最初の版の主要な部分を流用することができた。もしElectronを使ったら、JavaScriptに書き直さなければならなかっただろうから、全部作り直しになるうえに、内部動作が非同期になってしまうから、大変な苦労になったはずだ。

とはいえ、Tcl/Tkは(昔感じたように)やっぱり言語仕様がおかしい(古代の言語のせいもあるのだろうか)ので、結構苦労してしまって、こんな時間だｗ でも、上のようにできたので、(まだいろいろ改良したいことはあるものの、)とりあえずは満足だ。

↓

その後更に改良し、リリース年と大き目(250画素)のジャケット画像を出せるようにした。

どうやったかというと、Dbus/MPRIS経由でSpotifyアプリから取得できる曲情報(Metadata)の中に"xesam:url"という、曲情報ページ(webプレーヤーのようなページ)のURLがあり、(大変ありがたいことに、)そのページのソースにSpotify.Entityというトラックの詳細情報が記述されているので、そこからリリース日(release_date)と大き目のジャケット画像(imagesの中のwidthまたはheightが300画素のもの)のURLを抽出するようにした。これはおそらく非公開情報なので、Spotifyの心変わりで動かなくなってしまうが、駄目なら従来の動作をするはずなので、(がっかりはするが)致命的な問題にはならない。

ちなみに、上の方法を思い付いたのは、上記の曲情報ページにリリース年が書いてあるので、その文字列を強引に抽出(スクレープ)して使おうかと思ってソースを見たらだ。情報は(東洋の経済紙の無知で不勉強この上ない訳者に「気味の悪い拡張子」と書かれてしまったｗ)JSON形式で構造化して書かれているので、ちゃんと処理すれば、綺麗にデータが取れる。

なんか、こうやって、それまで考えてできない・難しい・面倒と思ってたことを、試行錯誤や裏技や力技でできるようにするのは、とても血沸き肉踊るものがあって、プログラミングの醍醐味と言えよう。まあ、こういう裏技は趣味だから使えることだが、仕事にも形を変えてフィードバックできると思う。と言っても、意識低い僕は、仕事のために(「自己研鑽」だの「スキル向上」だのｗ)趣味のプログラミングをしている訳ではなく、お客さんや上司などの鼻を明かすとか、期待よりずっと早く仕事を終わらせて、遊びの時間が増えるのが楽しいからであるｗ (6/10 13:41)

(6/10 21:28 若干修正・加筆, 6/11 5:48 わずかに加筆)

PS. 改良したい点は、以下の通り。

• プログラムを終了するとSpotifyも終わる問題の解決。 → 仮のターミナルからspotifyを起動したら直った。(6/10 11:19)
• その他の問題の修正
• アプリのタスクバーアイコンの設定 → できた。(6/10 11:19)
• ステータス行のレイアウトの改良 (レイアウトするのに四苦八苦している)
• 再生状態アイコンのサイズを小さくする。
• ジャケット画像を大きく (大きな画像を取るには、SpotifyのWeb APIを使う必要があるので、面倒) → できた。(上述の通り。6/10 13:34)
• 初出年の表示 (取るにはSpotifyのWeb APIを使う必要があるので、面倒) → できた。(上述の通り。6/10 13:34)
• 再生時間の表示(プログレスバー): なぜか、Dbus/MPRISで取れる再生位置(時間)が0のままで更新されない。(Web helperでSpotifyアプリから取れるが、今一つ効率が悪そう)
• プログラムの整理 (いろいろ汚いｗ)
• CPU負荷・メモリ量に問題ないことの確認 → 大丈夫そう。(6/10 11:19)
  • メモリ: 全部で35MB程度
  • CPU負荷: 0% (通常時)

PS2. おや、新しいジャケット画像の取得方法だと、右下にSpotifyのマークが入っていない。全く予想も期待もしてなかったが、すっきりするので結構うれしいことだ。それから、Spotifyのリリース年はGPMよりずっと正確なので、ちゃんと参考にできるから、出すようにした甲斐がある。 (6/10 14:11)

Spotifyの使い勝手を改良するプログラム(暫定版)を作った。仮に「Spotify制御ツール」(spotify-ctl)と呼んでいる。(作るのに結構苦労した割には、)見た目はしょぼいが、僕には欠かせないものだ。以下のような機能がある。

• リモコンでSpotifyを操作できる。GMB(gmusicbrowser)と切り替えて使える。
• 音量正規化のon/offをボタンで切り替えられ、その状態を表示できる。
• リモコンで、「この曲の再生後に停止」を指示することができ、その状態を表示できる。

意外なことに、ほとんど誰も「この曲の再生後に停止」機能を欲していないようだが、几帳面な僕には必要だ。今の曲で聴くのを一旦止めようと思った時、一瞬でも曲のお尻が欠けたり次の曲の頭が出るのが許せないのだ(これ、本気です)。常に「ぴったり」で停めたいのだ。それをやるのにこの機能がないと、(車の信号待ちの時のように)曲の終わり辺りで再生位置のメーターに神経を集中させる必要があるので、疲れるｗ

少し内部的なことを書くと、システムは、以下のように、リモコン対応部(GMB用のプログラムに機能を追加)と制御・表示部(本体)からなる。

リモコンサービスプログラム

• リモコンのキー(再生、停止など) → SpotifyまたはGMBに指示を送信する(DBus)。送信先(操作対象)は下のように切り替える。
• 対象切り替えキーまたはその時の状況(例: 片方のアプリしか起動してなかったら、そっちに送る。片方が再生中だったら、そっちに送る。)で、制御対象(SpotifyとGMB)を切り替える。
• 対象の切り替え時には通知を表示する。
• 「この曲の再生後に停止」のキー → 制御・表示プログラムに指示する。

制御・表示プログラム

• Spotifyアプリ (DBus) → 曲情報 → ウインドウに曲名、演奏者、アルバム名を表示する。
• Spotifyアプリ (DBus) → 再生状態 → ウインドウに表示する("Playng status": "▶"/"⎟⎟")。
• 音量正規化変更ボタンのクリック → Spotifyに設定し、ウインドウ下部のボタンに状態("RG is ON"/"RG is OFF")を表示する。
• リモコンからの「この曲の再生後に停止」の要求 → 要求の有無をウインドウに表示("Playng status": "▶"/"▶⎟⎟")し、要求がある場合、曲の切り替わり直後に停止する。その後、要求をクリアする。

なお、本当は、GMBのミニプレーヤー(下図左側)のようにテキストを綺麗に表示してジャケット画像も出したかったのだが、表示に使ったツール(yad)の機能の限界のために見送った。余裕があれば、別のツール(uzblブラウザが有望)で実現したい。が、簡単に操作できることが重要で、見栄えは本質でないので、優先度は高くない。あくまでもお遊びだ。

やりたかったイメージ (左(GMB)が理想)

「なんだ、偉そうなこと言っておきながら、結局(GPMでやっていたことと)同じことを繰り返してるじゃん」と言われそうだが、結構違う。GPMの時は、第三者の作ったライブラリやアプリなどを改造して使っていたが、こっちは、純正のアプリを何も変えずにそのまま使い、一部(音量正規化の設定変更の仕方)を除いて、公開されている仕様(DBus/MPRIS)に基づいて作っているので、Spotifyの勝手な変更(仮にあったとしても)に右往左往させられる心配は少ない。だから、将来的な手間はずっと少ないはずなので、音楽(=本質)に集中できる。

↓

遊んでしまったｗ テキストを見やすくし、ジャケット画像をSpotifyから取得して表示するようにし、再生状態はアイコンにした。これならまあまあ許せるかな? 表示には前と同じプログラム、yadを使ったが、前(form)とは別のモード(list)を使った。 (6/3 3:33, 13:12)

外観を大幅に改良したSpotify制御ツール

PS. まったくの余談だが、デバッグ中に「さらば涙と言おう」(1971)が掛かった時(→ 図)、ものすごく懐かしかった。というのは、僕の通っていた小学校では、下校時間にこの曲が流されていたのだ。どうしてこの曲なのかは今となっては知る由もないが、毎日掛かっていたのだ。たまたま帰るのが遅くなって、夕方の薄暗い時に、ちょっと悲しい気分で聞いた記憶がある。なお、この曲がいつまで使われていたのかは記憶にない。

何十年振りに聴いた気がするが、清潔とかシンプルな曲だと思い込んでいたのに、(基本はそうだけど)意外な雰囲気だったことが分かった。例えば、ハワイアンな音(ギター)があるのだ。尾崎の「また逢う日まで」(1971)もそうだが、当時は結構妙なアレンジが多かったのかも知れない。まあ、今の歌(全然知らないがｗ)でも後でそう思われる気もする。

あと、彼がのちに県知事になるなんてのは、まったくおかしなことだｗ でも、USだって似たようなものだ(爆)

PS2. GPMを退会するに当たり、ライブラリ(お気に入りのようなもの)の一覧を保存しようと思っていたのだが、面倒だ。ツールはあるはずだが、それを引っ張りだして実行するのすら面倒だ。そして、意外なことに、近頃は、「そんな一覧なんてなくてもいんじゃない?」とすら思って来た。

というのは、確かに、気に入った曲の一覧があればいいが、今まで、それを見て聴くことがほとんどなかったからだ。逆に、重複のチェックに使った程度だ。あとで一覧を見て振り返ればおもしろいだろうが、その程度だし、それなら日記やこのブログに書いてあるからいい。(クラシック音楽については)僕は、常に、新しい(自分の知らない)、自分好みの演奏を聴きたいと思っているからだろう。あと、演奏者やジャケットを見れば思い出せることが多いし、気づかずに再度聴けば気に入る可能性もあるのだ(実際、最初は気に入らなかった演奏をあとで気に入ったことがあったし、その逆もあった)。

要は、昔の人のように、何かの曲の話になったら、「ああ、あれ(あの人の演奏)は良かったよ」みたいなものだと思っている。曲名と演奏者名が分かれば、世の中のどこかにあるはずだから、聴こうと思えば聴けるので、音楽を聴くのに(個人の)ストレージは不要になった。すごい時代だ。というか、昔に戻っただけ?ｗ

↓

重い腰を上げて、ライブラリの曲一覧をダウンロードした。GPMでは190アルバムと表示されていたが、ダウンロードしたら184個だった。まあ、6アルバム程度は「誤差」として良しとするｗ

なお、Googleのサービスはもちろん、既成の(第三者の)プログラムでもできないようだったので(検索したら、ブラウザでGPMを開いて、開発者ツールにJavaScriptのプログラムを入れてなどという前時代的なことが書いてあって、げんなりした)、gmusicapiのMobileClientインタフェースのget_all_songs()を使って適当に作った。いつもながらPythonは嫌いだ。Perlよりはまともだが、なんで人気があるのか分からない。 (6/3 22:01)

PS3. 今気付いたが、このツールのおかげで、(Spotifyのアプリではできなかった)曲名や演奏者名などのコピーが容易になった。自分では気付かずに作ったが、これはうれしい!

PS4. それなりに動いていて便利なのだが、(いろいろ工夫はしたものの、)曲情報が改行されていないのはやっぱり見難いので、いろいろ試した結果、表示部に全世紀の遺物的なプログラム、Tcl/Tkがすごく良く使えそうな感じだ。今日、外側を作ってみたら、かなり理想に近くなった。あとは中身を作るだけだ。 (6/5 22:27)

新しいUIの案