Archive for 5月, 2019

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

先日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

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を作成・操作できて、すぐに試用・評価が始められた。これはすごく推奨できる(対象者はとても限られるがw)。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なら馴染み易いのかも知れない(でも、実際に調べると訳の分からないことが多そうだ)w

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

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

  •   0
  •   0

キーボード(FILCO Majestouch BLACK Tenkeyless, FKBN91M/NFB2)の底にある滑り止めのゴムかそれを貼っている両面テープが劣化したようで、ベトついてきた。気付いたきっかけは、時々、机にベトベトした汚れが付いているのを見たことだった。最初(去年の今頃)は、机に塗り直したオイルが良く乾かずにムラになったのかと思ったが、そうではなかった。先日、ふとキーボードの底面を見たら、ゴムが埃だらけでベトベトになっていたので、劣化していることが分かった。

見ると、4つの脚全部が劣化しているのだが、どういう訳か手前がひどい。どうやら、ゴムでなくゴムを貼り付けている両面テープが劣化してベタベタな「何か」になり、手前側は面積が大きいので机に垂れたのだろうか。それで、このゴムを「何とか」することにした。ついでに、埃などでかなり汚れていたので清掃もすることにした。

劣化したゴムをどうするかだが、手前のものは、以前流しの樋を固定するために買った滑り止めに交換し、奥は、ゴムの上から剥がせるシールを貼った。清掃も含めて特に問題なく終わった。一番の問題は、両面テープのベトベトのタチが悪かったことだ。指にくっついたらなかなか取れず、気持ちが悪かった。

清掃してとても綺麗になった。しかし、滑り止めについては早くも問題が生じた。日記に書くため、手前に貼った滑り止めの材質を調べたら、ポリウレタン製だったのだ。これは、以前手直しした、経年劣化したバッグのコーティングの材質である。だから、いつか劣化する。ゴムでは両面テープが劣化したが、今度は滑り止め自体が劣化するので、更に好ましくない気がした。更に、奥のシールは貼ってすぐに剥がれてしまった。そもそも「剥がせる」シールだから当然ではある。

それで、手前と奥両方を、昔買って残っていた、机や椅子の脚の底部に貼って騒音や傷を防止するフェルトに交換した

この作業も簡単に終わった。ただ、奥は貼る場所(脚)のカーブがキツいため、フェルトがすぐに剥がれてしまったので、(ケーブルを束ねるのに良く使われている)ビニル被覆の針金で固定した。本当は細い結束バンドの方が強力で良さそうだが、手軽なので針金にした。そもそも、キーボードを持ち上げることは滅多にないから固定しなくてもいいとは思ったが、剥がれた粘着材に埃が付着したり、いつか外れて嫌な気分になるのが嫌なので、一応固定した。

作業後は、フェルトのせいでキーボードが軽く(スルッと)動くようになった。これは想定外だったのだが(滑るフェルトを貼ったので当然ではある)、僕は、とりたててキーボードの固定が必要な使い方をしていないし、食事とか作業の時などに頻繁に前後に動かすので、その時に滑れば机に傷を付けないから却って好都合なので、「結果オーライ」となった。

今回は良く考えずにテキトーに作業を始めたのでいろいろ想定外のことが起こったが、手軽に(その割には写真が多いが)うまく行ったので良しとするw

 

PS. キーボードの清掃後、キートップも劣化していることに気付いた。良く使うキー(A, S, D, Eなど)がひどい。まるで、お寺の凹んだ石段だ。汚れなのかも知れないが、擦っても全然取れないので、コーティング(しているのだろうか?)とかキートップ自体が削れたのかも知れない。まだ4年も使っていないのだが・・・ この辺りは、指の腹でなく爪の先で押すことが多いからなのかも知れない。

キートップも劣化していた。

このキーボードは文字がキートップでなく側面に印刷されているので、使い込んでも文字が削れてみにくくなったりしないから選んだのだが、こういう落とし穴があるとは思いも寄らなかった。まあ、それでも、いくら使い込んでも穴が開くとは思えないのでw、キーのスイッチが壊れるまでは問題なく使えそうだ。

そういえば、キートップとは関係ないが、このキーボードは、長期間(1か月くらい?)使い続けると誤動作するのか(Linux側の問題の可能性もある)、文字が勝手にリピートするようになる(ケーブルを抜いて挿し直すと直る)。定期的(あるいは、スリープからの復帰時など)にキーボードをリセットする処理ができないかと、今思った。

