list_categories=Array ( [0] => WP_Term Object ( [term_id] => 54 [name] => オーディオ [slug] => audio [term_group] => 0 [term_taxonomy_id] => 54 [taxonomy] => category [description] => [parent] => 4 [count] => 198 [filter] => raw [cat_ID] => 54 [category_count] => 198 [category_description] => [cat_name] => オーディオ [category_nicename] => audio [category_parent] => 4 ) [1] => WP_Term Object ( [term_id] => 3 [name] => 日記 [slug] => 00-diary [term_group] => 0 [term_taxonomy_id] => 3 [taxonomy] => category [description] => [parent] => 0 [count] => 1948 [filter] => raw [cat_ID] => 3 [category_count] => 1948 [category_description] => [cat_name] => 日記 [category_nicename] => 00-diary [category_parent] => 0 ) [2] => WP_Term Object ( [term_id] => 62 [name] => 音楽配信 [slug] => %e9%9f%b3%e6%a5%bd%e9%85%8d%e4%bf%a1 [term_group] => 0 [term_taxonomy_id] => 62 [taxonomy] => category [description] => [parent] => 4 [count] => 46 [filter] => raw [cat_ID] => 62 [category_count] => 46 [category_description] => [cat_name] => 音楽配信 [category_nicename] => %e9%9f%b3%e6%a5%bd%e9%85%8d%e4%bf%a1 [category_parent] => 4 ) )
piu lentoの日々 » オーディオ

Archive for the ‘オーディオ’ Category

Spotifyの音量正規化機能は大抵はうまく動いているのだが、曲によっては音量や音自体がおかしくなることがある。特に、Pink Floydの"Speak to me"(1973)の先頭のように音量がとても小さい時に破綻する。それでも、Google Play Musicのように、ないよりはずっといいのは確かだ。

が、近頃、SpotifyのWeb APIが使えるようになり、その中に曲の(音的な)特徴を取得する機能があるのに気付き、それを使って音量正規化ができないかと思っていた。具体的には、"Get Audio Analysis for a Track"(以下、Analysis)や"Get Audio Features for a Track"(以下、Features)が使えそうなので、調べてみた。

すると、どちらでも音量正規化に必要となる特徴量(曲の音量)が取れそうなことが分かった。具体的には、それらで取得できる"loudness"や"energy"である。なお、Analysisは取得できる情報は多いものの、上記の値程度しか使わないし、毎回分析するのか処理が遅いので、Featuresを使うことにした。

新しい音量正規化の処理として、以下のような手順を考えた。

  1. 新しい曲の再生開始時に、Features APIを実行し、音量の特徴量を取得する。(→ L)
  2. Lから、音量を正規化するための音量調整量を求める。(→ G)
  3. GをSpotifyの音量値に変換し(→ V)、設定する。

いくつかの曲で試したところ、音量の特徴量Lとしては、loudnessが良さそうだった。定義(概要)は以下のようなので、理論上はそのまま使えそうだ。

The overall loudness of a track in decibels (dB). Loudness values are averaged across the entire track and are useful for comparing relative loudness of tracks.

なお、energyの定義(概要)は以下のようなので、うまくLに変換できれば、(数値でなく)聴感的な音量の正規化ができそうなのだが、いい方法が思い付かなかったので、今回は見送った。

Energy is a measure from 0.0 to 1.0 and represents a perceptual measure of intensity and activity.

GMB(gmusicbrowser)での音量正規化の結果と比較して検討し、loudnessをそのままLとして使う場合、LからGへの変換式は以下とした。

G= X - L

Xは目標とする(一定にしたあとの)再生音量(dB)で、試行錯誤の結果、-13(dB)が最もGMBの音量に近くなったので採用した。

(10/12 6:26追記) 後から気付いたのだが、上のXは正確には2つの要素からなる。一つは、目標とする音量Yであり、これが仮想的な0dBとなる。もう一つは、正規化した音のシステムの最大音量(0dB)からの余裕Zであり、Yの音量は実際のシステムでは-Zとなる。音量をYに正規化したあと、音量(振幅)はZまで大きくなることが可能である。XはYとZの和であり、通常はY= Z= X/2と設定するので、上のように書いても大きな問題ではないが、動作の調整・確認をしている時に「何かおかしい」と思ったので書いた。

ただ、これは考え過ぎとか誤解だと思う。今、書いたあとに気付いたのだが、Yは実際には「平均」音量であり、もしYを「最大」音量(0dB)とすれば、Z= 0となる(それで充分)だから、Y= Xとなり、上の変換式はそのままで正しい。最初は最大音量と考えてその式を書いたのに、実際の動作を見ているうちに誤解したのだろう。 (だから、この節は書かなくても全く問題ないのだが、忘れるために書いておくw)

が、更に気付いたのは、Lはloudnessであって最大音量ではないので、やはりYは平均音量と考えるべきで、やっぱり上の節は要る。別の考えをすれば、Lに係数が要るのかも知れないということだ。その係数は、その曲の振幅の変化量(= ダイナミックレンジ)を示す値だろう(が、それはSpotifyでは分からない)。

Spotifyの音量を調整するには、アプリの音量そのものを変更する以外に、Spotifyアプリのあとにアンプやミキサーを入れてそれで調整する手がある。しかし、外部プログラムから手軽にゲインを変更可能なものが見つからなかった(MIDIを使えば制御できそうではあった)のと、できるとしても結構大げさになるので、今回は見送った。

Spotifyアプリの音量を変更するには、(現在のSpotifyアプリはDbusでは音量が調整できないため、)Spotifyアプリにウインドウシステム(X11)経由でイベント(キーやマウスホイール)を送ってボリュームを操作する方法と、PulseAudioのSpotifyアプリのボリュームを設定する方法がある。後者は音量値にdBや相対値が指定でき、pactlコマンドで簡単に実行できるので採用した。

上記のように、音量値にdBが指定できるので、基本的に、GがそのままSpotifyの音量値として使える。ただし、Gが大き過ぎる(例: 0よりかなり大きい)と音質が劣化するので、上限(Vmax)を設けることにした。今回はLは6(dB)とした。結局、Spotifyの音量設定値V(dB)は以下のようになる。

V= G (G < Vmaxの時),
     Vmax (G >= Vmaxの時)

ただし、pactlコマンドの仕様により、符号付きの値は現在値からの相対値になってしまい、負のdBは相対値とみなされるために(、結局全然)使えないので(どういうつもりなのか、作者に聞きたい)、pactlに指定する時に0..1の数値(R)に変換している。これはdBから数(比率)への変換で、以下のとおりである。

R= 10(V/20)

ここで不思議だったのは、Rをpactlに指定すると期待どおりの結果にはなったのだが、設定後に取得した音量の%の値が想定と異なるのである。例えば、"0.5"を指定すると、結果は"50%"でなく"79%"となる。dBの値は"-6.02dB"と正しいが、%はどうもおかしい気がする。本来は50%になるべきと思うのだが、%の値も対数なのだろうか。謎ではあるが、実際の音量や聴感的には期待どおりなので、深くは考えないことにした。ただ、将来的に、バージョンアップなどでこの動作が変わってしまうリスクはある。

pactlコマンドでSpotifyアプリの音量を設定するには、以下の手順で行う。

  1. Spotifyアプリのsink-inputのIDを得る。→ siid
    • pactl list sink-inputsの出力を解析する。
  2. Spotifyアプリの音量をRに設定する。
    • pactl set-sink-input-volume siid Rを実行する。

上記の処理を実装して聴いてみたところ、概ね期待通り動いている(→ 曲が変わるとボリューム(画面中央下部)が動くデモ)。ただし、以下のような問題がある。

  • 曲の切り替わりの検出に時間ズレが生じることがあるので、音量設定タイミングがずれることがある。
    • 音量の小さい曲の後に大きい曲が掛かる場合、音量を下げるのが遅れる場合があって、その時には、次の曲の先頭が(一瞬)大音量で再生されてしまう。
    • 逆に、音量の大きい曲の後に小さい曲が掛かる場合、音量を上げるのが早過ぎる場合があって、その時にも、次の曲の先頭が(一瞬)大音量で再生されてしまう。
  • 曲によっては少し大きく感じることがある。
    • 例: Commodores "Easy", CHIC "Le Freak"

曲の切り替わりの検出精度は、Spotify API自体にズレがあるので、容易には向上できず、本質的な解決は難しいのだが、音量を一気に変えずに、1回の変更量に上限を持たせて少しずつ変えるようにして(ただし、音量を下げる時は2倍の速さにする)緩和を試みた。また、変更前の音量が0dBを超えている場合は、超過分を一度に下げるようにした。この修正の都合で、pactlへの音量設定値を、比率(R)でなく現在の音量とVの差分にした(結局、符号付きのdB指定(相対値)だけでも良くなった)。

(10/3 12:23追記) 曲の頭が一瞬大音量になることがある問題は、JACKのエフェクタを使えば緩和できるかも知れない。Spotifyの出力を、瞬間的な大音量を抑えるようなエフェクタ(リミッター?)につなぎ、音量正規化がonの時だけそのエフェクタをonにすれば良さそうだ。エフェクタの制御は本アプリ(Spotifyミニプレーヤー)からMIDIで行う。おもしろそうだが、パラメタの設定は難しそうだ。余りにも気になるようなら、やってみたい。

この場合は、音量正規化もJACKでできる。Spotifyの出力をミキサーのSpotify用入力につなぎ、その音量を本アプリから行えばいい。上記エフェクタの入力レベルが変えられるなら、それでも可能だ。ただ、これ自体の価値はそれほどない。あくまでも、大音量を抑えるついでにできるということだ。

大きく聴こえる曲は、今のところどうしようもない。数値で正規化する限界なのかと思い、採用を見送ったenergyがうまく使えないものかと思っている。ただ、GMBの正規化でも同様なことはあるし、自分や周囲の状態によっても音量は違って聴こえる(要は「気のせい」)から、あまり深追いしても仕方ないのかも知れない。

(10/6 21:22追記) 音量で気になっていることの一つは、静かな曲の音量が大きくなり過ぎることなので、それを解消するのに上記のenergy(以下、E)を使って音量設定値Vを調整してみた。

静かな曲はloudness(L)が小さいためにVが大きくなるので、音量が大きくなりやすい。一方、そういう曲はEも小さいので、Eの大きさ(小ささ)でVを調整することを考えた。Eが小さい時は、その分Vを減らすのである。

