piu lentoの日々 (piu lento days)

先日書いたspicetify-cliのCSSを改造して できるようにした。結局、Spotifyアプリの実体はHTMLで、元々はコピーできるのだが、なぜか無効にしていたので、それを再度有効にすればいいだけの話だった。

こういうことは今までにも何度も見た(例: Webで右クリック禁止)が、全くクソ馬鹿野郎だと思う。考えが浅はかだ。そうやってユーザーの利便性を落として、どういう意味・価値があるのか。そんなに自分の財産を保護したいなら、公開せずに後生大事に金庫にでも保存していればいいのに! もし意識せずにそうなったのなら、もっと低レベルだ。

文学作品だったら少しは分かるが、単なる技術的とか豆知識とかの類でコピペ禁止にしたって、嫌がらせ以外に何の意味もないよ。

文学作品や歌詞だって、データをコピーするのはユーザーの自由で、それを合法的に使うのには何の問題もないのに、最初から疑ってできないようにするのは ちょっと違うと思う。

CSSは得意でないので結構苦労したが、基本的には、CSS中でコピーしたい要素の user-select プロパティを text などに変更すれば良い。

苦労したのは、以前の版(現行もそうかも)のSpotifyアプリのCSSがぐちゃくちゃで、同じような要素が別のクラスになっているので、「探しては設定する」を何度も繰り返した(そこまでする必要はなかったが、ついムキになったｗ)。

参考までに、以下に、以前の版(1:1.1.68.632.g2b11de83)のSpotifyアプリに対するspicetify-cli(1.2.1)のデフォルトのテーマ(SpicetifyDefault)の改造版のuser.cssへの追加分を載せる。ただし、他にもいろいろ変更しているので、これだけではうまく行かないかも知れないし、残った(コピーできない)部分があるかも知れない。でも、基本的なアイデアはこれだけ(コードは長く見えるが、主要部分は下から2行目のたった1行だけ)だ。

/* Make texts selectable.: Butty */
/* Not effective/useful in some part (eg. tracks in track list). 
  Because, possibly, the draggable attribute is set by JS.: TODO */
[draggable] {
  user-select: unset;
}

#document, /* Not enough: Reset later by JS. */
/* For playlist page. */
.glue-page-header__content-inner, 
.playlist-content,
/* For album page. */
.Header__content, 
.AlbumRoot__content .glue-page-wrapper,
/* Sidebar and player control (bottom). */
.LeftSidebar, .view-player, 
/* Others. */
.tracklist-album, .tracklist-chart, .tracklist-basic, .tracklist-playlist, 
  .tracklist-podcast, .tracklist-popular, .tracklist-station, .tracklist-queue, .tracklist-search,
.HomeRoot, .MadeForYouRoot, 
.RadioHubRoot, .RecentlyPlayedPage,
.App__description, .app-content, .App__content, .App,
/* For credits. */
.CreditsModalContent
{
  user-select: text;
}

これで、マウスのドラッグやCtrl-Aで以下のようにテキストが選択でき、当然ながらCtrl-Cでクリップボードにコピーできるようになった。

Spotifyアプリからテキストをコピーできるようにした。(全選択した状態)

なお、サイドバーと下部のプレイヤー制御部が選択されていないが、別の要素のためのようで、どちらかの部分でCtrl-Aを押すと選択できる。

なお、思い付き+勢いでやってみたため、ちょっと不便なことがある。ボタンなどの余計なテキストも選択され、また、曲一覧の部分では思った部分がなかなかマウスで選択できず、特定の曲の選択が難しいのだ。これはHTMLの作り(JSで設定されたdraggable属性はCSSでは解除できない)と僕の未熟さのせいで、基本的にはちゃんとできるはずだ。

あと、全然見ない(ので忘れて居た)のと、一応 日本での取り扱い状況を尊重して、歌詞をコピーできるようにはしていない。

実際に使うか使わないかは別として、「(クソみたいな制限なんてせず、)できるものはできるままにしておく」ってのが僕の主義なので やってみた。

昔に比べていろいろ改悪された、現行版Spotifyアプリ(Linux版)。かなり嫌なのは、再生中にアイコン(以下、再生中アイコン)が ちらちら動き続けて目障りなことだ(→ 画像: 1曲目の緑の棒グラフのようなアイコン)。たまたま今日 アプリが更新されたので試したが、やっぱり変わっていなかった。それで、以前どこかのページで知った情報を思い出して、無理矢理アイコンを換えられないものかと試したらできた。

試したアプリのバージョンは、 1:1.1.68.632.g2b11de83 である。※

※アプリでは出せないので、 aptitude show spotify-client コマンドで表示した。

概要(ポイント)は以下のとおり。

• SpotifyアプリのUIは /usr/share/spotify/Apps/xpui.spa (以下、UIファイル)の中に入っている。
• 再生中アイコンはUIファイルの中の images/equaliser-animated-green.gif で、24x24pxのアニメGIF
• UIファイル(xpui.spa)はZIPファイルなので、問題のアイコンのファイルを交換して作り直せば良い。

再生中アイコンを置換する手順の例は以下のとおり。

1. UIファイル(/usr/share/spotify/Apps/xpui.spa)を展開する。
   1. cd ~/tmp
   2. mkdir -p sp-xpui-work/xpui
   3. cd sp-xpui-work
   4. ln -s /usr/share/spotify/Apps/xpui.spa xpui.zip
   5. cd xpui
   6. unzip ../xpui.zip
2. 展開したディレクトリ中の再生中アイコン images/equaliser-animated-green.gif を適当なものに交換する。
   • 条件: ファイル名はequaliser-animated-green.gif, GIF形式, 24x24pxであること。
     • ファイル形式はPNGでもいいかも知れないが、SVGは駄目だった。
   • アプリに合わせて、背景は暗く(黒系)、描画色は白などが良い。
3. 新しいUIファイルを作る。
   1. zip -r ../xpui-new.zip *
4. 新しいUIファイルを/usr/share/spotify/Apps/に置く。
   1. cd /usr/share/spotify/Apps
   2. sudo mv -i xpui.spa{,.orig}
   3. sudo cp -i ~/tmp/sp-xpui-work/xpui-new.zip xpui.spa

アイコンは既存のものでも構わないが、GIFで背景が暗い、丁度良いものがすぐには見付からなかったので、gimpで文字"♪"(サイズ: 22pxくらい)でテキトーに作った。

面倒なのは、アプリが更新されるたびにアイコン置換作業をしなくてはならないことだが、自動化できそうだ。

この手順(以前のアプリでも同様)でUIをいろいろ改造できそうだが、まだ良く見ていない。 → ちょっと見たら、JSは判読困難なので改造は難しそうだが、CSSなら何とかできるかも知れない。: 例えば、緑で気に入らない再生中の曲の文字の色を変えるのはできるかも。 → 思い付いた。標準の色遣い(テーマ)が暗くて嫌いなので、つい、ライトテーマを作りたくなるが、まあ、それは やり過ぎってものだｗ (9/23 11:33)