LinuxのUSBの機能を使い、スリープからの復帰時にキーボードをリセット(正確には、USBデバイスのdeauthorizeのあとにauthorizeして、キーボードを再登録する)するようにしてみた。数か月後に結果が分かるはずだ。ただし、この処理はUSBコネクタを抜くのと異なり、キーボードの電源が切れるかは不明なので、もし、キーボード側が異常動作しているのなら、効果がないかも知れない。 (13:03, 14:52)

  •   0
  •   0

副題: 腐った革袋に良いワインか・・・

昨日行ったラ・フォル・ジュルネ TOKYO 2019へのいろいろな文句を、怒涛のようにぶちまける。その他に、いつものように、その日にあったことで気になったことなどを列挙する。

全般

何が「音楽祭」だよ! あんなのストレスを溜めるだけの苦行だ。音楽を楽しむ以前にイライラしたり疲れてしまって、そういうのに耐えて精神を鍛える修行とか、何かの罰ゲームだ。

東京国際フォーラム(以下、TIF)の問題

TIFの全ホールを使っているようなので、ものすごく大勢の人が来ていた。全ホールの収容人員を1万人とすれば、ピーク時にはその数倍から十倍は来ていたはずだ。人が多過ぎて、食事やトイレなど、普通のことすら何一つまともにできない。何でも行列だし、人が多い所(棟の間の広場)ではその行列で通路も塞がってしまって、まともに歩くこともできない。椅子もテーブルも空いている訳なくて、休むことも満足にできない。都心だけど土地は無駄に広いので、何をするにしてもとにかく歩くばかりだった。

まさに、阿鼻叫喚の地獄絵図だった。毎日満員電車で通勤している人は慣れているのかも知れないが、休みの日まであれでいいのだろうか?

ホールのある棟は階段やエスカレーターばかりで、どこに何があるか分からない。表示はあっても分からない。エスカレーターの前で、係員が「R(扉)は手、L手」(左右逆ではない)と連呼していたくらいだ。他には、トイレの表示を頼りに階段を降りたら、突然表示がなくなり、実は真後ろにトイレがあったりする。ここに比べれば、以前懲りた文京シビックホールの方がまだマシだった。

トイレについては、小さいの(小が数個、大が1室しかないのが多い・・・)が分散していて、そのせいかどれも混雑してしまって、すごく不便だった。女の人はどのトイレも長い行列で、更に大変だっただろう。。。

レストランは高いうえに行列※、周りも高級な店か飲み屋。なぜか、コンビニがほとんどない。これの客以外に、はとバスの観光客や有楽町やビックカメラなどの客も多くて、外も競争率が高そうだった。

※その中にはSizzlerもあった。それを見て、大昔(90年代半ば)、横浜かどこかに行って昼食の時だったか、どこも混んでいて、Sizzlerですら行列ができていて、「なんでSizzlerなんかに並ぶ必要あるの!?」とブチ切れたのを思い出した。一緒に行った方には大変申し訳ない・・・

結局、僕は、昼食は食べられず(探し回っているうちに最初の公演の時間が来てしまったため)、飲み物も買えず(気力がなくなった)、トイレで水を飲んだだけで最初の演奏を聴き、その後、地図アプリで何とか見付けたコンビニでおにぎり2個を買って食べた。一個の具は筍だったのだが、次の演奏の時に、なぜか湿った竹の匂いがして不思議に思ったら、自分だったw

ラ・フォル・ジュルネ TOKYO 2019(以下、LFJ)の運営の問題

クラシック音楽を知らない人が運営しているとしか思えない。とにかくうるさい。あれは、映画とかポップ音楽の乗りだった。というのは、ホールAのステージ両脇にはディスプレイがあるのだが、開演前に延々と うるさい音を出しながら動画広告(要はCM)が表示されていたのだ。興ざめだし、演奏前に集中を高めたいのに全く落ち着かない! あと、このCMはベレゾフスキーの調律中にも流れていたのだが、邪魔じゃなかったのだろうか?

同じくステージだが、視覚的にもうるさい。ディスプレイの下にはきらびやかで悪趣味なライトが点灯していた。演奏中もずっと! このライトはステージの背にも同じ色で光っていた。もちろん、演奏中も。