Eがどういう単位・仕様の値なのか不明(0..1ということだけ明らか)なのだが、試行錯誤して、Eの値をdBに変換してVに加える(Eは0より小さいので、実際には引かれる)ようにした。Eで調整した音量設定値V'は、次の式で求められる。

V'= V + k * 20 * log10(E) (E >= Eminの時)
      V + k * 20 * log10(Emin) (E < Eminの時)

kはEの強さを調整するための定数で、0.05から0.3程度が良さそうであるが、いろいろな曲で試したところ、0.15辺りが最も適当だった。ただ、曲によって変わるので、更に調整が要りそうだ。Eminは想定する最小のEで、0.0001とした(log(0)はエラーになるので、それを防ぐために定義している)。

この式は全くの思い付き(と誤り)から出て来たものである。Eの詳細が不明なので、そのままdBに変換していいのか怪しいが、VはdBなので、VをEで調整するのなら、少なくとも、EをdBに変換した値を使うのは適切だと思う。

残念ながら、この方式は、元々音量が小さくなくて更に大きく聞こえる曲(例: 上記の"Easy"や"Le Freak")には効果がない。それらはEが大きいため(だから、うるさく聞こえるのだろう)、ほとんどVが減らないからである。それらには別の特徴量が使えるのかも知れない。

(10/9 11:09追記) 音量でもう一つ気になっていることは、クラシックの曲の正規化がうまく行かないことだ。クラシックの曲はポップ音楽と違ってダイナミックレンジ(音量の幅)が広く、平均音量が小さいことが多いため、ポップ音楽と同じように正規化すると音量設定値Vが10dB前後ととても大きくなってしまう。一方、DACは0dB以上の音は再生できないので、音質が劣化する。

これに対処するには、まず、目標音量Xを下げて(例: -20dB)、(形式的な)増幅の余地を増やす必要がある。また、10/6の追記とは逆に、energy(E)に応じて音量設定値Vを増やす方が良さそうだ。そこで、E(のdB値)に応じてloudness(L)を増やすことにした。ただし、LがXより大きい場合に更にLを増やすと、Vが減って逆に音量が下がってしまうので、Lを増すのはLが小さい場合だけにした。クラシック音楽用の音量設定値V''は、次の式とした。

V''= X' - L''
  X': クラシック音楽用の目標音量 (dB)
  
  L''= L' (L' < X'の時)
        L (L' >= X'の時)
  
    L'= L + m * 20*log10(1 - E) (E >= Eminの時)
         L + m * 20*log10(1 - Emin) (E < Eminの時)

mはEの強さを調整するための定数で、いろいろな曲で試したところ、0.05辺りが最も適当だった。また、X'は-24dBとした。これらも継続して調整が要りそうである。

なお、目標音量をかなり下げるために音質の劣化が心配だが、まず、ほとんどの場合に実際の設定音量は0dB付近になるため、大きな問題はない。なお、仮に設定音量が目標音量と同じくらいになった場合には音の有効ビット数が減るため、音質が劣化する。その有効ビット数は、元の音を16ビット相当(ダイナミックレンジ: 約100dB)とした場合に設定音量を-24dBに落とした場合には、概ね (100-24)/6= 12.7ビット程度になる。この場合でも、有効なダイナミックレンジは76dB程度あるはずだ。

実際に、いろいろな音量の曲に対してこの方式で音量正規化を行った場合と音量正規化を行わない場合の音量を比較したところ(どちらも、アンプの音量は最初に調整した後は変えないものとする)、音量が適正だと感じることがほとんどだった。数値的にも、それらの曲に対して約9dB(= 2.8倍)の幅で調整を行っていたので、効果はありそうだ(→ クラシック音楽でも、異なる曲を混ぜて聴く時には音量正規化はあった方がいい)。なお、この方式ではポップ音楽も正規化できるが、方式やパラメタが最適でないうえに、ポップ音楽はダイナミックレンジが狭い場合が多いため設定音量が目標音量(-24dB)付近になることが多いので、音量と音質の点で得策でない。そのため、この方式をクラシック音楽用のモードにし、従来のをポップ音楽用にした。

クラシック音楽用の音量正規化モードを追加したため、ミニプレーヤのUIを変更し、音量正規化のon/offでなく、off("-")またはモード(ポップ("P")/クラシック("C"))で表示するようにした。

それから、音量正規化のモードを切り替える際に音量が大きく増加することがある(例: クラシック → off)ので、安全のため、再生中にそのような切り替えを行った場合は一時停止するようにした。

最後に、気になっていた、静かな曲での正規化結果を比較してみる。以下は、"Speak to me"の先頭約20秒(鼓動)の部分の右チャネルの波形(上から順に、GMB (正規化off), Spotify(正規化off), GMB (正規化on), Spotify(正規化on), Spotify(今回の正規化))である。なお、それぞれの開始時刻は合わせていないので、波形の位置は異なる。

Pink Floyd "Speak to me"の先頭約20秒の右チャネルの波形比較

正規化した波形(最後の3つ)を見ると、明らかに、Spotifyの正規化は「やりすぎ」であり、そのためにおかしく聴こえていたことが分かる。一方、今回の正規化(一番下)は小さ目ではあるが、GMB(上から3番目)と同様の振幅になっている。聴いた感じでも問題なく、今回の方式が有効であることが確認できた。

なお、今回の正規化の振幅が小さ目なのは、この曲の音量がとても小さく、本来の音量設定値が上限(6dB)を超えているために、充分に音量を上げられないためである。

→ 音量制限の上限を解除して試したところ、振幅がSpotify以上に大きくなってしまった(フルスケールを超えた)。パラメタの調整(あるいは、上記のenergyの利用など)が要るようだ・・・ そして、Spotifyの正規化の処理は正しかったようだ。この点はがっかりした。

→ 音量設定値の上限を7.5dBにしたら振幅がGMBと同等になったので、当面はこれで試してみたい。

→ (19:40追記) どうやら、(当たり前ではあるが、)0dB(100%)より大きく増幅するのは良くないようで、少し長くクラシック(0dB超えの曲ばかり)を聴いたあとにポップに切り替えたら違和感が生じた(耳がずっと圧迫されていたような感じ)。また、当たり前だが、たまに音量がオーバーレンジ(0dBを超える)するのも余りいい気分でない(ただし、瞬間的なので聴いていても分からない)。それで、上限を0dBにすることにした。それで音量が小さくなってしまう曲はもともと小さく作っていると考えて、諦めることにする。

馴染みのない方のために説明すると、0dBを超えて増幅するというのは、デジカメのデジタルズームとかISO感度を高くするようなもので、確かにそれらしい画像は写って便利なのだが、無理してデータを作ってるから画質は期待できないということだ。

あと、"Speak to me"の冒頭の音がおかしく聴こえるので、Spotifyアプリの正規化は動的に処理(例: 現在までの音量などで現在の音量を調整する)しているのかと思っていたが、波形はそうでもないので、音量を上げ過ぎているだけなのかも知れない。ただ、目標音量を小にすると音量が下がり過ぎてしまうので、Spotifyアプリは今一つなことは確かだ。

副次的な効果として、今までは、音量正規化をon/offする際はSpotifyアプリを再起動する必要があるので、再生が停まり画面が変わってしまうなど、ちょっとしたストレスだったが、今回の方式では気軽にいつでも(まさに"on the fly")切り替えられるようになり、大変便利になった。実際には、このイライラを解消したいということが、今回の作業に着手する大きな動機になった。

(10/6 21:22, 21:39 変数名の重複を修正、設定値を更新)

 

PS. その後、調整・修正・改良しながら使っていて(というか、そればっかりしているがw)、上記の曲間のタイミングずれによる不意の大音量を解消したいと思っている。が、それは難しいことも分かった。今のところ、以下のようなことを考えている。

  • コンプレッサーやリミッターで大音量を制限する。
    • 大音量がほんの一瞬に抑えられるが、通常の曲(特に、クラシックは音量レベル(上記L)が小さいと認識されるため、大抵、音量(上記V)が最大に設定される)の大音量も制限してしまうので、(聴感上は分からないが、)常時は使いたくない。必要な時だけonにする必要がある。
  • コンプレッサーなどを使わないで回避する。
    • Spotify web APIのタイミングズレを補償する。
      • (無音で?)曲間を検知して、曲間と認識する。
      • 「スマート」な処理を作る?
      • 次の曲の先読み?
    • 我慢する。

切り替えて使うにしても、コンプレッサーなどはどうも気に入らない(onにしている時は妥協していることになる)ので、使わない方法を考えている。でも、できるかどうかは不明だ。まあ、あまり頻繁に起こらない(実際、昨日確実に起こっていた曲で今日は起こらない)ので、我慢するのが一番効率的なのかも知れないw

その他、以下のような改良をした。

  • 音量設定処理の遅延を防ぐ。
    • 曲間にSpotify web APIの認証トークン(有効期限がある)を更新すると音量設定処理が遅くなる可能性があるので、可能な限り、「忙しくない」時にトークンの更新をし、曲間での更新を抑えるするようにした。
      • 具体的には、再生中に一定間隔(例: 2分)で(無駄に)web APIをアクセスする。この時、トークンの有効期限を短め(例: -5分)に見て早目に更新しておく。一方、曲の切り替わり時のアクセスでは、有効期限ギリギリまで(例: -10秒)トークンの更新をしないように指示する。
  • 自動的に音量をリセットする。
    • 再生を停止してある程度(例: 20秒)時間が経ったら音量をデフォルト値(例: -10dB)に戻すようにして、(小音量の曲の再生後、)次に再生する曲の頭が不意に大音量にならないようにした。
      • ただ、次に再生する曲の頭が小さくなってしまうことがあるという弊害はある。

(10/5 10:50)

PS2. PSに書いた、Spotify web APIの曲の切り替わり通知タイミングずれによる意図しない大音量を防ぐ方法について考えた。曲の切り替わりを正確に検出して、その切り替わった時点で音量を設定すればいい。そのためには、まだ曲間になっていない場合にはそれまで待てばいいが、既に曲間が過ぎている場合には時間を戻して、出た音の音量を変える必要がある。果たして、そんなことはできるのか?

まず、曲の切り替わりを正確に検出するのが難しい。 一番簡単なのは無音検出だろうか。現在の再生位置が曲の終わり付近になった場合やSpotifyアプリから来る「曲が変わった」イベントの付近で(これらはある程度正確と考えられる)無音になったら「切り替わり」と判定するか。曲の中には終わったと見せかけて再度始まるものもあるが、さすがに終わりの数秒間ではなさそうだ。だが、今と次の曲がどちらもメドレーとかライブとか雑音が多くて、無音部分がなかったら駄目だ。。。

