piu lentoの日々

試用期間はあと1週間くらい残っているが、もう、音楽配信サービスはGoogle Play Music (GPM)で決まりだ。

実は、この週末辺りにも、サービスに入る意味(価値)を再確認したり、「実は、(良く調べれば)Spotifyがいいんじゃないか?」と思ったりした。それで、いろいろ調査したために、今日はドライブを延期する羽目になってしまった。

まず、僕にとっての音楽配信サービスの用途・メリットは、以下のようなものだ。

• 新しい曲を探すツールとして。
• クラシックの特定の曲の好きな演奏選び用
• (昼休み、帰省、旅行・出張時に)暇な時に聴く
• 「無制限の試聴」、あるいは、「無駄にCDなどを買うのの防止」
• ダウンロード版を買う前のマスタリングや音質の確認用

これだけでも充分と思う。が、最初に大いに期待した、CDの置き換え(撤廃)については、キャンディーズや小泉や昔のRushがないなど、意外に揃ってないので、僕にとってはまだまだである。でも、事務的な問題だろうから、あと数年で完備するのではないかと思っている。

あと、車で聴きたいものやずっと手元に残しておきたいものは買う必要があるのも、最初の期待からは外れる。ただ、購入前の確認ができるので、以前諦めた、CDからダウンロード購入への移行が再び可能になるので、悪いことばかりでもない。

よって、音楽配信サービスに入る価値は充分あるという結論になった。

次に、「本当にGPMがいいのか」という点でも迷いが生じたので、再度、Spotifyを使って機能を比較したり、レパートリーの広さを比較し直してみた。

まず、機能の比較については、概ね以下のようになった。

Spotify

• 長所
  • 書誌(初出年など)が正確
  • 100以上の検索結果が出る。
• 短所
  • 行動(例: 聴いた曲)やプレイリストをデフォルトで公開する(例: ユーザー名で検索できて、聴いた曲が表示されてしまう)。
  • 日本の懐かしいポップスなどのラジオ・プレイリストはほとんどない。
  • アルバム情報の編集ができない。
  • 純正アプリは駄目(随分前から要望があるのに、改良する気がない)
    • 日本語の入力不可
    • 表示テキストのコピー不可
    • ジャケット画像の拡大表示不可 (再生中のものだけ可)

GPM

• 長所
  • 日本の懐かしいポップスなどのラジオが充実している。
  • アルバム情報の編集ができる。
  • 行動(例: 聴いた曲)やプレイリストをデフォルトで公開しない。
  • リコメンドが結構いい。
• 短所
  • 書誌(初出年など)が不正確、情報が少ない。
  • 外国の曲の邦題、カタカナ表記の外国アーティスト名が嫌 (例: GPM ⇔ Spotify)
  • 100以上の検索結果が出ない。
  • Linux用純正アプリがない。Webでの使用が基本。
  • サードパーティのアプリ(GPMDP)はまあまあ(というかイマイチ)。

明らかにGPMが優位だが、特に、日本の懐かしいポップスへの対応(これはSpotifyには永遠に無理だろう)、プライバシーへの配慮(SpotifyはGoogleよりひどい)、アプリなどに見られる見識の普通さ(Spotifyが低過ぎる)、そして、(将来)YouTube Redも使えることが期待できるのが、僕にとっては重要だ。

なお、GPMの短所のほとんどは自力で解決できる見込みが立った。

