忘れるために書いています。コメントはお気軽に。
気付いたら、Spotifyのクラシック音楽のDaily mixのひとつが、ほとんど「春の祭典」、「展覧会の絵」、「パガニーニの主題による狂詩曲」の中の曲ばかりになっていた。
Spotifyのクラシック音楽のDaily mixの選曲が偏っている・・・
たしかにどれも好きだが、ここまで続けられると飽きるし、それぞれの曲は繋がっているからバラバラにされては困るし、ジュースじゃないのでミックスされるのも困る。
今気付いたが、その原因は、それらの曲はどれも短い曲・楽章・変奏が集まって一つになっており、当然ながら、僕はそれぞれの曲をいつも通して聴き、いろいろな演奏者のを取っ替え引っ替え聴き、しかも、好きな演奏の各小曲に♥(Like)を付けているので、僕がそこら辺を「すごく好き」とみなされて、このように推奨されている気がして来た。うむ。
そして、SpotifyはGoogleとかじゃないので、ここら辺のAI的な処理があまり賢くないのだろう。まあ許せる。
ルーティンワークｗでCeronの新着ニュースを見ていたら、「小泉今日子、全104タイトルのべ726曲が一斉サブスク解禁（コメントあり） - 音楽ナタリー」というのが目に入り、早速Spotifyをチェックしたら確かに入っていた。
ようやく小泉今日子の曲がSpotifyに入った。
でも、まあ、特に急いで聴きたい曲はないから、入っているのを見て「ふーん」と思っただけだが、少しして、折角だから とりあえず聴いてみようと思い、最新のベスト「コイズミクロニクル ~コンプリートシングルベスト1982-2017~」(2017)を試している。
演奏や音じゃないからいいけど、これのジャケットは「なんだかなあ・・・」である。この、昔の(ビットマップを改造して作った)ようなフォントは一体??※ どういう味を出したかったのか? あと、配信の画像では細かい文字が見えない。。。
※全くの余談だが、昔(1990年代前半)、LaTeXという文書整形システムを使っていたのだが、それに使えるフリーの日本語フォントがほとんどなく、X Window Systemの日本語ビットマップフォントを加工して使っていたことがある。今みたいに拡大・縮小自由自在のベクターフォントじゃないので、その字形は線が細かったり太かったり、線の横にドットがギザギザと出ていたりで、なかなかひどいものだった。偶然だとは思うが、ジャケットの「小泉今日子」の文字は、そのフォントにそっくりなのだ。
最初のほうの曲目は手持ちのベスト(「ザ・ベスト」(1986))と同じなので目新しくはないものの、やっぱり懐かしい。僕は、「まっ赤な女の子」(1983)辺りからリアルタイムに聞いていた気がする。と言っても、その頃はまだTVなどでちょっと聞く程度だった。なぜか力を入れ出したのは、何度か書いている"Today's girl"(1985)からだった。
このベストには、シングル(B面?)だけとか別名義で出した曲(例: あんみつ姫 「クライマックス御一緒に」(1984))も入っているから、手持ちになかった曲も聴けていい。
(ここまでの時点では)「渚のはいから人魚」(1984)、「渚のはいから人魚」(1984)、「迷宮のアンドローラ」(1984)、「ヤマトナデシコ七変化」(1984)、"The Stardust Memory"(1985)なんて、つい乗ってしまった・・・ (ほとんど全部だｗｗｗ)
余談: 「ヤマトナデシコ−」だと思ったが、たまたま観たTVの歌番組で、あんみつ姫の格好で歌ったのだが、お笑いの人(東八郎?)が一緒におかしく(茶化しっぽく)踊っていたので、最後に彼女がちょっと切れて「バカヤロー」って言ってたのを思い出す。その動画、あるかなあ・・・
そして、以前書いた山口百恵と違って、数百曲のうち聴きたいのは数曲ってことはなく、数十曲はありそうだ＾＾ うむ、そうだったか。
少し音質の話を書くと、聴き出した時から、なんとなく音質が違う(良い)気がして、リマスタリングしたのかと思い、調べたら本当にそうだった。手持ちに比べて細かい音もちゃんと聞こえるが、(特に海外に)良くあるリマスター版のように、低音や高音を出し過ぎて「いかにもいい音」にしていないのが好感が持てる。こういう真っ当なリマスターなら許せる。いったい、どうすれば こうできるのか、ちょっと不思議ではある。ビクターの(この盤を担当した)エンジニアは腕がいいのかも知れない。
例えば、「半分少女」(1983)は、高域はもちろん低域もいい感じになっている。"The Stardust Memory"は右の電子(電気)ピアノと思われる音が違う(より忠実な感じ)。「ハートブレイカー」(1985)は低域が豊かになり、全体的な迫力も増えている。「なんてったってアイドル」(1985)は高音(シンバルなど)が ちゃんと聞こえる(切れ味が鋭いが、うるさくない)。
気付くと、いくつかのことをばっさりと捨てていた。例えば・・・
その他に、速い車、自炊、自転車、プリンタ、手帳、紙の写真、賀状、見栄を張る・格好つけること、(無理のある・無意味な)人付き合いなど、書き出すと随分いろいろあるが、ここは文化・芸術的なことに絞る。そういうものではピアノを手放したが、諦めたからで、なくてもいいから捨てた訳ではない(ものすごい余裕があれば、大きなグランドピアノ(フルコンとは言わないが、(サイズとして)C7くらいは欲しいな)を眺めて暮らしたいｗ でも、見るだけじゃ詰まらないな。まあ、ご飯は進みそうだがｗ)。
映像は全く観ない訳ではないが、なくてもいい。そもそもTVもビデオプレーヤーもない。好きな映画はあるが、あらすじやシーンなどを思い浮かべたり、検索してちょっと見る程度でいい(おそらく、後述の脳内演奏同様、記号化されて頭の中に格納されているのではないか)。映像に近いものとして、劇は捨てたつもりはなく、機会があれば観たいが、「(手配とか面倒だし、大体分かったので)まあいいか」って感じだ。
それらの代わりに音楽があればいい。ただ、オペラは(僕には)要らない(やっぱり面倒だ)。聴くだけでいい。「脳内演奏」(演奏しなくても、「パブロフの犬」とかレモンや梅干しのような場合もある)でもいい※。更に無音があればいい。
※そういう意味では、以前やりたいと書いた「脳内演奏」はできている。脳内で完璧に演奏しなくても良くて(その必要はなく)、自分の好きな曲を見付け、その自分好み(本当は「作曲者の意図どおり」であるべきなのだろうが)の演奏を見付ければ、あとはOKだ。それ以上CD(演奏の記録)を買う必要も、コンサートに行く必要もない。だから僕にはSpotifyのようなサービスがとても合っている。今朝、散歩中にそういう結論になった(今はね)。
本は意図的に捨てたのではなく、「読めない身体(頭)」になってしまった。数行とか一ページくらいで、「じゃあまたあとで・・・」になってしまう。本の価値を否定する訳ではなく、読めれば読みたいけどやっぱり読めないし、(自分としては)それまでに随分読んだから、読まなくても「まあいいか」って気はある。
それについて大変思い上がったことを書くと、映像作品も文学作品もいろいろなパターンを知ってしまって、それ以上にすごいとか新奇とかおもしろいものがあるとは思えないのだ。音楽にも同様の感はあるし、それどころか、日々の生活ですらそうだ。いや、実際には新しいものはあるとは思う。僕の興味とか頭の硬化の問題だと思う。
そして、今のところ、絶対に捨てられないのはPCだろう(「スマフォでは駄目なんです。キリッ」ｗ)。以前も書いたが、そのことが非常時には結構なリスクになる気がする。とはいえ、PC一式をかついで避難することはできない(ノートPCも余り好きじゃないし、そもそも通信回線がない)ので、どうにもならない。
PS. そういう訳で、手持ちの映像作品のDVDなどは、ここ数年全く観ていないから処分したい気もするが、一応好きで買って思い入れもあったので、どうにも決断できない。その時は、ここ数年全く触ったことのないCDも一緒に、一気に処分したい。更に、心理的抵抗は岩のように大きいが、(プレーヤーすら持っていない)レコードも処分したい。そうしたら結構物が減るだろうな。
PS2. グランドピアノの価格を調べたら、意外に安かった。ヤマハのC7Xは350万円と、ちょっとしたいい車より安い。調律は要るが(弾かなければ不要だが)、ガソリンもオイル交換も不要だし、税金も保険も車検もないから、維持費も安そうだ(いやいや、実際には空調の効いた頑丈な部屋が要るけど)からお買い得だ。だけど、やっぱり、一台持つとしたら、兎にも角にもスタインウェイだろうｗｗｗ (すると、値段はきっと一桁上になるんだろうな・・・)
ちなみに、重さも車よりずっと軽くて、C7クラスだと400kgくらいしかない。軽より軽いじゃないか(爆)
(結構前に書き出したが、発展させるのが面倒になったのと、他のネタが熟成中なので、主に脳内演奏について加筆して公開した。)
ここ数日、「例のトリッキーなやつ」(先日の投稿の、Spotifyアプリのログから音量正規化のための値(RG値)を抽出して正規化する方法)が諦めきれず、悪戦苦闘していた。何度も諦めたのだが、そのたびにアイデアが出て来てしまって再挑戦する羽目になり、今日は随分いい感じになったのたが、やっぱり駄目だった。
記念(または証拠)に、最良の状態での動作光景を載せる。画面左上はRG値取得用Spotifyアプリ、右上はミュート(上側)・ゲイン調整+リミッター(下側)用アンプ、左下はミニプレーヤー、中央から右下は再生用Spotifyアプリである。曲間でのアンプの設定の変化や、プレーヤーの切り替わり(アプリ下部の緑の帯)に着目されたい(もちろん、手で操作している訳ではないし、マウスなどを自動操作するツールを使っている訳でもない)。
Spotifyアプリから音量正規化のための値を抽出して音量正規化している画面
動作の流れは以下である。
基本動作はできた※のだが、試しに少し(15分くらい)動かしていたら、RG値取得用アプリとSpotifyサーバの通信ができなくなってRG値が取れなくなってしまった。再生用アプリの動作は問題ないので、短時間(RG値取得用アプリに切り替わっている時間は約2秒)で切り替えるとうまく動かなくなってしまうのかも知れない。まあ、再生し始めたと思ったらすぐに切り替えるなんておかしな使い方を想定していないのはもっともだから、仕方ない。
※本方式での音量正規化処理自体は、全く問題なかった。性能(音量の揃い具合)はSpotifyアプリよりも良かった(とはいえ、大差ではない)。また、前回(「と思いきや」のあと)失敗した、プレビュー版のRG値とは異なる場合が多かったので、そちらには得体の知れない値が入っているようだ。
あと、不思議なことに、投稿用に動画を撮り直そうとして再度動かしてみたら、プレーヤー切り替えのタイミングがずれて※、曲間で余計な音(RG値取得中または曲の先頭に戻る前の音)が出るようになってしまった(上の動画はボツのテイクを投稿用に少し編集している。でも、ちゃんと動いていたのは確かで、夢や幻や捏造ではないｗ)。だから、SpotifyのアプリもWeb APIも、こういうタイムクリティカルな用途には無理があるようだ。
※アプリの切り替え時間(= RG値の取得・処理時間= 曲間)は最初は4秒くらいだったのだが、それでは遅過ぎるので(結構苦労して)高速化・最適化したら不安定になったようだ。元の遅い版ならもう少し安定なのだろうが、それでは気分が悪いｗ それどころか、最初は1秒以内にしたいくらいだった。
そもそも、(前回も書いたが、)これをやりたかった理由の一つはダイナミックレンジをなるべく減らしたくないことだが、再度計算してみたら、Spotifyの音量正規化のQuietモード(基準音量: -23LUFS)を使っても2ビットも落ちないことが分かった※ので、ポップ音楽でそこまでこだわる意味は全くないから無理する必要はない。
※先日の試算では、音量を-23LUFSにするのに23dB下げると考えたが、それは誤りで、SpotifyがRG値の計算に用いているReplayGainの基準音量は-14LUFSなので、(-14-(-23)=)9dB下げる程度であり、それは(9/6=)約1.5ビット相当である。
あと、RG値取得用アプリが駄目になる問題は、例えば、通信できなくなったらしばらく(数分?)待ってアプリを再起動すれば回復できるだろうが、たとえ自動的にするとしても、再起動されるまでは聴けなくなって気分が良くないし、音量正規化のon/off切り替え時にアプリを再起動したくないからこの方法にしようとしたのに、(再生用ではないけど)やっぱり再起動が要るのでは馬鹿らしい。それに、上に書いたように、タイミングが変動して安定して動かないのでは、とても実用にはならない。
そんな訳で、結果的には無駄なことをして疲れたが、いろいろ(細かい)発見があっておもしろかったせいか、余りがっかりはしていない。むしろ、事前の予想どおり駄目だったものの、基本的には目論見どおりに動作して満足したし、方が付いてせいせいしたｗ
最後に、開発中に分かったことなどを少し書く。
PS. それにしても、昨日(12/29)までは年末という気がしなかったのだが、今日(12/30)になったら急に「今年ももう終わりか」モードになって、妙に慌ただしい気分になってしまった。そして、「年末なのにプログラミングなんてしている場合かっ?」て気もしたが、特に他にすることもないので問題ないｗ
Spotifyの音量正規化の改良では散々試行錯誤したが、ようやく自分が納得できるかたちで実現できた。もちろん、結果(性能)も全く問題なかった。音量(Integrated loudness)の値は全く問題なかったし、随分聴いてみたが、(自作とは全然違って、)我慢できないほどうるさい曲(演奏)※も小さ過ぎるものもなく、随分手を焼いていた曲もあっさり大丈夫だった。これなら気楽に聴いていられそうで、ようやく目的が達成できた感じだ。
※正確には、「うるさい」と感じる演奏はある。が、その音量値は全く異常でなかった。ということは、音作り(周波数分布や音質の悪さ? いわゆる「海苔波形」?)によるのか、僕との相性が悪い(音の好みや聴覚のラウドネス特性とのズレ?)のだと思う。実際、不思議なことに、アンプの音量を小さくしていても、いつもうるさく感じる演奏はやっぱりうるさく感じる。つまり、「うるさい」は音量が大きいだけではないということだ。まあ、語義からしても当たり前か。
以下に試行錯誤の経過や内容を書く。
前回の投稿ではSpotifyの音量正規化のNormalとQuietを手で切り替えて使うと書いた。そして、前回も書いたが、音量を揃える(増やす)ために増幅してもそれほど音質が劣化しないことが分かったので、その方法を詳しく検討した。基本的には、単に(ソフトの)アンプで増幅すればいいのだが、使う要素(アンプの種類)や増幅する量を最適にしようとしたのだ。
まず、以下を試した。増幅量は+11dB(-23LUFSを-12LUFSにしようとした)にした。
PulseAudioでの増幅で音質劣化がありそうだったので、何種類かの増幅量で歪率を測定したが、オーバーフロー(0dBを超える)しなければ(+15dBくらいまで)は問題なさそうだった。それで、実際の曲で試したら、ポップ音楽でも意外にダイナミックレンジが広いようで、+9dBでも簡単にオーバーフローした。
それで、リミッターでオーバーフローしないようにすることにした。PulseAudioで増幅してオーバーフローすると、その時点で歪んでしまうので、あとにリミッターを入れても無意味なので、JACKのアンプ+リミッターの構成にすることにした。リミッターにもいくつかの種類があり、以下でオーバーフローさせて試したが、いいものは少なく、結局、Fast Lookahead limiterを使うことにした。これには入力にゲインがあって、それがアンプの役割をするので丁度良かった。
それから、Spotifyの音だけを増幅したいので、SpotifyのJACKへの出力を独立にし、更に、ポップ音楽用とクラシック音楽用で増幅をon/offする必要がある。
その前に、いつも評価用に使っている曲をSpotifyの正規化(Quiet)+増幅(+9dB)で試したところ、殆どのポップ音楽は問題なかったが、"Speak to me"は駄目で、Normalと同様な不自然さがあった。原因を調べたら、前回の投稿の付録に詳しく書いたが、オーバーフローがリミッターでカットされる時間が長いためだと分かった。それで、増幅量を+6dBに減らし、リミッターの回復時間を長く(2秒)にすることで不自然さを緩和した。回復時間を"Speak to me"の鼓動の周期より長くすれば、ずっと音量が下がったままになるので、不自然さが緩和されるのだろう。完璧ではないが、"Speak to me"のような曲は例外的だから許容できると考えた。ただ、他の曲が不自然になるかも知れないので、その時に調整したい(今のところは問題ない)。
結局、以下の3つのモードを作ることにした。
ポップ向けでの増幅量について: 通常のReplayGainで正規化する(あるいは、0dBまで目一杯出す)他のプレーヤー(具体的にはgmusicbrowser, GMB)と音量を揃えるにはなるべく上げる方がいいが、前述したオーバーフローによる劣化も嫌なので、試行錯誤(勘?ｗ)で決めた。+7dBだと、SpotifyのQuietモードでの基準音量 -23LUFSを-16LUFSまで上げることが期待できる(当初は+10dBして-13LUFSくらいにしたかったが、やり過ぎのようだ)。
3つのモードはミニプレーヤーのボタン(右端の"Sp", "S", "-")で切り替える。音量正規化の有無はSpotifyを再起動すればいいが(とはいえ、重いから避けたかったが、それ以外に方法がないので仕方ない)、JACKのアンプで外部から制御できるものがなかった(後述するように、実はそうではないが、当時はそう思っていた)ので、増幅の有無の切り替えが困難だった。それで、接続(配線)を変えることにした。簡単に書くと、以下のように切り替える。
なお、なるべくSpotifyを再起動しないで済むように、右クリックで音量正規化モードの切り替えを逆順にできるようにしたのだが、順番を覚えていないためにやっぱり再起動になる羽目になるので、マウスオーバーでガイドを出すようにした。
なお、プログラム(xdotool)でリミッター(アンプも兼ねる)のEnableボタン(中央付近)を押すことでも、増幅の有無の切り替えが可能なので試してみたのだが、勝手にマウスが動くと(その後自動で元に戻しても)結構ストレスに感じるし、その時の操作状態によっては誤動作・操作することもあるので止めた。
その後、モード切替のたびに接続(配線)を変えるのは全然スマートでないし、遅いし、JACKサーバへの負荷が重そう(頻繁に繰り返すとおかしくなりそうな気がした)なので、避けられないか考えた。それで、以下の2種類を順に試した。
MIDIについての特記事項を以下に列挙する。
それから、Spotifyの音量正規化(改良版)の性能を自作の方式と比較した結果を書く。双方で共通する38曲(演奏)について比較した。
判定条件
Spotify (Quietモード)+増幅 (ポップ音楽用: "Sp")
自作の方式 (ポップ音楽用: "Pk")
はっきり言って完敗である。Spotifyには不可(×)の曲がまったくなかったのには感心する。しかも、範囲内(○)に収まっている率が1.5倍と高く、音量のばらつき(音量の標準偏差)は半分以下、偏差の平均は1/7以下である。(数値的には)充分に音量が揃っていると言える。
ただ、負け惜しみではあるが、Spotifyは必要なデータを使って「普通に音量正規化(ReplayGain)をしている」のだから、良くて当たり前だとは思う。が、自作で情報(RG値)が不足した状態でいくら頑張っても勝ち目はないし、意味がないことは確かだ。
最後に、今回分かったことなどを列挙する。
これにて音量正規化問題は一旦終了!
一段落して、心置きなく気楽に音楽が聴ける。
と思いきや、、、毎度のことながら、そうは問屋が卸さなかったｗｗｗ
昨夜、複雑なために一旦諦めたトリッキーなSpotifyの音量正規化用の値(以下、RG値)取得の方法を、なるべく簡単に実現するにはどうしたらいいかなどと考えながらSpotifyのログを眺めていたら、思わぬ展開になった。すごく簡単に取れるかも知れないことが分かったのだ。
RG値はSpotifyアプリのログに出ることは分かっていたが、音量正規化をonにしないと出ないし、その仕様がいつなくなるかも知れないのだが、SpotifyのWeb APIのGet a Trackなどで取れるプレビュー(試聴)用のMP3ファイルに入っていたのだ。全くコロンブスの卵というか、灯台下暗しだ。
その前に、RG値も入っていると思われる、ヘッダ部("head file")取得用URLがログから分かり、その中身はBase64エンコードされたOggだったので、「もしや!?」と思ったのだが、曲のデータ同様中身が暗号化されていてお手上げだった。
ただ、プレビュー用のファイルを普通にsoxiやexiftoolやプレーヤーで情報を表示してもなぜかRG値(例: REPLAYGAIN_TRACK_GAIN)が出ないので諦め掛けたのだが、ffprobeでは"Side data"として出た。だから、通常のMP3での格納方法ではないのかも知れない。あるいは、僕がMP3に詳しくないだけか?
↑調べたら、MP3のRG値は「LAMEタグ」というものに入るようだ(MP3の標準タグ(ID3v2?)に入らないのかは分からない)。eyeD3というコマンドに--lametagというオプションを指定すると見られる(そうしないと見られない!)。あ、lameはフリーのMP3エンコーダだから、LAMEタグという名前からして、それが独自に付けているようだ。ということは、入ってないものも、将来なくなる可能性もありそうだ。MP3は随分使われているのに、RG値すら標準で入れられないのだとしたら、なかなか面妖だなあ。。。 (18:51)
それで、その値が正しいかを確認するため、数曲で全体(全曲)とプレビュー版のRG値(track gain)を比べた。なお、全体のRG値はSpotifyアプリのログから抽出した。
一見、全体とプレビュー版で随分値が違っていたのでがっかりし掛けたが、差を求めたら1dB未満(0.5dB前後?)なので、使えるかも知れないと考えた。
最初はRG値の差は圧縮率の違い(全体: 160kbps, プレビュー: 96kbps)によるものだと思ったが、その後、プレビュー版は先頭の30秒だけで、RG値もその部分のものであるために異なっているのではないかという懸念が生じた。それで、先頭の音量は小さく、後半に大きくなる曲("Stairway to heaven")で確認したら、プレビュー版のRG値も全体ものらしいことが分かった。: プレビュー版のRG値は全体の値とほぼ同じで、更に、手持ちのもの(マスタリングが異なるかも知れない)の先頭を切り出してRG値を求めたら、(先頭は音量が小さいため、)プレビュー版や全体より随分大きな値になった。以下にそれらの値を示す。
実際、手持ちの演奏のラウドネス(Integrated loudnessをebur128コマンドで求めた)は13.3LUFS違っていた。
念のため波形を比較すると、確かに先頭と全体の平均音量は10dBくらい違っていそうだから、きっと大丈夫だ。
"Stairway to heaven"の振幅: 上: 全体, 下: 先頭30秒 (縦軸はdB)
実際、Spotifyの立場で考えると、プレビューを提供するためだけに全部の曲のRG値を計算し直すのは馬鹿らしいし、プレビュー版の再生時に正規化するとしたら(実際にはしないと思う)、全体のRG値でする方が本来の雰囲気に近く、「試聴」の意図に合うから、全体のRG値を入れている(実際には全体の値を捨てずに残しているだけ?)のは腑に落ちる。想像だが、この値はレーベルから提供された試聴用ファイルに入っているものなのではないだろうか? (音源提供者向けの案内を調べれば分かるかも知れない)
プレビュー版内のRG値を使う場合には、以下のような手順で「普通の」(自分の好きな基準音量に合わせられ、Spotifyアプリのリミッターを回避する)音量正規化ができそうだ。
あとは作るだけ。だが、ちょっと疲れた。それに、寒いしお腹空いたしｗ
と書いたところで、思わぬ落とし穴に気付いた。: すべての曲に、あるいは、今後もずっと、プレビュー版にRG値が入っているか疑問だ。入ってない曲があったり、いつかなくなる可能性がありそうだ。上に書いたように、この値は使われることがないだろうし、意図的に捨てていないからあるだけで、Spotifyのサービスの仕様ではないからだ。
そうなっても、(今までのように、)いくらでも回避策は考え付くだろうが、結局、堂々巡りになりそうな感じだ。それだったら、(音質などが完璧ではないものの、)気楽に聴ける今の状態で満足するのが一番得策な気はするが・・・ うーむ。 まあ、興味本位で「お遊び」でやるなら ありかな(いや、全部遊びだがｗ)。
↑イマココ
↓
(12/25 12:41) 「プレビュー版のRG値で正規化」をちょっと試してみた。結論は、やっぱり駄目だった。以下に理由を書く。
どちらも致命的だ。評価用プレイリスト(ポップ・クラシック合計約90曲)で試したところ、ポップ音楽はまあまあだったが、クラシック音楽は惨憺たる結果だった。うまく行くものもあるから、その曲のプレビューのRG値が良くないのだが、どうしてそうなのかは分からない。プレビュー部分だけのRG値が入っているとか、元の版が違う(プレビュー用は初期のマスタリングなど?)とか、テキトーに計算したとかだろうか。いくら原因が分かっても、プレビュー自体すらなくてもいいような状態でSpotifyは全く保証していないので、対処してもらえる訳がない。
プレビューですらこんなことでは、以前書いた、ログからRG値を抽出する「トリッキーな方法」なんて余計駄目だろう。
いずれにしても、結果としてはイマイチだった。これがうまく行ったらすごくいいと思うが、やっぱり問屋が卸してくれなかった・・・ まあ、作るのはそれほど大変でなく、いつものようにおもしろかったからいいや。
そういう訳で、今は元の状態に戻して、「気楽に聴ける」状態になった(この音量正規化が破綻しないのには本当に感心するｗ)。これを試した一番の理由の、正規化をon/offする時のSpotifyの再起動を回避する件については、別の方法を考えたい。
一応、設定画面を開かずに、外部から音量正規化をon/offする方法はないかSpotifyに聞いたが、「ない」とのことだった。まあ、それは仕方ない。きっと、かなりニッチな要望なのだろう・・・ (12/25 15:38)
(とりあえずは、)本当に一件落着■
(題の漢字は、各自自由にご想像下さいｗ)
どっかの国の政府とか軍隊みたいに、勝算がないのに精神論(利権も?)で金・労力を投入して無理な行軍を延々と続けて、最後に、さまざまな言い訳をしながら形式上は「成功」などと発表してドヤ顔して(それどころか、首謀者が逃亡・知らん顔して、)煙に巻くのは愚の骨頂だ。駄目なものはなるべく早く気付いて切る(少なくとも、再検討や方向転換する)のが重要だ。
試行錯誤しているSpotifyの音量正規化処理の改良だが、ポップ音楽モードがそこそこ うまく行って、クラシック音楽モードも調整して目処が立ったものの、今朝寝ながら思い付いた(気付いた)。Spotifyアプリの(標準の)音量正規化機能がどのくらいのものなのか、それと今回の自作の方式にどのくらいの差があるのか確認しようと。特に、曲の特徴量のデータが誤っているのではないかというくらい大音量になるいくつかの曲(例: "Take My Breath Away", "Catacombae")は、Spotifyアプリの音量正規化ではどうなるのか興味があった。
やってみたら、多くの収穫があった。
Spotifyアプリの結果を聴いたら悔しいくらいだった(上記の困った曲が何の問題もない音量で出ていた)。悔しいけれど、結局、自作の方式でいくら頑張っても苦労ばかりで余りメリットはなさそうだ(そもそも、目的はそこにない)。それよりは、Spotifyアプリの音量正規化をうまく使えばいい。
一番手軽なのは、音量正規化をする場合は常にQuietモードを使うことだ。これなら、ポップ音楽でもクラシック音楽でも切り替え不要で、静かな曲でも音が不自然になることはなさそうだ。ただ、目標音量が-23LUFS程度と小さいので、もったいない気がする。特に、ポップ音楽では、もっと音量を上げてSN比を向上させたりダイナミックレンジを減らさないようにできる(だからNormalモードを使いたいのだが、例のコンプレッサーが邪魔だ・・・)。が、そもそも、音量正規化して聴くというのは、BGMのように気軽に聴いている時であり、その時にSNだのダイナミックレンジだのと言っても無意味だ。逆に、真剣に聴く時には音量正規化を使わないから、これで問題ないとも言える。
少し前に試行錯誤中に知ったのだが、Spotifyアプリの音量正規化はトラックモードとアルバムモードを自動で切り替える(アルバム再生時は後者になる)とのことなので、自作しようと思った切っ掛けの一つの、アルバムモードがないことも解決できた(この機能は後から追加されたのか、最初からあったが公表されていなかったのか)。そういう点でも、特にモバイルなどで切り替えずに使いたいなら、Quietモードにしておけば不便はない(まあ、モバイルでは周囲が騒がしいので、すごく静かな曲が不自然でも問題なさそうだから、Normalでもいいとも言える)。
ただ、Quietモードのもう一つの問題は、音量が小さいので他のプレーヤー(僕の場合は、gmusicplayer, GMB)と合わないことだ。これは結構厄介だ。Spotify(音量正規化)からGMBに切り替えた途端に大音量(約+11dB, 3.5倍)になるので、常に注意が要るし(大抵忘れて驚くｗ)、アンプの音量調整が煩雑だ。アンプの音量を変える代わりに他のプレーヤーの音量を下げる手もあるが、やっぱり「もったいない」から避けたい。逆に、Spotifyアプリの音量を後で大きくして合わせる手もあるが、一旦小さくしているのを増幅すると音質が劣化するから嫌だ。
書いた後で気付いたが、小さくしたのを増幅すると音質が劣化するというのは本当だろうか? (アナログでなく)ディジタルなので、増幅でオーバーフローしない限り、小さくした時より劣化することはない気がして来た。あとで検討したい。 ← データフォーマットにも関係ありそうだ。 → 検討結果を付録に記載した。 (12/19)
調べると、-23LUFSというのはEUの放送の基準レベル、あるいは、クラシック音楽向けだそうで(USや日本の放送は-24LUFS)、それに合わせるのは悪くないとは思うものの、自分の閉じた環境なのに一律に低く合わせるのはやっぱりおかしい気がする(実際、SpotifyやYouTubeの基準は-14, -13LUFSと、-23LUFSよりかなり大きい)。
以下に、候補とそれぞれの欠点をまとめる。
上述のとおり、自作の音量正規化が駄目なのはSpotifyからReplayGainが取れないためなのだが、どうにかして取る方法はないかと試行錯誤していたら、思わぬことで取れた! 既に書いては居るが、アプリのログやコンソール出力に表示されるのだ。以下に"Speak to me"での例を示す。太字がトラックのReplayGainである。
02:05:55.089 I [libvorbis_ogg_decompressor.cpp:401] track gain: (13.25Db), track peak: (0.409425dB), album gain: (-5.09dB), album peak: (1.02865dB), normalization: trackgain
ちなみに、それらはGMBでの同じ曲(同じマスターと思われる)でのReplayGainの値と概ね合っていた。
なお、peakの単位が"dB"と書いてあるが、誤りであろう(正しくは単位なし)。同じく"Db"もtypoだろう。ここら辺は そうなる状況が分かる。つい指が動いたとか、余計にコピペしたとか。「(見ると気になるけど、)デバッグ用だからまあいいか」、みたいなｗ
それで、自作の音量正規化にSpotifyのReplayGain(以下、"RG")値を使う(苦肉の)策を考えた。理論的には、RG値取得用と再生用の2つのSpotifyアプリを使えばできそうだ。以下に手順概要を示す。
ちょっと手で試して、やればできそうな気はしたが、(すっかり忘れて居た)昔のGoogle play musicの時(→ 例)と同様に、余りにもトリッキーで嫌になるくらいだ。また、アプリが2個なのでメモリも2倍食いそうなのも嫌だ。そもそも、ログにRG値が表示されるのは仕様でもなんでもないので、出なくなったら元の木阿弥だ。。。
だから、やっぱり筋が悪い。
そして、作るのは面倒だｗ
それで、とりあえずは、Spotifyの音量正規化機能を使うことにし、ポップ音楽とクラシック音楽でNormal(ポップ)とQuiet(クラシック)を切り替えて使ってみて、Normalでどのくらい不自然な曲があるかで判断することにした。Normalで駄目な曲は(DBに記録しておいて)自動でQuietに切り替える手が考えられるし、多かったらQuietだけ使うとか、上のトリッキーな手を使うことも考えられる。
それにしても、「とりあえず」のNormalとQuietを手で切り替えて使うにも自作ミニプレーヤー(minisp)に多少の変更が要るので、「ちょっと疲れたから、まあ明日にするか・・・」と一休みしているｗ ← イマココ
相変わらず寄り道が多く、先は長いｗ
(12/19 16:40) 付録: (デジタルで)増幅すると音質が劣化についての検討
結論は、「理論的には劣化しないが、現実には劣化する」である。以下に理由を書く。
まず、本文に書いた状況での音質劣化は、音量を下げた時点で生ずるものが主である。音量を下げることによってデータの有効ビット数が減るため、振幅分解能が減る(例: ものすごく小さい音が消える)ためだ。音を格納するデータフォーマットが浮動小数点型であれば、おそらく分解能が減ることはないが、整数型の場合には減る。その程度は以下のように試算できる。
音量を-23dB下げた場合、1ビットは約6dBなので、23/6= 約3.8ビット減る。
これによるダイナミックレンジの減少量は、データフォーマットを16ビットとすれば、3.8*6= 22.8dBである(音量を下げた分(23dB)そのもの)。
(2020/1/2 12:28記) 注: その後、Spotifyが音量正規化値の計算に使っているReplayGainの基準音量は-14LUFS相当であることが分かった。そのため、実際に下がる音量は9dB程度で、減るビット数は1.5ビット程度と少なく、特にポップ音楽では、音質の劣化もダイナミックレンジの減少もほとんど問題にならない。
実害について考えれば、対象はポップ音楽であり、そのダイナミックレンジを高々18dB(約3ビット分)程度と推測すれば、音量を下げた残りのビット数は16-3.8= 12.2ビットで、音源の3ビットより充分大きいので、記録された振幅がよほど小さくない限り、問題ないと考えられる。
次に、増幅の影響を考える。増幅は乗算なので全く音質が劣化する要素はないが、現実には、処理系や出力のデータフォーマットは整数型で取り得る範囲が有限なため、大きく増幅すると上限を超えて(オーバーフローして)音質が劣化する。つまり、波形の超過分がカットされるので、音が変質する(例: 歪む)。
この検討中に気付いたのだが、私が"Speak to me"で感じた不自然な感じは、オーバーフローによるものだった。具体的には、音量正規化時に過大に増幅するとオーバーフローが生じ、その超過分をカットすると生じる(これはリミッターの動作であり、本文中の「コンプレッサー」は実際にはリミッターであった)。
不自然さが起こる原因を詳しく推測すると、この曲は低音(鼓動)が強いため、それがオーバーフローしてカットされるのだろう。カットされるのが単発的(不定期)や短時間(瞬間的)に起こるのなら気づきにくいからまだいいのだが、この曲の場合は、定期的に起こる鼓動で、テンポが遅いために比較的長時間音が大きい状態なので、カットされる期間が長く、その間の他の音の聞こえ方が変わって不自然になるのだろう。
この現象はSpotifyアプリの音量正規化だけでなく、私の環境でも起こったので気付いた。具体的には、次のような処理をした時に、Spotifyアプリの音量正規化(Normal)と同様の不自然さが生じた。
Spotifyアプリの音量正規化(Quiet) → アンプ(増幅率: 6-9dB程度) → リミッター
また、Spotifyアプリの音量正規化(Quiet)だけでは不自然さは生じなかったので、問題はリミッターに起因する可能性が高い。
なお、「リミッターが原因だったら使わなければいい」ということはない。リミッターがなくても、超過分はどこかで(例: DACで出力する時)カットされ、それはリミッターよりもひどい音質劣化を生じる可能性が高い。
(12/19 22:23) 補足: 上でデータフォーマットを16ビットと想定したのは、Spotifyアプリの出力がそう("s16le")だからで、通常のOSのサウンドシステムはもっとビット数の多いフォーマットをサポートする。例えば、私の使っているJACK Audioは32ビット浮動小数点である。だから、音質の観点ではSpotifyに音量正規化をさせるのは得策でない。上述の、音量を下げることによるダイナミックレンジの低下などが起こる。が、もし仮にJACKの中やその手前のPulseAudioで行うなら、劣化する可能性はほとんどない。
その後の増幅はJACKで行っているので、通常の増幅率ではオーバーフローしないから、音質劣化も発生しないはずだ。しかし、元々のデータが最大値に近いほうに詰められているためにオーバーフローするし、そうでなくてもDAC(サウンドカード)に出す時にオーバーフローする。それを防ぐには、リミッターを入れるか、音量を下げて(= 適当な値で除算して)全体的なレベルを小さくして(= 小さい方にずらす)DACに出すことが考えられる。
結局、後者はSpotifyの音量正規化(Quietモード)の小さい音のまま出力することと同等である。もちろんそれでも良かったのだが、他のプレーヤーと音量を合わせたいから増幅しようとした。
PS. SpotifyアプリからのRG値取得には、音楽圧縮フォーマット展開用ライブラリ(vorbisを使っているようだ)をすげ替えればできるかと思ったのだが、自前で作っているかスタティックリンクしているらしく、外部のものは使っていなかった。考えが甘かったが、まあ、そうれはそうだろう・・・ あとは、逆コンパイルしてバイナリエディットとかいう手もあるかも知れないが、「うーん」だ。それに、プログラムの改ざん検証をしているかも知れないから、できないかも知れない。
なんてことを考え出すから、寄り道が増える訳で・・・
使っているうちに不満(例: うるさい曲がある)が出て来たために、Spotifyの自作ミニプレーヤー(minisp)の音量正規化処理で、音量の補正量をやはり自作再生履歴DB(Mlhi)に記録しおいてそれがあれば使えるようにしようと思ったのだが、そもそも、元々の方式がいい加減では補正ばかりになって良くないことに気付いた。それで、まずは音量正規化処理を改良することになり、今は、その改良した方式の評価のために、Spotifyで再生している曲の音量を自動で測定する機能を作っている※。音量はできるだけ聴感に近い方がいいので、ラウドネス(Integrated loudness: "I", 参考)にした。随分目的から離れてしまった気がするが、きっと気のせいだろうｗ 自分でやり出したこととはいえ、なかなか面倒だが、いろいろな物を組み合わせて機能を実現するのはおもしろい。
※なぜ自動化しようと思ったのかというと、ラウドネスメーターはあらかじめ曲の先頭で計測開始しておかなければ、正確なIntegrated loudnessの値が出ないので、だらだらと評価がてら聴いていて「大き/小さ過ぎるかな?」(調整がおかしい?)と思ってからでは遅く、再計測しなくてはならないからである。再計測にしたって、曲全体を再度聴くのは苦痛なので、先頭だけなど一部になって、正確でなくなってしまう。曲間で自動リセットしてくれるような測定アプリがあればいいが、そういうものはなかった。また、GUIに表示された測定値を見て手で記録するのは面倒だし間違い易いから、自動でファイルに記録できれば好都合だ。
更に、複数の補正条件・設定の比較についても、それぞれの条件で評価用のプレイリストを再生しておけば(僕が聴いて居なくても、スピーカーで音を出さなくても)通して測定できるので、(この機能が完成した暁には)容易になるはずだ。
更に、普通に再生しながら、補正条件とその結果の音量を測定してDBに記録しておき、次回はそれに基づいて最適な音量に調整するってことも可能な気がしていて楽しい。
更に、今思い付いたが、AIみたいな機能で、長時間いろいろな曲を自動再生して勝手に学習させて、設定を自動調整するなんてのもいかにもおもしろそうだが、先は長いし、そもそもSpotifyを聴くだけなのにそこまでする必要があるのかと・・・ｗ
こうやって風呂敷夢を広げるから、大変になるのだ。
詳しくは別に書くつもりだが、音量正規化の基本的な処理は、従来と同じようにSpotify APIで取得できる曲(トラック)の特徴量(loudnessとenergy)を組み合わせて、曲の本来の音量を推測(復元)し、それを元に正規化している。今回は、その推測の方法を改良しようとしている。今までは思い付きで対数あるいは指数関数を使っていたが、今は下のグラフのような、energyによって特性(係数)が変化する式を試している。グラフはいかにももっともらしくて うまく行きそうに思えるが、そんなことはないｗ それに、これは何かの理論に基づいている訳ではなく、やっぱり思い付きや試行錯誤からの経験によるものである。試すとまあまあうまく行く(しないよりはずっといい)のだが、やっぱり限界はあるし、値に問題はなくても聴覚に合わないことがある(合わないものが充分に少なくなったら、補正量をDBに入れようと思っている。が、いつになることやら・・・)。
あと、以前のように、公開DBに音量正規化用の値(再生ゲイン)などがないか探したたら、2つ見付かった。一つは前回も見付かったDynamic range databaseで、もう一個はAcousticBrainzだ。前者は、前回は(記憶している限りでは)APIがないのとレパートリーが狭そうなので止めた。後者は、言い方は悪いが「玉石混交」(「ゴ○屋敷」などもっとひどい言い方はあるが、それは言い過ぎだろう)で、全く手軽に使えないので却下した。確かにデータは多いのだが、全然整理されておらず、ただ数字があるだけで、同じIDなのにそれぞれ随分違っていてどれが正しいのか分からず、禄に検索もできなかったら、どうやって使うのかと思う。
作業の途中で分かったことも多かった。SpotifyのAPIから得られるloudnessは多くの場合はIntegrated loudnessまたはReplayGainと同様(同等)のものなのだろうが、そうでないことも多い。中で変・特殊な処理(音量(loudness)が小さいけどenrgyが大きい曲では更にloudnessを小さくしているフシがある)をしている可能性と、データが誤っている場合もありそうだ。そもそもSpotifyアプリで使っている再生ゲインを出してくれれば、こんな苦労をしなくて済むのだが(アプリの一時ファイルを見たりしたが、それらしい値は見つからなかった)・・・
そもそも、Spotifyアプリの音量正規化処理が「普通」だったら、こんな苦労は全くしなくていい(実際、したい訳じゃなくて、ただ音楽を聴きたいｗ)のだが、前回書いたように、やっぱり謎の処理をしていることが分かった(何人かの方が書かれていた: 例)。どうやら、アプリにコンプレッサーとかリミッターのような処理が入っていて、特にすごく音量が小さい曲(僕が気付いた曲: Pink Floyd: "The dark side of the moon"の"Speak to me")でおかしくなるようだ。再生ゲインの値がおかしい可能性はあるにしても、せめてその余計な機能がなければまだ良かったのに、どうもお節介な感じだ・・・
ラウドネスの測定プログラムは、GUIのものならいくつかあるのだが、測定・記録を自動化するのは困難なので、スクリプト(jack_captureで音を録り、ffmpegのebur128フィルタでラウドネスを計算する)を作ってミニプレーヤーに組み込んだ。基本的には、ただ再生しているだけでデータが貯まるから楽ちんなのだが、例によっていろいろ凝るから本末転倒になって、処理が複雑になればバグは増えるからデバッグが大変で、また勝手に疲れている。 ← イマココ
PS. 以前、「Spotifyには満足している」と書いたが、誤りではない。が、それはあくまでも曲目と音質についてであって、機能は別であるｗ
PS2. これを書いていて、技術バカにありがちな、「フラット(あるいはリニア)信仰(あるいは症候群、至上主義)」という言葉を思い付いた。やっぱり、こだわり過ぎは駄目なんだろうと思う。が、気軽に聴いている時に、曲のたびに「うるさい!!」とか「小さい・・・」とイライラしてボリュームを調整するのは嫌だってのは大いにある。
PS3. Evernoteやスマフォ・PCのおかげで紙やペンとは無縁の日々なのだが、さすがにグラフの形を考えるのはEvernoteでは無理で(タブレットなら手描きできそうだが、それも煩雑な気がする)、紙が必要だった。が、すぐに使えたのは小さい電話用のメモ帳しかなかったｗ
(12/14 13:11 少し修正)
何かで"others"という単語を見たら(もう、何だったか忘れたｗ)、「アザース」という読みが浮かび、そんな流行語があったと思った。
調べたら、偶然にも、近頃復活したとかいうコメディグループの番組が発祥らしい。
だけではおもしろくないので、ついでに: さっきSpotifyからこんなメールが来た:
2019年にSpotifyで聴いた曲数
平均すると約13曲/日で(重複を除いているのか不明だし)、多いのかどうかは分からないが、Spotifyには大変お世話になっていることは確かだ。
それで、そのメールに記されていた2019年のまとめページを見たら、トップのアーティストは意外にもカーズだった。ページに"Say thanks"というボタン(ツイートするようだ)があったが、写真(下にもあり)に写っているのは(オールが死んでしまっているため)3人で寂しいうえにオケイセックも死んでしまって、まさに「ありがとう」と言いたい。
ちなみに2位はユジャ・ワンだった。これも意外だが、彼女はいろいろといい＾＾ ただ、5位までに大好きなルガンスキーが入ってないのは不思議だ。何かおかしいのかも知れないが、まあいい(彼はもっぱらSpotifyでなく手持ちの音源で聴いていたからかも知れない)。
なお、1位(loved most)の曲は去年と同じく、ヒューイ・ルイス&ザ・ニュースの"The power of love"(1985)で、これは本当に大好きだ。
他には、59か国の曲を聴き、特定ジャンルに固定せず("refused to let one sound define you.")、436もの新しいアーティストに触れたそうで、まさにSpotifyならではだ。
ページの最後に「良かったら(SNSなどに)どうぞ」みたいな画像があったので、ここに貼る。
2019年のSpotifyのまとめ
Spotifyにも「ありがとう」と言いたい。
(と、オチを付けてみたｗ)
PS. 投稿を見直して思い付いた。自作の音楽再生履歴管理システムMlhiを使って、手持ちの音源も合わせた順位も出すとおもしろそうだが、SQL(検索コマンド)を考えるのがちょっと面倒だｗ 日々、聴いた履歴は記録されているのだが、その活用まではなかなか手が回らない。
ちなみに、MlhiのDBに入っているのは延べ約4500曲(今年の中頃から)なので、ほとんどはSpotifyで聴いているはずだ(感覚とも合っている)。
PS2. Spotifyが出て来たのでついでに書くと、今年は1枚もCDなどを買わなかった。それでいいか悪いかは別として、(曲目も音質も)何も不自由していないどころか充分に満足しているから、きっといいことなのだろう。
Spotifyの歌謡曲系のDaily mix(毎日変わるリコメンドのようなラジオ)でピンク・レディーが結構頻繁に掛かり、結構聴き応えがあって感心する。
当時は、見た目からして色物の雰囲気で全然好きじゃなかったのだが、改めて(レコード版を)聴くと ちゃんとしていて悪くない。(すごいメンバーが作った)曲自体もいいのだが、(時代を感じさせないのか、古くて却って新鮮なのか)音作りに感心する。特にイントロなどは意外に音がすごい(ちゃんと作られている)ので、全然馬鹿にできない。歌も結構ちゃんとしている。
例えば、以下のような曲がいい。
ペッパー警部(1976), 渚のシンドバッド(1977), ウォンテッド(指名手配)(1977)
特に、「ウォンテッド(指名手配)」の冒頭は意外な音で格好良くてグッと来るので、是非お試しを(→ YouTube: この版はまだ甘く、上のSpotifyでの版がいい。版がいくつかあるのか、このアルバム(→ 試聴)でリミックスしたのだろうか?)。
ただ、カルメン '77(1977)やサウスポー(1978)は上に挙げた曲ほどではなかった。忙しくて質が落ちたのか、単に好みでないのか。だから、ベスト盤を通して聴くと、飽きてしまうかも知れない(まあ、他の人・グループも同様だから仕方ないか)・・・
あと、上に「レコード版」と書いたように、TVでの歌は(当然ながら)いろいろな点で今ひとつだった記憶があるから、それで印象が悪いのはあるだろう。
PS. なぜか、"S・O・S"(1976)や「透明人間」(1978)はまだ掛かっていないようで、不思議だ。
PS2. それから、近頃、なぜか、Spotifyの「嫌い」(Don't like)機能がなくなってしまったようだ。仕方ないけど、嫌いな曲やアーティストを性懲りもなく掛けられるとイライラするので、Mlhi(自作の再生履歴管理システム)を使って、「強制スキップ」機能を実装したくなって来た。
先日、「(これ以上、)いい曲や演奏が見つからなくなったら(どうするかねぇ)・・・」のように書いたが、そんな心配はSpotifyの「ラジオ」(あるいは同様のサービス)で解消するかも知れない。
延々と続けていた、オーディオの「音質向上」の試みがようやく終わった感じで(その予想だにしなかったｗ結末については、あとで書く予定)、耳も身体も疲労困憊でポップ音楽を聴くのすらキツいし、大丈夫そうな曲を考えるのもダルかったので、今までは避けていた、(音や曲が耳に優しいものの多い)クラシックのラジオを試してみた。とりあえず、モーツァルトのにしたら、意外に「使え」て感心した。
最初に、僕の好きな(しかも、近頃、ちょっと聴きたくなっていた)「フィガロの結婚」の序曲が掛かったのは とても印象が良かった。ただ、ヤーコプスの(2004)はちょっと速くて好みではなかったが、以前いろいろ比べたら(僕にとっての)速目なのが一般的なようだから、仕方ない。
ラジオは、知らないアーティストを知ることができるからいいし、種になるアーティストや作曲家(今回はモーツァルト)以外の曲も掛かって試せるからいい。ただ、僕はモーツァルトといえども好きでない曲が多いし、好きな曲だって好みでないアーティスト(の演奏)も多く、そういうのが頻繁に掛かって気分が悪くなるのが嫌だから、今まで試していなかった。しかし、今日試したら、嫌いな曲や演奏が余り掛からなくて安心した。もしかしたら、僕の好みに合わせて選んでいるのかも知れない。だとしたら、本当に使える。
それから、ちょっと聴いていただけで、今まで知らなかった、気になる(ちょっと気に入った)ピアニスト(Alessio Bax: モーツァルトのピアノ協奏曲 第27番の第2楽章で)が見付かったり、見直した人(ラン・ラン)が居たり、意外にいけそうな曲(モーツァルトのオーボエ協奏曲)があったりして、その点でそもそもの要望が実現できて、随分効率(時間的効率も「コスパ」も)がいいｗ
とはいえ、一楽章だけなら気に入っても、全曲を聴くとがっかりすることは多いが、(世の中はそんなに甘くないので)仕方ない。実際、日記を調べたら、Baxは実は今年の頭に別の曲(同協奏曲 第24番)を聴いていて、「オケがしょぼい」とか「重みが足りない」とか、余り印象が良くなかったことが分かった。でもまあ、今度はいいかも知れない・・・
Spotifyアプリの更新の後だったと思うが、8/6にライブラリの仕様変更に気付いた。最初はアプリがおかしくなったのかと思ったのだが、仕様変更のようだ。アナウンスを調べてはいないが、ニュースになっていないので、黙って変えたようだ※。まあ、僕にはMlhiがあって、元々Spotifyのライブラリをあてにしてないから、仕様が変わっても大きな問題はない。
※少し調べたら、数か月前(3月頃)に変わったようで(面倒だし、余りにもぐちゃぐちゃで詳しく知っても無駄そうだから、飛ばし読みしかしてない)、Linux版への反映が遅れたのか僕が気づかなかっただけなのかは分からないが、当時は混乱したり怒った人が多かったようだ。そりゃあそうだよね。
具体的には以下のような感じだ(LinuxのSpotifyアプリで見た違い)。
結構大きく変わったのか外見(表記)上の変更なのか、微妙なところである。簡単に言えば、従来の+(ライブラリに保存)と♡(Like)が統合されて♡になった感じだ。元々二つあるのは煩雑だったし、♡できる場合とできない場合があったのが解消されたので、まあ、ありがたい。
ただし、従来の"×"(Don't like/Hate)は"-"(Hide this song)に変わったのだが、やっぱりできない場合があるのが惜しい。まあ、これはリコメンドに反発するｗためのもので、普通の時にHideできたら永遠に出なくなってしまうので、その管理機能が必要になるから、簡単には行かなさそうだ。
そして、新しい仕様では、自分が♡した曲(従来は♡せずに「ライブラリに保存」した曲も含んでいた)をAPI "Get Current User's Saved Tracks"で取れそうだと思って試したら、実際にそのAPIの結果とアプリの"Liked Songs"の先頭の数曲が一致した(だから、♡は内部では「ライブラリに保存」の動作をしているようだ)。
あとでこれを使って、♡した曲の評価をMlhiに(自動で)取り込みたい(いつになるかは不明ｗ)。
PS. こんなことより、アプリのメモリリークを直して欲しいなあ・・・ これは、どうあがいてもこっちでは直せなさそうだ。
PS2. こうやって自己満足な変更をしてユーザーを混乱させ・怒らせて、碌に意見を聞かず、喜ばせることをほとんどしなかったら、いつかSpotifyは終わってしまうのではないだろうか? 僕は基本的にはSpotifyじゃなくてもいいけど、Spotifyは公式APIがあることとLinuxアプリがあることが一番の価値で、他にそういうサービスがないので、終わってしまうと不便だ。が、まあ、他のサービスでも非公式のライブラリはありそうだからいい。ユーザーの意見を無視してばかりいたら、絶対に終わるね。
自作の音楽再生履歴・感想の記録・検索システム Mlhi※の現状について、他の方が見ても有用ではないだろうが、自分のまとめとして書く。
※ふと頭に浮かんだ「ライフログ」という単語から思い付いたのだが、システム名は「音楽(再生)ログ」や「音楽(再生)ロガー」とかそういうのが適当そうで、簡潔でいい。ようやく、自分が何を求めていたのか分かったのかも知れないｗ これで行けば、英語の略称(Mlhi)の元としては"Music logger managing listening history and impressions"のようなものがこじつけられる。(こういう「逆のこじつけ」とかこじつけの変遷は良くあるので、気にしないことｗ) (7/19 6:42追記)
状態: 一段落、あるいは、停滞中 (85%くらい?: 随時新しくやりたいことが増えるので、この値にどの程度の信頼性があるか不明)
現状のままでも、SpotifyとGMBで再生した曲の履歴が自動で記録できるので、データ収集に関しては当初の目的が達成され(残件は収集したデータの使い方や見せ方が主になる)、webの表示・検索もそれなりに使えて大きな問題がないので、ちょっと満足してしまった。鞍点?
今できること
TODO
そして、夢・・・
※昨夜見付けた・聴いたJun Asai(浅井純)の「展覧会の絵」(2014)とFlying Doctorの演奏(→ 例)がとても気に入り、それらはCDなどで発売されていないので、是非やりたくなった。
ここに書くのは適当でないが、Asaiの演奏は以前から気に入っているのに、SpotifyはおろかCDすら売っていないのが残念だ。まったくもったいない。この演奏が発売されたら、是非手に入れたい。それから、Flying Doctorは(気持ちだけは)全力で応援したい＾＾
といった感想を自分のDBに記録したいのだ。
大きな不便や問題がなく使えているうえに、時々「夢」を思い付いて、そっちを考えたり作ったりするほうがおもしろいので、なかなか本流の完成度が高まらない。(Googleとかにありがちなパターン?ｗ)
(19:40, 20:40 若干加筆; 7/19 朝 加筆)
何の気なしにSpotifyのRelease Radarを見ていたら、ずっと待っていた「彼」の曲があった。ついに、吉幾三の曲が入ったのだ。もちろん、「俺ら−」もある(正直言うと、これだけが好きだｗ)。千昌夫の曲があったので、「もしや」と思ったら、その次に入っていた。
まだ入ったばかりのせいか音響特性分析されていないようで、Get Audio Features APIがエラー(404)になり、自作ミニプレーヤの再生ゲインの不具合(要改良点)が見付かったので早速直した。
PS. 今気付いたが、音響特性だけでなく初出年も入っていない。手が回らないのだろうか? ← このレーベルの他の人(例: 千、五木)も入ってないので、レーベルが駄目な感じだ。
でも、そういう時に作ったものには結構高い確率でバグが潜んでいるので、喜ばしいばかりでもないｗ
半ば疲れつつも飽きずに作っているMlhi(音楽再生履歴・感想の記録・検索システム)のwebの見た目を改良できたので、結構進んだ気がした。とはいえ、それは、SpotifyのミニプレーヤーにMlhi対応機能を組み込むための準備なので、実際にはそれほど進んでいない。というのは昨日の話で、今日は更に進み、ミニプレーヤーにMlhi対応機能を組み込んで動き出した。いろいろ改良したいことはあるが、「一段落」している。
昨日からの作業は、ミニプレーヤーに対応機能を組み込むための準備とその実装である。いろいろな機能を組み込みたいが、「ミニ」なので表示に使える面積が小さい。そこで、何をどのように表示するかの検討が重要だ。
今回組み込もうとした機能は、以下である。
評価はwebと同様にアイコン(♥など)と色でいいが、再生履歴は、回数と完奏率を別々に出すのではスペースを食うので、減らし方を考えた。デザインは全く素人だが、その代わりに(結果的に)工学的に考えた。
スペースを節約するため、表示する部品を一つにするとすると、2つの情報を1つにすることになるので、2次元とか3次元的な表示になるのだろう。最初は、マークの形と色で表すとか小さな円グラフにするとかを考えたが、どうも今ひとつだった。完奏率は、やっぱりwebの棒グラフが見やすい。それで、ミニプレーヤーを眺めながら考えているるうちに、再生位置のバー(プログレスバー)が目に付いた。これがうまく使えれば、スペースとしては全く問題ない。そして、プログレスバーの下に完奏率の棒グラフを並べることを思い付いた。この時、再生回数はグラフの色で表すのだ。早速、イメージ図を描いて検討した。
なかなか良さそうな感じなので、試してみることにした。ただ、いきなりミニプレーヤーに入れるのは大変だし、駄目だった時に疲れ果てるので、試しにwebに入れてみた。すると、結構いい感じにできたので、採用することにした(webもこの表示に変更した)。ついでに、以前からやりたかったのだが、アイコンなどへのマウスオーバーで値(評価の値や再生回数)を出せるようにした(図上方のベージュ色の四角は、完奏率にマウスオーバー)。再生回数を表示しないようにしたので、なおさらこの機能が必要になったのだ。
あとで気付いたのだが、棒グラフでの表示方法は、以前から謎だったYouTubeでの良い評価率の表示(なのだろうかと、今推測している)に似ている。棒を細くするところは、まさにそのものだ。
Webのいいところは、ページの表示内容をプログラムで書けるので、ある値の色やその段階がどのようになるか試しに表示させられることだ。これで色や計算式を調整・確認した。のだが、例によって思わぬ間違いがあった。再生回数から色への変換式に対数を使ったのだが、PHPのlog()は自然対数(普通は"ln()"と書くと思っていたのだが、log10()があるし、数学ではlogとlog10だから、僕の思い違いかも・・・)で、想定していた常用対数(底が10, "log10()")でないために、実際には変な値になっていた。それでも、対数や色は細かく確認できない(やればできるが、それらしかったので正しいと思い込んだ)ために気付かなかったのだが、ミニプレーヤー(計算にはbcというプログラムを使ったので、自然対数しか使えない)に組み込んだ時にwebと色や係数が違うことでようやく気付いたｗ
上に少し書いたが、再生回数を色で表すために数値を色に変換する処理が必要で、これにも少し苦労した。最初は、グラデーションの方法・式(検索するといろいろ出てくる。が、ほとんどはRGBで計算していて、HSVでなくていいのかなと思う)で無段階にする(例: サーモグラフィーのようなイメージ)ことを考えたが、そこまで細かく色が判別できる訳ではないし、その必要もないし、グラデーションでは常に期待する(好きな)色が出る訳ではないので、好きな系統の色を選んで10段階(色)にすることにした(今はとても便利で、色チャートのサイトがいっぱいあって、いくらでも色が選べる → 例1, 例2)。ただ、それでも問題はあって、使い続けると曲の再生回数が無限に増えるので、いつかはオーバーフローして「最大」の色ばかりになってしまうことだ。色数を固定したままそれを防ぐには、何らかの方法で再生回数を色に割り当てる(対応させる)必要がある。
再生回数の最大値は、将来は例えば100回とかにもなるだろうし、一方で、常に「1回」という曲もあるだろうから、最大値との比でのリニアな変換にしたら、全体としては再生回数の多い曲は少なく、ほとんどの曲は小さい値だろうから、(少ない回数を薄い色に割り当てた場合)ほとんど見えなくなってしまう。それで、標準偏差で再生回数の分布を求めて「何とか」(ここには特にアイデアはなかったｗ)できないかと思ったのだが、使っているDBのSQLiteにはその機能がない。自分でSQLを書けば出せるが面倒なので止めて、ふとひらめいた対数を使うことにした(音量は対数表示することから連想したのだと思う)。対数を使うことで、小さい値の変化は拡大され、大きい値では圧縮されるので、結果的に幅の広い再生回数の違いが見やすくなるはずだと考えた。音で言えば、レベルメーター(今は滅多に見ないが・・・)の棒の長さを色にすることに相当する。この対数が上に書いたものである。
その変換は、基本的には、DBに記録された曲のうちで最大の再生回数を求め(この機能はSQLiteにもある。こういうのが一発でできるところが、DBの深みにはまる原因なのかも知れないｗ)、それと対象の曲の再生回数の比の対数で色の番号を決めている。どういう訳か、実際の変換式は複雑になったのだが、その理由はすっかり忘れたｗ おそらく、対数には0を与えられないとか、値域(色の番号)を0から9にするとか、そういう理由だったと思う。
ちなみに、最大の再生回数を求めるにはちょっとしたSQLを実行する必要があって、そのためのプログラムを作る必要があると思い、疲れているので「またかよー(一体、いくつ作ればいいんだ?)」とうんざりな気分になったのだが、曲をSpotifyとDBから検索するために作ったプログラム(webで検索に使っているもの)にそのSQLの判定部を「適当に」(= "1 order by played_cnt desc limit 0,1")入れたらできてしまったので、ちょっと驚いた。自分では全く想定していなかった用途に使えるのはおもしろいけど、結構怖い。こういうところからセキュリティホールが生まれるのかも知れない。
ここまでが昨日の話(log/log10の誤りに気付いた話とSQLの話を除く)で、今日、ミニプレーヤーに組み込んだ。久し振りのTck/Tk(どう考えても仕様が狂っている・・・)や肥大化したシェルスクリプト(調べたら、約1万行になっていた・・・)に手こずったが、さっき、何とか動き出した。
早速使ってみると、満足するどころかすぐにいくつも文句が出て来るｗ 例えば、完奏率の棒グラフの色が鮮やか過ぎて目障りだとか、コメント(せめて有無)も見たい(→ とりあえず、コメントがあればアイコンを出し、マウスオーバーで出るようにできたが、間抜けな場合もあるｗ: 6/20 16:39 → 暫定対応した。: 6/22 8:41)とか、webと同様にマウスオーバーで値を見たい(→ それほど手間が掛からずに追加できた。: 6/20 12:34)などだ(我ながら、全くわがままだ)。もちろん、アイコンのクリックで評価などの値を設定したいとか、GMBのミニプレーヤーにも組み込みたいなどの希望・予定はあるが、次の段階の話だ。
以前苦しんだフォントと同様に、色も奥が深く、webと同じ値でもミニプレーヤーでは違って見える。おそらく、大きさ(面積)や背景や周囲の色によるのだろう。鮮やか過ぎたものは、とり急ぎ渋目の色に変えたのだが、この辺りはじっくり調整する必要がありそうだ。(こういう時に、変更したい箇所で右クリックすると色チャートが出て変更できたりすると便利だが、さすがにそれは全くもって無理だｗ)
(6/20 7:43 加筆・修正; 6/20 12:34, 16:39 マウスオーバーを追加した件を追記, わずかに修正)
ようやく正式な名前を決めた、Music listening history and impressions "Mlhi" DB (音楽再生履歴と感想の記録・検索システム※)に、先日やる気が出てしまったgmusicbrowser(GMB)対応機能にを追加しようと作り出し、さっきようやく動き出したのだが、気付いたら一週間経っていたｗ
※日本語の名前は今考えたので、やけに長いうえにダサいｗ
まあ、見た目はほとんど変わらない(そういうふうに作ったので)。GMBで再生した曲は再生の都度DBに記録され、履歴webに出る。Spotifyと同様に完奏率が出るし、評価やコメントを付けることもできる(それ以外の細かいことはまだだが)。
GMB対応に伴うDBの構成変更の内容が確定していなかったのと、うっかりDBを壊すのが怖いので、今はテスト用のDBを使っているが、もう少ししたら本物に切り替えたい。
それから、Spotifyでもそうしたのだが、再生した曲のDBへの登録を外部プロセスでなく、GMB本体(Spotifyではミニプレーヤー)に組み込んだ。これもまだできたてで怖いのだが、外部プロセスの場合、再生開始してからDBに登録されるまで30秒近く掛かっていて、いつも「遅いなあ、まだかよ」と思っていたのが、瞬時に(数秒以内に)登録されるようになったのが大変気持ちいい。これなんだよ! (と、ひとりごつｗ)
以下に、少し実装の話を書く。
思わぬ利点は、今までは、GMBはSpotifyと違って評価が付けられない(実際にはできる)とか再生履歴が残らない(上記のとおり、実際には残る)とかコメントが書けない(実際には書ける)などの理由で(要は、見やすくないとか手軽に更新できないのが面倒だったようだ)、余りGMBで聴かなくなっていたのだが、これができてから、(テストの意味もあるが、)俄然使う気が起こったことだ。将来的には、SpotifyとGMBをシームレスに(シャフル)再生できそうな(したい)気がして来て、夢にはまったく限りがないｗ
BTTFで言えば、やっと落ち着いたと思っていたら、またドクが来て、「未来に道は要らない!」とか言われて引き戻されるようなものだｗ
あと、やけに長いコメントが入っている曲が見付かったりする(CD-DBに入っていたのが取り込み時にそのまま入ったのだろうが、今まで全然知らなかった。 ← 実際にはコメントに購入日を記載した時に気付いたはずだが、すっかり忘れていた)のは、おもしろいのはもちろん、今までは不便で活用できなかった情報が生かせそうな点もwebでの履歴表示のいいところだ。
これでもまだ83%といった感じだが、大分落ち着いてきた。でも、プログラム中に山ほど"TODO"があるので、なかなか先は長い。そういうのは普段は何もないのだが、突然牙を剥くので(早速、ここに載せる画像を追加する時に出たｗ)まったく油断できない。
(6/17 19:46 若干加筆・修正)
開発中の音楽再生履歴記録・検索システム(仮)、そこそこ使えているうえに、煮詰まっているというか、完成度が高くなってきたために(それでもまだ8割くらいか)、いくら作り・直してもキリがなくて(しかも、劇的にすごくはならない)疲れたので、ちょっと脇道に逸れて、先日書いたgmusicbrowser(以下GMB)との連携・統合の一部の、GMBの再生履歴を取って記録することを試してみた。
まあ、GMBで再生している曲情報を取ること自体は全く簡単で、Dbusインタフェースを使えば目をつぶってもできたくらいだが(実際には少し手こずった)ｗ、その先が大変だ。
先日も書いたように、再生している曲・演奏・録音(以下「演奏」)が「何か」を特定(同定)することが難しい。なぜ同定が要るかというと、GMBでもSpotifyでも同じ演奏を再生したら、同じ演奏の履歴として記録したいのだ。片方で再生したらもう片方とは別扱いになるのでは全く無意味だ。
そして、上記のGMBから取れる曲情報は、曲名、アーティスト名、アルバム名などで、それだけあれば充分だと思われるだろうが、実際には不十分だ。例えば、以下のような問題がある。
そこで、先日も書いたように、各演奏はISRCで区別し(ISRCのないものは別扱いにする)、ある演奏がどのISRCに対応するかを音響指紋で識別しようと考えた。音響指紋と演奏を照合するためのシステムは、AcoustIDとMusicBrainzを使うことにした(無料で使えるのはこれらしかないため)。
手順は以下である。
全くシンプルで、すぐにでもできそうに見える。確かに、それほど時間が掛からずに作れた(でも疲れたｗ)。が、ちょっと試したらとんでもなかった。以下のような問題が噴出した。
まさに、「聞いてないよー!」の世界だｗ
それでいろいろな工夫をしたが、現時点では、完全な自動処理(演奏の同定)をするのは難しい感じだ。以下に、したことと起こった問題を書く。
ちょっと見た感じでは、多くの(2/3以上?)普通の演奏では問題なく動いている(→ 出力の例)のだが、たまに間違うのはやっぱり気に入らない。
他の問題として、MusicBrainzではリマスターやレコードの演奏などが全部通常版(例: CD)と同じに区分されている(Spotifyは、基本的に最新の1種類しかない。リマスターがあればそれだけになるし、当然ながらレコード版はない)。これは、技術だけでなくポリシーの問題も絡むので、すぐにはどうすればいいかが決められない。リマスターやレコードを通常版と別扱いにしたいこともあるし、そうでない場合もあるのだ。
AcoustIDとMusicBrainzはイマイチなので使わなくてもいいのかと思ったが、そうではない。それ以外に有効な手段がないので、やっぱり音響指紋での識別をした方がいい。その点で、Spotifyが音響指紋を提供してくれると一番ありがたいが、そうも行かない。今のところは、(リアルタイムでの)完璧な同定は諦め、バッチ処理でGMBとISRCの対応表を作って、その結果を「見て」修正するのがいい感じだ。ただ、GMBには1.5万曲くらい入っているので何とも大変そうだし、時代遅れな気がする。
次善の策として、SpotifyにはなくてGMBでしか再生できない演奏についてだけ対応表を作って、その内容を確認することが考えられる。それなら2500曲以下と大分減るが、そういう演奏はISRCがないものも多いので、別の問題(ISRC以外の何で演奏を区別するか)がある・・・
できそうでできないのは、SpotifyのAPIの音楽分析アルゴリズム(演奏の「活発さ」や拍などが分析されて公開されている)でGMBの演奏を分析して音響指紋の代わりに照合に使うことだ。でも、SpotifyのAPIではローカルファイルの分析はできないと思うし、Spotifyのアルゴリズムは公開されていないので、自分で実装することもできない。
もう一つ、最後の手段としてあるのは、仕舞い込んだCDを引っ張りだして、その中に記録されているであろうISRCを取り込むことだ。これが一番確実ではあるが(こうなると分かっていたら、最初からやっていただろう)、ISRCが入ってないものもあるだろうし、レンタルのものはできないし、そもそも、面倒だからやりたくないｗ
てな訳で、またしても(普通の人には全くどうでもいい)泥沼にはまり込んだ今日この頃・・・
↓
(6/9 7:15追記) 昨夜、寝る直前に思い付いたのだが、IDとして各演奏に固有の識別記号を割り当てたいので、曲ファイルのダイジェスト(ハッシュ)値(例: MD5)をIDに使ってみたい。ただし、普通にファイルのダイジェスト値を使うと、それはタグ(例: 曲名)を変更しただけでも変わってしまって不便(タグを変えるとファイルとIDが合わなくなってしまう)なので、音響指紋のダイジェスト値を使うことを考えた。
ファイル名などをテーブルに記録して、そこでの通し番号などでIDを割り当てることもできる(GMBの方式)が、ファイルを移動したり名前を変えたらテーブルを更新しなくてはならないから不便だ。それを解消するために、曲のファイル自体にIDを持たせたい。そのためには、ファイル内(例: タグ)にIDを記録するか、ファイル名にIDを付加するか、上記のようなファイルの特徴をIDにするのがいいだろう。
IDをファイル内に記録する場合、既存のファイルすべてに記録する必要があって面倒なうえに、内容が変わらないのにファイルが更新されるのは嫌だし、今後、ファイルを追加するたびに忘れずにIDを記録しなくてはならないので煩雑だ。
ファイル名にIDを付加する(デジカメ画像の管理で実施している)のは簡便だが、既存の多くのファイル名を変えるのは好ましくない。例えば、GMBへの曲の登録をし直す必要があって、現実的でない。また、ファイルを追加するたびにIDを追加しなくてはならない煩雑さもある。
ファイルの特徴をIDにするのであれば、ファイル自体には何もしなくていいうえに、ファイルの中身を変更しない限り、あらかじめ決めた手順(計算)によっていつでも同じIDが得られるから便利だ。
音響指紋は、その名のとおり、(ファイルに格納された)音の特徴(だけ)に基づいているので、タグは無関係なはずだ。実際に試してみたら、本当に、タグを変えても音響指紋とそのダイジェスト値は変わらなかった(当たり前のことだが、結構うれしかった)。なお、当然ながら、異なる演奏は別の(音響指紋・)ダイジェスト値になった。ただし、同じ演奏でも、通常(CD)版とリマスター版やレコード版の音響指紋は異なったので、結構敏感なようだ。
この方式なら、IDはファイル(の中身の音)に固有だし、生成にも再現性がある(同じ音のファイルに対してはいつでも同じ値が生成できる)。ただ、音質や雑音などの条件が異なると「同じ演奏」でも同じIDにはならないが、そこは諦める(そもそも、GMBの中では重複した演奏(ファイル)は極力排除しているから、大きな問題ではないと思う。あるとすれば、リマスター版やレコードをオリジナル(CD)と同じと扱うかどうかの類だ)。
逆に、ダイジェスト値に衝突(偶然の一致、重複)が生じて、別の演奏に同じIDが割り当たる可能性はある。ただ、広く使われている方式でも(ハッキングを除いて)そういう問題が起こったという話は聞かないので、確率は低そうだ(また、音響指紋のデータは短いので、指紋の小さな変化でもダイジェスト値に反映されるから衝突は起こりにくそうだと想像するが、確証はない)。万が一衝突した場合は、(どうにかしてそれが検出できたとすれば、)IDに子番号を追加すればいいのではないかと思っている(と書いたものの、IDをテーブルなどで一元管理しないので、IDを生成した時点では衝突は分からなそうだ・・・ が、下に書いた変換テーブルで対応できるかも知れない)。
また、ISRCへの変換は変換テーブルで行う。その時に、重複した同じ演奏のIDに一つのISRCを割り当てることで集約できそうだ。
再生履歴DBでは、当初は、同じ演奏であっても、GMBのもの(音響指紋からIDを生成)とSpotifyのもの(ISRCからIDを生成)とは別のものとして記録するが、上記ISRCへの変換テーブルができたら、履歴などの情報を自動的にマージ(統合)したい(実際には、記録されたデータ自体は変更せず、DBの機能を使って統合されているように見せたい)。
と、またしても夢は膨らむのであったｗ (そして、例によって落とし穴が待ち構えている?)
(21:06 わずかに加筆・修正; 21:19 題の誤りを修正; 6/9 7:15 追記)
音楽再生履歴記録・検索システム(仮)を作りながら使っていると、いろいろなアイデアが浮かぶ。作ることや使っている時にバグが出て急いで直すｗのには結構疲れているが、アイデアを出すのはおもしろい。そういうものの例を書く。
Spotifyのミニプレーヤーのプログラムが複雑なうえに、作ってから時間が経ってしまって中身を忘れているので、このシステムを組み込む(「ミニプレーヤーをこのシステムに対応させる」が正しい)のが億劫なのだが、自動スキップや音量正規化の補正は外部プログラムでもできそうなので、手軽に試せそうだ。
アイデアを考えてもすぐに試さずに考えて(「温めて」)いると、アイデアだけでなく実際の使い方も良く考えるので、いい方法(例: 簡単に実現できる)とか更にいいアイデアに繋がるのがおもしろい。すぐに作り出すのもおもしろいけど、無駄になることが結構多いのも興味深い。考えるうちに、「なんだ、これいらないじゃん」と、不要なことに気付く機能すらある(こういう時は手間が省けるので、「マジで」嬉しいｗ 結局、僕はプログラミング自体やパソコンだの計算機に張り付くのが好きではないのだろう。知らんけど。だって、そもそも画面を注視したりキーボードを叩くことが目的じゃないからね。僕にしてみれば、上に書いたことを「やって」と指示したらすぐにできるものがベストだ)。
そして、このシステムは、最初は「まだ聴いたことのない演奏を手軽にSpotifyで検索する」ために作ろうとしたのだったが、検索機能の充実はそっちのけで自動スキップのようなアイデアに夢中になっていたり、検索にしたって、「嫌いなアーティスト・演奏は出て来ないようにしたい」と思っている(いた)ところを見ると、僕がいかに「嫌いな曲は少しでも聴きたくない!」、わがままな奴かが分かったのも、おもしろいｗ
PS. そもそも、システムの名前をちゃんと決めなくてはと思っているのだが、なかなか付かない(ただ、何も呼び名がないと不便なので、自分では"Tih DB" (Tih= Track info. and history)や"Tih web"などと呼んでいる。: 名前からも分かるように、基本的にはSpotifyを中心としたシステムではない)。ここまで決まらないものは珍しい。それだけ、コンセプトが確定してない、やりたいことが多いってことだろうか。まあ、音楽は奥が深いからね。
PS2. 別の(まじめな?ｗ)意味でのこのシステム作りでの大きな収穫は、DB(SQLite)とJavaScriptに抵抗がなくなったことだ。どちらも全く得意ではなく「ちょっと使える」程度だが、躊躇せず(「重い腰」を上げなくてもいいｗ)使えるようになった。DBは便利だとすら思って、他にもいろいろ使いたいほどだし、webはJavaScriptを使わないとできないことが多い(正確には、使わなくてもやればできるけど、ページ遷移が生じて鬱陶しくなるし、効率が悪くなってしまう)ので、仕方なく多用している。
PS3. 書こうと思っていたけど書けなかった、Spotifyの検索などのAPIがしょうもない件については別途書きたい。
(20:49 修正・加筆)
動作確認や修正や暇つぶしにSpotifyの再生履歴記録・検索システム(仮)のページを眺めていたら、なかなかおもしろいことがあった。単にテストのために思い付いて入れたのだと思うが、(ビートルズの)"Sgt. Pepper's"での検索結果を見ていたら、本物以外に数多くのカバーがあった。
それは当然だから驚きもしなかったし、ほとんどは「いかにも『カバーしてみました』」って感じで全然興味が湧かなかったのだが、数が多いのに感心して下まで見ていたら、2作、目をひくものがあった。一つはある意味恐ろしい問題作ｗ、もう一つは感心するくらい良かった。こんなに幅広いとは、さすがビートルズだ。
まず、「問題作」は、大場久美子のカバー(シングル)、"Sgt. Pepper's Lonely Hearts Club Band"(１９７９?)である。そもそもこの人がこれを歌う意味や理由が不明だったが、「怖いもの見たさ」で聴いてみた。が、あえて書こう、
ひどい・・・ 下手過ぎる。
数秒ではなかったが、(記録によれば)1/3くらいで止めた。もちろん、評価を-5(最低)にした。なんでこれが発売されているのか謎なレベルだ。そういえば、これの入っていたベスト盤の曲目を見て、「あれ? 『狼なんて−』とか、ヒットがあったはずだが・・・」と思ったあとで誤解に気付いたのだが、大場久美子は「コメットさん」ではあったが、石野真子ではなかったのだ(もちろん、浅田美代子でもない)ｗ 石野には大変失礼なことをした。
気を取り直して、次の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)
という訳で、このシステムの検索機能はまだまだ開発途上ではあるのだが、それでもいろいろ遊べることが分かって「ご満悦」であるｗ それ以外に、昨夜、やっぱりテストや好奇心で検索結果を見ていたら、今まで聴いたことがないラフマニノフのピアノ協奏曲第3番の演奏(Lukas Vondracekのエリザベートコンクールでの演奏, 2016)が見付かって、早くも本来の用途に役立ったから、改良すれば便利になりそうだ。※
※これを書くのに、その演奏が誰の何だったか調べようとしたのだが、履歴検索はまだ手軽にできなくて(SQLの一部を打ち込むので、気軽に日付で検索するなんてことはできない)ちょっと苦労したけど(日記やDBブラウザを見れば一発だが、意地で使ってみたｗ)、ちゃんと見付かった。
Spotifyの再生履歴記録・検索システム(仮)が大分できて来た。まだまだやりたいことは多いし、修正・改良すべき点も多いが、一段落した感じだ。
見た目が前回とほとんど変わらないのが残念だがｗ、7割くらいはできた気がする。それにしても、いつものことだが、体感で半分を超えると、ぐっと進みが遅くなる。できあがるにつれて、完成度を高めるために作業量が増えるうえに、動き出して使ってみると新しいアイデアが出てくるので、更に作る量が増え、そのために修正や動作確認をする時間も雪だるま式に増えて、逃げ水のようにゴールが遠くなる。
前回からいろいろやったのだが、見た目のインパクトが大きいものは、ボタン一発でSpotifyの再生履歴が出せるようになったことだろうか。前回は再生中の曲だけだったのを、(DBのコマンドを駆使して)指定した数の過去に再生した曲を取れるようにした。もちろんSpotifyアプリでも出るが、自分で作ったので随分使いやすい。例えば、評価やコメントをあとから手軽に書けるようになった。他には、webなので、タイトルなどをコピーできるのは誰にでも便利な気がする(もちろん、web版Spotifyでもできるが)。
あとは「できたてのほやほや」(でまだ満足に動かないｗ)のアルバム表示機能も便利だ。検索結果や再生履歴に表示されている曲のアルバム名をクリックすると、そのアルバムの曲が全部表示される(書くと当たり前の機能ではあるな・・・)。他に、Spotifyのアルバムやトラックへのリンクも表示するようにしたので、日記やブログで参照するのも楽になりそうだ(ミニプレーヤーでは簡単だが、アプリだとメニューを数段階移動しないと取れない)。
逆に、苦労して作ったけど意外に使っていないのは再生機能だ。これはアプリで充分だ。でも、そのうち検索機能(これが一番の目的なのだ)が充実したら使うかも知れない。
そして、今日の夕方くらいから、聴きながらコメントや評価を付けたり過去の感想を転記したりして、実際に使っている。自画自賛だが、なかなか便利だ。最初はそれらはDB管理アプリ(DB browser)で入力・修正していたのだが、段々使う機会が減って来た。
残件で大きいのは、ミニプレーヤーとの連携(履歴や評価のアイコンを出す、手軽に履歴を付ける、コメントを書くなど)だ。それから検索のプリセットの作成(今は検索条件にSQLの一部を打ち込んでいるのを、いくつかのパターンから選べるようにする)だ。
作っていて思い付いたのは、Spotifyのリコメンドでない、「自分のリコメンド」(履歴と評価をもとに、自分の好きな曲だけを選んで掛ける)を再生できるとおもしろそうだ。そこまでは行かなくても、意味があるかは別として、このシステムに自分のプレイリストが作れる。将来、別のプレーヤー(gmusicbrowser)とも連携できたら、プレーヤーをまたいで再生できるようになるからおもしろそうだ。
もう一つのアイデアは、嫌いな曲が掛かったら即座に自動で飛ばす機能だ。これはすごく便利そうだｗ ただ、たまに気まぐれで聴きたい時もあるだろうから、ある程度の猶予時間が要りそうだ。
ちなみに、このシステムを作ろうとしたのは、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"させてもらいたいｗ
でも、それとは関係ないけど、Googleの画面作り(配色・配置)は嫌いじゃないｗ このシステムのwebページの雰囲気が似ているのは、そのせい(好みの近さ)かも知れない。特に似せているつもりはないが。そして、ダークモードは大嫌いだｗ
あれから寝食を忘れてｗ作っていて、web(検索画面)が大分いい感じになって来た。何をどう良くしたのか、思い出したり調べて書くのも面倒だが、僕的には随分良くなった気がするｗ 例えば、評価を色の濃さで出す(図中の♥マーク)とか、平均「完奏率」(最後まで聞いたか)※を棒グラフで出すとか、前の投稿に書いたが、再生をwebでなくSpotifyプレーヤーでできるようにしたとか、トラック情報を開閉できるようにした辺りだ。まだまだやることは多いが、それなりの形にはなって来た。
※「「完奏率」(最後まで聞いたか)」は少し誤解しやすいので補足すると、1曲を最後まで聴いたら1、途中で止めたり飛ばしたら0なのではなく、止めたり飛ばした時点までの再生時間の曲の長さに対する割合が1回の完奏率になる。例えば、半分まで聴いたら0.5である。その合計を再生回数で割ったものが平均完奏率である。
プログラミングしていると時間がすぐ過ぎるし、おやつはもちろん食事も面倒になるから、ダイエットになるうえにお金も掛からないおから、いいことづくめだね。ってなんか、シャレにならないけど、そんなことはないよｗ これからの人は、みんなプログラミングするみたいだから、メタボになる心配はなさそうだね。頑張ってね!(爆)
↓
(5/19 20:58) その後もいろいろ改良していたが、見た目は劇的には変わっていない。Spotifyは、どうしてか、クラシック音楽の作曲者をアーティストに入れてしまうので、ミニプレーヤーでしているのと同様に削除するようにしたことと、「現在再生中の曲」をボタン一発で出せるようになった(図の中央上部の"Now playing")のと、評価をスライダーで設定する(図の右下)UIができたくらいだ。もちろん、普段はスライダーは出ていないし、評価を変えたらアイコンも色も変わるよ!ｗ (→ デモ動画)。HTML5のおかげで、こういうの(inputのrangeというのを使った)が手軽に(とはいえ、何度も書くが、HTMLだのJavaScriptは苦手なのでそれなりに苦労したがｗ)できるようになってありがたい。
今は、コメント欄もトラック情報や評価と同様にアイコン(ボタン)を押すと開いて入力できるようにしようとしているのだが、UIの概形ができたところで力尽きているｗ 不思議なことに、余り考えずに「これだとどうなるかな」とテキトーに作ったら、「こうなったらいいね」っていう感じに入力欄が開いたので、何かの奇跡かと驚いた。 ← イマココ(ってやつ)ｗ
体験談的なことを書くと、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も何とかなった。(→ デモ動画) 昨日から何も変わってないように見えるが、見た目を変えてないから当然だｗ あとはやっつけ仕事で作った下回りの処理(DBへのアクセス)などをちゃんとしたい。
コメント設定機能も動き出した。
それから、SQLiteへのネット経由でのアクセスは、rqliteというもので可能なようなことが分かった。その他に、socatとsqlite3コマンドを使って自分で実現することも考えられた。後者は全く面倒で安定性に欠けるから論外だが、前者は何となく筋が良さそうだった。が、他にも同様に「自分」に通信する必要があるもの(例: Spotifyでの再生)があるので、ひとまず保留にした。
(5/17 21:00 完奏率について補足; 5/19 20:58 現状を追記; 5/20 22:09 現状を追記)
piu lentoの日々 by PiuLento is licensed under a Creative Commons 表示 3.0 非移植 License.
他サイト・メディアからの文章・画像などの引用・転載については、本文の記述上必要な範囲に留めているつもりですが、問題があれば対応しますので、その箇所にコメントを記入するか、メールでご連絡下さい。
本ブログのスタイルは、SriniのEvanescenceとLilia Ahnerの"Minimalist Red"(MovableType用テンプレート)をベースにしています。Faviconは、猫とネコとふたつの本棚の猫のフリー素材部屋に掲載されている作品をico形式に変換して使用しています。