無音を検出すること自体は可能だが、ちょっと重い。そもそもそういうプログラムが要る(探せばあるだろう)。無音がない場合にも対応するには、音の特徴を分析するのだろうか。それは結構重い・・・

時間を戻すのは、不可能に思えて実は可能だw 戻す期間を数秒間に制限すれば、再生する波形をその時間分格納し、古いものから順に再生するようにすれば(ところてんのような感じ)、その数秒間は戻すことができる(正確には、Spotifyが再生したと思っている音はまだ再生されていないから、出てしまったはずの音(= 過去の音)を操作することができる)。問題は、再生に常にその数秒間の遅延が生じることだ。再生ボタンを押してから数秒待たないと音が出ないし、停めても数秒間は音が出る(こっちは何とかできる気がする)。それが許容できるだろうか。

一方、今日は問題が全然起こらなくなってしまって、「もしかしたら、いじっているうちに直ったのか?」と、淡い期待をするのだが、実際にはそんなことはないのは、今までの経験から明らかだw でも、滅多に起こらないことは確かなので、わざわざ上に書いたような大掛かりなものを作って苦労しなくてもいいような気がしている。ただ、技術的な興味から、やってみたい気分はある。

そして思ったのは、(昔の)日本にはこういう物好きな技術者が多く、それだけならまだいいが、お客や経営者が無理難題を吹っかけたにも関わらず、(24時間戦うw)彼らによって実現されてしまった製品を素直に販売してしまったから、ガラパゴス化してしまったのかも知れないということだ。

(10/5 21:28)

  •   0
  •   2

[10/1 8:18 この問題は解決した。原因と対処を最後に示す。]

面倒なことは、いつも突然やって来る。昨日、ふと、SpotifyとGMB(gmusicbrowser)を切り替えると音量が違うのが気になっていたので、それを可能な限り合わせたくなって、テスト信号を作って再生したら、思わぬことに気付いてしまった。

MP3のスイープ信号を再生したら、GMBからの音がおかしかったのだ。特定の周波数(例: 5.5kHz)が小さくなった。以下に問題の波形(問題の起こった5.5kHzの正弦波の再生波形の比較)を示す。上は問題がある場合、下は問題のない場合である(左チャネルだけを抜粋した)。なぜか変調が掛かっている感じで、音量が小刻みに振動している。そのために音が濁って聞こえる。

興味から、この変調波の周波数を調べたいのだが、普通にスペクトルを出しても出ず、なぜかLPFでも抽出できない(LFP後のスペクトルが出ない)。目視では24Hz程度と分かるが、なぜLPFで取れないのだろうか。振幅がとても小さいのか(そうなら、こんなに振れない気がする)。まだまだ知識が足らないようだ。。。

↑ 分かった! スペクトルを拡大したら、5.5kHz付近に2つの山があった。それらが干渉していたのだ。2つの差は約25Hzで、上記の目視と一致した。でも、なぜこういうことが起こるのだろうか? 新たな謎だ。

参考のため、実際の音(再生音を収録したもの)をこちらに置く。最初が問題のある場合、次が問題のない場合である。音量が大きいが、小さくしても現象は変わらなかった。多くの環境で再生できるようにMP3にしたので、環境によってはどちらも同じように(問題があるように聞こえる)可能性がある。

同じ音でもFLACのファイルを再生する場合は問題が起こらず、出力系をJACKからPulseAudioに換えても問題は起こった。それから、同じMP3のファイルを他のプレーヤー(例: XPlayer)やGstreamer(以下、GST)の再生プログラム(gst-play-1.0)で再生しても同じ現象が起こるが、問題の起こらないプレーヤー(例: Spotify, AlsaPlayer)もあるので、GMBが再生に使っているGSTのMP3デコーダ(デフォルトのもの)に問題がある可能性が高いことが分かった。

更に試したら、madというデコーダを使うと問題が起こらなくなることが分かった。以下に、gst-launch-1.0での例を示す。下記太字の"mad"を"decodebin"に変えると、問題が起こる。

gst-launch-1.0 filesrc location=test.mp3 ! mad ! audioconvert ! autoaudiosink

結局、GSTのデフォルトのデコーダ(decodebin?)に問題があるようなのだが、仮にGSTのバージョンが古いせいだとしても、OSのパッケージのものを使っているため、それより新しいものにバージョンを上げるのはかなりの手間(自分でコンパイルする)なので、上の例のようにGMBで使うMP3デコーダを変更するようにした。

MP3デコーダはmad以外にmpg123audiodecやavdec_mp3でも問題が起こらなかった。ただ、gst-launch-1.0で使う場合にはmadしか音が出なかった(他はprerollのエラーが起こった)。これは、僕がGSTの使い方を良く理解していないせいだ思う。

それで、3つの中では(名前から)一番品質が良さそうな(イメージの)avdec_mp3を使うことにした。ただ、何か問題があった時やデフォルトのデコーダで試したい時に手軽にデコーダを変更できるように、GMBの拡張設定で変えられるようにした。

他に分からなかったのは、GSTのパイプライン(上記のコマンド例のようなもの)でMP3デコーダを指定する順番が最初でないと うまく動かなかった(再生開始しない)ことだが、これも僕がGSTを良く理解していないせいだと思う。

 

昨夜から延々と試行錯誤と対処をして、ようやく本題の音量を合わせる話に進むことができた。テスト信号とメーターで音量を比較してみたら、結局、音量正規化を行わない場合には、どちらも同じ音量で再生されることが分かった(まあ、デジタルなのだから、大きく違ったらおかしいが・・・)。僕のシステムではDACの前に部屋の特性補正用のイコライザを入れているが、両方とも音量を100%にしてもオーバーフローは起こらないようだった。ただ、念のため(論理的でない「気休め」)、イコライザの前で1dB下げるようにした。

音量正規化を行う場合には、SpotifyとGMBの音量は異なっていた(これが、気になっていた音量差である)。それぞれの仕組みや目標音量が異なるためだろう。手持ちとSpotify両方にある数曲で調べたら、曲にもよるが、1〜3dB程度Spotifyが大きかった。それでミキサー(jack_mixer)を使って2dB程度下げたら、差が1dB以下となった。これで聴感的にも合えばいいが・・・ → 残念ながら、曲によってSpotifyの正規化後の音量が違うようで、あまり合わない感じだ。

まったく、手製のシステムは不意に問題が起こって気が抜けないものだ。まあ、オーディオ道 趣味なんてそんなものだろうw ただ、JACKだといろいろな部品をマウスで配線して手軽に試行錯誤や確認ができるのは便利だし、いろいろな知らなかったことが分かるのはおもしろい。

それから、MP3デコーダの問題はダウンロード購入したMP3音源の音質劣化を起こすことに気付いて確認したら、確かに若干音がおかしくなっていた。具体的には、ルプーのモーツァルト ピアノ協奏曲 第21番(1975)で弦(バイオリン)の音量が大きい箇所で違和感がある。実際、今年の頭に音が悪いことに気付いて書いている(これはこっちの問題だし、苦情を言ったら確実に泥沼化して疲弊しただろうから、黙ってて良かったw)。今聴くと、MP3デコーダを変更すると、違和感がほとんどなくなって、すっきりした気分のいい音(曇り空がちょっとした青空になった感じ)になる。確かに、録音が古いことによる音の悪さもあるのだが、MP3デコーダの問題が大きかったようだ。

もちろん、他のMP3音源でも同じ問題があるはずだが、特定の音(例: 5.5kHz)が続く場合にしか顕著にならないようで、たまたま僕の手持ちの曲ではそのパターンが少なかったらしく、気付かなかったようだ。実際、ルガンスキーのラフマニノフ ピアノ協奏曲 第2,3番(2005, 2003)ではまったく差が分からず、以前どおりのいい音にしか聞こえない。

それにしても、ルプーについては本当に音が悪いことが分かっていたなんて、僕の耳と環境は随分良くなったものだ。つい最近まで何がいい音か分からなかったことを思うと、全く感慨深い・・・

 

(10/1 8:18追記) MP3の音がおかしい問題の原因が分かり、対処できた。

しつこく試したり調べていたら、ヒントになる投稿が見つかった。どうも、GSTにインストールしていたFluendo MP3 Decoder(flump3dec、パッケージ: gstreamer1.0-fluendo-mp3)が古い(その投稿が2007年なので、それより前!)うえにバグがあったようだ。そして、今(実際には2007年以前から)はそれがなくてもMP3を再生できるとのこと。僕が自分でgstreamer1.0-fluendo-mp3をインストールしたのかは今となっては分からないが、余計だったようだ(← 別のPCには入っていないので、自分で入れたようだ)。

それで、gstreamer1.0-fluendo-mp3をアンインストールして問題のファイル(5.5kHzおよびスイープ)を再生してみたら、正しい音が出た(再度インストールしたら、やっぱり駄目になった)。ルプーのモーツァルト ピアノ協奏曲 第21番も大丈夫そうだ。それで、GMBのMP3デコーダの指定も止めて、デフォルトに戻した。

いつものように最後はあっけなかったが、原因が分かって良かった。それにしても、余計なパッケージは削除して欲しいものだ(→ Ubuntuの人)・・・

  •   0
  •   0

頻度は減ったものの、相変わらず自作のSpotifyミニプレーヤー(minisp)の改良・デバッグもやっているw 昨夜辺りだったか、ブラウザなどのフォントをいじっていて、ふと、minispの文字の大きさのバランスが気になった。僕としては、タイトルは大き目にし、演奏者とアルバム名などは少しだけ小さ目にしたい。一度気になるとどうしても我慢できないので、文字のサイズを調整してみたのだが、微妙なところでうまい設定ができない。

というのは、Tcl/Tkは作りが古いせいか、フォントサイズを整数(例: 10pt)でしか指定できないため、サイズを変えても同じような大きさに見える場合があるせいだ(例: 13ptと11pt: この時、後者を10ptにすると小さくなり過ぎてしまう)。

が、僕の理解では、今はTrueTypeなどのベクターフォントが使われているので、整数でないサイズ(例: 10.5pt)も使えるはずだ(実際、MS Wordでは10.5ptがデフォルトだった)。しかし、Tcl/Tkにはそのサポートがない。それで、そこを「なんとか」してみた。