ホールに入って椅子に座って、このありさまを見たら、本当に嫌気が差した。それでも演奏を聴きたかったので耐えたのだが、最初の演奏は前に書いた通りの惨憺さだった・・・ もしかして、ベレゾフスキーが本気を出さなかったのは、この醜態のせい? (まあ、そんなことは全くないと思う)

それから、前の稿にも書いたが、ホールAは広過ぎて後ろの席の音が醜悪だ。音が悪すぎて苦痛のレべルではなかった。企画・設定する時に聞いて確認していないのだろう。多くとも収容人員を半分にすべき(サントリーホールだって2000人だったと思う)だが、それでは儲からないのだろう。逆に、5000人で3000円(最後列でも2500円)も取ったら、主催者は「割安」どころかすごく儲かるはずだ。

ステージ脇のディスプレイだって、細かいところが見えるのは確かに便利だが、視点が動くし、明るいから演奏への集中を削ぐ。遠くの人のためという建前だろうが、そもそも人を入れ過ぎるから要るので、客を減らしてディスプレイはなしにすべきなのだ。

とにかく、LFJは最低だった。

しかし、今思うに、実は僕の方が場違いで、趣旨や中身を確かめずに安易に行ったのが大間違いだったのではないだろうか? LFJは、純粋にクラシック音楽を楽しむ人に向けているのではなく、

連休だし、近くで気軽に時間つぶしができ、しかも、家族とかパートナーと一緒に行けて、いかにもセンスがあって文化的で意識高そうで、(若い人なら)彼女とかにうんちくなどを傾けられ、帰りにおしゃれなレストランで食事したい。

とか思う人たちに適当な、「テキトーなお祭り騒ぎ」だったのではないだろうかw

実際、若い人や家族連れ(赤ちゃん連れも)が多かった。しかも、曲や作曲家に特別に興味がなさそうな人が多そうだった。でも、そうであれば、どういう考えでクラシック音楽を、しかもその曲(僕が聴いた曲なんて、「運命」とか「別れの曲」などとは違って、どれもそんなに有名ではないと思う)を、聴きに行ったのだろうか。そこが理解できない。普通のポップ音楽とか映画でいいじゃん。そっちの方がずっと分かりやすいよw 確かに幅広い人に興味を持たれるのはいいけど、聴いたあとで「綺麗だ(すごか)ったね」などで終わって何もしなければ、余り意味がない気がする。まあ、それでも、低い確率ではあるが、これを機会に継続して聴きたくなる人が居るかも知れないから、紹介とか裾野を広げるという意味では価値があるのだろう。

良かったこと

そんなしょうもない催事ではあったが、わずかながら良かったことがあった(もちろん、演奏自体は概ね良かったが、別に書いたのでここには書かない)。

  • スタッフがちゃんとしていた。多くは学生のアルバイトだと思うが、みんなきちんと対応していた。ただ、かなりスタッフが多かったから、経費が掛かってそうだ。まあ、5000人のホールに客を詰め込んで総入れ替えで回転させれば、充分に元が取れるのだろう。
  • 人ばかりの外に比べて、ホールの中は涼しかったことw あと、椅子の幅や間隔が広めなのは良かった。