「やり過ぎ」と書きつつも調べたら、(Linux版)SpotifyアプリのUIは(以前の予想どおり)基本的にブラウザ版と同じようで、ブラウザのWeb Developer Toolsを使えば、下のように(難読化を解除して)要素が調べられ、ちょっと変えて試すことができそうだ。 (9/23 11:52)

ブラウザ版で再生中アイコンの元(URL)を調べた。

→ (9/24 15:37) 「ちょっと」試したが、挫けた。UIファイル(xpui.spa)中のCSS(xpui.css, vendor-xpui.css)の色を変えて明るくしてみたら、(テキトーにやった割には)結構うまく行き、これなら(もっとちゃんとやれば)行けそうだと思ったのだが、表示内容(例: Daily Mix)によってはウインドウ(曲リスト)の半分だけ暗くなってしまった。

更に調べたら、JS(xpui.js, vendor-xpui.js)の中でも色を設定していた。しかも、(難読化のせいかも知れないが、)同じ色の値が何度何度も書いてあって、なんとも腐っているサイコーなこと・・・ 素人かな? まあ、ツールで作ったりすると良くありそうな感じだが、なかなか付き合い切れない。

ただ、明るいテーマは なかなか爽やかで僕好みで捨て難い。が、苦労して色を変えても、アプリの更新で お釈迦になる可能性が高いので、あるアプリなりウインドウの色を実行時に変えるようなプログラムで色を変えたいが、そういうものはあるのだろうか?

↑ 色をグラデーションにしているので、単純な色の置換(LUT)では無理そうだ。 (9/24 17:33)

→ (9/24 19:17-9/25 12:30) 更に調べていたら、spicetify-cliというプログラムでテーマを変更できることが分かった。想像だが、これは上で僕がやったようにSpotifyのUIを展開して改造し、容易にカスタマイズできるようにているのだろう。デフォルトは(今は なき)GPMに似ていて懐かしい。

それで早速、僕のデスクトップのテーマ(Mint-X-Sand)に近付けてみた(spicetifyの古い版(1.2.1)は以前のSpotifyに対応しているので、そっちに適用した)。調整が不充分で見にくい箇所があるのと、ちょっと素っ気ないが(→ 調整し、テーマ(CSS)にも手を入れて随分改良した)、暗いよりずっといい。このプログラムは使い方のドキュメントが少ないが、いろいろ使えそうだ。

(9/26 7:09) 確かにspicetifyは使えるんだけど、Spotify同様なかなか余計なことをしてくれる。デフォルトはSpotifyのテーマを明るくするだけでいいのに、作者の好みで いろいろ変えてしまって(余程GPMに近くしたかったのか?: 個人的には、細かいところが「これは ないだろう」レベル)、それを戻すのに苦労した。まあ、苦手・嫌いなCSSの勉強(というか 付け焼き)には なったかなｗ

アイコンの交換は成功したものの、現行版には移らない。これはまあ、ちょっと思い付いたからやった、暇つぶしのお遊びだｗ

というのは、確かに以前は効かなかった、前・後ページのショートカットキー(Alt+←/→)が前の版で直ったが、依然として検索などで日本語が入力できないし(これは古い版でも同様)、左ペインでプレイリスト一覧がごちゃついているのが気に入らないからだ。それらが直ればいいが、まあ無理だろう。他に良くない点(例: 音が悪い)がなければ、百歩譲ってそれらを我慢して移行するのもありかも知れない。が、特にいいことはなさそうなので、古い版が動かなくなってからでも良さそうだからだ。

(9/23 5:12 画像を改良, わずかに加筆・修正, 9/23 9:48 わずかに加筆・修正, 9/23 11:33, 11:52 少し加筆, 9/23 16:07 PSに加筆して まとめとした。)

昨日、Linuxのメモリ消費が多くなって来たので※再起動したら、青天の霹靂。なぜかSpotifyアプリが激変してしまった。

※いろいろなアプリがメモリリークしていて、長期間動かすとそれが溜まるせいだと思う。

今考えると、おそらく少し前にアプリが更新されていた※のだが、アプリを再起動していなかったので更新が反映されなかったのではないかと思う。そういえば、3月末辺りに"Made for you"が変わったのは、これの関係だったのかも知れない。その変更の時は、「なかなか良くなった」と喜んでいたのだが・・・

※問題のバージョンは1:1.1.55.498.gf9a83c60

少しいじっただけで、以下のような違いに気付いた。

• なくなったショートカットキーがある。
  • 例: 前・後ページ(表示内容)への移動 (Alt+←, Alt+→)
• 設定のAboutがなくなったので、バージョンが表示できない。
  • 細かいことだけど、「どうよ」と思う。
  • 前の版に戻して(後述)気付いたのだが、実はAboutはあったけど気が動転して気付かなかったのかも知れない。
• ライブラリにMade for youのタブがなくなった。 → Homeから表示しろってことだろうか。
• 画面のデザインが煩雑になってしまった。
  • Web版に近い気がする。
• 起動時にdevilspieでの位置指定が効かない。
  • 起動後は効くので、起動時のアプリ名が変わったのだろうか?

ショートカットキーがなくなったのは とても不便だ。今までは、マウスジェスチャ(右クリック+左/右ドラッグにAlt+←/→を割り当てた)でページ切り替えしていたのができなくなってしまった。

すごく不便なので、何とか対処したいが できないだろうか? xdotoolで試したが、それらのショートカットキーの対応自体がなくなった感じだ。

デザインはまさに劣化と感じる。その劣化度は、以前のがどうだったか思い出せないくらい強烈だ。。。 一番嫌なのは、再生中の曲の左のアイコンがちょろちょろ動くことだ(画像の黄色い円の中)。ひょっとしてアニメGIF? 90年代じゃねーんだよ!! そもそも、ページに画像や色が無駄に多くて全く鬱陶しい!!! 鬱陶しいので余り表示させたくない。

以前のが簡素過ぎたのかも知れないが、目障りでない点ではずっと良かった。

それで、試しに(、デザインがどうだかは分からないが、)Winodws版アプリをWineで動かそうとしたら、「管理者アカウントではインストールできない」というエラーとなって、諦めた。。。

不思議なのは、この劣化を検索しても出て来ないことで、誰も気付いていないのか、多くの人は新しいデザインが好きなのか、Linux版を使っている人がすごく少ないのか、僕の環境がおかしいかのどれかだ。

想像だが、Linux版のメンテが面倒になって、UIに関しては基本的にweb版を表示するようにして手を抜こうと思ったか、逆に、下手に頑張っちゃってLinux版をWindows版に寄せたか共通化してしまったのかも知れない。