検索したら、やり方そのものは見つからなかったが、ヒントがあった。tk scalingコマンドを使うと良さそうな感じだった。つまり、それに適正な値の数倍の値を指定して、文字などを小さ目に描画させる一方、その分、フォントのサイズを大きく指定すればいいと考えた。例えば、10.5ptは2倍なら"21"ptと整数で指定できるから、10.5pt相当の大きさで表示できるはずだ。

やってみたら、(ちょっと手間取ったものの)うまくいった。1/2だと単位(ステップ)が荒そうだったので、1/4で描画する(tk scalingに本来の4倍の値を指定)ようにして、4倍のフォントサイズを指定した。

本当にわずかな差で、ちょっと見ただけでは違いが分からないのだが、タイトル以外(演奏者とアルバム名など)が小さ目になっている。これだと、日本語がまだわずかに大きく見えるのでもう少し小さくしたいのだが、10.25pt相当は効かないようだった(10.5ptと同じ大きさで出た)。内部で丸められるのか、ベクターフォントといってもどんなサイズでも生成できる訳でなく、可能なサイズにステップがあるのだろうか。まあ、これでも充分満足できるから、良しとする。

「これで一件落着」と思って、くつろいで聴いていたら、思わぬことに気付いてしまった。文字数によってバランスが変わるせいか、文字の大きさが違って見えるのだ。以下はどれも同じ文字サイズなのだが、タイトルとその他の文字の大きさが異なって見える。

タイトルの文字数が少ない時は、タイトルが小さく見え、タイトルの文字数が多い時は、逆にタイトルが大きく見える(はじめは、プログラムがおかしくて毎回サイズが変わっているのかと思っていた)。後者を見ると、ちょっと「うっ」という感じ(圧迫感がある)になって、小さくしたくなる。。。 今まで調整がうまく行かなかったのは、これで右往左往していたことがあるのだろう。プロには常識なのかも知れないが、錯覚の一種なのかも知れない。漢字はアルファベットに比べて面積が大きいのも関係してそうだ。

さすがにこれは配置や構成だけの問題ではなく、感覚が関係しているし、仮に文字種(例: 日本語/英語)や文字数でサイズを自動調整するにしても、設定可能な文字サイズに制限があって解決できないだろうから、「適当」なところで諦めるしかないだろう。そういうことを考えると、デザイナーやDTP職人(?)の方たちの苦労が偲ばれる・・・

(8/23 16:27追記) 昨夜の思い付きの「タイトルのサイズを自動調整」を試してみたら、意外にうまく行った。文字種を調べるのは面倒なので、タイトルの長さに応じて3段階にサイズを変えてみたら、意外にも、かなりいい感じになった。

ただ、やっぱりうまく行かない場合はあって、下段の最後の2個のような時がちょっと気に入らない。が、文字種での判定やタイトル以外のサイズ変更処理も必要で面倒なので、保留にした。

 

 

PS. オーディオの「測定できない音の違い」って、こういうものもあるのかも知れないと思った。要は、本当に測定値は同じで、感覚的な問題で違って聞こえる、「錯覚」(??)ではないかと。

PS2. 視覚的なことと言えば、さっき、「Twitterでも気になっている人が多数「Spotify」のロゴの傾き」というニュースを目にしたが、僕は全然気付いてなくて、アイコンを見てようやく分かったw なかなか妙だし、おもしろい。

今、Spotifyのロゴを見て気付いた(気になった)のは、線と枠の間隔が左右で違う(右に寄っている)ように見えることだ。でも、じっと見ると同じようにも見えるし、それよりも、色遣いが良くないせいか、目がおかしくなる・・・

  •   0
  •   0

近頃は、見るだけで嫌気が差すもの・人が多い。TVはないから頻度は低いのだが、webを見るだけでもイライラして来る。以下にそんなのの一覧を示す。

  •  東京オリンピックのキャラ
    • ゴテゴテし過ぎていて80年代以下w 目がチカチカして目障りなので、とにかく見たくない! 本当に子どもが選んだのか。消去法で仕方なくなのかねぇ・・・
    • まあ、オリンピック自体がゴリ押しだらけの、センスのかけらもないものだが。
  • 「ご意見番」
    • デブのデラックスなご意見番
    • 歌手や役者の癖にご意見番に成り下がった中高年たち
    • でも、こいつら(ご意見番といったって、副業じゃないか)の言うことをありがたがる連中の方が、もっとセンスが悪い。
  • 白塗りの顔が大きい女性芸人
    • 似たような人に、上着みたいな名前の女性芸人。髪の長さで区別するといいようだ。
  • 太眉を描いた女性芸人
    • 気持ち悪いので、あの眉は本当に止めて欲しい。
  • 音楽業界
    • レコードを「ヴァイナル」とか言って売るレコード屋
      • (30cmの)LPレコードは「12インチヴァイナル」だそうだw まったく「は?」だ。
      • 「アナログレコード」って書くのもアホかと思う。今、「デジタルレコード」なんてあるのか?
    • 紙ジャケでは飽きたらず、帯まで付けて「日本初版を復刻」とかいう、誰得仕様のCD・レコードを売るレーベル
    • かっこつけた顔や格好をジャケットに出すクラシック演奏者(かなり多いw)

こういう輩には、モーツァルトやベートーヴェンの爪の垢でも煎じて飲ませたい。いや、全く効果ないけどw

 

PS. 逆の例では、近頃、上下逆さまに顔が写っているジャケットのアルバムを出した、ちょっと不思議系の外国の若手女性歌手が妙に気になる。曲を聴く気にはならないが、二番煎じでなく、やり過ぎにもならずに目をひくところは、ある種のセンスの良さなのかも知れない。

PS2. 全くの余談だが、「デジタルレコード」があり得るかを考えてみる。まず、レコードにデジタルで記録できたとしても、恐ろしく使い勝手が悪いだろう。モデムのような「ピーガー」音を格納するのだろうが、どのくらいのデータが入るのだろうか。

(本当は33kbpsまでしか無理だが、)ビットレートを56kbpsとして裏表46分とすると、

(56*1000/8)*46*60= 18.4MB

となる。300kbpsのMP3を格納するとすれば、1枚のLPレコードには

(56*1000*46*60)/(300*1000)= 515秒= 8.5分

のデジタルデータしか入らないから、SPレコードと同様に盤の交換が頻繁そうだw しかも、事前に何枚ものレコードを読み込ませてから(85分分を読みこませるとしたら、10枚分なので、460分= 7.7時間も掛かる)でないと聴けないのは不便だ。

ハイレゾオーディオのビットレートは知らないが、仮に4Mbpsとすれば、

(56*1000*46*60)/(4*1000*1000)= 38.7秒

となって、テスト信号には充分だろうが、音楽再生には全く実用的ではない。

この試算をする前は、「ハイレゾだったら、おそらく1秒分くらいしか入らないのではないか」と予想していたが、まあそんなものだった。

そもそも、「アナログの音」が好きな人にとっては、いくら雑音がなくて音が劣化しない「デジタルレコード」があっても逆に意味がないだろうから、需要はなさそうだw (8/8 10:37, 17:19)

  •   1
  •   0

暇なので、余計なことをいろいろ考え付く。昨日、ふと、光回線のアダプタ(ONU)が邪魔に思えた。ONUの後に繋ぐルータは結構前に本棚の下に移設して、見えなくしていたのだが、ONUは光ケーブルが短いうえに弱くて移動できないので、光端子の近くに置いて、小さい衝立のようなもの(台)で隠していた。が、やっぱりすっきりせず、見るたびに何とかしたいという気分になっていた。しかも、衝立の陰に埃が溜まって来たのも、嫌な感じだった。

それが、何の拍子だったか、「丈夫な光ケーブルがあれば延ばせるのではないか?」と思い※、Amazonを探してみたら、強化された光ケーブルがあった。キーワードは、「光配線コード」と「曲げに強い」とか「曲げフリー」のようだ。

※順序が逆かも知れない。「とりあえず断線してもいいから、安いケーブルで延ばそうか」と探していたら、関連商品に強化されたものが見つかったような気もする。しょうもないことに、すっかり記憶がないw

全く知らなかったのだが、通信用光ケーブルにはいろいろな種類があるようで、フレッツの光回線に使えるのは、以下の仕様らしい。

SCコネクタ(シャッターなしでも可), シングルモード(9/125), 1心(芯?), SPC研磨, 波長: 1310/1550nm

畑違いなので、まったく初めての単語が多い。そして、家庭用でもシングルモードを使っているのがちょっと意外だった(業務用をそのままを使っているのかも知れない)。だから、やろうと思えば100mくらいは延ばせるのではないか(要確認)。

余談: オーディオマニアは、このケーブルを使うことは考えないのだろうか? 普通のS/PDIF用光ケーブルなんて、きっとマルチモードだし、減衰も大きそうだし、特性も悪そうだから、この通信用インタフェースとケーブルを使えば、波形が美しくなり、ノイズやジッタなどが減って、音質が向上するとは思わないのだろうか? (僕は思わないがw) まあ、音質は分からないとしても、コネクタはしっかりしているから、それだけでも使う価値はありそうだ。

ヨドバシには全く置いてなかったので、Amazonで注文した。線が黄色の物は安いのだが、目立つのは嫌なので、割高だけど白色のものにした。5mで約1500円だった。プライム会員でないと送料が掛かるのだが、運良くお試し会員になれたので、なった。

今朝届いたが、とても簡素な袋(クッションの薄い紙袋)に入っていて、輸送中に破損しないのかと思った。更に、「ステンレス管で保護」とかいう割には華奢で弱そうだった(しなやかで、全然硬さを感じない。径は3mm程度)。破損させないように気を付けるに越したことはないだろう。さっそく試してみたら問題なく通信できたので、ONUをルータの近くに移動させた。ルータ同様に横置きできることが分かったので、最終的には、本棚の下のルータの隣に置いた。ついでに、JACKが問題なく動いているので、グライコ(DEQ2496)を仕舞って、本棚も少しすっきりさせた。

(長らく掃除をしていなくて埃が溜まっているので)写真は載せないが、光端子の付近がとてもすっきりして、大変気分がいい。ONUがなくなった以外に、光通信自体には電源は要らないので(というのはまやかしで、実際には光を出すのも受けるのにも電源は要る。この光は局から直接来ているのだろうか? それとも近くに中継点がある?)、電源アダプタなどを置く必要がなくなったのも大きい。あと、光ケーブルが細くてLANケーブルより目立たないのもいい。