雑記

  • 若者(概ね2人連れ)の会話が楽しそうだった。映画の話(例の「ピカチュー」や長澤まさみが出ている作?)とか、本に書いてあったらしい音楽のうんちく(ホールの音を調整する人の仕事の話: 「調律師」と言っていたが、実際の名称は違うと思う)とか。うらやましかったし、後者の話には興味があったが、さすがに割って入る訳には行かなかった(それなことをしたら、良く居る、昔取った杵柄オジさんだ)w なので、微笑ましく聞いていた。
  • 写真を見て気付いたが、近頃は聖子ちゃんカットが復活した?? 単なるミディアムボブ? 服装も80年代っぽい気がする。
  • いまだにCD販売をやっていて、それを買う人が多いのが不思議だ。
  • (都内は)さすがに綺麗な人(女性)が多い。あんなにバッチリにして疲れないのか謎だ。慣れなんだろうが・・・
    •  でも、綺麗なのに性格が悪い人も居る。
    • でも、田舎は綺麗でなくても性格が悪い人が居る・・・ (そうだったか)
  • 年寄りは素直でない。
    • 行きのバスで、バスのカードが止まってしまうので手で押さえないように言われても、例によってムスっとして返事もしない。しかも、このババアは降りる時も同じことをして手間取っていた。
  • 連休のせいか、行きのバスは珍しく満員になった。
  • 行きの宇都宮駅で、今更指定席を取ろうとする人が多いようで、券売機は混んでいた。しかも半分くらい停まっていて、更に混んでいた。釣り銭切れだったのか?
  • 新幹線でもSpotiyは問題なかった。ただ、行きは疲れていたのと、帰りは聴いた演奏に満足して、ほとんど聴かなかった。脳内演奏や本物の音楽の方がいい・充分な気がしている。あと、近頃は無音もいい。
  • 新幹線の通路の反対側の列に、熱心に勉強する若い女性が居た。隣席のババアに嫌がらせ(荷物が邪魔だとか)をされても、丁寧な受け答えをしていたので感心した。集中したのか、最後はあぐらをかいていた。そういう人は結構好きだw
  • 演奏中に奇声を発する人が居た。最初の2公演で居た。子ども? 精神障害者?
    • あと、老人は例によってビニール袋をごそごそ。あれ、なんなのかねぇ・・・ やっぱり、飽きたんだろうか。だったら、曲名を見て分かる(分からない)んだから、来なければいいのに。
    • もちろん、隣には、演奏中にパンフを取り出して読みだす人も居たw あれはなぜ??
  • どの公演でも、席の周囲の女の人の匂いがキツかった。いい匂いの人は居なかった。ただ、いい感じの人は無臭だった気がする。その方が好印象だ。
  • 演奏が終わって下の階に降りる時、平然と横から列に割り込む(仲間内で「列になってるのねー」とか話しながら、しばらく列と並行に歩いて、おもむろに(僕の前に)割り込んだ)ババア数人が居た。オバさんて、なんでマナーを守らないのだろうか? まあ、ジジイも一緒か。
  • その後階段で、近くを歩いていた女性が連れに「隣の人が・・・」と言い出したので、もしや、隣に座って居た人で、「リズムに合わせて頭とかを動かして鬱陶しかった」とか言われるのではないかと、ちょっとドキッとした。だが、「煙草臭くてー」だったので、ほっとしたw
  • 疲れのせいか、帰る頃には視力が落ちた。暗いせいもあって、良く見えなかった。
  • なぜか口内炎ができていた。疲れなのだろうが、飲んでいるビタミンB剤が効いてないようだ・・・
  • 帰りの新幹線の通路で: 席に向かう時に反対側からも来たので、数人を通し、切れ目ができたから進んだら、ババアとガキが来て、避けずに(こっちを無視して)平気な顔で通って行った。譲り合いすることを知らないのだろうか。すごく疲れていたし、頭に来たので、少しぶつかったけど僕も無理して通った。それが結構後味が悪かった。
    • 僕は、車でのやり方のように、交互に行こうと思ったのだが、「普通の人」は、行列がなくなるまで、延々と待つものなのだろうか??
    • ババアはやっぱり・・・
  • 宇都宮駅に、いかにもアメリカンな白人女子が居た。「Youは何しに?」w
  • DQN車が駅前ロータリーを結構通っていた。連休のせいか。あんなに居たとは知らなかった。あと、バス用のレーンに入って、停留所に停めて邪魔になっている馬鹿も多かった。
  • なぜか、駅のコンビニは人が多くて列が分からなくて面倒だったので、何も買わずに帰った。吉野家も、最終バスの時間まで余裕がなくて入れなかった。結局、夕食もまともなものが食べられず・・・ さすがに、僕もそこまでストイックではないw
  • 帰りのバスは丁寧な運転手さんで怖くなかった。珍しい。
  • 珍しく何の忘れ物(持参し忘れも)もなかった。
  • かなり歩いたせいか疲れたせいか、今朝は1週間前に比べて体重が1kg減った。そして、ふくらはぎが痛い。

てな訳で、メモしたことや思ったことをほとんど全部吐き(掃き)出したので、すっきりしたw

AQUOS sense liteで撮影

  •   1
  •   0