今はまだ耐えられるけど、更にLinux版の手抜きが進んで、消滅(Evernoteのように「Web版を使ってね!」)という憂き目になったら すごく困るな・・・ その時はまた「移動」かも知れないな。もちろん、行く先があればだが・・・

↓

とりあえず、(クソな状態で使いたくないが、そんなのに対応するのは時間の無駄だし そんなパワーもないので、)アプリを前の版に戻したら(コマンド例は下記)、当然ながら元の表示・動作になった。ただ、いつか使えなくなりそうだ。

sudo aptitude install \
spotify-client=1:1.1.42.622.gbd112320-37

Spotifyアプリを前の版に戻して、平和が戻った。

即座に更新マネージャが更新の案内を出したが 「無視」にして、しばらくは これで お茶を濁そう＾＾

年末の風物詩?、Spotifyから今年のまとめ、「音楽で1年を振り返ろう。」が届いた。残念ながら去年より簡素になってしまって、去年は自分用のwebページに華々しく記録が書かれていたのだが、今年はちょっと賑やかなメールだけになり、送られて来る記録的な内容は聴いた(掛けた)時間(62,262分 → 約2.8時間/日)だけで曲数(延べもユニークも)は分からない。他には各自のプレイリスト"Your Top Songs 2020"で順位を参照できるだけになった。その順位が何に基づくのか(例: 再生回数)も分からない。: (Amazonだけでなく、)Spotifyも作っている人が変わったのか、経営状態が良くないのか。

まあ、そういうこともあろうと(でもないが)、僕にはMlhiという自作の再生履歴記録システムがあるので、履歴は ばっちり記録されている。その活用については下に書く。

Spotifyによれば、今年最も再生した曲は、意外にもポールとスティーヴィー・ワンダーの"Ebony and Ivory" (1982)だった。確かに良く掛かっていた気はするし、嫌いな歌ではない。ちなみに、マイケルとの"Say say say" (1983)も好きだが(当時は嫌いだったｗ)、なぜか10位以内には入っていなかった。参考までに5位までを載せる。それぞれに、Mlhiで調べた再生回数(後述)も示した。

1. Ebony and Ivory (Paul McCartney & Stevie Wonder, 1982)
   • 全96回 (2020年: 79回)
2. My love (Wings, 1973)
   • 全85回 (2020年: 74回)
3. Band on the run (Wings, 1973)
   • 全78回 (2020年: 72回)
4. Jet (Wings, 1974)
   • 全73回 (2020年: 70回)
5. Maybe I’m amazed (Paul McCartney, 1970)
   • 全72回 (2020年: 69回)

と、まあ、見事なほど「ポール一色」だ。いや、嫌いじゃないけど大好きって訳でもないんだが・・・ なお、10位までには、他にELOとBad fingerしか入っていない。ビートルズはどうしたんだろうか??

それから、去年はどうだったかというと(去年のブログの画像より)、

1. The power of love (Huey Lewis & the News, 1985)
2. 初恋 (村下孝蔵, 1983)
3. More than a feeling (Boston, 1976)
4. 夏をあきらめて (研ナオコ, 1982)
5. Mr. サマータイム (サーカス, 1978)

全然違う。。。 気付いていなかったが、今年は去年から10年くらい過去にさかのぼって70年代がメインだったようだ。あと、去年はなぜか、熱・暑(苦し)そうｗとか夏っぽい歌を良く聴いていたようだ。

もちろん、ここまででは終わらないｗ 今年のプレイリスト(順位)を見ていて、再生回数の順位なのか順不同なのか分からなかった(プレイリストに再生回数が出ていない)ので、Mlhiで調べてみた。Mlhiのwebで検索したりDBにアクセスすれば再生回数は簡単に出るが、「最初」からの回数なので、今年の分は手で計算した。すると、概ねSpotifyの順位に合っていたので、Spotifyは再生回数でソートしたようだ。

ところで、調べていて、妙なことがいくつかあった。

"Ebony and Ivory"はMlhiには2つの曲(演奏)が入っていて、Spotifyのリストに載っていた演奏は全44回だが、もう一つ(SpotifyのIDが異なる)は全52回だった。※ なので、Spotifyはどうにかして「実質的に同じ演奏」を統合してカウントしているようだ。

※なお、それらは異なるアルバム(オリジナルとベスト盤)に入っており、リマスタリングしたせいか、ISRCも異なっている。また、Spotifyのリストはベスト盤のを載せていた。

"Maybe I’m amazed"は、最初はMlhi(webもDBも)では検索できなかった。いろいろ試すと、 ' の文字が違うためだった。分かるかどうか分からないが、 ' には開き、閉じ、垂直なものの3つがあり、この曲の表記(閉じ?)とキーボードから入る文字(垂直)が異なるために検索に出てこなかったのだ(曲名をSpotifyからコピー・ペーストしたら出て来た)。他には " も同様だし、Unicode全体だともっと多そうで、結構深そうな問題だ。

そう言えば、論外な話だが、日本語の曲名の濁点を " にしてしまって、「眼(まなこ)はタ"イアモント"」(あくまでも仮の例)のように出る、残念な曲もあった(それだけでなく、カタカナを半角にしていた気もする・・・ ← 別の曲だったかも知れない)。日本のレーベルが配信に出す時にテキトーに打ち込んでしまったのか(さすがにないか)、そのレーベルが元々そういう残念な管理なのか、そして、(書いたあとで気付いたのだが、)半角カタカナを全角に直した名残りなのか。いずれにしても、これでは全然検索できない・・・

余談だが、こういうのは日本だけかというと実はそうでもなさそうで、海外ではdiacritical mark(ウムラウトなど)の表記方法(特に、別の文字で代替する場合)もいろいろあるようで、そこで問題になりそうだ。

更に謎なのは、10位だった"Listen to what the man said" (Wings, 1975)はMlhiのwebでは検索できなかった。確かにDBには入っているのだが。いろいろ調べると、どうやら、近頃Spotifyの演奏が新しい版に入れ替わったためのようで、Spotifyの検索をしないようにしたら出て来た。

DBに入っているものと2020年のリストに入っているのは"Listen To What The Man Said - 1993 Digital Remaster" (ISRC:GBCCS0700283)だが、今Spotifyで検索して出て来るのは"Listen To What The Man Said - Remastered 2014" (ISRC:GBCCS1400011)である。

音楽配信はダイナミックに中身が変わることの典型だろうが、これも意外に深そうだ。再生すると確かに同じ曲が演奏されるが、以前聴いたものとは違う版だということが起こる。この曲は以前の版も残っているが、完全に置換されてなくなっているものもあるだろう。そこにこだわるマニアは、CDなどを買って それぞれの版を手元に残す必要が出て来る(が、僕はもういい)。