PS. ちなみに、通信速度を測ってみたら、Fast.comで"140Mbps"と出た。これが速いのか普通なのか、値が正しいのかそうでないのかは全く分からないし、普通に通信できればいいから気にしないがw、とりあえず、光ケーブルに問題はなさそうだ。

(7/27 2:44, 6:48, 7:36 写真を載せ、少し加筆)

  •   0
  •   1

この連休にはオーディオ(スピーカー・部屋)の音響特性の測定と調整をしようと思っていた。が、今日は下の家族が居るようで、子どもが走り回ったりして雑音が出るので延期した。それで、ちょっと前に思い付いた機能を作ってみた。

僕は、gmusicbrowser(GMB)の出力は標準のPulseAudioでなくJACKに出すようにしている。それに深い意味や大きなメリットがある訳ではないのだが、イコライザや出力はJACKなので、PulseAudioを介さずに直接JACKに入れることで、わずかに音の劣化が減ることを期待しているのだ。

が、それにはちょっとした問題がある。GMBのJACK出力は、曲を再生中以外ではなくなってしまうので、そのままでは再生するたびに接続しなければならず、全く実用的でない。それで、jack-plumbingという自動接続プログラムで接続するようにした。

それで問題なく使えていたのだが、先日、一つだけ問題が見つかった。音源がモノラル(正確にはチャネル数が1)の場合、左のスピーカーからしか音が出ないのだ(JACKでなく、PulseAudioの時は出ていた)。

どういうことかというと、GMBやJACKにはモノラルをステレオに変換(正確には、単一チャネルの音を両チャネルに出す)する機能がないため、モノラルの場合にはGMBからは最初の出力ポート(左チャネル)しか生成されず、jack-plumbingにもチャネル数が1の時は重複接続するような機能はないため、結局、左チャネルの入力ポートにしか接続されないので、左からしか音が出ないのだ。

モノラル(1チャネル)の音源なんてほとんどないから、我慢・無視すればいいだけなのだが、好奇心とか興味でなんとかしたくなった。それで、それにはGMBの改造が要るので、どうせやるなら、ついでにJACKへの自動接続機能も付けて、jack-plumbingを廃止したくなった。やり方は大体分かっていたので、今日は実装と修正をした。

それから、別件だが、少し前に、特定のアプリの音を特定の出力(例: ヘッドフォン)だけに出したくなって、それも実現していた。

以下に、それぞれの実現方法や実装の概要やちょっと苦労した点を書く。

(4/29 13:25追記) さっき、昨日思い付いたこと(下記の「Gstreamerの機能でも接続できるのかも知れない。」)を試したら、意外に苦労はしたものの、概ねうまく行った。おかげで、処理を大幅に簡素化できた。Gstreamerには分からないことが多過ぎて、まだ気に入らないこと(モノラルの処理)があるのだが、とりあえずは良しとする。以下に、その内容を"[4/29]"として追記する。

(4/30 9:42追記) 昨夜(4/29)、上に書いた「気に入らないこと(モノラルの処理)」もできた。Gstreamerの動作が調べたことと違うので、やっぱり苦労した。他に、特定アプリの音に関する接続漏れが見つかったので、修正した。以下に、それらの内容を"[4/30]"として追記する。

GMBからJACKへの自動接続機能

  • GMBで再生時、Gstreamer(再生用ライブラリ)の再生準備をした後(playbinというものの初期化後)、指定したJACKの接続先(入力ポート)に接続する。
    • JACKへの接続にはjack_connectコマンドを使った。もしかしたら、Gstreamerの機能でも接続できるのかも知れない。
    • [4/29] GstreamerのJACKモジュール、jackaudiosinkの自動接続機能でJACKに接続できるようになった。今までできなかったのは、仕様(使い方)を理解していなかったのと、JACKサーバに知らない機能があったためだった。
      • jackaudiosinkのプロパティconnectを"auto"にし、port-patternに接続先を設定(正規表現。例: "jack_mixer:In .+")すれば自動的に接続される。
      • JACKサーバのバージョンによっては、self connect(アプリが自分で接続する機能)が無効化されているために接続できない場合がある。その場合は、jack_controlコマンドでself connectモードを" "(self connect有効)に設定し、サーバを再起動する。
        • 例:  jack_control eps self-connect-mode " "
      • self connectを有効にした時、PulseAudioサーバのバージョンによっては、pacmdでmodule-jack-sinkをロードした時に、自動的にデフォルト出力に接続される場合がある。その場合は、ロード時に自動接続を無効化すればいい。
        • 例: pacmd load-module module-jack-sink connect=false
      • ただし、私はJACKサーバをjackdbusで起動しており、その場合にはmodule-jack-sinkが自動でロードされるようで、上記の指定は無効なので、JACKサーバの起動後に自分で切断している。設定ファイルに書けばいいのだろうが、JACKの開始スクリプトに書いた方が確実と考えた。
  • 曲をスキップさせたり再生ゲインのモードを変更した時などにはplaybinが初期化されるので、再度接続する。
    • [4/29] jackaudiosinkの機能で接続する場合には不要になった。
  • 理由は分からないのだが、playbinの初期化直後は接続に失敗するので、その場合は一定時間後にリトライするようにした。
    • たまたま、GMBには500msの周期処理(UpdateTime)があることに気付いたので、その中にリトライを追加した。
    • [4/29] jackaudiosinkの機能で接続する場合には、自分で接続しないので失敗することもなく、リトライは不要になった。
  • 接続済みの場合に再度接続しようとすると、無駄な処理の繰り返しになって負荷が増えるので、接続しようとする前に接続済みかどうかを調べるようにした。
    • JACKの接続確認にはjack_lspコマンドを使う自作のコマンドを使った。
    • [4/29] jackaudiosinkの機能で接続する場合には、自分で接続しないので不要になった。
  • 接続先ポートはGUIで設定できるようにすべきだが、頻繁に変える訳ではないので、今はプログラムの中に記述している。

GMBでのモノ→ステレオ変換

  • 上記のJACKへの自動接続時に、再生しようとしている曲がモノラル(チャネル数=1)だった場合、最初のチャネル(左)をJACKの右チャネル入力にも重複接続する。
  • [4/29] Gstreamerの信号処理機能を使えば、1チャネルを2チャネルにすることも可能そうだが、方法が分からなかったので、ミキサーにモノラル入力を追加し、モノラルの場合には、出力先をそこにすることにした。
    • 試しにモノラル入力に音を入れてみたら左右両方に出力されることが分かったので、こうした。
  • [4/30] Gstreamerの信号処理機能を使い、1チャネルを2チャネルにするようにした。
    • GMBのイコライザの処理を参考にして、Gstreamerの「パイプライン」というものを追加した。
    • 調べたところでは、"audioconvert ! audio/x-raw,channels=2"(チャネルを2つに増やす)というパイプラインでできるはずなのだが、どうしてもエラーになってしまう。また、"audioconvert mix-matrix='<<(float)1.0, (float)0.0>, <(float)1.0, (float)0.0>>'"(左チャネルの音を右チャネルにも出す)も駄目だった。試行錯誤の結果、"audiochannelmix left-to-right=1 right-to-right=0  ! audioconvert"(左チャネルの音を右チャネルにも出す)は成功したので、これを使うことにした。
  • 曲がステレオ(チャネル数>1)に戻った場合は、右チャネルへの重複接続※を切断し、通常の接続を行う。
    • JACK接続の切断にはjack_disconnectコマンドを使った。
    • [4/29] ※「右チャネルへの重複接続」は「モノラル入力への接続」と読み替える。
    • [4/29] jackaudiosinkの機能で接続する場合には明示的な切断手順がないため、一旦、playbinの状態を初期化してから設定すことにし直した。以下に手順を示す。
      1. playbinをset_state("null")で初期状態にする。
      2. 同様に、Ready状態にする。
      3. 出力先を変更する(port-patternを設定)。
      4. 1と同様に、Paused状態、Playing状態にする。→ 再生が再開する。
    • [4/30] GMBからは常に2チャネルが出力されるようになったので、重複接続やモノラル入力への接続切り替えは不要になった。
  • この時、通常の接続を接続する前に重複接続を切断すると、一瞬音が切れるように聞こえるので、通常の、右から右への接続を行ってから、重複接続(左から右)を切断するようにした。
    • こうすると、一瞬音が混じるはずだが、音が切れるよりはマシなので、こうした。実際には混じって聞こえる感じはしないので、一種の錯覚なのだろう。
    • [4/29] jackaudiosinkの機能で接続する場合には音が途切れないので、不要になった。

特定のアプリの音を特定の出力だけに出す。

  • PulseAudioに、新しい出力先を作る。
    • 新しい出力先を作るには、pacmdコマンドでmodule-jack-sinkをロードした(pactlでもできるはず)。
    • 例: pacmd load-module module-jack-sink channels=2 client_name=PA_alt_jack_sink  sink_name=PA_alt_jack_sink
  • 対象のアプリの音をその新しい出力に出すようにする。
    • アプリの音の出力先は、音量調節アプリ(pavucontrol)で設定すれば、それが記憶されて、以降は自動で出力されるようになるが、プログラムで明示的に接続した方が、後日、設定したことを忘れて困ることがないと思うので、次のようにした。
      • pactl subscribeコマンドでPulseAudioのイベントを監視し、対象のクライアントが接続されたら、pactl move-sink-inputコマンドで、対象のクライアントの出力を新しい出力に接続する。
      • subscribeではクライアントIDしか出力されないので、pactl list sink-inputsコマンドでクライアント名を取得して対象のクライアントかどうかを判定し、同時に得られるクライアントの出力(sink-input)IDをmove-sink-inputに指定する。
    • なお、pactlコマンドもクライアントとして認識されるので、上記処理でpactlを実行するたびに新規クライアントのイベントが生成されて無限ループになってしまうので、pactlコマンドの実行後は新規クライアントのイベントを1個読み捨てるようにした。そのため、タイミングによっては本当の新規クライアントイベントが破棄される可能性があるが、起こる確率が低いので、対処はしていない。

以下にJACKの接続例とミキサーの図を示す。

左図で、左中央の"gmusicbrowser"がGMBの出力で、上記の自動接続機能によって中央のミキサーの入力(jack_mixerのIN L,R)に自動接続される。モノラル時には、上記の変換機能によって、中央図のように、GMBの1つの出力が重複してL,Rチャネルに自動接続されて、両方のスピーカーから音が出るようになる。

[4/29] 改良後のJACKの接続例とミキサーの図を示す。