以前書いたように、昨日、ラ・フォル・ジュルネ TOKYO 2019で3つの演奏(公演)を聴いた。演奏は一部を除いて良かったのだが、施設(東京国際フォーラム)や運営がひど過ぎて(「[悲報] ラ・フォル・ジュルネ TOKYO 2019の運営がひどすぎた件」という題にしようと思ったくらいだ)、演奏は別にして、あそこにはもう二度と行きたくない(無料でも断る!)。それについては別途書くことにして(→ 書いた)、まずは聴いた演奏の感想を中心に書く。以下の"No."はラ・フォル・ジュルネの公演番号である。

No. 113: アンヌ・ケフェレック: モーツァルト ピアノ協奏曲 第25番

指揮: ミハイル・ゲイツ、オケ: シンフォニア・ヴァルソヴィア

この演奏については、席の問題が大きくて、純粋な演奏の感想を書くのが難しい(「評価対象外」とした方が適切なくらいだ)。席が最後列(後ろは壁)だったため、音が最悪だった。

このホール(ホールA, 次の2公演も同じホールだった)は5千人くらい入るようで、かなり大きいせいか、最後列は完全に「アウェー」な感じで、音も見た目も一体感が全くなかった(観たことはないが、野球の外野席のような感じだろうか)。「なんか遠くでやってるな」、「向こうで拍手の音が聞こえるね」って感じだ。だから、音に包まれるなんてことが全くなくて、コンサートの意味が感じられなかった。音量も小さく、例えば、全奏で大音量のはずの箇所でも自分の動きで出る音(例: ハンカチが擦れる音)が聞こえるくらいだった。

音量以上にひどかったのは、ステージからの距離が長いための遅延のせいで音が混ざってしまい(いろいろな遅延時間の音が混ざったのだろう)、短い音符、特に連打がぐちゃぐちゃになってしまった。更に、音質もひどいものだった。生演奏の良さは全くなく、質の悪いスピーカーで出してるのかと思った。はっきり言って、あの音をずっと聞かせられるんだったら、家で僕のステレオで聴いた方が100倍マシだと思った。あのホールは音楽用ではないのではないだろうか? それは、ステージの外見でも分かると思う。少なくとも、クラシック音楽のプロは居ないようだ。それでも使いたいなら、せめて後ろ半分の席を使わないようにするとかしないと、かなり無理がある。

別の投稿で書いたが、既に演奏の前に完全に嫌な気分になっていたので、第1楽章が始まって、とんでもない音なのが分かったらすぐに帰りたくなったのだが、通路から遠くて途中で出るのが難しかったし、連休なので新幹線の自由席には座れなさそうなことに気付いたので、我慢した(結果的には、それで以降の演奏を聴けたので、良かった)。

前にも予想したが、ケフェレックのこの曲は僕にはイマイチだった。僕は、この曲は、フレイのような豪快とかパワフルな演奏が(曲の性格にも合っているように思えて)好きなのだが、その正反対であったせいは大きい。まず、音が弱い。弱くて良く聞こえない。これは席の問題だけでない気がする。仮に近くても物足りないと思っただろう(多分、古楽器の好きな人は問題ない)。あと、何となく神経質そうな音に聞こえたのも、気に入らなかった。

モーツァルトの時代は(今のピアノはなく、)フォルテピアノだったから、大音量はあり得なくて、小さい音で弾くのが歴史的には正しいという考えなのかも知れないが、それなら小さいホールでやって欲しかった。ただ、弾く動作が大ぶりなところ(例: 少し長い休符の前の音を切る時に腕をバッと引く)があって、実は本人は大きく弾いているつもりなのかも知れない。それなら弱過ぎる。実際、同じオケでショパンを弾いたベレゾフスキーの音量は充分だった(ただし、席はずっといいところだったから、単純な比較はできない)。おもしろいことに、彼の振りは全く大人しいものだった。

いずれにしても、僕の好みではなかった。何となく、中学時代の、すぐに小言を言ううるさいオバさん先生を思い出してしまった。

※2曲目にバルディルーによるモーツァルトのクラリネット協奏曲も演奏されたが、知らない曲だし、そもそも早く出たかったから良く聴いていなかったので、感想は省略する。曲としては好きではない。

No. 114: ネルソン・ゲルナー: ラフマニノフ ピアノ協奏曲 第3番

指揮: スラドコフスキー、オケ: タタルスタン国立交響楽団