ついでに、Mlhi全体、つまり、Spotifyとgmusicbrowser(以下GMB)を合わせた順位を調べてみた。これもDBで簡単に出せる。ただし、記録フォーマットの関係で今年だけの分を抽出するのは面倒なので、「最初」から(Spotifyは2019年から、GMBは2016年から)にした。また、テストで何度も少し掛けた曲があるので、再生回数でなく、完奏率×再生回数(→ 「好き度」みたいなもの? または、何度掛けても途中で止めなかった → 気に障らなさ → 当たり障りのなさ?= 「ポップ度」??)で順位を付けた。それぞれの曲名の下の数字は完奏率×再生回数である。

1. My love (Wings, 1973)
   • Spofity, 86.0
2. Come together (The Beatles, 1969)
   • GMB, 85.8
3. Band on the run (Wings, 1973)
   • Spofity, 75.15
4. Here comes the sun (The Beatles, 1969)
   • GMB, 74.7
5. Piano concerto No.2 in C minor Op.18 : III Allegro scherzando (Lugansky, 2005)
   • GMB, 74.45

やっぱり、意外なほどポールが強いｗ そして、ビートルズはGMBで聴くことが多かったようだ。また、大好きなルガンスキーのラフマニノフのピアノ協奏曲もGMBで聴いている。

参考までに、上の順位は以下のようなSQLで出した。

select track_id, title, artist, album, 
  played_full_tot, played_full_tot/played_cnt, played_cnt 
from trk_info_hist
where played_full_tot is not null
  and played_full_tot <= played_cnt
order by played_full_tot DESC limit 0,20;

再生履歴をDBに記録しておくと、(趣味的に)おもしろく便利だ。一方で、「年ごとの順位を手軽に出したい」といったようないろいろな要望や思わぬバグも出て来て、なかなか先は長い。 (でも、記録していることに安心して、なかなか手を付けないｗ)

PS. MlhiのDBに登録された曲は8千曲近くなった(去年の中頃から記録し始めたため、去年の今頃は4500曲だった)。DBのサイズも大きくなって、約5MBになった。それでも、まだまだ小さいうちだから問題なさそうだ。

夕方にSpotifyが時々音切れして直らないので、アプリを再起動したら、なぜか、SpotifyのDaily mixが様変わりして、今までは1-6までプレイリストがあったのに、アーティスト名のものだけになっていた(参考: 昔の状態)。そういえば、今朝辺りから やたらにビートルズが掛かっていたのは、それだったのか。

まあ、それに気づかず「Spotifyも僕の好みが分かってきたじゃん」と思って居たから結果的にはいいけどｗ、なくなってしまうと寂しいし、アーティストのプレイリストは今までの数字のものとは全然違うものだから困る。

Androidアプリでも同様だったので、システムのトラブルか仕様変更か。ただ、検索しても誰もそれに触れていないようなので、僕だけの問題なのかも知れない。

もう少し様子を見よう・・・

なぜか、SpotifyのDaily mixが様変わりして、アーティスト名のプレイリスト(mix)だけになってしまった。

↓

(12/3 8:42) 実は、Daily mixの名前の付け方が変わっただけなのかも知れない。つまり、今までは"Daily Mix 1"という番号の名前だったのを、"Queen Mix"のように、そのmix(プレイリスト)のメインとなるアーティスト(大抵は最初の曲のアーティスト)を名前にすることにしたのか。※ それなら、僕の選び方(最初の数曲で「グッ」と来るか)に合っているから歓迎だが、本当にそうなのか(何となく、名前の付いたアーティストに偏っている気がする)。プレイリストとは別に、各アーティストや曲などでのラジオ(例: "Queen Radio")もあるので ややこしい・・・

※Spotifyの説明には、今も、「最大6個できる」とあり、確かにアーティスト名のプレイリストは6個ある。

なお、元々の音切れも原因が分からないが、通信速度を測ったら変動が大きいことがあったのと、今は直っているので、たまたまネットが混んでいたのかも知れない。

気付いたら、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)は高音(シンバルなど)が ちゃんと聞こえる(切れ味が鋭いが、うるさくない)。

気付くと、いくつかのことをばっさりと捨てていた。例えば・・・

• 映像(TV・映画など)
• 本(文学など)

その他に、速い車、自炊、自転車、プリンタ、手帳、紙の写真、賀状、見栄を張る・格好つけること、(無理のある・無意味な)人付き合いなど、書き出すと随分いろいろあるが、ここは文化・芸術的なことに絞る。そういうものではピアノを手放したが、諦めたからで、なくてもいいから捨てた訳ではない(ものすごい余裕があれば、大きなグランドピアノ(フルコンとは言わないが、(サイズとして)C7くらいは欲しいな)を眺めて暮らしたいｗ でも、見るだけじゃ詰まらないな。まあ、ご飯は進みそうだがｗ)。

映像は全く観ない訳ではないが、なくてもいい。そもそもTVもビデオプレーヤーもない。好きな映画はあるが、あらすじやシーンなどを思い浮かべたり、検索してちょっと見る程度でいい(おそらく、後述の脳内演奏同様、記号化されて頭の中に格納されているのではないか)。映像に近いものとして、劇は捨てたつもりはなく、機会があれば観たいが、「(手配とか面倒だし、大体分かったので)まあいいか」って感じだ。

それらの代わりに音楽があればいい。ただ、オペラは(僕には)要らない(やっぱり面倒だ)。聴くだけでいい。「脳内演奏」(演奏しなくても、「パブロフの犬」とかレモンや梅干しのような場合もある)でもいい※。更に無音があればいい。

※そういう意味では、以前やりたいと書いた「脳内演奏」はできている。脳内で完璧に演奏しなくても良くて(その必要はなく)、自分の好きな曲を見付け、その自分好み(本当は「作曲者の意図どおり」であるべきなのだろうが)の演奏を見付ければ、あとはOKだ。それ以上CD(演奏の記録)を買う必要も、コンサートに行く必要もない。だから僕にはSpotifyのようなサービスがとても合っている。今朝、散歩中にそういう結論になった(今はね)。

本は意図的に捨てたのではなく、「読めない身体(頭)」になってしまった。数行とか一ページくらいで、「じゃあまたあとで・・・」になってしまう。本の価値を否定する訳ではなく、読めれば読みたいけどやっぱり読めないし、(自分としては)それまでに随分読んだから、読まなくても「まあいいか」って気はある。

それについて大変思い上がったことを書くと、映像作品も文学作品もいろいろなパターンを知ってしまって、それ以上にすごいとか新奇とかおもしろいものがあるとは思えないのだ。音楽にも同様の感はあるし、それどころか、日々の生活ですらそうだ。いや、実際には新しいものはあるとは思う。僕の興味とか頭の硬化の問題だと思う。

そして、今のところ、絶対に捨てられないのはPCだろう(「スマフォでは駄目なんです。キリッ」ｗ)。以前も書いたが、そのことが非常時には結構なリスクになる気がする。とはいえ、PC一式をかついで避難することはできない(ノートPCも余り好きじゃないし、そもそも通信回線がない)ので、どうにもならない。