[4/29] モノラル時には、上段右図のように、GMBの出力がミキサーのモノラル入力(jack_mixerのMono_In)に入り、ミキサーによってL,Rチャネルに出力されるので、両方のスピーカーから音が出るようになる。

[4/30] モノラル時も左右チャネルから音が出るようになったので、ミキサーのモノラル入力への接続は行わなくなった。そのため、モノラル時の接続状態は上の「通常(ステレオ)再生時」と同じである。

特定アプリの音は、PulseAudioから左下のPA_alt_jack_sinkに出力され、ミキサーの入力(jack_mixerのAlt_In L,R)に接続されている(この接続は勝手に切れないので、静的な設定にしている)。ミキサーでは、この音(の中央列: Alt_In)をミュートしている(図のMボタンがミュート)ので、通常の出力(MAIN L,R)からは出ないのでスピーカーからは出ず、特定の出力(Realtek_aout)だけに出力される。ミュートを解除すれば、通常の出力にも流れて、イコライザ(jack_rack)を経由してJACKの標準の出力(system)に出て、スピーカーからも出すこともできる。

[4/30] 特定アプリ以外の音(通常の音)をヘッドフォンに出すことを忘れていたので、接続を追加した(jack_mixer: In Out L/R → Realtek_aout: playback_1/2)。

まあ、オーディオシステムは、あくまでも音楽を聴くのが目的であって、こういう作業はまったく本質ではない、自己満足とか慰みの領域ではあるのだが、自分で構築したシステム(暇さえあれば、自分のアイデアで改良できる)で音楽を聴けるのは、なかなか楽しい。そして、こんなことはWindowsやMacではまず無理(可能ではあるだろうが、手軽にはできない)だろうから、Linux+JACKにして良かったと思う。とはいえ、実は、こここに書いたことだけなら、WindowsやMacではやる必要のない作業なのかも知れないw

が、それにしても、こういう作業をすると、今まで知らなかった・やったことのないことを見つけたり気付いたりすることがあって、技術者としてはおもしろいし、いつか仕事でも使えるかも知れないから、一石三鳥だw まじめな話、Windowsだと、基本機能になければ(その基本機能もコロコロ変わる)、他人が作ったアプリを探して使うしかない(ものすごく時間を掛けて、自分で作れば別)から、おもしろくないしつぶしが効かない。あ、Mac?、あんなものは林檎社がUNIXを腐らせしまっているので、全く論外ですw

 

PS. 今の録音エンジニアなどの方には当たり前なのだろうが、今回のように、「接続を忘れてたから追加する」とかいうのがマウス1個wでできるのは、JACKの大きなメリットのように思う。昔(僕が中高大の頃)は、本物のケーブルで接続しなければならなかったから、端子やケーブルや機器が足りなければ接続できなかったし、端子の形状が違っても駄目だったし、信号レベルやインピーダンスも考慮すべきだったし、並列・直列接続し過ぎると音質が劣化するし、ミキサーを介さずに複数の出力を同じ入力に繋げるのは電気・音質的に良くないことだった。

今はそんなことを全く意識する必要がなく、自由に接続できるので、すごく便利だ。機器にしたって、「ミキサー(あるいはミキサーのチャネル)がない・足りないからから増やそう」と思っても、お金を工面して買いに行くw必要などなく、即座に無料で増やせる。もちろん、PulseAudioやALSAでもそういう変更は可能だが、GUIではできず、設定ファイルを書き換える必要があるから、「ちょっとやってみよう」という気にはならない。

そういうことがあるから、いろいろな手間や欠点があったにも関わらず、JACKに乗り換えようと思ったのかも知れない。 (4/29 10:34)

 

(4/29 5:02 加筆・修正; 13:58 改良した内容を追記; 4/30 10:16 4/29夜の改良・修正点を追記、その他、若干修正; 4/30 10:37 題を変更; 4/30 17:59 若干修正)

  •   0
  •   0

以前にも書いたことがある気がするが、近頃、以前にも増して音の違いが分かるようになった気がする。その原因は、音の出力系をグライコ(DEQ2496)からJACKとPC内蔵DACに切り替えたからとは思えないが、気付いた時期とは一致している。

例えば、以下のようなことがある。

  • ビートルズの2009年ステレオリマスターと"Millennium remasters"(海賊盤。"Dr. Ebbetts"と呼ばれているものの更なるコピー)の音の違いが一瞬で分かる(「音が悪いなあ」と思ってプレーヤーを見ると、後者。ちなみに、リマスターを買った当時は、後者の方がいい音だと思っていた。なお、1988年に出たCDは分からない)。
  • 小泉今日子 「ヤマトナデシコ七変化」の「クシャーン」という、何かが潰れるような音がリアル(正確には、実際にはリアルでないことも分かるのだが、リアルっぽく聞こえる: 「カニかま」がちゃんとそれと分かり、銘柄が判別できるような感じw)。
  • 同 "The Stardust Memory"のサ行の音の悪さ(「潰れ気味」と書けばいいのか。DeEsserの設定不良?)。

まあ、機材や再生環境に関しては、DEQ2496を導入した時から必要充分な状態になったと思っているので、短期的には体調の変化(音に敏感になっている?)、長期的には経験値が上がったということなのかと思う。あ、環境については、JACKに切り替えた時に部屋の特性に対する補正を再調整したのが効いている可能性はあるか。

いずれにしても、昔は劣悪(と言っても、当時はそれなりにいいものを揃えていたつもりだった)な機材や再生環境で、原音(レコードやCDに記録された音)に忠実な再生なんて夢のまた夢だったし、経験が少ないために脳がついて来られなかったのだろうか、聴いても音や歌詞が判別できないことが多かった。

だが今は、(とりあえず)忠実な再生が出来る機材や環境が手に入って、手軽にいい音で再生でき、脳も(老化するばかりでなくw)継続的にバージョンアップできているようなので、うれしい限りだw

 

PS. 驚くべきことに、今、ビートルズの2009年モノラルリマスター("Please Please Me")を聴いてみたら、全然音が悪くない。買った当時は、音(振幅)が変に圧縮されて聞こえて嫌だったのだ。これは、機材・環境の改善の効果かも知れない。だとしたら、随分長い時間を無駄にしていたことになる。もう少し確認してみたい。

確かに音は悪くないのだが、やっぱりステレオ盤の方が好みだ。ステレオ盤の方が抜け感(今はやりの用法ではないw)があって、心地良い気がする。

PS2. 上で1988年のビートルズのCDの音は分からないと書いて気付いたのだが、Dr. Ebbettsはレコードから音をダビングしているから音が悪くなっている一方、本物のCDはオリジナルのマスターテープからデータを作っているから音の劣化がないということではないだろうか。

ということは、今、(どういう訳か)みんながありがたがっているアナログ盤(レコード)もそんなものではないだろうか? まあ、今のレコードは制作者がそれ用にマスタリングしているのだろうから(全くご苦労なことだ)、それなりの意味はあるのだろうけど。

まあ、好みの問題だ。ストレートな音を好むか、アナログ媒体のフィルタを通した音を好むかの違いだろう。後者が好きなのなら、聴けばいい。僕はレコードやテープといったアナログ媒体自体には全く価値を感じないし、音がいいなどとも思わないし、好きでもない。

「コーヒーを純水(H2O)で淹れるか湧き水で淹れるかの違い」と書くと、なんか違う気もするしw、「MT車とAT車の違い」、あるいは、「電気自動車とエンジン車の違い」と書いてもやっぱり違う感じだ。

さらに話が逸れるが、将来、モーターの車が普通になったら、「エンジン車のまろやかな加速がいいんだよなあ」とか言って乗る人が出て来そうだw

  • Dr Ebbetts

    Dr Ebbetts

    Please do not use Dr Ebbetts as a label unless it …

  •   0
  •   0

暇があると、特にやりたくはないのだが、つい、JACKのイコライザ(の種類)による耳痛の原因を調べ出してしまう。今日は、以下のことをした。

  1. DEQ2496("DEQ")とJACKのイコライザのDIN dual tone特性の比較
  2. 耳の痛くなるイコライザの一部を無効にした場合の確認
  3. JACKのイコライザの作り(実現方式)の調査
  4. JACKのイコライザ同士やDEQとの波形の差の測定

1では、DEQとFIL-pluginsの4バンドPEQ("PEQ4")とCalf Jack Hostの8バンドPEQ("Calf")で有意な差はなかった。だから、混変調歪みが原因ではなさそうだ。

2では、Calfの低域(120, 200Hz)の広く深い減衰設定を無効にし、代わりにPEQ4のその部分を使ったら、耳痛が出なかった。そのため、Calfでの広く深い減衰設定が問題らしいことが分かった。

3でPEQ4とCalfのプログラム(ソースコード)を確認したら、重要なことが分かった。耳の痛まないもの(PEQ4)と痛むもの(今回はCalfを調べた)では、フィルタの実現方式が異なっていたのだ。

  • PEQ4: 格子(lattice)型IIRフィルタ ("2nd order resonant filter implemented with Mitra-Regalia style lattice filter" → 典拠)
  • Calf: 双2次(biquad) IIRフィルタ(直接I型) ('"traditional" Direct I form' → 典拠)

IIRフィルタの実現方式の特徴を調べたところ、方式によって演算誤差の影響が異なり、直接型は誤差の影響を受けやすく、余り使われていないとのことだった。

余談: 大学で勉強したので、上のような話は調べるまでもなくスラっと出て来ないといけないのだが、当時(今もw)、フーリエ変換やFFTまでは問題なかったが、「z変換? はぁ?」となり、難しい式を見ただけでお腹いっぱいになって「パス」していたw だから、今回も、「ソースを読んだ」と言っても、コメントから判別した程度だ。

これと2の結果より、直接型を使っているイコライザ(Calfなどほとんどのもの)は、広く深い減衰設定を行うと誤差の影響(誤差が蓄積するのだろうか)で音質の劣化(歪み)が生じて耳が痛むのではないかと推測する。ただ、試験信号のような単音(純音)では歪みは生じず、音楽(特定のポップ音楽)で生じるのが不思議だ。 ← 試験信号でも劣化は生じているのだろうが、(下のグラフで分かるように)振幅が小さいので、周波数特性のグラフを見たり比較しただけでは識別できないのだと思う。