最高だった! 終始乗れて、完全燃焼して真っ白な灰になったw ケフェレックで帰らなくて良かったと思った。

ゲルナーは想像と違って小柄で(上述のフレイの指揮者ズヴェーデンと混同していたようだ)、人の良さそうな、ちょっと頼りなさそうなおじさんだった。だから、始まる前は、「(パワーなどの点で)大丈夫かな?」と心配したのだが、最初のフレーズを聴いた時点で全く問題ないことを確信した。実際、彼はこの曲を完璧に弾き切った。見事だったとしか言いようがない。下のベレゾフスキーを評したようなことを書くとすれば、「恐ろしい子!」だw

彼は頻繁に指揮者を見ていたのだが、難曲なので、致命傷になりかねない音ズレなどを減らそうという気持ちだったのではないか(そういう動作で、「いいおじさん」の印象を受けた)。音ズレの点では、結果としては、下に書くベレゾフスキーとは逆で、ほとんど感じられなかった。

席については、2階席だったのでステージが遠く(ステージ脇にディスプレイがあったので、遠くてもちゃんと見ることはできたが、後の稿で書くが、それもいいことばかりではなかった)、上から見下ろす感じで今ひとつだったものの、音は問題なかった。S席(この演奏)とA席(ケフェレック)の違いは大きいようだ。ただ、ケフェレックのAはCとかDのほうが妥当な気がする・・・

席が良かったので、普段、家では聞こえない低音が聞こえて、「なるほど、こういう作りだったのか」と思った(腑に落ちた気がした)。そういう音が聞こえることで、更にいい感じに・気持ち良くなったので、こういう音が家でも出せるといいのだが、そこから無間地獄が始まるので止めておくw

あと、別投稿の雑記の項に書く方がいいかも知れないが、途中で赤ちゃんが泣き出してしまって、母親に抱かれて退出したが、なぜか全然気にならず、微笑ましく思えるくらいだった(「そりゃあ泣くよね」、「どっちも可哀想に・・・」くらい)。(曲の)場所にもよるだろうが、この曲は僕の中では格闘技なので、細かいことはいいようだw でも、モーツァルトやショパンでは全くありえない。それにしても、この曲に赤ちゃんを連れて行くのはどういう考えなのか、聞いてみたい。けしからん以上に(それは今回は許せた)、どういう効果や価値があると思ったのだろうか。下手するとトラウマになる気がするw 単に、何も考えてないのか。まあ、誰も預かってくれないとかいう事情はあるだろうから、仕方ないが・・・

No. 115: ボリス・ベレゾフスキー: ショパン ピアノ協奏曲 第2番

指揮: なし (コンマス: ハウファ)、オケ: シンフォニア・ヴァルソヴィア

大変僭越ながら、「君はもっと良く弾ける子でしょ?」と言いたい。いや、実際のところ、彼の音は、溜息が出たほど・「死ぬほど」美しかった。オケもピアノに負けず綺麗だった。後で気付いたが、このオケは最初のケフェレックのと同じだったようだ。それにしては、音の聞こえ方が全然違っていた。編成や席の違いが大きいのだろうか。

協奏曲の前に、彼だけで練習曲を数曲演奏したのだが、最初の「エオリアン・ハープ」には本当に参った。あんなに綺麗な音が出るものかと思った。これだけで満足だったし、他にも練習曲を多く演奏したので、それだけでも充分な気がしてしまった。

一方、メインの協奏曲では(練習曲でもそういうフシがあったのだが)、どうも、本気を出してないような気がした(そんなことは全然ないとは思うのだが)。損しているのは、彼は、フルコンが小さく見えるくらい身体が大きくて、小さく見える鍵盤を大きな手で軽々と、いかにも赤子の手をひねるように弾いているように見えてしまうことだろう。その他に、ごくわずかに音が軽く感じたせいもある。ただ、前に書いたように、彼はサラッと弾く人のようなので、それが彼の表現なのかも知れない。そういうところが、以前買ったラフマニノフ ピアノ協奏曲 第3番のCDを気に入らなかった原因かも知れない。

