piu lentoの日々 (piu lento days)

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くらい違っていそうだから、きっと大丈夫だ。

実際、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)

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

 

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