それで、4でPEQ4とCalfの波形の差やDEQとPEQ4およびCalfの波形の差がどうなっているか見てみた。結果は以下である。

  • PEQ4とCalfの波形に違いはあるが、PEQ4とCalfのどちらが「正しい」のかは分からないし、それらの差の振幅はかなり小さく(最大で-50dB程度(=最大音量の約0.31%))、それが聴こえて音質に影響を及ぼすのか疑問だ。ただ、曲全体を測定した訳ではないので、測定していない箇所で差(波形の違い)がもっと大きくなっている可能性はある。 → Rush "Big money"の曲全体で確認したところ、特に大きくなっている箇所はなかった。
  • 差信号の帯域は200Hz-2kHz程度(概ね、イコライザで補正している範囲)で、これが歪みになって耳を痛くしているのだろうか? ただ、耳痛の原因になると言われている帯域(例: 4kHz以上)より低いので、本当に耳痛の原因なのかは疑問だ。ただ、上と同様に、測定していない箇所で高域に歪み成分が出ている可能性はある。 → Rush "Big money"の曲全体で確認したところ、超低域(60Hz付近)の差が大きくなっていた(この付近は曲自体の振幅も大きかった)。
  • DEQとPEQ4またはCalfの波形にも違いはあるが、DEQとの差分の求め方に問題がある可能性がある(DEQと内蔵DACの出力はアナログであるうえに、振幅差や時間差があるので、差を正確に求めるのが難しい)ので、有意な差かどうかは疑問だ。

曲全体で確認した結果から、どうやら、(PEQ4の出力が「正しい」と仮定すれば、)Calfの演算誤差(あるいは音質劣化)の影響は超低音に出ているようなので、CalfにHPFを追加して超低域をカットして聴いてみたところ、わずかに耳閉感はあったものの、概ね問題なかった。

超低域の差の原因としてもう一つ考えられるのは、フィルタの遅延時間(位相)の差だ。どちらかのイコライザが低域になるほど遅延時間が長くなるか短くなるのであれば、その帯域で差を求めたら片方が筒抜けになるだろうから、グラフのような山ができるのは自然だ。これは誤差の影響でも音質劣化でもないので、耳痛の原因ではなくなる。そうであれば、最初に書いた帯域(200Hz-2kHz)が効いているのであろう。ただ、上記のように、この帯域をカットしたら耳痛が改善したので、やはり、誤差の影響はあるのではないかと思う。

イコライザの演算誤差による音質劣化が直接耳痛を起こすのか、スピーカーで混変調を起こして高域の歪みになって耳痛になるのかは分からない。なお、曲によって耳痛が起こったり起こらなかったりするのは、曲ごとに誤差が問題となる帯域の成分の量が違うからではないか。いずれにしても、Calfのような作りのイコライザは僕には使えないことが分かった。

(4/3 5:18, 7:49追記) 上記のPEQ4とCalfの差分は、演算誤差でなく、それらの設定パラメタ(フィルタの幅・鋭さ)の違いによるものが大きそうだ。というのは、PEQ4は、それをQ値でなく独自の値で設定するので、目分量で決めた。それをCalfに移植する時には、グラフの形が合うように目分量でQ値を決めたので、パラメタは厳密には同一にならず、曲線の形は一致しないから、比較的大きな差分が出ているのだ。あとで、PEQ4のフィルタの幅・鋭さとQ値の関係を調べ、より正確なQ値をCalfに設定して差分を測定してみたい。

(4/5 6:48, 7:35追記) PEQ4のバンド幅の設定値(→ BW)とQ値の関係を推定したところ、以下の式が良さそうだった。

Q= 0.45/BW

そのQ値(元の値から最大2%程度変わった)をCalfに設定したところ、特性のグラフは良く一致した。PEQ4との差分も20dB程度小さくなったが、スペクトラムの形状は余り変わらず、超低域(20-75Hz)の成分が大きい。なお、グラフで見る限り、位相特性の差はなかった。

やはり、特に超低域でイコライザ(フィルタ)の誤差が出るようだ。両方に誤差があって、どちらかが大きいはずだが、数値計算でフィルタを実現する以上、「真のフィルタ」の出力を得ることはできないから、どちらがより正しいのかを測定することはできない(それぞれの式から、誤差の理論値を求めることは可能だろう)。ただ、聴感(耳痛のなさ)ではPEQ4はDEQに近いので、PEQ4の方が誤差(別の言い方をすれば、音質の劣化度合い)が少ないと考えられる。

ただ、差分の最大振幅は約-60dBで、0.1%に相当するのだが、それが耳痛を起こす程音質を劣化させるのだろうか? スピーカーでの混変調歪みや、耳や脳内での妨害が大きいのだろうか?

いずれにしても、(特定の使い方をした時に)「音質の悪い」イコライザ(フィルタ)はあると言え、後述の結論に変更はない。

そして、すべてのものを確認した訳ではないが、多くのJACK(正確にはLADSPAやLV2)のイコライザは、安直な実装を行っている可能性がある。Calfなんて、"Studio"なんて単語が名前に入っているうえに見た目もかっこいいけれど、中身はお粗末(双2次IIRフィルタの直接I型)でがっかりした。演算誤差の影響がどの程度かは分からないが、リソース(処理速度、メモリ量)の豊富なPCで実行するのだから、多少演算量が多くなっても、誤差に強い(=ロバスト性が高い、音質劣化が少ない)方式を選ぶべきだ。おそらく、実装する時に最初に目した(あるいはどこかからのコピペ?)、処理が簡単な方式(直接型)を禄に検討・評価せずに使ったのではないか。

一方、DEQはプロ(スタジオ)用機器だからか、(PEQ4と同様に)演算誤差の影響を受けにくい方式を使っていて、それで耳痛が出ないのではないか。そして、PEQ4を見つけたのは全くの僥倖なのだが(これがなかったらJACKは使えなかったから、DEQから脱却できなかった・・・)、ページを見ると、ちゃんとした方のようなので、定石通りに作ったのだろう。

ただ、多くの人がCalfなどのイコライザを使って問題になっていないということは、演算誤差の影響は実際にはなく、あっても耳痛には関係ないか、僕の使い方(設定)が常識外れで音質が劣化しているのか、僕が特に敏感なのかも知れない。あるいは、現実にはJACKのイコライザ(、あるいはJACK自体)を使っている人がほとんど居ないから発覚していないだけなのかも知れない。それはそれで、他にも問題がありそうだから、結構良くない話だ・・・

という訳で、ひとまずの結論は以下になる(したい)。

耳の痛みはイコライザ(PEQ)のフィルタの作り(実現方式)に起因する可能性が高い。

  • 具体的には、定説通り、双2次IIRフィルタの直接型は良くなさそうだ。
  • イコライザの使い方にも依存し、低域に広く深い減衰(例: 120Hz, -9dB, 1.5oct)を設定するのは良くなさそうだ。

 

PS. DACなどで、フィルタを切り換えて音が変わる・変えられるというのは、こういうことがあるのだろう。ただ、前にも書いたが、それは売りにするものではなく、(すべての場合に最適なものがないから)仕方なしにやるとか、おまけでしかないと思う。元々いいものを使っていれば、切り替える必要なんてない。車のタイヤで言えば、オールシーズンタイヤで充分なら交換は不要で、無理ならノーマルとスタッドレスで切り替えざるを得ないのと同様だ。

それから、ハイレゾ化(アップサンプル)すると音が変わると言われるのも同様だ。その時に使うフィルタの作りがイマイチなために、音が(劣化とまでは言わないが)変質することもあるのではないか。ニセレゾなんて、元々ない音を追加して本当に変質させているしねw

PS2. JACKの自由に配線できる機能のおかげで、耳痛の原因を調べるためのいろいろな実験(確認)が手軽にできた。が、それは実は本末転倒で、耳さえ痛くならなければ、実験など不要だったのだ。でも、やっぱり、いろいろ遊べるのは好きだw

  •   0
  •   0

JACKが落ち着いてちょっと余裕が出来たので、例のイコライザ(の種類)による耳の痛みの問題をまた少し調べた。

まず、今までに、FIL-pluginsの4バンドPEQ ("PEQ4")なら問題ないことが分かっていて(、今もそれを使っているのだが)、その設定を他のイコライザに適用(移植)したらどうなるか試してみた。結果は、残念ながら駄目だった。以下の4種類を試したのだが、どれも、耳の痛みに通じる耳閉感があった。

次に、問題の原因を探るため、以前から疑っていた、混変調歪み(IMD)(につながる特性)を測定しようとしてみた。以前はうまく行かなかったのだが、Room EQ Wizard (REW)の信号発生器のdual tone機能で2つの周波数の音を同時にイコライザに入れ、その出力をREWのリアルタイムアナライザ(RTA)で測定した。

REWはいろいろな種類のdual toneが出せるのだが、とりあえず、一般的そうなDIN(250Hz:8Khz= 4:1)とSMPTE(60Hz:7kHz= 4:1)で試した。直感的には、DINの方が音楽再生に近い気がする。

すると、興味深い結果が出た。以下の各グラフで、黒はイコライザなし(原音)、赤はPEQ4、青はCalf、ベージュはDSP、上の群は左チャネル、下の群は右チャネルである。また、低音の山の辺りは差が出ないため、上部をカットしている。なお、TAPはかなり特性が悪かったので(高音の山が出なかった)表示しておらず、TBPWS+SBPの測定は省略した。

僕の考えでは、イコライザなしに近いもの、あるいは、山が鋭いものや2つの周波数の間が低いものが特性がいい(=耳痛が少ない)はずなのだが、実際には、特性の悪そうなPEQ4(赤)が(耳に)良く、特性の良く見えるCalf(青)やDSP(ベージュ)は駄目だ。

何種類かの測定方法で試したのだが、どうも不思議なことが多かった。窓関数(連続した信号の切り出し方)や表示方法を変えるだけで、特性(グラフの形)がかなり変わってしまった。そもそも、イコライザなしの特性が予想外に悪いのが腑に落ちない。それは、僕がこういう測定の基本を知らないためだと思う。

だから、上のグラフ自体はイコライザの特性の良し悪しを直接表している訳ではなく、各イコライザには混変調歪み(あるいは、耳痛の原因となる音質劣化)の出方の違いがあり、グラフはその違いがあることだけを示していると解釈した。そして、(グラフからは信じがたいが)PEQ4は一番劣化が起こりにくい(少なくとも、僕には一番音質がいい)作りなのだろう。