他に気になったのは、何度も、オケとピアノやオケの中での音ずれがあったように聞こえたことだ。指揮者が居ないせいなのだろうか。最初は、ピアノが中央に配置されているところから見て、ベレゾフスキーが弾き振りしているように思ったのだが(実際には、弾き振りだったらピアノの前後が逆で、ピアニストが奥を向くように配置する)、パンフにはそうは書いてなかった(コンマスがリードするような雰囲気だった)。ただ、ステージ脇の画面には、時折彼が他の楽器に目配せして(睨んで?)いるのが写っていた。だから、主導権が誰にあるか不明な状態で演奏されているために音ずれが出たのではないかと思う。そういうところも、本気を出してないように感じた一因かも知れない。

今回の席は、1階の中央の少し後ろと、この日の中で一番いいところ(一般的には普通の席)だった。そのため、音質は全く問題なかった。ゲルナーの時と同様に、家では聞こえない低音が聞けて良かったし、音の作りが分かった。

まとめ

全体的には良かった。一番は、やっぱり、ラフマニノフのおじさんだったw ただ、さすがに一日で3つの演奏を聴くのは疲れた。例えば、最後の演奏が終わった時、左脚のふくらはぎがつりそうになった。でも、疲れは演奏以外の問題によるもののほうが大きかったと思う。それでも行って良かった(しかし、再度書くが、あそこはもう真っ平御免だ)。

 

(14:35, 17:21 加筆・修正)

  •   1
  •   1

Spotifyで何の気なしに(他のに飽きて)、プレイリスト「昭和歌謡」でも掛けようと思って、「まあ、どうせいつもの曲だろう」と思いつつも曲のリストを見たら、なんと、キャンディーズが入っていた。ちょっと驚いてアーティストのページを見たら、オリジナルアルバムがフルに入っている感じだ。

プレイリストへの登録日が"7 days ago"とあるので、1週間前くらいに入ったようだ。だが、4/30に聴いた時にダメ元で探しても出て来なかったのが不思議だった。ただ、ちょっと試したら、どうも探し方が悪かったようで、英語の綴り"Candies"では出ないようだ。なぜかキャンディーズを聴きたくなったことや、何かのニュースを読んだついでに「田中好子」を検索したのは、虫の知らせだったのか?w

考えてみると、田中の命日(4/21)が近かったからか、ニュースに出ていたのを読んで検索し※、命日に関連して(何かの区切りが付いた?)Spotifyにも追加されたような気がする。

※詳しい経緯を思い出した。「カフェテリアの甘い罠w」を書く時に「甘い罠」で検索したら、「春一番」について、「後奏のギターが間違って聞こえる」という内容が書かれたブログのページが見付かり、それを確認したくて聴きたくなったのだ。まったくの偶然に「誘惑の甘い罠」という節が浮かんだ(最初は誰の歌かも分からなかったので検索した → 実際には山口百恵だった)はずなのだが、本当に虫の知らせだったのかも?

そして、あの自民のちょっと苦境の大物政治家I氏も喜んでいるだろうか?w まあ、そもそもレコードを全部以上持っているだろうし、外で聴く時だってSpotifyなんて使ってないだろうから、関係ないな。

Spotifyも地道にレパートリーを増やしているようだ。これからも頑張って欲しい。ただ、もしやと思って吉幾三※や山口百恵や小泉今日子を探したが、やっぱり入っておらず、まだまだ頭が硬いか遅れている人(レーベル)は多いようだ。

※吉に関しては、なぜか、あるプレイリストに本人の曲が登録されているし、そこからアルバムにも行けるのだが、曲は再生不可の状態になっている。近いうちに入るのか、海外では再生できるのか、昔は入っていたけど配信を止めてしまったのだろうか。

 

PS. 懐かしいグループ 青い三角定規は、Spotifyの英語モードだと"Bluetriangle"と出て、(単なる直訳なのに、)かっこ良いうえに自然で、USのグループと言っても分からないくらいだ(実際、何かの曲一覧で見た時、「こんなグループあったっけ?」と思った)。便宜上付けられただけなのか、当時からそうだったのか、ちょっと気になる。 → 調べたら、当時のシングルのジャケットに"BLUE TRIANGLE"と書いてあるので、概ね元々そういう綴りだったようだ。ちょっと感心した(ただ、近年のベストCDにはローマ字で"A・O・I Sankakujohgi"と書いてあるのは、本人とは関係ないだろうが、頂けない)。