• 書誌(初出年など)が不正確 → SpotifyやDiscogsやAllMusicなどで調べる(なお、MusicBrainzはほとんど役に立たない)。
• 邦題、日本語(カタカナ)の外国アーティスト名 → アプリでなく、webなら言語を指定できるので、英語表示にできた(URLを https://play.google.com/music/listen?hl=en のようにする)。こうすると、日本のポップスも英語やローマ字になってしまうが(例)、外国の音楽が英語や原語で表示されることのほうが重要なので、英語表示にすることにした。なお、どういう訳か、英語表示でも日本語で表示される日本のポップスがある。
  • (9/13 21:40追記) その後、web(ブラウザ)であれば、タブを2つ使うことで、英語と日本語の両方を表示することができることに気付いた。
• 100以上の検索結果が出ない。 → サードパーティのライブラリ(gmusicapi)を使ったプログラムを使って(作って)、かなり多くの検索結果が出せるようになり、GPMのレパートリーの広さをかなり正確に調べることができた(後述)。
• GPMDPがイマイチ。 → 中身はwebそのもので、GPMDPは外枠を作っている程度で、バグもあるので、リモコンを使うなど外部と連携させる場合などを除き、使う意味は余りない。逆に、ブラウザでweb版を使う場合、マウスジェスチャでページ移動ができるので便利だ。ただし、Vivaldiではミニプレーヤーが出ない問題があるが、元々それほど有用でないので、大きな問題ではない。
  • (9/13 21:36追記) その後、GPMDPでマウスジェスチャが使えるようになった。Easystrokeというソフトを使い、戻る(キー: BS)と進む(キー: Alt+→)にジェスチャを割り当てた。
  • また、暫定的だが、英語表示ができるようにもできた(例)。具体的には、~/.config/Google Play Music Desktop Player/json_store/.settings.jsonの中のlastPageというメンバにGPMDPが最後にアクセスしたページのURLが格納されているので、その"?"の後に"hl=en&"を追加して(例: "https://play.google.com/music/listen?hl=en&pli=1#/home")、英語版にしてGPMDPを起動すれば良い。
  • GPMDPは資料やソースが公開されているため、プログラムの変更や内部データへのアクセスがしやすそうなので(実際、上記の暫定英語表示はそれでできた)、改良(カスタマイズ)のベースにしようと思っている。

最後に、レパートリーの広さを再確認した。以前調べた時は、GPMは100以上の検索結果を出さないため、曲によってはSpotifyの方がアルバム数が多い(多く見える)場合があったが、今回は、調べたすべての場合で、大差でGPMの方が多かった。以下に結果の抜粋を示す。

• モーツァルトのピアノ協奏曲 第23番 (K.488)のアルバム数
  • GPM(以下、G): 459
  • Spotify(以下、S): 211
• ラフマニノフのピアノ協奏曲 第3番のアルバム数
  • G: 388
  • S: 101
•  ビートルズのアルバム数
  • G: 52
  • S: 23
• クイーンのアルバム数
  • G: 57
  • S: 35
• グールドのアルバム数
  • G: 231
  • S: 201

もちろん、音楽は数が本質ではなく、GPMには重複が多そうだが、それにしても違いが大き過ぎるので、レパートリーの点でSpotifyを選ぶ理由はないだろう。

なお、GPMは検索結果が100までしか出ないため、普通に使っていては、上記のような広大なレパートリーをフルに活用するのは難しい(例: 知らない演奏者は検索に指定できないから、存在を知ることができない場合がある)。この点は、GPMの検索の仕様が改善されるまでは、後述のような外部の検索プログラムを使う必要がありそうだ。

以上より、僕にとってはGPMがベストで、Spotifyは次点以下で、言ってみれば、GPMのサービスが終わってしまった時に「仕方なく入る」程度のものとなった。

PS. 近頃、なぜか、GPMのラジオ(日本の懐かしいポップス関係)で斉藤由貴の「卒業」がよく掛かる。今日で通算6回目だ。不倫スキャンダルに同期しているのか、単に人気があったから良く掛かるだけで、考え過ぎかｗ (9/11 19:41)

参考: gmusicapiを使ったGPMの検索プログラムについて

gmusicapi-scriptsのgmsearch.py(GPMの自分の「音楽ライブラリ」を検索するプログラム)を改造し、gmusicapiのMobileclient interfaceの検索関数(search())を使って、GPM全体から検索できるようにした。search()では、曲名以外にアルバム名などでの検索結果も取得できるので、アルバム名を使って、ある曲が含まれる、あるいは、あるアーティストのアルバム一覧が取得できるようにした。改善すべき点は多いが、以下のような形式で検索を実行する。

グールドの全アルバム(共演は含まず)を検索する場合: python3.5 gmsearch_b.py -u User -p Password -Q "Glenn Gould" -t al -f 'artist:^Glenn Gould$' -y

↓ 出力例

1. Glenn Gould "Bach: The Goldberg Variations, BWV 988 (1981) - Gould Remastered" (2008) [-, B6nyodkgdszrcbq2kih4ebl3qry]
:
230. Glenn Gould "Glenn Gould plays Richard Strauss: Ophelia Lieder op. 67; Enoch Arden op. 38; Piano Sonata op. 5; 5 Piano Pieces op. 3" (2012) [-, Bi4h5u7bbiqaca2mwgxtqah3zyq]

※行末の英数字は、GPMでのアルバムID。

このプログラムは、webやアプリでは省略されている曲やアルバムなどの情報(例: ディスク番号)や情報の内部形態をそのまま取得できるので、大変有用だと思う。ちなみに、この情報には再生ゲインは入っていないので、近いうちにGPMが音量の正規化に対応することはなさそうだ。

なお、search()の結果の最大数は、gmusicapiの資料では100だが、Noneを指定することで、最大1000までの結果が得られることが分かり(ただし、結果が長くなり過ぎると、途中で切れてエラーになる)、レパートリーの比較に役立った。この隠し機能がいつまで使えるのか分からないが、なかなか便利なので、なくならないで欲しい。

PS2. 今回、gmusicapiなどが使っているPythonというプログラミング言語を使う羽目になった。Perl以上に"awful"で、「使ってられない!!」と思った。が、流行っているようなので、まあ、僕が古いのだろう。それにしたって、インデント(段付け)をプログラムの構造にするって、本当にいい(論理的・効率的)のだろうか?

僕は、とてもおかしいと思う。というのは、そもそも、普通のプログラミング言語はテキストなのだから、段付けのような「見た目」よりも、論理的な構造で成立するものだと思うし、(目に見えにくい)空白の数の違いや空白とタブの混在にいちいち文句を言われたら、書く時に必要な注意が増えてストレスが高まると思うのだ。もちろん、プログラムの見た目を綺麗にすれば、分かりやすくなるから、それ自体はいいことなのだが、強制されたら苦痛だ。

段付け以外に奇異に感じたのは、ifやelseの行末の":"だ(下の例を参照)。「何これ?」って感じだ。空白の数(=見た目)で構造を定義しているなら、改行だってそのように使えばいいはずで、行末の印なんて冗長だと思うのだが、何か理由があるのだろうか?

if [type_mns[type]]:
    type_mn= type_mns[type]
else:
    type_mn= type_mns["so"]

※おそらく、上のプログラム自体はもっと簡潔に書けて、if自体不要になりそうだが、記述例として挙げた。

あと、Linuxなどの問題ではあるが、Pythonはバージョン間の違いが大きいせいか、特定のバージョンでしか動かないプログラムがあるので、複数のバージョンをインストールせざるを得なく、それぞれを区別しないと、プログラムがうまく動かない(上の例で"python3.5"と陽に書いているのはそのせい)とか、あるバージョンをアンインストールすると、システムが正常に使えなくなる問題があって、正直言って手を焼いている。