その後調べたら、パラメトリックイコライザ(PEQ)はIIR(無限インパルス応答)フィルタで作るらしいが、IIR型は演算誤差が蓄積するという情報があった。その誤差が蓄積して音質が劣化し、耳の痛みが生じているのではないかと考えている。ただ、JACKのモジュールの内部処理は浮動小数点演算のはずなのに、それでも誤差が溜まるのか、ちょっと分からない(確かに、普通の数値計算でも、いい加減な処理をしたら誤差が増大してまともな結果が出ないから、それと同様なのだろう)。処理方式で誤差蓄積量が違うという記述もあったので、最終的にはイコライザのプログラムを読むしかないが、かなりハードルが高い。それに、読んで、「確かに駄目だ」と分かったところで、僕には改良することはできないから、読んでも無駄だとも言える。

あと、PEQは「Qが鋭いと演算精度が下がる」という記述もあった。「Qが鋭い」というのは、Qの値が大きいことなのか小さいことなのか、山が鋭いことなのか分からないが(某有名オーディオ機器メーカーの広告なので、表現がいい加減なのだろうw)、いずれにしても、設定によっては音質が劣化するのだろう。そして、僕の設定(多分、低域の幅広く深い減衰)が良くないような気がして来た・・・

その、PEQの設定(使い方)の問題は、PEQやIIRフィルタの作りや式に詳しい人なら当たり前のことなのだろうが、僕は全然ピンと来ない。ただ、ロバスト性が高いイコライザがあることは確かで、PEQ4はそうだろうし、製品ならDEQ2496がそうだ。プロ用機器は、そういうところがちゃんと考えられているのかも知れない。

という訳で、現段階では以下のようなことが分かっている。

イコライザの種類(作り)と使い方によって音質は変わり(音質が劣化し)、耳が痛くなることもある。ただし、その音質劣化は普通の周波数特性では判定できず、複数の周波数の音を同時に入れるような測定(例: DIN dual tone)をしないと分からない。

これは、「物理特性では本当の音質は分からない」という説を裏付けそうだ。

なお、混変調歪みは「本当の音質」に関係している可能性があるが、今は表示している機器が少ないし、2つの周波数だけでは不十分で、無限の組み合わせでの測定が必要そうだ。

だから、オーディオ機器メーカーは、良く、「『マイスター』が何百時間も聴いてチューニングした」とか言っているのだろうか。僕の考えでは、その音の良し悪しの本質は主観的なものでなく、上記のような複数周波数からなる信号(=音楽信号)に対する特性に帰着するのだろうが、それに気付いている人が少ないのか、気付いていても、(うまく表現できる値がないので、)あえて主観的なものと表現しているのか(その方がありがたそうだから?)、分からない(僕にはどちらでも構わないが、音質は(主観的なものだから)数値とは無関係だと言われたり、それを発展させて、物理法則とは無関係な、非論理的な「トンデモ理論」を出されると、どうしても信用できない)。

もし、音の良し悪しの本質が主観的なものでしかなかったら、オーディオ機器なんて作った人の耳(あるいは運?)に依存し、その「耳」は買う人みんな違うはずだから、一般的に「音のいい製品」なんてあり得ないことになる。それだったら、本当に「何だっていい」ことにならないか? そして、誰かが「いい」と言ったものを、みんな盲信して買うのか(昔からそんな気がするがw)。

それにしても、オーディオ機器の音質を測る・示す・改良するのは、なかなか奥が深いものだ。

  • bmc0/dsp

    bmc0/dsp

    An audio processing program with an interactive mo…

  •   0
  •   0

JACK(Linuxのサウンドシステムの一つ)への移行が軌道に乗ってから約2週間経ったが、大きな問題はなく、満足している。また、耳が痛くなる問題は再発していないので、解決したようだ(結局、PEQの使い方が悪かったようだ → PSも参照)。以下に、利点と欠点とその他を書く。

利点

  • 使用しているサウンドカード(ASUS Essence STX II)とアンプ(SAYA SP192AB)の機能・仕様により、システムの電源を切る前にアンプの電源を切ったり音量を絞ったりしなくても雑音が出なくなった(グライコ(Behringer DEQ2496)は電源on/off時に雑音を出す)。
    • ただし、ボリュームを全く動かさないと(摺動面の状態が悪くなって)雑音が出やすくなると聞いたことがあるので、寝る前は絞り、朝は何回か動かすようにしている(が、それでもこのアンプは雑音が出ることがある)。
  • 他のシステム(PulseAudioやALSA)と違い、(仮想的な)音の配線を(設定ファイルなどでなく)マウスでできるので、とても便利。
  • 音の処理や配線を自由に変更できるので、思い付いたことを簡単に試せるようになった(PluseAudioやALSAでやろうとすると、設定ファイルに書く必要があるので、かなり面倒)。が、ここは研究室ではなく、音楽を聴くのが目的なので、そんなに頻繁に音の実験をする訳ではない。
  • プログラム(スクリプト)との親和性が高いので、ちょっとした処理は自分で作れる。
  • イコライザの調整が楽になった(グライコの小さいディスプレイを見ながらつまみを回すのでなく、キーボードで数値を入力でき、設定をファイルに保存できる)。ただし、最終的には実特性を測定して調整する必要があり、そのためにはマイクを立てる必要があり、それはやっぱり面倒なので、ものすごく楽になった訳ではない。
  • 外部のグライコ(DEQ2496)が不要になったので、システムをコンパクトにできた(そのうちDEQ2496は片付けたい)。また、DEQ2496が壊れた時のことを心配する必要がなくなった。ただし、サウンドカードやPCが壊れた時の心配は要る。
  • PCから外部に(光や同軸やUSBで)音の信号を出さなくてもいいので、その分、(ジッターが減るなどして)音質の劣化が減るはずだ。が、実際にはそういう経路の寄与は微々たるものだろうから、分からないと思う。
    • 逆に、サウンドカードはPCの雑音や電源変動の影響を受けやすいが、聴いた感じでは全く分からない。

欠点

  • JACKの扱えるサンプリングレートは固定で、単一の値である(それ以外は変換される)。僕はCD系(44.1kHz)がほとんどなので問題ないが、DVDなど(48kHz)の音も良く聴く人やいろいろなハイレゾ(JACKが対応しているかは不明)を聴く人には余り良くないだろう。
  • 音の処理(信号処理)をソフトで行うので、その分、CPU負荷が高くなる。ただし、普通に再生している場合は、OSのload average(平均待ちプロセス数)は0.5以下、JACK関連プロセスのCPU使用率は4%程度なので、全く実害はない。
  • 間違ってウィンドウを閉じるなどして、JACKの各プログラムを終了させると、音の経路が切れて音が出なくなってしまうので、注意が要る。同様に、イコライザの設定を間違って変えてしまうと音がおかしくなる。また、JACK関連のプログラムが多くなると、アイコンが増えて表示領域がいっぱいになってしまう。
    • → 滅多に設定を変えないプログラムは、アイコンを非表示にするといいのかも知れない。
  • ごくたまに、重い処理(例: 外部HDDの取り外し)をすると音が飛ぶことがある。ただし、原因となった操作をするといつも起こる訳ではないので、JACKには関係ない可能性が高い。
    • → 音飛びを防ぐため、JACKとgmusicbrowser(以下、GMB。実際にはGstreamer)のバッファサイズを大き目にした。
  • JACK関連の詳しい情報が余りなくて(あっても誤りだったり古かったりして)、自分なりに理解して使えるようにするのに結構苦労した。更に、「これだけでいい」というソフトがなく、取捨選択や自分で作る必要があった。また、JACK自体が古く、更新がされていないようなので、将来性に不安がある。
    • が、JACKは信号処理の枠組み程度のものなので、もっといいものができれば、それで既存の(LADSPAやLV2の)イコライザは使えるだろうから、大丈夫ではないか。
  • 当たり前ではあるが、間違った配線をすると、音がおかしくなったり、出なかったり、ハウリングなどが起こったりするので、注意する必要がある。

その他

  • (グライコのAUX出力が壊れたため、代わりにオンボードのサウンド出力を使うようにしたために)ヘッドフォンの音量が不足することがある件は、jack_mixerというソフトで音量を大きくすることで解決できた。複数の出力が出せるので、スピーカーで聴く時にも(アンプの音量を変える代わりに一時的に)調整できるし、音量メーターもあるのでちょっと便利だ。
  • GMBをJACKで使うと音量が不安定になる問題があったが、Gstreamerのplaybin(これが何かは分かってない)を作る時に"soft-volume"というフラグを指定しないようにしたら直った。この意味や、これで本当にいいのかは、良く分からない。ただ、基本的に、GMBの音量は変更しない(常に100%にしている)ので、問題はなさそうだ。
  • GMBはJACKへの接続を自動では行えないようで、それで手で接続しても再生を停止すると切れてしまうので、jack-plumbingというソフトで自動接続するようにした。
  • GMBの音を(PulseAudio経由でなく)直接JACKに出すメリット(音質がいい?)があるのかは全く不明だが、余計なものを通さないので(何かしら)良いと考えて、そうしている(はっきり言って、気分の問題であるw)。
  • 以前も書いたかも知れないが、JACKの接続状態を自動的に保存するプログラムを作った。ログイン時には、JACKの各プログラムの起動後、その保存された配線を復帰させるようにしている(qjackctlは僕には使いにくいため)。
    • なお、上記のjack-plumbingと接続保存プログラムは競合するので、jack-plumbingで自動接続した接続は保存しないようにした。
  • JACKにしたのではあるが、下位(ドライバ)にはALSAが使われているので、alsamixerというプログラムでサウンドカードの設定をする必要がある(そうしないと、音が出なかったり録音できなかったりする)。分かりにくいし、煩雑な点だ。
  • JACKにしたことで音質が良くなったということはないと思う。何となく、音がいい(低音や高音が良く出ている)ように感じることがあるが、気のせいか、音量が大きくなったせいか、イコライザを調整し直したためだと思う。
  • 昔、スリープからの復帰後にJACKの音が出ないことがあったのは、使っていたプログラム(qjackctl?)が悪かったのか余計なことをしたためなのか、分からない。今は、特に何もしなくても、スリープからの復帰後にJACKの音は出る。
  • JACKはWindowsでのASIOのような位置付け(仕組みは全然違うだろう)のように感じる。

画面

 

PS. 耳の痛みは、PEQの使い方(設定)以外に、PEQの仕様(中の作り?)にもよるようだ。というのは、さっき、いくつかの別なイコライザ(Calf EQ8, LADSPA DSP, TAP Eq/BW, Triple/Single band para. with shelves)を同じ特性にして試したところ、短時間しか聴いていないのだが、どれも耳閉感があったのだ。依然として謎は解けていない。 (3/25 15:05)

  •   0
  •   0