Archive for the ‘音楽配信’ Category

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

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

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

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

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

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

その前に、外観(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回呼んでいる。それがとてもおぞましい。。。 (が、そもそも、シェルスクリプトなんて外部コマンドを呼びまくりなのだから、この程度で苦しくなったら即座に窒息してしまって生きて行けないだろうから、気にしなくていいのかも知れないw)。

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

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

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

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

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

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

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

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

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

 

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

  •   0
  •   0

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

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

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

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

なんか、こうやって、それまで考えてできない・難しい・面倒と思ってたことを、試行錯誤や裏技や力技でできるようにするのは、とても血沸き肉踊るものがあって、プログラミングの醍醐味と言えよう。まあ、こういう裏技は趣味だから使えることだが、仕事にも形を変えてフィードバックできると思う。と言っても、意識低い僕は、仕事のために(「自己研鑽」だの「スキル向上」だのw)趣味のプログラミングをしている訳ではなく、お客さんや上司などの鼻を明かすとか、期待よりずっと早く仕事を終わらせて、遊びの時間が増えるのが楽しいからであるw (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アプリから取れるが、今一つ効率が悪そう)
  • プログラムの整理 (いろいろ汚いw)
  • CPU負荷・メモリ量に問題ないことの確認 → 大丈夫そう。(6/10 11:19)
    • メモリ: 全部で35MB程度
    • CPU負荷: 0% (通常時)

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

  •   0
  •   1

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

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

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

少し内部的なことを書くと、システムは、以下のように、リモコン対応部(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の勝手な変更(仮にあったとしても)に右往左往させられる心配は少ない。だから、将来的な手間はずっと少ないはずなので、音楽(=本質)に集中できる。

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

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

 

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

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

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

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

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

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

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

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

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

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

新しいUIの案

  •   0
  •   0

前回、Googleのいつもの勝手気ままな行動のために休日を潰したことを書いた。その時は暫定的な対処でしのいだのだが、正式な対処をする必要があり、結構大変(しかも、Googleの気まぐれでこの先がどうなるか不明なので、すぐには手を付けられない)なことを実感した。それで、どうするか考えた。いくつかの案があったのだが、その一つに、以前は却下したSpotifyに移ることがあった。

Spotifyを却下した理由は、Linuxのクライアントで音量正規化ができなかった(設定はあったが、効いていなかった)ことと、僕の聴きたい曲のレパートリーがGPMに負けていたことが大きかった。ただ、そもそも、GPMでの多大な苦しみは音量正規化をするためだったので、もし新しいSpotifyクライアントで音量正規化ができれば、そんな苦労が不要なので、充分に再考の余地があると考えた。

調べてみたら、近頃Linuxのアプリが更新されたようなので、インストールして試してみた。すると、音量正規化がかなりうまく働くことが分かった。普通のポップ音楽ではボリュームを調整する必要がないほどで、僕が苦労して作ったGPM+GMBのシステムを軽く超えていた。ただ、動的に正規化しているためか、ピンク・フロイドの「狂気」の最初の曲のように小さい音が長く続く場合には、音量の変化が激しくなって不自然になる。それにしたって、わざわざその曲を試したから気付いただけで、今まで数日間、普通にポップ音楽のラジオ(プレイリスト)を聴いていた限りでは、全然おかしくなった。あと、無料プランなのでビットレートは低いはずだが、(ポップ音楽では)音質も悪くなかった。

レパートリーに関しては、確かにGPMの方がいいことがある。が、試して実感したことがある。それは、(以前も書いたが)Spotifyの方がGPMよりずっと「音楽的」だということだ。言い方を変えれば、音楽好きな人たちが運営している雰囲気が感じられるのだ。一方、GPMからはそんなことは全然感じられない。他の事業と一緒で、持ち前の技術やお金やパワーでささっとシステムを作って出している感じだ。基本はお金や彼らの興味(先進性の誇示?)のためにやっているので、儲からなくなったら、あるいは、飽きたらあっさり止めるだろうし、(彼らにとって)つまらないことはしないのが見え見えだ。その証拠の一つが、上の音量正規化だ。ずっと要望されているにも関わらず、なーんにもしていない。GPMのラジオを聴くと分かるが、曲ごとに音量がバラバラなので、全く楽しめない。彼らはシステムを作るだけで、そのシステムでロクに音楽を聴いたことがないのだろうし、興味もないのだろう。きっと、良く居る技術○鹿集団なのだろうと思う。

ラジオ(プレイリスト)の曲目にしても同じだ。GPMにもそれなりのラジオがいくつもあるのだが、いつも何となく不満だったり物足りなかった。ところが、Spotifyのは全然違っていて、「これだ!」と感じられるのだ。

例えば、今朝からSpotifyの"My Generation: '80s"(無料会員登録すれば見られます)を聴いているのだが、最初の2曲を掛けただけでうれしくなった。「青い珊瑚礁」の次は「異邦人」なのだ! しかも、洋楽(例: ノーランズ "I'm in the mood for dancing")も混ざっていて、まるで僕のために作ってくれたようなリストなのだ。そういうのが全部で100曲、たっぷり聴ける。GPMのラジオは機械で作ったような感じだったが、これは違う。音楽好きのスタッフが作っているように思う。(6/4 20:54追記: 実際のところ、スタッフがどうなのかは分からないが、今日読んだ記事によれば、Spotifyの創設者ダニエル・エクは音楽好きらしい。顔はちょっと怖くて(眉毛がないところは、映画"The Wall"のピンク(ボブ・ゲルドフ)みたいだ)、いかにもロック好きの熱血漢という感じだw それはともかく、やっぱり、大きい会社のように、「儲かりそうだから、ちょっと真似してみるか」程度の軽い気持ちで始めた訳ではないようだ。)

Spotifyでプレイリスト"My Generation: '80s"を再生中

今まで試して来て、いろいろな不満・欠点は見つかっているのだが、それでも乗り換えたい気分になっている。繰り返しになるが、音楽的だということ以外に、純正アプリに音量正規化機能があってまともに使えるから、GPMでのような散々な苦労をする必要がないのは大きい。

とはいえ、やっぱり欠点はあるので、可能な範囲でカバーしようと思っている。以下に、現状での不足・不満な点を列挙する。いくつかは既に対処している。

  • サービス
    • レパートリーが若干狭い(アルバム数が少な目)。 → 入ってなくて聴きたいものは、CDを買うかダウンロード購入すればいい。
    • GPMの"I'm feeling lucky"に相当するラジオ(プレイリスト)がない。そのうちリコメンドされる?
    • 手持ちの曲(レパートリーにないものなど)をアップロードできない(デバイスごとに入れるしかない)。 → 割り切りの問題?: 自宅ではもちろん聴けるから、外で我慢すればいい?
  • Linuxアプリ
    • 音量正規化のon/offが面倒(拡張設定を開く必要がある) → 検討中
    • 曲名などのテキストが選択できず、コピーもできない。 → "Suggst an Edit"を選択するとブラウザで表示されるので、できる。
    • 「この曲で停める」がない。(GPMも同様) → 検討中
    • 検索に日本語が入らない。(ペーストは可。Webは可) → 何とかして欲しいw
    • リモコンをGMBとうまく共有する必要がある。 → 概ね対処済み。
    • Thumbs up/downできない(アイコンが出ない)ことが多い。謎仕様。(Thumbs up/downはリコメンドに関係ないのなら問題ないが)
    • UIが暗い。 → 改造できるようだ。

逆に、Spotifyのメリットもある。上に書いたこと以外に、以下のようなことがある。

  • サービス
    • 初出年が概ね正しい。(GPMよりずっと正しい)
  • Linuxアプリ
    • 検索結果の最大表示数が多い。
    • アタッカ(メドレーのように、2曲が切れずに繋がっていること)がちゃんと繋がる(今まで試した曲では、GPMで切れていたものも切れなかった)。
    • 演奏者などの情報も見られる。

数は少ないが、欠点を補って余りある。それらもSpotifyが音楽的だと感じる所以だ。

と、ここまで書いたら、当時結構好きだった"Overnight success"が終わったところで、無慈悲な鉄槌を下されてしまったw いや、無料プランの上限(15時間/月とのこと)に達してしまって、次が聴けない・・・ 無料でも無制限じゃなかったのか?? 広告を出してないからか。まあいいや、あとでプレミアムに申し込もう。そして、さっさとGPMを引き払おう!

最後に題について少し説明すると、僕はGPMをいじって遊びたかった訳ではなく、普通に音楽を楽しみたいがために散々苦労していたのだ。その原点に立ち返れば、これまでの苦労をきれいさっぱりドブに捨ててでも、Spotifyに移る価値があると思っている。だから、今までの実績(だかなんだか)があってもなくても、それに固執せず、原点に立ち返って、何が本質かを再確認するのは重要だと思う。と、ちょっと意識高そうなことも書いてみたw

 

PS. 早速プレミアム会員を申し込んだ。最初は100円/3か月なので、結構お得だ。なお、このキャンペーンや通常の最初の30日間無料試用は、以前試用をしたことがあると適用されない。僕も、新規アカウントを作り直したのに、そのパターンになってがっかりしていた。が、どうやら支払い口座(例: クレジットカードの番号)で判定しているようで、別の方法で支払うことにしたら、無事100円になった。ちょっとセコいが、まあ、チートして無料で使い続けるよりはマシではないかw (5/31 4:47)

  • My Generation: '80s, a pl…

    My Generation: '80s, a pl…

    多様化していた80年代の日本音楽シーン。初頭はテクノがあり、後半はバンドブームがあり、そしてディスコ…

  •   0
  •   0

5/22(US時刻)に、USなどでGoogle Play Music (GPM)がYouTube Musicに統合された。日本もそのうちそうなるらしい。4月下旬のニュースでは「Google Play Musicが年内に終了」などどいうセンセーショナルな見出しでびっくりしたのだが、中身を読むと、実際には上記のようなことで、全然「終了」ではない(それどころか、実質的には名前が変わった程度)のだが、記者が無知なのかアクセス数を稼ぎたいのか知らないが、大げさな見出しになっていた。(→ 先週、より正確なニュースがあった)

僕は、GPMが終了することはまずないと信じていたので(というのは、これくらいのサービスは、Googleのパワーやリソースをもってすれば、全然問題ない(Spotifyは結構辛そうな気がする)。逆に、投資に比べて利益(お金以外も)が多そうだ。)、それについては全然心配しなかったのだが(仮に終わりになっても、Spotifyなどの代わりがあるから、お気に入りの曲・アルバム一覧などを保存して、移るだけだ)、ちょっと気にあることがあった。それは、GPMをYouTubeに統合するために、システムの内部構造が多少変わる可能性があり、その変化の影響で、今僕がgmusicbrowser (GMB)でGPMを聴ために使っている、gmusicapiなどのプログラムがうまく動かなくなったら、GMBでGPMが聴けなくなって不便を強いられるのではないかという心配だった。その後、疲れのせいかちょっと調子が悪くて余裕がなくて、たまたま、移行した頃から家ではGPMを聴いておらず、移行の件もすっかり忘れていた。

そして今朝。たまたまGPMを掛けたら、なぜか再生できなかった。アプリを再起動したり何度試しても駄目で、無事死亡した。ログを見たら、HTTPエラー403(Forbidden)で曲取得用URLの取得に失敗していた。最初は、自分のPCのLinuxの更新でPython(gmusicapiを動かすプログラム)やgmusicapiを駄目にしたかとか、GPMの認証がおかしくなったのかと思ってその辺りを調整してみたが、駄目だった。それからGPMが移行したことを思い出して、それに関係しているのかも知れないと思った。そして、苦労して作ったシステムが、気付いたら音もなくバベルの塔のように瓦解してしまっていて、また一から作り直しになるのかと、結構重苦しい気分になった。

HTTPエラーが出ていることから、GPMの通信手順がちょっと変わったのかとか、曲のURLを取得するためのURLが変更になったのかと思った。それで、gmusicapiを最新版にしたり、AndroidのGPMアプリの中に新しいURLが書かれていないか調べたが、前者は効果がなく、後者は見当たらなかった(アプリでは使っていないのか、別のページからリダイレクトしているのか)。あとは、参照するDNSサーバを変えてみたり、locale(言語)を変えてみたりしたが、効果はなかった(思い付いて試してみたのだが、まあ、効果がなくて当たり前だ)。

そこで、試しにパスワードを異常なものにしてみたら、別のエラー(HTTP 401だったと思う)が出たので、認証自体は問題なく通っていることが分かった。また、gmusicapiを使ってGPMの曲の検索をしてみたら、正常にできた。要は、本当に、曲のURLを取得する要求(だけ)がハネられている(Forbidden)なのだ。

それで、いつから駄目になったのか(いつまでちゃんと使えていたのか)を調べたら、5/23の6時頃までは正常に再生できていた(それが最後だった)ことが分かった。切り替えがUS時刻の5/22 0時だったとしたら、それは日本時間の5/22 13時前後だから、切り替え後しばらくは使えていたようだ(ここは不思議だ。切り替えはUSの午後から夜だったのかも知れない)。

八方塞がりになったので、検索してみた(Googleだと「自サービスに関する望ましくない情報」としてブロックされている可能性があったので、Bingも使った)のだが、ほとんど出て来ないので、まだ誰も困っていないようだ。それから、gmusicapiが公開されているサーバ、Githubの問題掲示板(Issues)を見てみたら、何となく、それらしいのがあった。スレッド名は以下である:

get_stream_url gives 403 with 'DEVICE_NOT_AUTHORIZED' for Mobileclient.FROM_MAC_ADDRESS #590

去年からの問題ではあるのだが、近頃になって3人が投稿している。そして、(現時点で最後の)fizzybunkという人の投稿を読んで確信した。近頃(移行に関連して?)、曲のURL取得要求を出す時に指定するデバイスIDには(正しい)AndroidデバイスのIDを指定する必要があり、それ以外はエラー403になるようになったようだ。以下に主要な部分を載せる:

I even have tried using a valid android device_id that is registered with the account, seems the only way I am able to get Mobileclient.get_stream_url() to work is being logged into the account on the mobile app with the device of the device_id at the same time. Otherwise it is throwing a 403 error.

今までは、(デフォルトの、)PCのMACアドレスから生成した仮のデバイスIDが使われていたのだが、それでは駄目になったのだ。それで、今使っているスマフォ(AQUOS)のデバイスIDを指定すれば動きそうだとは思ったのだが、とんでもないヘマをしたらAQUOSでも聴けなくなってしまう可能性もあったので、まずは、iPhoneのIDで試したが、駄目だった。

それどころか、iPhoneのGPMのアプリを動かしたあとでGPMのデバイス一覧を調べたら、今日からiPhoneは「PC」扱いになっていた。以前はスマフォ("iOS")だったのに、それとは別に、(ちゃんとしたGPMのアプリを動かしたというのに)PC扱いのデバイスが増えてしまった。GPMに登録できるデバイス数は10個までで年間に4個しか解除できないので、これは結構ひどい。iPhoneの人から文句が出そうだが、まだ誰も騒いでいないようだ。

他に試したことも全然駄目だったので、意を決してAQUOSのデバイスIDで試したら、嘘のようにちゃんと動いた。fizzybunkさんの書き込みは正しかったのだ。

(ほぼ一日を潰して、)とりあえずは復旧した。が、AQUOSのデバイスIDを使うことで、AQUOS側に影響が出ないとも限らないし(ただし、分身の術を使わない限りw、PCのGMBとスマフォで同時に聴くことはないので、競合の問題はない)、今後、更に別の変更がなされて問題が起こりそうで心配だ。前者については、もし問題が起こるようなら、昔使っていたNexus 4にGPMのアプリを入れて、そのIDを使おうと思う。※ 後者はGoogleの腹一つなので、全くどうしようもない。ただ、世の中には多くのGPMアプリが出回っているから大きな変更はできないはずで、今回のようなちょっとしたことであることに期待する。

※AQUOSのデバイスIDを使って曲のURLを取得していると、AQUOSがすぐに(数時間以内)Googleからログアウトしてしまって不便なので、Nexus 4のIDを使うことにした。この問題はGithubの別のスレッドにもあったので予期してはいたが、いろいろな落とし穴が多そうだ・・・ (5/28 6:15)

ただ、本当に駄目になってしまったら、新しい曲の取り方を探すか、別のサービス(例: Spotify)に移ることを考えることにする。だが、仮にSpotifyに移ったって、通信手順などは非公開なので、曲にアクセスするためのプログラムはやっぱり第三者がリバースエンジニアリングで作ったものだから、いつ動かなくなっても不思議はない。だから、サービスを移るのはそれほど本質的でなさそうだ(ただ、SpotifyにはLinuxのアプリがあり、GPMのブラウザよりは使いやすそうなので、GMBで全然聴けなくなってしまった時に移る先としては、意味がある)。

まあ、結局のところ、Google様が心変わりしないように祈りながら音楽を聴く程度しか、できることはなさそうだw

 

PS. それにしても、今回の変更で、日本、いや、世界中で、ものすごい数の人が「あれー!? 再生できない?」って言いそうなものなのに全然そうでないってことは、LinuxでGPMを苦労工夫して聴いている人は、本当に少ないってことのようだ・・・

  •   0
  •   0

スマフォでGPMを聴くが、音量は「最大」にしたら何とか足りたものの、(グライコで調整しても)音が悪くて不満。そこで、ふと思い付いて、仕事用に持参したノートPCでテザリングして聴こうとするが、インストールしていたVivaldiやFirefoxではFlashプラグインがどうのこうので、結局、Chromeをインストールした。いろいろ手こずったが、今はいい音でK.488が聴けているので、満足。やっぱり、こうじゃなきゃダメだ。

それにしても疲れたw

PS. もちろんポリーニで、寝る前の締めだ。

(3/29 20:22追記) 昨夜、PCをスリープにしておいて今朝復帰させたら、電池残が半分以下に減っていた。それで小一時間聴いたら、もう電池がなくなって停まってしまった(こうなるとは思ってなかったので、ACアダプタは部屋に持って来なかった)。まったく、重くて大きいだけのダメPCだ(某林檎社製)。仕方ないので、続きはスマフォで聴いた。スマフォにしても、テザリングすると電池消費率が大きかった(約10%/h)。

まあ、それは仕方ないのだが、思い付いたことがある。大抵のホテルには外部入力端子付きのTVがあるから、ケーブル(ミニ-ピンまたはミニ)を持って行けば、TVに繋いで音楽が聴けそうだ。これなら音質は問題ないし、テザリングは不要なので電池に優しいし、クソ重いPCを持って行かなくても大丈夫だ。次回は是非試そう。

 

(3/31 7:11 少し加筆)

PS2. 実は、少し前までは、音量不足と音質を改善するため、ポータブルスピーカーを買おうと思っていた。が、スマフォにケースを付けたら音量が大きくなったように感じられ、音質も少し良くなったように感じられたし、イコライザアプリを見つけたし、スピーカーは結構大きくて重いので、持ち歩きたくなかったので、「次回」(=今回)試してから決めようと保留した。

そうしたら、軽くてかさばらず、0円で済むケーブルのアイデアが出たのは、大変ありがたい。野宿などしないので、大抵は問題ないw あ、実家はケーブルを伸ばさないと駄目だし、寝る部屋にはTVがないな・・・ (3/31 7:19)

  •   0
  •   0

さっきから、Arie Vardiという人のK. 488 (1988?)を聴いている。最初は素直な感じで悪くなかったのだが、段々、気に入らなくなってきた。1楽章のイントロは良かったのだが、その後はちょっと慌ただしい感じでもったいない。深みも少ない。実は、忘れていたのだが、この演奏は以前聴いていたようで、thumbs upしていたのだが、取り消した。逆に、downにしたいくらいだ。

僕は、この曲の2楽章終盤の寂しいピアノが好きなのだが、この人のはちょっとおかしく、サーカスみたいに(ラフマニノフのピアノ協奏曲 第3番 第2楽章後半にそんな箇所がある)なって、場違いで台無しになっていた。。。 3楽章だって、もう少し流麗に弾いてほしい。曲に負けているよ。(今気付いたが、この人、弾き振りしている。ピアニストの弾き振りは大抵失敗するんだよね。止めときゃいいのに・・・)

と、がっかりすることも多いのだから、K. 488だったら愛聴のポリーニのにしておけばいいのに、僕はなぜ、新しい演奏を探すのだろうか。良くは分からないが、変化とか「もっといいもの」を求めているのだろう。まったく、自分で弾け(き)もしないのに贅沢(高望み)もいいところだ!w

でも、今は、GPMのおかげで、この程度ならいくらでも贅沢できるのだから、本当にありがたいことだ。

  •   0
  •   0

唐突に(いや、詳しい方は知っていたのだろうが)、AmazonのMusic Unlimitedという音楽配信サービスが開始された。どういう訳か、他社と横並びの「4千万曲」(これ、誰かちゃんと数えたの?)のライブラリと月約千円(プライム会員でない場合)だそうだが、とりあえず、試す価値はありそうだ(30日間試用可能)。

一番気になるのは、レパートリーの広さと音量の正規化ができるかだ。あとは、ラジオの質だろうか。それから、手持ちの曲のアップロードができれば、更に良い。

でも、おそらく、Linux(正確には、非純正のプログラム)からは使えないだろうから、すぐに移行するメリットはないだろう。が、GPMが駄目になった時に移る先が増えたことは喜ばしい。

(11/9 7:54 追記) 昨夜、(入会しない範囲で)試してみた。その結果、いくつかいい点はあるものの、すぐにGPMから移行するほどではないことが分かった。

長所

  • Webで、検索結果が100項目以上出る(GPMは最大100項目)。
  • 言語の切り替えが可能(web)。
  • 初出年が正しいことが多い(℗の年が書いてある)。
    • ただし、発売日が℗の前日(=前年の大晦日)になっている(web)。これは、不要な時差の計算(UTC → JST: 9時間引く)をしているためのようだ。
    • 例: "℗©1983"なのに、"発売日: 1982/12/31"

短所

  • 非純正も含め、Linux用のアプリなどは全くない(webでアクセスするのみ)。
  • 音量の正規化機能はない。
  • 手持ちの曲のアップロードは250曲まで無料? (入会していないので、確認不可)
  • レパートリーはGPMに負けていることが多い。たまにGPMより多いことがある程度。
    • ただし、GPMは検索結果数の制限(100)で、全部は出てこない。
  • GPM同様、小泉今日子、キャンディーズ、小林道夫、クロマニヨンズやRushの"Power windows"など、ないものはない。
  • 検索はイマイチ。
    • 例: "serkin mozart"では一部しか出ない。
  • Webのテキストのコピーができない。

結論

Amazon Music UnlimitedはGoogle Play Musicより良い訳ではない。

 

(11/10 7:32 語句を変更)

PS. 上記の「不要な時差の計算」はどうもおかしいことに気付いた。UTCからJSTに直すなら、9時間足すのだ。純粋なバグ(例: ℗の年をローカル時刻(JST)と想定し、発売日をUTCで出そうとしている?)か、もっと深い変なことをしているのか。まあ、変なことは確かなので、何でも構わない。言えるのは、

Amazonよ、見えるところくらいちゃんと確認しろ!

だ。 (11/10 7:39)

  •   0
  •   0

土曜にちょっと思い付いて始めたことが結局無駄だったので、週末を潰した。まあ、雨だったし、外出しない予定だったからいいけど、ちょっと気分が悪い。

やりたかったのは、以前から気になっていた、GPMの曲に初出年が入っていない(GPMのページに表示されている年も誤っていることが多い)ので、自分で付ける仕組みを作ることだ。

これが意外に奥が深かったのと、GPMのお節介のせいもあって、意外に難しかった。基本的には、曲・演奏情報の公開DB(今回はMusicBrainzを使おうとした)で検索すればいい。が、そもそも、演奏者名、アルバム名、曲名で検索すると複数の候補が出て来て、どれが「正しい」かの判別が難しい。例えば、同じアルバムが再発された場合である。その場合は最古のものを選べば正しい可能性が高い。一方で、クラシック音楽の演奏のように、同じ人が同じ曲を何度も録音して、同じアルバム名で発売している場合、最古では正しくない。また、ライブ盤の区別もする必要がある。

更に、GPMは表示のモード(日本語/英語)によって、前記の情報をローマ字(英語モードの時の日本語の曲)や片仮名(日本語モードの時の海外の曲)にしてしまうことがあるので、演奏者名などでの比較すらままならないことがある。

かなり苦労して、年を取得する手順・方法は見つかったのだが、やっぱり最後は複数候補の判別が困難なことが分かったので、正式な実装・採用は止めた。

基本的には、音響指紋(fpcalcやffmpegなどのプログラムでAcoustIDが計算できる)を使うことで、ある演奏から、演奏者名と曲名の特定ができる! と思ったのだが、再発などによる複数の候補が出てくるうえに、意外に重複するようで、あるAcoustIDで検索すると、別の人の全く違う曲(演奏)も出て来る(処理時間やデータ量による制限なのだろうが、これで本当に「指紋」と言えるのか?)。そのため、指紋以外に、演奏者名や曲名などでの判定も要ることが分かった。

その場合、上記のGPMのローマ字・片仮名問題以外に、一般的な問題もある。例えば、同じアルバムなのに、異なる名前・表記になっていることがあるのだ。具体的には、リマスター盤のアルバム名や曲名の最後に"(2009 Remaster)"のような文字列が追加されていることが多いが、それが、GPMとDBで記載方法が異なっているのだ。元々、正式には付いていないものなので、どちらが正しいとも言えないし、正式な曲名にも付いていることがある(例: 森高の「ザ・ストレス (ストレス中近東ヴァージョン)」)ので、"("や"["以降を全部無視すればいい訳でもない。そもそも、リマスター盤の初出年をいつにするかも難しい。更に、名前の中の記号の表現が異なる場合(例: "~"と"〜")もある。演奏時間も使えると思ったが、実際には、微妙に(1秒前後)異っている場合が多いので、単純には使えない。

(10/30 21:16追記) リマスターで思い出した。更に重箱の隅をつつく話なのだが、リマスター盤の年をいつにするか(オリジナル盤の発売年か、リマスター盤の発売年か)は、まあ、オリジナル盤の発売年がいいだろう。が、良くリマスター盤のボーナストラックとして、当時未発表だった曲("Previously unreleased" tracks)が入っていることがある。それの年は、いったいいつにすればいいのか?

初出年=初めて発売(リリース・公開)された年という原則では、リマスター盤の発売年が正当だが、それではどうも納得できない。下に書いたように、「これが出た(出てないけど)頃は*してたなあ」や「世の中は*だったなあ」とか思えなくなってしまうのだ。逆に、その曲を録音した年にすると、公開されてもいない年を「初出年」にするから、捏造のようになって、記録の信頼性が下がってしまう。なので、今は、原則として、初公開のボーナストラックはリマスター盤の発売年にしている。なお、ライブ盤は、録音された時に演奏が公開されたのは確かなので、かなり後年に発売された場合には録音=演奏された年にしている。

まあ、記録というのは、本来、情緒とは正反対のものなのだろうから、割り切って、全部、その盤の発売年に統一すればいいのだろうが、趣味のものなので、何とも割り切れない状況が続いている。そして、この問題は、GPMに限らず、CDを買った場合に常に起こ得るので厄介だ。

この問題の原因は、初出年は単なる記録なのに、情緒を絡めていることなのだと思う。更に、「初出」としているからややこしくなる訳で、純粋に「リリース(発売)年」にすればいいのだろう。そうすれば、再発盤だってそれが発売された年にすればいいので、何も悩む必要はない。だから、単純に発売年にしているGPMのやり方は、規則が統一されているという点で、実は正当なのかも知れない(そして、これは、西洋人にはごく自然な論理的な思考から来ているのかも知れないと考えるのは、買いかぶり過ぎか)。ということは、僕は何も悩む必要がなかったのか? (そうではないと思うが) 全く奥が深い・・・

ローマ字や片仮名での表記は、ある程度は「別名」としてDBに入っているのだが、やはり、GPMとDBで異なる場合(例: The Beatlesの片仮名表記は、MusicBrainzでは「ザ・ビートルズ」、GPMでは「ビートルズ」)があって、判定は容易ではない。

そもそも、GPMがちゃんと年を入れてくれればこんな苦労はしないのだが、彼らも多くの人も、こんな些細なことには無頓着なのだろう。確かに、演奏が聴けることが一番重要だ。

では、なぜ演奏の初出年が欲しいかであるが、僕の物好きとしか言いようがない。もちろん、曲や演奏の良し悪しに背景は無関係と思っているのだが、聴きながら、その曲がいつ頃演奏・発売されたのかが分かると、同じ人が同じ曲を複数回録音している場合の違いから、「この人は、*年間でこんな風に成長(退化)したのか」とか思うことがあるし、「これが出た頃は*してたなあ」、「世の中は*だったなあ」とか思えば親近感が湧くような気がするし、郷愁にふけることもできるではないか。物好き以外に、特にクラシック音楽では、(このブログで書いているように)他の人に伝える場合に、「※の*年の版」と指定しなければ正しく伝わらないこともある。

そんな訳で、今はやりのAIを活用して、曲(演奏)を入れたら、音だけでなく、歴史的な情報(webはもちろん、過去の出版物など)を使って考証して、一発で正しい曲・演奏情報(メタデータ)を出してくれるシステムが欲しくなった。誰がいつ何を演奏・発売したという「事実」は、それほど多くのバリエーションは生じないだろうから、文章を理解できるAIに演奏家の経歴などの資料を片っ端から読ませればできそうではないか。Googleなら、やる気を出せばすぐにできるだろうが、こんな情緒的・ニッチなことに価値を見出さないだろうから、まずやらないだろうw

書いていて、「これはドクが西部劇の時代に作った製氷機(大山鳴動して氷一個)だ」と思ったw

更に、現実のことを考えると、GPMの曲(演奏)は一過性のもので、その時聴いたら終わりで、長く残る訳ではないのだから、こんなに手間を掛けて年を自動で付ける(しかも正しいとは限らない)なんてペイしない(元々曲名や演奏者名などは付いているのだから、それで充分だろう)。気になったら自分で調べれば良く、買ったものだけは詳しく調べて付ければいいのだ。が、そこは技術者の性で、理論的にできそうなことや、自分でやると手間が掛かるけど自動でできそうだったら、その仕組みを作りたくなってしまうのだろう・・・

  •   0
  •   1

GPM(Google Play Music)が思ったより使える。基本機能はもちろん、"I'm Feeling Lucky"ラジオ(何か分からないが、その人の好きそうな曲を掛ける?)もいいことが分かった。数日前、聴きたい曲もラジオも思い浮かばなかったので試してみた。最初の頃に試した時は、予想通り、クラシック音楽が楽章ごとに混ざっていたので、「邪道だ!」と思って使っていなかったのだが、その時は考えるのが面倒だったし、「一楽章だけでも、新しい曲や演奏を試すのもいいか」という気分になったのだ。

実際に聴いてみると、確かに全曲でないのは嫌だが、それぞれの作曲家や演奏者の特徴が分かる場合があって、意外に良かった。まあ、好きでない作曲家に関しては、今までのイメージが覆ることはほとんどない(例: パガニーニは時代がかった感じ、ベルリオーズは苦手、プロコフィエフはやっぱり変、ワーグナーはダサい)のだが、たまに、今まではほとんど聴かずに敬遠していたけど、実は結構いけると思う人(曲)があった。以下に例を挙げる。

  • フォーレ バイオリンソナタ 第1番 (第4楽章): 結構いい。
  • フォーレ 「夢のあとで」: 綺麗でいいかも。
  • ハイドン ピアノソナタ 第37番 作品30-3 (楽章不明): モーツァルトに通じるものがあって、馴染める。
  • ハイドン ピアノソナタ 第43番 作品41-4 (楽章不明): 聴き応えがある。

上を見ると、新たにフォーレやハイドンを試すのも良さそうだ。が、やっぱり、何となく面倒ではあるw それにしても、フォーレはどこから出てきたのか??

また、演奏者についても、いくつか再発見あるいは印象の変化があった。

  • ソコロフ: シューベルト 「3つのピアノ曲」 (第3曲)では、キレやパワーや広がりがあっていい感じだったが、別の曲(ゴルトベルク(ライブ))では、アクが強過ぎるのか、なんか疲れて飽きた。
  • キーシン: 基本的に遅すぎるイメージがあるのだが、「展覧会の絵」 (「バーバ・ヤーガ」)は結構良かった。

掛ける曲は、今までに「いいね!」(Thumbs up)したものやライブラリに保存(「お気に入り」のようなもの)したものや再生回数が多いものの傾向(作曲家、演奏者)から判定しているようだ。更に、どういう条件なのかは不明だが、クラシックだけでなく、ポップ音楽も掛かる(しかも、クラシックとポップ音楽が混ざらないのがありがたい。ラジオの再生を開始した時点で、どちらになるかが決まるようだ。)ので、なかなかおもしろい。

GPMには数千万曲もあるから、聴きたい曲・演奏が決まらない時や、知っている曲・演奏に飽きた時には丁度良さそうだ。旅行に例えれば、基本的には自分で全部決めて運転するドライブがいいが、たまには、行き先不明で、何も考えずにただ座っていれば(寝ていても)、「どこか」に行ける、ミステリー・バス・ツアーもおもしろいようなものだ。

PS. こういうところは、GoogleはSpotifyよりはるかにまともだと感じる。Googleは、昔(検索で始めた時)から、こういう機能をことさら宣伝せずに、淡々と(ある意味余興なのかも知れない)作って出すが、決して押し付けない。その点は当時から評価していた。ただ、「もう(飽きたから?)止めるので、別のを使ってね」が多いのは困るがw

一方でSpotifyは、全然使ってないのに勝手に「あなたのためのプレイリストを作りました!」などというお節介なメールを(解除しているのを無視して)押し売りのように送りつけてくる(しかも、最初の頃に見たら、そのリストの中身は全く的外れだった)。文化・センスの違いが大き過ぎる。例えれば、GoogleはUnix系、SpotifyはMicrosoft系だ。

  •   1
  •   0