PS. そういう訳で、手持ちの映像作品のDVDなどは、ここ数年全く観ていないから処分したい気もするが、一応好きで買って思い入れもあったので、どうにも決断できない。その時は、ここ数年全く触ったことのないCDも一緒に、一気に処分したい。更に、心理的抵抗は岩のように大きいが、(プレーヤーすら持っていない)レコードも処分したい。そうしたら結構物が減るだろうな。

PS2. グランドピアノの価格を調べたら、意外に安かった。ヤマハのC7Xは350万円と、ちょっとしたいい車より安い。調律は要るが(弾かなければ不要だが)、ガソリンもオイル交換も不要だし、税金も保険も車検もないから、維持費も安そうだ(いやいや、実際には空調の効いた頑丈な部屋が要るけど)からお買い得だ。だけど、やっぱり、一台持つとしたら、兎にも角にもスタインウェイだろうｗｗｗ (すると、値段はきっと一桁上になるんだろうな・・・)

ちなみに、重さも車よりずっと軽くて、C7クラスだと400kgくらいしかない。軽より軽いじゃないか(爆)

(結構前に書き出したが、発展させるのが面倒になったのと、他のネタが熟成中なので、主に脳内演奏について加筆して公開した。)

ここ数日、「例のトリッキーなやつ」(先日の投稿の、Spotifyアプリのログから音量正規化のための値(RG値)を抽出して正規化する方法)が諦めきれず、悪戦苦闘していた。何度も諦めたのだが、そのたびにアイデアが出て来てしまって再挑戦する羽目になり、今日は随分いい感じになったのたが、やっぱり駄目だった。

記念(または証拠)に、最良の状態での動作光景を載せる。画面左上はRG値取得用Spotifyアプリ、右上はミュート(上側)・ゲイン調整+リミッター(下側)用アンプ、左下はミニプレーヤー、中央から右下は再生用Spotifyアプリである。曲間でのアンプの設定の変化や、プレーヤーの切り替わり(アプリ下部の緑の帯)に着目されたい(もちろん、手で操作している訳ではないし、マウスなどを自動操作するツールを使っている訳でもない)。

Spotifyアプリから音量正規化のための値を抽出して音量正規化している画面

動作の流れは以下である。

1. Spotifyアプリ(音量正規化: off)が再生を開始する(またはトラックが変わる)のを待つ。
2. アンプでSpotifyアプリの出力をミュートする。
3. プレーヤーをRG値取得用Spotifyアプリ(音量正規化: on)に切り替える。
4. その曲のRG値が取得できるまで(再生して)待つ。
5. アンプにRG値を元に計算したゲイン(増幅量)を設定する。
6. プレーヤーを再生用Spotifyアプリに切り替える。
7. 曲の先頭に戻る。
8. アンプのミュートを解除する。
9. 再生を開始する。