PS2. リンクを挙げた曲の入っているベスト盤(「GOLDEN☆ベスト キャンディーズ コンプリート・シングルコレクション」(2011))のジャケットは当時から嫌いだった。まず、"Candies"と書かれた文字がそうは読めない。次に、色柄が全然「らしくない」からである(こういうののほうがらしい)。が、まあ、僕は熱心なファンでないから、大した問題ではないw

  •   0
  •   0

伝統が大好きな日本の人たちは、なぜ、当たり前の顔をして太陽暦(グレゴリオ暦)を使っているのだろうか? 西暦の年号はキリスト教由来のものだ(から、それだけにするのはけしからん)と言うが、グレゴリオ暦だって日本のものではない。時間の基本的な単位だって、秒でいいのかどうか甚だ疑問だ。僕は歴史には詳しくないが、今の暦になったのは明治のようなので、まさかそれが日本古来の伝統だということはあるまい。ダブルスタンダードだ。

伝統を守るのであれば、年号同様、日付や時刻も世界標準と伝統的な暦(何にするかは勝手に決めて欲しい)を併記すればいいし、お役所は伝統的な暦で運用すればいいではないか。明六つ・暮六つとかやればいいのだ。今はデジタルだからいくらでもできる(かも知れない)し、伝統を守るんだから、不便に耐えるのは当たり前だよねw

でもまあ、考えてみると、大量の西洋文明が流入した明治起源のものを「伝統」と称している場合が多いから、彼ら的にはこれで筋が通っているのかも知れない。僕はとても不思議な気がするが。「伝統」と言うなら、やっぱり平安、せめて江戸ではないか?

もちろん、僕は世界標準の体系だけで充分だ。

 

PS. と書きつつ、この文章を日本語で書くのはダブルスタンダードかも知れないねw まあ、今はUnicodeのおかげで日本語の文字は世界標準に取り込まれているから、完全なガラパゴスとも言えないかな。本当にいいのは、全部の投稿を日英併記することだろう。仕事サイトではやっていたが、趣味だとなかなか・・・ 機械翻訳の精度がもっと上がれば楽になるけど、言葉遊びの類は難しいだろうな。

  •   0
  •   0

コンビニで金曜のコンサートの券3枚を受け取った帰りに、電気店に寄った。もちろん買いたいものなんてなくて、休憩と情報収集と人間観察wのためである。連休のせいなのかいつもなのか、閑散とした店内で、ふと電子ピアノが数台並んでいるのを見たら、

英雄ポロネーズ」を盛大に弾きたくなった!

完璧に弾き切って、何事もなかったように立ち去った

ら、きっと、カ・イ・カ・ンなんだろうなと思ったが、残念ながら、弾く腕も何も全くないことに気付いてしまったので通り過ぎたw

 

PS. 例として1番目にリンクを載せた浅野真弓という人の演奏(2016)が、僕の好きなルービンシュタインの演奏に通じるものがあって、かなり気に入った。スケルツォ(2016)は、力強い部分(ポロネーズもそうだが、力の入れ方と抜き方)がすごく気持ちいい。僕は、ここら辺の曲にはそれほど興味がないのだが、この演奏はいいと思った(強いて言えば、途中の「シュワーッ」となる箇所の発泡感が少し物足りない気はした: って、分かるかなぁ、分かんないだろうなぁ)。いい人を見付けた。僕にしては珍しく、どちら3回くらい聴いた。(繰り返し聴いたら多少のあらが見えたものの、)それほど良かった。まさに棚ボタだ。

PS2. 本来の収穫もあったw ホイールの回転にノッチがあるというのか、一定の角度で停まるマウスが増えて来たのだ。逆に、無段階のものが少なくなった気もする。これなら、今度マウスが壊れても、(直さなくても)買い換えれば良さそうだ。あと、メカニカルなのか、それなりに打鍵感のいいキーボードもあった。マウス同様、「ゲーミング」と書いてあったが、コンパクトなので、いざというときはいいかも知れない。ただ、どちらも安くはなかった(キーボードは1万円くらい)ので、買うなら通販かな。

  •   0
  •   1

 

PS. この猫は、たぶん、いらすとやのイラストなんだろう。僕はそういうのを安易に使うのは嫌いだし、いらすとやの作品はワンパターンなので好きじゃないが、これは許すw

  •   0
  •   1