基本動作はできた※のだが、試しに少し(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切り替え時にアプリを再起動したくないからこの方法にしようとしたのに、(再生用ではないけど)やっぱり再起動が要るのでは馬鹿らしい。それに、上に書いたように、タイミングが変動して安定して動かないのでは、とても実用にはならない。

そんな訳で、結果的には無駄なことをして疲れたが、いろいろ(細かい)発見があっておもしろかったせいか、余りがっかりはしていない。むしろ、事前の予想どおり駄目だったものの、基本的には目論見どおりに動作して満足したし、方が付いてせいせいしたｗ

最後に、開発中に分かったことなどを少し書く。

• Spotifyアプリを外部から制御するにはWeb APIとDbusの2種類でできるが、プレーヤーを切り替えて使う場合はWeb APIだけを使った方がいい。Dbusで操作すると、どのプレーヤーが対象か分からなくなったり、意図したプレーヤーが操作されなかったり、プレーヤーの切り替えがうまくいかない場合がある。
  • Web APIはかなり遅い(数百ms/回)のでDbus(数十ms/回)で高速化したかったのだが、残念ながら駄目だった。
• SpotifyのWeb APIを短時間に頻繁に使うとサーバがエラーを返すようだ(本文に書いたエラーもこれと同様)。HTTP 500なのでアクセス制限(rate limit)ではないようだが・・・
• 更に、頻繁に使わなくても謎の動作をする場合がある。Dbusを使わなくてもおかしくなることがあるようだ。
• 曲の開始直後に先頭にシークすると前の曲にジャンプしてしまうようで、少し待たないといけないようだ。
• Linuxのサウンド系には謎の損失(音量低下)があるようで、どこかで4dBくらい音量が下がる。PulseAudio(実際にはALSA)からJACKに入るところか、JACKからサウンドカード(実際にはALSA)に出るところかと想像している。
  • ポップ音楽用の音量正規化の場合、目標の音量をReplayGainと同じ-14LUFSにしたので、理論上はアンプのゲインをRG値そのものにすれば良いはずなのだが、この損失を戻すためのゲイン(4.5dB)を加算した。
  • なお、クラシック音楽用ではその損失を加味して、4dB下げるだけで目標の音量(-23LUFS)になった。
• (書いても誰も分からない気がするが、)本方式の制御プログラムでは、2つのイベント入力(SpotifyアプリのログとDbusのイベント)を混ぜて受信することで、両方ともタイムアウトなしの受信にすることができ、イベントに対するレスポンス時間の短縮と負荷の軽減ができた。でも、本文に書いたように、高速化したら逆効果だったようだｗ

PS. それにしても、昨日(12/29)までは年末という気がしなかったのだが、今日(12/30)になったら急に「今年ももう終わりか」モードになって、妙に慌ただしい気分になってしまった。そして、「年末なのにプログラミングなんてしている場合かっ?」て気もしたが、特に他にすることもないので問題ないｗ

Spotifyの音量正規化の改良では散々試行錯誤したが、ようやく自分が納得できるかたちで実現できた。もちろん、結果(性能)も全く問題なかった。音量(Integrated loudness)の値は全く問題なかったし、随分聴いてみたが、(自作とは全然違って、)我慢できないほどうるさい曲(演奏)※も小さ過ぎるものもなく、随分手を焼いていた曲もあっさり大丈夫だった。これなら気楽に聴いていられそうで、ようやく目的が達成できた感じだ。

※正確には、「うるさい」と感じる演奏はある。が、その音量値は全く異常でなかった。ということは、音作り(周波数分布や音質の悪さ? いわゆる「海苔波形」?)によるのか、僕との相性が悪い(音の好みや聴覚のラウドネス特性とのズレ?)のだと思う。実際、不思議なことに、アンプの音量を小さくしていても、いつもうるさく感じる演奏はやっぱりうるさく感じる。つまり、「うるさい」は音量が大きいだけではないということだ。まあ、語義からしても当たり前か。

以下に試行錯誤の経過や内容を書く。

前回の投稿ではSpotifyの音量正規化のNormalとQuietを手で切り替えて使うと書いた。そして、前回も書いたが、音量を揃える(増やす)ために増幅してもそれほど音質が劣化しないことが分かったので、その方法を詳しく検討した。基本的には、単に(ソフトの)アンプで増幅すればいいのだが、使う要素(アンプの種類)や増幅する量を最適にしようとしたのだ。

まず、以下を試した。増幅量は+11dB(-23LUFSを-12LUFSにしようとした)にした。

• JACKのjack_mixerのボリューム:音は悪くない感じがした。 → その後、長時間聴いたら耳閉感が起こった。
• PulseAudioのボリューム (Spotifyのsink-input):音が悪い感じがした。わずかに耳閉感が出た。

PulseAudioでの増幅で音質劣化がありそうだったので、何種類かの増幅量で歪率を測定したが、オーバーフロー(0dBを超える)しなければ(+15dBくらいまで)は問題なさそうだった。それで、実際の曲で試したら、ポップ音楽でも意外にダイナミックレンジが広いようで、+9dBでも簡単にオーバーフローした。

それで、リミッターでオーバーフローしないようにすることにした。PulseAudioで増幅してオーバーフローすると、その時点で歪んでしまうので、あとにリミッターを入れても無意味なので、JACKのアンプ+リミッターの構成にすることにした。リミッターにもいくつかの種類があり、以下でオーバーフローさせて試したが、いいものは少なく、結局、Fast Lookahead limiterを使うことにした。これには入力にゲインがあって、それがアンプの役割をするので丁度良かった。

• Fast Lookahead limiter: 一番いい感じ。過大入力でも、自然な音で0dBを超えないように制限される。
• Wave Shaper (Sine-Based): 過大入力(例: +17dB)で音が変わる(歪む)。
• Simple Limiter (Peak Env. Track.): 過大入力(例: +17dB)で「ワウワウ」になる。
• Calf Sound GearのCalf Stereo Tools: 最初は良かったが、長く聴いたら耳閉感が起こった。
  • 後述のNon Mixerにした時に、バイパス機能とSoftClip(リミッター)があるので試した。

それから、Spotifyの音だけを増幅したいので、SpotifyのJACKへの出力を独立にし、更に、ポップ音楽用とクラシック音楽用で増幅をon/offする必要がある。

その前に、いつも評価用に使っている曲をSpotifyの正規化(Quiet)+増幅(+9dB)で試したところ、殆どのポップ音楽は問題なかったが、"Speak to me"は駄目で、Normalと同様な不自然さがあった。原因を調べたら、前回の投稿の付録に詳しく書いたが、オーバーフローがリミッターでカットされる時間が長いためだと分かった。それで、増幅量を+6dBに減らし、リミッターの回復時間を長く(2秒)にすることで不自然さを緩和した。回復時間を"Speak to me"の鼓動の周期より長くすれば、ずっと音量が下がったままになるので、不自然さが緩和されるのだろう。完璧ではないが、"Speak to me"のような曲は例外的だから許容できると考えた。ただ、他の曲が不自然になるかも知れないので、その時に調整したい(今のところは問題ない)。

結局、以下の3つのモードを作ることにした。

• ポップ音楽向け: Spotifyの音量正規化(Quiet)+増幅(+7dB)
• クラシック音楽向け: Spotifyの音量正規化(Quiet)、増幅なし
• 音量正規化なし: 増幅なし

ポップ向けでの増幅量について: 通常のReplayGainで正規化する(あるいは、0dBまで目一杯出す)他のプレーヤー(具体的にはgmusicbrowser, GMB)と音量を揃えるにはなるべく上げる方がいいが、前述したオーバーフローによる劣化も嫌なので、試行錯誤(勘?ｗ)で決めた。+7dBだと、SpotifyのQuietモードでの基準音量 -23LUFSを-16LUFSまで上げることが期待できる(当初は+10dBして-13LUFSくらいにしたかったが、やり過ぎのようだ)。

3つのモードはミニプレーヤーのボタン(右端の"Sp", "S", "-")で切り替える。音量正規化の有無はSpotifyを再起動すればいいが(とはいえ、重いから避けたかったが、それ以外に方法がないので仕方ない)、JACKのアンプで外部から制御できるものがなかった(後述するように、実はそうではないが、当時はそう思っていた)ので、増幅の有無の切り替えが困難だった。それで、接続(配線)を変えることにした。簡単に書くと、以下のように切り替える。

• 増幅あり: Spotify → アンプ → ミキサー → 補正用イコライザ → 出力
• 増幅なし: Spotify → ミキサー → 補正用イコライザ → 出力

なお、なるべくSpotifyを再起動しないで済むように、右クリックで音量正規化モードの切り替えを逆順にできるようにしたのだが、順番を覚えていないためにやっぱり再起動になる羽目になるので、マウスオーバーでガイドを出すようにした。

なお、プログラム(xdotool)でリミッター(アンプも兼ねる)のEnableボタン(中央付近)を押すことでも、増幅の有無の切り替えが可能なので試してみたのだが、勝手にマウスが動くと(その後自動で元に戻しても)結構ストレスに感じるし、その時の操作状態によっては誤動作・操作することもあるので止めた。

その後、モード切替のたびに接続(配線)を変えるのは全然スマートでないし、遅いし、JACKサーバへの負荷が重そう(頻繁に繰り返すとおかしくなりそうな気がした)なので、避けられないか考えた。それで、以下の2種類を順に試した。

1. OSC(Open Sound Control)という仕組みで外部プログラムから制御可能な、Non Mixer(エフェクタも入れられるミキサー)を使い、リミッターの増幅量を変える。
   • Non Mixerはエフェクタのon/off(Bypass)を外部プログラムから制御できないので、増幅なしの場合にはリミッターの増幅量を0dBにすることで、offの状態にした。
   • この方法には実用上は何も問題がなく、充分良かったのだが、微妙に気に入らないために別の方法を探して、次の項のjack-rackになった。例えば、以下が気に入らなかった。まあ、車で言えばトヨタのように、「ソリが合わない」ってやつだろうかｗ まあ、jack-rackが駄目なら戻ればいい。
     • 外部からBypassが制御できない。ゲインでもできるけど、何か直接的でない。
     • 大げさ: ウインドウが無駄に大きいけど小さくできない(確か、一番幅を狭くした状態がこれ)。
     • 名前が悪い(結構真面目に良くない)。「おフランス」なのだろうか?
2. MIDIでjack-rack(エフェクタを入れるソフト)を外部プログラムから制御し、リミッターのon/offを切り替える。
   • 試行錯誤の結果(以前試した記録が役に立った)、MIDIを使う方法が分かり、どうにかjack-rackも制御できるようになったので、リミッターのon/offが外部から制御できるようになった(図のEnableボタンを押すのと同じ効果)。
     • ただし、ちょっとしたバグがあり、jack-rackの起動後にMIDI設定のダイアログが出てしまうが、仕方ない(これを自動で閉じるようにしたら動作がおかしくなってしまったので、手で閉じることにしている)。
     • ↑面倒だし目障りなので、xdotoolで"OK"ボタンを押すようにして自動で閉じるようにした。ただ、ウインドウサイズが変わると予期せぬ事態が起こりそうだ。 (18:19)

MIDIについての特記事項を以下に列挙する。

• JACKサーバ: MIDIドライバ(midi-driver)に"seq"を指定する。
  • 上記設定をすればa2j_control(a2jmidid)は不要と思われる。
• MIDIの配線: 当然ながら、JACKで、外(ALSA?)からのMIDI情報の出口(僕の環境では"Midi-Through:midi/playback_1")と制御対象の要素(jack-rack)を接続しておく(図左側の赤線)。
• MIDI制御情報の送信: sendmidiコマンドを利用した。他にもあるが、僕には一番使いやすかった。
  • 実行例: sendmidi dev "Midi Through Port-0" ch 1 cc 0 0: (僕の環境・設定において)jack-rackの"Enable"をoffにする。
    • 注: 上記MIDIデバイス名はJACKでのもの(一つ上の項に書いた)とは異なる(ALSAのもの?)。sendmidi listコマンドで名前を確認すること。
• jack-rackの設定: 制御したい要素(例: ボタン)上で右クリックすると設定ダイアログが出るので、そこにチャネル番号(sendmidiのchに指定する番号)とコントローラー番号(sendmidiのccに指定する番号。正式な名称は不明)を設定する。
  • この方法がなかなか分からなくて諦めていたのだが、jack-rackのgithubのページでようやく分かった。
  • Enableについては、設定値に127以上を指定しないとEnable状態にならない(Disable状態にする時は0でいい)ので、0と256を指定することにした。
  • あとで使うかも知れないので、Input gainとWet/dryも設定できるようにした。
• どうしてか、(音と違って)JACKでの正式なMIDIのポート名は"system:midi_playback_1"のような分かりにくいものになり、起動のたびに番号が変わる感じで(要確認: 思い違いかも知れない ← クライアント(jack-rack)側の名前の番号は、起動順序で変わるのかも知れない)、自動で配線を保存・復元する機能がうまく動かなかった。それで、現在使っているMIDIの線は1本と少ないので、自動保存・復元の対象にせずにJACKの起動スクリプトで個別に配線することにした。
  • JACKの設定などで直るのかも知れない。
  • ↑JACKの設定ではなく自動で割り振られるようなので、JACKサーバ起動時にMIDIポート名の変換テーブルを作り、接続の自動保存時に、そのテーブルを元に、クライアントの起動順序で変わらないポート名(alias)に変換して保存するようにした(変換後の名前でも接続できるので、復元は問題ない)。 (12/23 22:42)
• MIDIではデバイスの設定状態を取得することができない(標準的な方法がない)ので、アンプの状態は常に「上書き」する(現在の状態と比較するようなことは行わない)ことにし、設定後に状態をファイルに保存しておき、ミニプレーヤー(minisp)の起動時に保存された状態を再設定することにした。
  •  (ソフトの)MIDIは高速だしデータ量も少ないから、これで大きな問題はなさそうだ(世の中の電子楽器は基本はそうなのだろう)。
  • また、再生停止中にJACKサーバが再起動することもあるので、再生開始時にそれを検出したら(サーバの起動後に起動時刻をファイルに記録しておく)保存された状態を再設定することにした。上で「問題ない」と書きつつも、毎回無意味に設定するのは気分が悪いので、ここでは無駄な設定を省くようにしたｗ

それから、Spotifyの音量正規化(改良版)の性能を自作の方式と比較した結果を書く。双方で共通する38曲(演奏)について比較した。

判定条件

• 音量の許容範囲: 基準(中心)から±2LUFS以内 (幅: 4 LUFS)
  • 音量(Integrated loudness)が上記許容範囲内なら問題なし(○)とする。
  • 問題なしの外側2 LUFSを可(△)とし、可の外側を不可(×)とする。
  • 下記の「偏差」は、音量が許容範囲の外側(○以外)に出た量である。

Spotify (Quietモード)+増幅 (ポップ音楽用: "Sp")

• 設定
  • 基準音量: -16 LUFS
  • 音量の許容範囲: -18 .. -14 LUFS
• 結果
  • 範囲内(○): 35曲 (92%)
  • 可(△): 3曲 (7.9%)
  • 不可(×): 0曲 (0%)
  • 合計: 38曲
• 統計量
  • 音量の平均: -15.8 LUFS
  • 音量の標準偏差: 1.39
  • 偏差の平均: 0.1 LUFS
  • 偏差の標準偏差: 0.39

自作の方式 (ポップ音楽用: "Pk")

• 設定
  • 基準音量: -20 LUFS
  • 音量の許容範囲: -22 .. -18 LUFS
• 結果
  • 範囲内(○): 25曲 (61%)
  • 可(△): 9曲 (22%)
  • 不可(×): 7曲 (17%)
  • 合計: 41曲
• 統計量
  • 音量の平均: -19.5 LUFS
  • 音量の標準偏差: 2.80
  • 偏差の平均: 0.74 LUFS
  • 偏差の標準偏差: 1.54

はっきり言って完敗である。Spotifyには不可(×)の曲がまったくなかったのには感心する。しかも、範囲内(○)に収まっている率が1.5倍と高く、音量のばらつき(音量の標準偏差)は半分以下、偏差の平均は1/7以下である。(数値的には)充分に音量が揃っていると言える。

ただ、負け惜しみではあるが、Spotifyは必要なデータを使って「普通に音量正規化(ReplayGain)をしている」のだから、良くて当たり前だとは思う。が、自作で情報(RG値)が不足した状態でいくら頑張っても勝ち目はないし、意味がないことは確かだ。

最後に、今回分かったことなどを列挙する。

• クラシック音楽は予想以上にダイナミックレンジが広い。例: チェロの演奏(「無伴奏チェロ」 "Suite No. 5 in C Minor BWV 1011: V. Gavottes I & II")でもピークが平均値+約18dBまである。
• 思い込みかも知れないが、日本のポップ音楽は比較的音量が揃っている。正規化後の音量が申し合わせたかのように基準値付近だった。国民性?
• どうしてか、Calf Studio Gear(JACK Audioのエフェクタのスイート)はやっぱり駄目だった。リミッターですら耳閉感が起こる。根本的に作りが悪いのだろうか? でも、誰も文句を言っていないようだから、僕との相性なのか・・・
• 少しだけでもMIDIの使い方が分かったのは収穫だ。演奏はしないが、JACKの要素の制御に使えるのが便利だ。
• 同様に、今回は使わないことになったが、OSCも制御に便利そうだ。ただ、手間を掛けてそういう新しいのを作らずに、Dbusを使えば良かったのにとも思う・・・

これにて音量正規化問題は一旦終了!

一段落して、心置きなく気楽に音楽が聴ける。

と思いきや、、、毎度のことながら、そうは問屋が卸さなかったｗｗｗ

昨夜、複雑なために一旦諦めたトリッキーな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アプリのログから抽出した。

• 夏の扉
  • 全体: -8.71 ｄB
  • プレビュー版: -9.30 dB
  • 差: -0.59 dB
• どうにもとまらない
  • 全体: -8.64 ｄB
  • プレビュー版: -9.10 dB
  • 差: -0.46dB
• Speak to me
  • 全体: +13.49 ｄB
  • プレビュー版: +14.10 dB
  • 差: +0.61dB
• Born to be wild
  • 全体:-3.64 ｄB
  • プレビュー版: -3.40 dB
  • 差: +0.24 dB

一見、全体とプレビュー版で随分値が違っていたのでがっかりし掛けたが、差を求めたら1dB未満(0.5dB前後?)なので、使えるかも知れないと考えた。

最初はRG値の差は圧縮率の違い(全体: 160kbps, プレビュー: 96kbps)によるものだと思ったが、その後、プレビュー版は先頭の30秒だけで、RG値もその部分のものであるために異なっているのではないかという懸念が生じた。それで、先頭の音量は小さく、後半に大きくなる曲("Stairway to heaven")で確認したら、プレビュー版のRG値も全体ものらしいことが分かった。: プレビュー版のRG値は全体の値とほぼ同じで、更に、手持ちのもの(マスタリングが異なるかも知れない)の先頭を切り出してRG値を求めたら、(先頭は音量が小さいため、)プレビュー版や全体より随分大きな値になった。以下にそれらの値を示す。

• Spotify
  • 全体: -5.26 dB
  • プレビュー版: -5.0 dB
• 手持ちの曲の先頭(30秒)の切り出し: +5.2dB (GMBで求めた)

実際、手持ちの演奏のラウドネス(Integrated loudnessをebur128コマンドで求めた)は13.3LUFS違っていた。

• 全体: -11.1 LUFS
• 曲の先頭(30秒): -24.4 LUFS

念のため波形を比較すると、確かに先頭と全体の平均音量は10dBくらい違っていそうだから、きっと大丈夫だ。

"Stairway to heaven"の振幅: 上: 全体, 下: 先頭30秒 (縦軸はdB)

実際、Spotifyの立場で考えると、プレビューを提供するためだけに全部の曲のRG値を計算し直すのは馬鹿らしいし、プレビュー版の再生時に正規化するとしたら(実際にはしないと思う)、全体のRG値でする方が本来の雰囲気に近く、「試聴」の意図に合うから、全体のRG値を入れている(実際には全体の値を捨てずに残しているだけ?)のは腑に落ちる。想像だが、この値はレーベルから提供された試聴用ファイルに入っているものなのではないだろうか? (音源提供者向けの案内を調べれば分かるかも知れない)

プレビュー版内のRG値を使う場合には、以下のような手順で「普通の」(自分の好きな基準音量に合わせられ、Spotifyアプリのリミッターを回避する)音量正規化ができそうだ。

1. Spotifyアプリが再生開始するのを待つ。
2. API: Get a Trackを使い、プレビュー版を取得する。
   • Get a trackのpreview_url要素より。
3. プレビュー版のファイル(MP3)からtrack gainを抽出する。
   • ffprobeを使う (exiftoolやsoxiでは出ない)
4. 音量正規化処理を行う。
   • 抽出したtrack gainに従って、音量補正値をアンプに設定する。
     • 基本的にはtrack gain(dB)そのものをを設定すればいいが、オーバーフローを回避するために、適切にオフセットする(下げる)必要がある。

あとは作るだけ。だが、ちょっと疲れた。それに、寒いしお腹空いたしｗ

と書いたところで、思わぬ落とし穴に気付いた。: すべての曲に、あるいは、今後もずっと、プレビュー版にRG値が入っているか疑問だ。入ってない曲があったり、いつかなくなる可能性がありそうだ。上に書いたように、この値は使われることがないだろうし、意図的に捨てていないからあるだけで、Spotifyのサービスの仕様ではないからだ。

そうなっても、(今までのように、)いくらでも回避策は考え付くだろうが、結局、堂々巡りになりそうな感じだ。それだったら、(音質などが完璧ではないものの、)気楽に聴ける今の状態で満足するのが一番得策な気はするが・・・ うーむ。 まあ、興味本位で「お遊び」でやるなら ありかな(いや、全部遊びだがｗ)。

↑イマココ

↓

(12/25 12:41) 「プレビュー版のRG値で正規化」をちょっと試してみた。結論は、やっぱり駄目だった。以下に理由を書く。

• 予想どおり、RG値が入ってない曲がある。確率は5%程度ではあるが、少なくない。
• 更に、RG値がおかしい曲もあった。こちらは10%程度と多い。
  • 数曲について、Spotifyアプリのログに出る全体(正式版)のRG値とプレビュー版のRG値を比較したところ、正規化後の音量が駄目だったものは大きく異なっていた。
  • 逆に、プレビュー版のRG値で正規化でも問題ない場合は近かった。
  • 当然ながら、全体のRG値で正規化した音量を計算したら基準範囲内だったので、問題なさそうだった。

どちらも致命的だ。評価用プレイリスト(ポップ・クラシック合計約90曲)で試したところ、ポップ音楽はまあまあだったが、クラシック音楽は惨憺たる結果だった。うまく行くものもあるから、その曲のプレビューのRG値が良くないのだが、どうしてそうなのかは分からない。プレビュー部分だけのRG値が入っているとか、元の版が違う(プレビュー用は初期のマスタリングなど?)とか、テキトーに計算したとかだろうか。いくら原因が分かっても、プレビュー自体すらなくてもいいような状態でSpotifyは全く保証していないので、対処してもらえる訳がない。

プレビューですらこんなことでは、以前書いた、ログからRG値を抽出する「トリッキーな方法」なんて余計駄目だろう。

いずれにしても、結果としてはイマイチだった。これがうまく行ったらすごくいいと思うが、やっぱり問屋が卸してくれなかった・・・ まあ、作るのはそれほど大変でなく、いつものようにおもしろかったからいいや。

そういう訳で、今は元の状態に戻して、「気楽に聴ける」状態になった(この音量正規化が破綻しないのには本当に感心するｗ)。これを試した一番の理由の、正規化をon/offする時のSpotifyの再起動を回避する件については、別の方法を考えたい。

一応、設定画面を開かずに、外部から音量正規化をon/offする方法はないかSpotifyに聞いたが、「ない」とのことだった。まあ、それは仕方ない。きっと、かなりニッチな要望なのだろう・・・ (12/25 15:38)

(とりあえずは、)本当に一件落着■

(題の漢字は、各自自由にご想像下さいｗ)