piu lentoの日々 (piu lento days)

先日、なおきさんにちょっと音(彼のBoseのスピーカーと僕のの比較)を送ろうとして録音したら、その音が予想外に悪かったのでがっかりした。この「がっかり」には、録音した自分の声を聞いた時のような違和感(実際には自分の声を録音した訳ではない)もあると思うが、雑音が多いのが主因だと思った。そこで雑音を何とかしようと思った。

音の経路は以下のようになっている。

マイク → ケーブル → マイクの電源 → マイクアンプ → PCのサウンドカード

途中の各要素を順次なしまたはoffにして雑音量の変化を調べ、それぞれの要素で生じる雑音量を推定した。詳しくは省くが、マイクアンプによる雑音が約30dBと多かった。他に、ケーブルによる雑音もあったが、マイクなしで開放しているために雑音を拾っているようだ。それから、サウンドカードをマイク入力(モード)にして"MIC Boost"(ブースト)をonにすれば、音量は大きくなるものの雑音が多くなった。ただ、通常はライン入力(モード)を使っているので、今回は関係ない。

雑音に加えて、元々マイクの音量が小さく感じていたこともあって、マイクアンプを換えたくなった。調べたら、マイクの電源(コンデンサマイクなので、電源が要る)はもちろん、USBで出力できるもの(例: ZOOM U-22, Behringer UMC22)があって、それを使えば以下のように要素数が減る(3→1)うえに、デジタルで直接PCに入力できるようになるので、欲しくなった。

マイク → ケーブル → マイク電源・アンプ内蔵USBオーディオインタフェース → PC(USB)

ただ、もちろん安くない(安いものでも5千円前後)し、製品によってはLinuxで使えない可能性もあるので、安直には買えない。いろいろ考えているうちに、もう使わなくなったグライコ(Behringer DEQ2496)のRTA(特性測定)用マイクアンプの特性が良ければ使えるかも知れないと思った。ただ、これは測定用なので、アンプの出力が外に出ている訳ではないから、すぐには試せない。

そこで、時間はあるしおもしろそうだったので、基板や回路を調べて、アンプの出力が取り出せるか検討してみた。回路図については、もちろん公開されていないので、昔入手した別製品(DCX2496)のを参考にした。基板については、最初にメイン基板を見たところ、DAC, ADC, コーデックは見つかったものの、アナログ系のアンプなどが見つからなかったので、不思議に思った。

まず、どのチップにRTAの信号が入力されているか調べた。それらしいチップは3個あった。基板の左から右に、以下のようだった。

• コーデック(ADC+DAC): AKM AK4524 (IC4) → RTA入力とAUX出力?
• DAC: AKM AK4393 (IC3) → Main出力?
• ADC?: 謎(Cirrus Logic製, 型番読めず) (IC2) → Main入力?

もちろん、位置関係やチップの性格から、RTAはコーデックに繋がっているらしいことは間違いなさそうだったのだが、謎のチップが何か知りたかった。MAIN入力端子の前にあることからしてADCだとは思うのだが、検索すると、DEQ2496のADCはAK5393(AKM製)とあり、Cirrus Logicではなく形状も違うので、不思議に思った。更にCirrus Logicで調べたら、どうやら、基板のバージョンによって以下の2種類が使われているようだ。

• 古いもの: AKM AK5393
• 新しいもの(僕のもの: V2.5?): Cirrus Logic CS5381

それで、謎チップの写真を画像処理してみたが、やっぱり判別不能だった(辛うじて"38"らしき数字が見える程度。OCRプログラムを使うと分かるのだろうか?)。印刷が経年劣化しているようなのと、表面の擦り傷か鉛筆の跡のようなものがかなり邪魔だ。

マイクアンプの出力は、上記のコーデックチップ(AK4524, IC4)の入力ピンから取れそうではあるのだが、ピンが細くて半田付けに失敗しそうだし、LRどちらの入力ピンを使えばいいか不明だったから、避けたかった。それでマイクアンプ(のチップ)を探したのだが、上記のように見当たらなかった。コーデックの中で増幅している(= 外に出せない)のかと諦めかけたのだが、検索したら、実はアナログ系の部品は入出力端子が載っている基板の裏面に実装されていることが分かって、その基板を外して、RTA入力端子付近のパターンをテスターで探り、(以前検索して見付けた)DCX2496の回路図も参考にして、どうにかマイクアンプの回路を推定した(他に、RTA入力がLINEレベルの場合にコーデックに直結する経路もあったが、省略した)※。なお、回路を推定するよりもドローアプリで回路図を描く方が大変だったｗ

※この回路図はあくまでも推定で、誤りがあるかも知れないので、注意すること。

オペアンプによる増幅回路を直列接続して増幅率を稼いでいるようだ。倍率は約42倍(= 約32dB; 前段: 約6倍, 後段: 約7倍)と推定したが、計算方法はうろ覚えなので間違っているかも知れない(ただ、調べると、マイクアンプの増幅率としては妥当な感じだ)。

早速、マイクアンプの出力が取れる箇所(オペアンプ4580(IC6)のピン1)とGNDにケーブルを接続して、PCのサウンドカードの入力に接続してみた。

特性を調べたところ、残念ながら、DEQ2496のRTAのマイクアンプは今ひとつだった。主な問題は以下のとおりである。

• 通常構成より雑音が多い: 低域: 約+3dB(120Hz), 高域: 約+5dB(4kHz), 最大: 約+10dB(15kHzの山) (AC電源系雑音を除く)
• 雑音の出方が良くない(素直でない)。(15kHz付近に山があるなど)
• 通常構成より音量が増える訳ではない。

なお、通常構成のマイクアンプは、オーディオテクニカ AT-MA2である。

参考のため、DEQ2496のRTAのマイクアンプおよび通常構成で、マイクがない場合の雑音の特性を以下に示す。DEQ2496では入力を開放にしたためにAC電源系の雑音(50Hzの倍音)が増えていたようだが、それ以外の雑音量も多く、雑音の分布(電源系を除けばフラットだからいいとも考えられる)や15kHz付近の山※が好ましくない。

※15kHzの雑音源は不明だが、MIDI(送信レート= 31.25Kbps → 1/2は15.6kHz)のクロックに関係があるのかも知れない。MIDIの信号も(デジタル音声信号も!)アナログ入出力と同じフラットケーブル(写真中央の灰色の帯)で繋いでいるのは、余りにも無神経に思える。

この原因は、マイクの信号レベルがかなり小さいのに、パターン※や配線(上記)や配置や部品＊(他と同じオペアンプを使っている)に気を遣っていないからではないかと推測する。まあ、マイクの音を再生する訳ではないし、これでも雑音量は-70dB前後に収まっているから、スピーカーからの再生特性測定用としては許容できる範囲ではあろう。

※今気付いたが、MAIN入出力に付いているGNDのジャンパ線(写真右側の縦の黒いケーブル4本)のような対策が効くのかも知れない。

＊部品に関しては、確かにこういうところなら、流行りの「オペアンプ交換」は効きそうだ。もし、同じ仕様でローノイズ型のものがあれば、改善されるかも知れない。ただ、15kHzは無関係なので、焼け石に水かも知れない。

仕方ないので、諦めてケーブルを外して元に戻した。この時、フラットケーブルの雑音防止のフェライトコアの止め金を固定する樹脂が剥がれて金具がすぐに外れるようになってしまったので、マスキングテープに替えた(写真の右側の黄色。中央は剥がれた樹脂)。

結論としては、DEQ2496のRTA用マイクアンプを使っても音量が上げられる訳ではないうえにアンプの特性が悪い(雑音が多い)ので、苦労してまで使う意味はないということになった。そして、(そもそもやろうと思っていた、)マイクアンプを換えたりマイクアンプ内蔵のUSBオーディオインターフェースにしても、音量が上がらない可能性はありそうだ。それでも性懲りもなくｗ、マイクアンプ内蔵のUSBオーディオインターフェースを試したい気はしている。

PS. 先日そそくさと片付けてしまった作業机があった方が、こういう時には便利なことに気付いた。が、こういう作業は余り頻繁にしないので、どうするか迷っている。

PS2. 作業した日(昨日)は、昼頃に思い付いて、空腹にも関わらずやりたくなって すぐに始めてしまったものだから、昼食を食べ損ねたｗ

PS3. サウンドカードのMIC Boostは、雑音が多過ぎて本当に使えない。まあ、限られた部品でやっているから(もしかしたら、ソフトでやっている?)仕方ないのだろう。

PS4. 最初は、RTAのマイクアンプの出力をDEQ2496のアナログ(MAIN)入力に入れて、MAIN出力をPCに入れることも考えていたが、疲れたのと、仮に音量が上がったとしても雑音の点で意味がないので止めた。

(11:41 加筆修正)

メイン机(「仕事用がメインじゃないのか」というツッコミもありそうだがｗ)の左に並べた作業机だが、その後、メインの椅子にちょっとした問題(欠点)が見つかり、作業机と共用したくなった。「は?」な書き方だが、以下のような経過である。

1. 今までは、(ちょっとした事情で)メインの椅子にテンピュールのクッションを重ねていた。
2. 作業机用の椅子(無印)を使うので、そこにテンピュールを移した。
3. メインの椅子の座面と尻との相性が今ひとつなのか、座っていると尻が痛くなることに気付いた。
4. やっぱり、メインの椅子にテンピュールを重ねたくなった(「腐ってもテンピュール」ｗ)。
5. 無印の椅子にクッションがなくなったので、作業机用の椅子にはメインの椅子を共用したい。

椅子を共用するには、(椅子をゴロゴロと横に移動するのは面倒なので、)メイン机と直角に作業机を置く必要があるが、前回書いたように、左だと眩しいとか収まりが悪いとかでイマイチなので、右に置いてみた。右なら眩しくはないだろうし、奥にPCや棚が来るので収まりもいい。更に、作業用椅子用の床面保護用のラグも不要だ。欠点は、棚やPCへのアクセスがちょっと面倒になることとメイン机の右側が混雑することくらいだ。棚やPCは、使いやすいところに移動してもいいだろう(そうすると、収まりは悪くなるが)。

気になるオーディオの再生特性は、なぜか(作業机がスピーカーの直前でないから?)、左に並べた時と違ってほとんど変化がなかった。右と左右が143Hzで1dB上がった程度である。だから、イコライザも作業机なし時のままで良い。実際に曲を聴いても特に問題はなかった(若干低音が強い気がするが、作業机をどかしても同じように聞こえたので、きっと、音量がちょっと大きいとか「気のせい」だろう)。

なぜかは分からないが、いろいろ「ウマー」な結果になったｗ

↓

その後、なおきさんからお教え頂いたのだが、作業机にノートPCやディスプレイを置いた場合(手持ちの予備で試した)、窓からの光が画面に反射して、若干まぶしいことが分かった。耐えられないほどではないのだが、やっぱり嫌だ。いろいろ考えたのだが、結局、作業机をメイン机の右隣に並べて置くことにした。それに伴い、棚をメイン机の左側に移動した。また、PCの置き方に迷ったのだが(メイン机の下に置くと足がぶつかる)、机の間を開けて置くことにした。

なお、オーディオ特性は、なぜか・やっぱり、机なしの場合や右に直角に置いた場合と変化がなく、問題なかった。しばらく様子を見て問題なければ、ラグを追加する(椅子を共用する場合)か無印椅子用のクッション(テンピュール?)を買うことにする。背もたれ用テンピュールを座面に敷く手もありそうだが、どうなんだろう?ｗ (8/29 16:13)

PS. 143Hzの山は、扇風機とかエアコンのファンの音が机で増幅されているのかも知れない。50Hzの3倍が143Hzとして出ているのだろうか? ただ、テスト信号の音量は結構大きいのに、それに勝つほどファンの音が大きくなっているとは思えない。が、いずれにしても、測定機材を仕舞ってしまって測るのが面倒なので、確認はあと回しにするｗ (8/29 10:12)

随分久し振りに掃除をした。大掃除の先取りと言えようｗ ずっと埃が溜まっていて嫌だったのだが、延々と延ばして来た。でも、来月から家で仕事をすることになり、そのための実機・機材が来るはずなので、その作業用の机を用意したくなったのだ。

今の机でもいいが、傷付いたり(場合によっては、半田で焦げたり)するのが嫌なので、今の机に換えた時にリタイアして電子レンジの台になっていた(→ 参考)、無印良品の古い机を使ってみることにした。

まず、その机を置きたい場所は まさに埃の吹き溜まりになっていたので、掃除をした。気合いを入れて、足掛け二日(約3.5時間)で風呂場を除く全部屋を綺麗にした。綺麗になってすごく気持ちいいが、すごく疲れた。汗びっしょりになったし、買い物に行く時、脚がへろへろだったｗ

古い机は今の机の横に置こうと思った。置き方として、最初は今の机と直角に置こうと思っていた。というのは、身体を90°回転させることで椅子を共用できるからだ。しかし、置いてみると、ちょっとかっこいいものの、何とも収まり(場所の効率)が悪い。しかも、正面にある窓からの光が眩しい。それで、普通に今の机の隣に並べることにした。さすがに収まりは良く、しかも、偶然、天板の高さが同じでいい感じだ。

これで作業場はできた。のだが、大切なことが残っている。オーディオ(スピーカー)の再生特性を確認し、調整することだ。こんな大きな板(作業机の天板)が増えたら、天板での反射できっと変わるだろう思った。実際に測ったら変わっていて、左だけ143Hz辺りが5dBくらい強くなっていた(図の中央のグラフの青線の左側の山。作業机なしは緑線)。調べると、143Hzは天井・床面間を波長とする周波数のようだが、なぜか机によって強調されたようだ。まあ、オーディオには謎が多いので、とりあえずイコライザを追加してそこを下げてみた(補正結果は図の上・中央のグラフの赤線。作業机なしはどちらも緑線)。なお、位相差の関係なのか、左右合わせて測ると作業机の影響が少なくなったので、143Hzを下げる量を2.5dBに減らした。また、バンド幅はイコライザの最小の0.125(単位はオクターブだと思う)にした。特性のグラフを見る限り、うまく補正できている。

実際に曲を聴いて確認しても、特に音質の劣化・変化は認識できなかった。ただ、不思議なことに、補正のために追加したイコライザを切っても違いが分からない。山が急だから、影響が少ない(瞬間的にしか効かない)のかも知れない。

それから、細かいことだが、古い机の手前の床を椅子のローラーから保護するラグ(チェアマット)を買う必要がある。ところが、Amazonなどを調べても、今使っているもの(住江織物製)のような丁度いいものが少なかった。そこで、とりあえず、やっぱりリタイアしていた古い無印の椅子を使うことにした。これはローラーでなく固定脚で、脚の下にフェルトが貼ってあるので、床を傷付ける心配はないだろう。それから、その椅子用に買った(かなり古い)テンピュールも載せた。これで完成だ。

ただ、仕事をする時間は長いはずなのに、(今のに比べて)座り心地の良くない椅子を使うのは、ある意味主客転倒で、本当はちゃんとした椅子ですべきだ。しばらく試して疲れや効率低下を感じたら、ラグを買おうと思う。

さて、どんな実機が来て四苦八苦する羽目になるのかねぇ・・・ (初日に会社に行ってみたら、「しばらく実機はないです」とか言われる気がしないでもないｗ) それから、そのうち機材が増えたら、作業机の前にリタイアさせた本棚を置いて、そこに収納することも考えている(機材は随時返すので、起こらなそうではある)。そうなると、ちょっとした研究室や実験室って感じになりそうだ。

(予想に反して、カテゴリ「新しい仕事」が続いた。家で仕事をするから、今後も続くのかも知れない。さすがに、実機などの写真は載せられないが。)

PS. やっぱり無印はいい。丈夫で長持ちするし、シンプルなので部屋に馴染む。机なんて、水拭きしたら木の香りがした。近頃は高くなってしまったようなのが、残念だ。それにしても、当時(20年前後前)は机・本棚からベッドまで買い込んでいて、随分バブリーだったなあ・・・ｗ

数日前の朝、突然、候補の会社の下見に行くことにした。少し前までは県内の会社Aに行こうと思っていたのだが、そこには既に行っていた(ただし、行き先を間違えた)ので、「(まだ応募してないが、)面接の時でいいや」と思って、行き先を埼玉の会社Bに変えた。(いや、ボケてません。確かにスピーカーの投稿です。少し待って下さいｗ)

外は灼熱だったにも関わらず、その会社には意外なほど楽に着いた。A社の2倍弱の距離だが、同じくらいの時間(約2時間)で着き、疲れは半分くらいに感じた。おそらく、主な道が太いバイパスだったのと、体調が良かったからだろう。

ここで不思議なことが起こった。到着して近くの駐車場に停めたら、ほぼ同時(少し前か後に)にB社の社長からの面接の打診(数日前に質問を出したら、履歴書などを送るように言われて、以前別の会社用に書いたけど出さなかったものを手直しして送ったので、成り行き上「応募」となりｗ、書類審査はすんなりパスしたようだ。予想外の展開ではあったが、仕事がおもしろそうで とても興味ある会社なので問題ない)のメールが届いたのだ。ここでおもむろに顔を出したらおもしろそうだし、「伝説」になりそうではあったがｗ、いろいろ準備をしていないので止めた。

B社の入っている建物はちゃんとしていた。多くの会社ではまだ夏休みの期間だったが、中に社員が居たようなので、夏休みは長くないようだ。社長からメールが来たということは、その日が休み明けだったのかも知れない。

不思議だったのは、その街が妙にしっくり来て、すぐに馴染めた気分になったことだ。まあ、目新しいものは良く見えがちだからだろうが、最初から「これは無理」ってこともあるので、悪くない感じだ(ちなみに、間違って行ったA社の辺りは実家辺りに勝るとも劣らないｗ ド田舎で、「ちょっと遠慮したい」だった。それを払拭・軽減できるかと思い、正しい場所に行こうと思っていた)。良くある地方の街だが、うまい加減に鄙びていて ゆるい・雑然とした感じなのが僕には丁度良さそうだった。ただ、(街では良くあることだが、)ちょっと不審そう(凶悪ではないｗ)な人が結構居たので、治安は若干悪そうな気がした(ここに比べればの話)。

てな訳で、行ってみたら悪くなさそうな感じだった。あとは、来週の面接の時に、社長や社内の雰囲気を良く確認したい。今までで一番社員数の少ない、とても小さい会社※のせいか、いろいろと謎・不審な点があるので、そこが心配なのだ。

※今考えると、会社を代わるたびに規模(社員数)が対数(「10などの負のべき乗」というのが正しい?)で減っているのが、おもしろい。

食事をしたら帰る予定だったのだが、ふと、なおきさんが近そうなので、都合が良ければ遊びに行きたくなった。それで、食事に行く前にメールしたら大丈夫とのことだったので、すごい暑さではあったが、僕の調子も良かったので行くことにした。昼食は蕎麦にした。いつも行っている地元の店とは随分雰囲気が違っていて、店内が若干暗くて静かで広々としているから、落ち着けて良かった。珍しく店内にTVがなくて静かなのには、好感が持てた。蕎麦は冷たくておいしかった。値段もいつもの店よりずっと高い訳でもなく、結構気に入った。 (いや、スピーカーは忘れてません。もう少し・・・ 略)

なおきさんのお宅は近いと思っていたのだが、渋滞があったせいか、やっぱり2時間くらい掛かった。混んでいたので結構疲れた。

話ははずみ、彼のスピーカー2種類(TIMEDOMAIN miniとBose SoundLink Mini Bluetooth speaker II)の音を聴き比べたりした。そして、Boseの低音に感心した。あんなに小さい(手のひらより少し大きい程度)のに、普通のスピーカー以上のすごい低音だった。それでいて、DQN車のような下品な「ズンズン」や「ドコドコ」ではないので、(予想外の強烈な低音に慣れれば、)なかなかいい感じだった。あのサイズで、どうやってあんな低音を出せるのか不思議だった。それから、曲によっては低音が出過ぎて不自然になることがあるのが気になった。それで、最終的にはスピーカーを貸して頂いて、僕の家で調べてみることになった。

(書き疲れたので、続編に: 散々期待させて済みませんｗ)

(お待たせしました、続編・完結編です。: 8/18 18:08)

家で聴いてみたら、やはり、低音が強過ぎる感じだった。自分のスピーカー(KEF Q300)と比べると良く分かった。設置の仕方を変えてみたが、余り変わらなかった。それで、何はともあれ、現状を知るために特性を測ってみることにした(なおきさんは測らなくてもいいと言っていたが、僕としては測りたかったｗ)。

(9/15 14:20 訂正・更新) 測定プログラム(REW)の設定誤りのため、本稿記述時の測定では150Hz以下がカットされていました(カットの度合いについては、中央図の青緑(今回)と青(前回: 誤り)をご参照下さい)。特に最初のグラフの超低域は正しくないです。そのため、再測定して記述を訂正しました。なお、訂正前の記述を"[2019/9/15訂正前]"として横線で囲って残しました。

すると、特性はフラットと言って良く、それほど不自然ではなかった(逆に、あの小ささでこれほどフラットになるのが不自然な感じはする)。近接では低域が5dB程度、高域が8dB程度上がっており、30cmくらい離れると、低域が8dB程度、高域が10dB程度上がっていた(いずれも中域を基準とした)。離れた場合に低域が強くなるのは、このスピーカーの構造(パッシブラジエーターなど)によると思われるが、高域については不明だ。近接でのマイクの位置が悪かったのかも知れない。(→ 中央図: 青緑: 近接, 紫: 30cm)

それで、実際の曲("Come together")の特性を測ってみると、意外なことに、低域に関しては、聴感とは異なってKEFと余り変わらなかった。強いて挙げれば、73Hz辺りが4dBくらい大きくなっていた(上の右図: 赤線の一番左の山)のと、KEFにはない133Hzの強い山(右図: 赤線の左から2番目の山)があるのが気になる。このような山が、不自然に低音が強く聞こえることに関係しているのかも知れない。(→ 右図: 赤: Bose, 緑: KEF)

[2019/9/15訂正前]

すると、不思議なことに、大きな問題はなく、低域が強調されている訳ではなかった。近接測定では、せいぜい、中域が少し下がり高域が少し上がっている(どちらも3dB程度)程度だったし、30cmくらい離れると高域が上がっているだけだった。(中央図: 青: 近接, 赤: 30cm)

それで、実際の曲("Come together")の特性を測ってみると、やはり、低音が強かった。この曲では73Hz辺りがKEFに比べて8dBくらい大きくなっていた(上の右図: 赤線の左側の山)。

なんとも不思議だった。それで、原因として、Boseが以下のようなことをしているのではないかと推測した。

• 低音が持続した場合に強調する。
• 音楽(楽器)の場合だけ、低域を強調する(→ テスト信号のような単音は強調されない)。

試そうとして、僕は楽器を何も持っていないのでどうしたものかと思ったのだが、ふと気付いて、シンセサイザーアプリ※(ZynAddSubFX)をインストールして、低音が出る楽器の音で試したところ、持続は関係なく、楽器の場合だけ低域が強調される(65-85Hz辺りが6dB前後上がる)ようだった。楽器かどうかの判定は、倍音成分の有無によるようだ(音が単成分の楽器では強調されなかったため)。ZynAddSubFXにはいろいろな楽器があるが、"Organ 3"が分かりやすかった。70Hz付近で5-8dB強くなっていた(左図: 赤線の左側の山)。

※最初はLMMSというアプリを試したが、機能が豊富過ぎて使えなかった。次にYoshimiというのを使ったが、今ひとつだった。

注: 上のグラフは、ZynAddSubFXの仮想鍵盤で、楽器の音を下から上まで順に出した時のピーク値である(そのため山が多くなっている)。なお、楽器のオクターブ設定は1(最低)にした。

それで、このやり過ぎな感じの低域強調を緩和しようと、イコライザを入れてみた。約70Hzを中心に6dB程度下げてみたところ、KEFと同様の特性になった(上の中央図: 朱(Bose+イコライザ)と水色(KEF)の線)。

実際に"Come together"を再生して比較したら、違和感は減って「許せる」程度になった。ただし、今度は高域がちょっと強いのが目立った(上記のとおり、高域が強目のため)。そこで、約5.5kHzを中心に約4dB落としたら、「まあ自然」になった。ただ、自分の(普通の)スピーカーに比べると、どうしても、広がりとかゆとりとか深みに欠け(これは、ひずみの多さから来るのではないかと推測している)、なんとなく「無理してる感」があるのだが、本体が小さいので仕方ないと思う。両方置いておいてちょっと聞くだけなら、どちらが鳴っているか分からないと思う(実際、出力先を確認しないと分からないことが結構あった)。何度も書くが、低音がすごくて感心した。

PS. 個人的には、この、謎の低域強調がなくても充分低音が出ているのだから、一種のバグのような気がするが、どうなのだろう? また、別の機種だが、リセットしたら直った(本当かどうかは不明)という情報があったので試したが、効果はなかった。

(8/18 18:19 題を変更, 18:55 TIMEDOMAINスピーカーの名前を確定, 19:40 わずかに補足)

どういうきっかけで思い立ったのか忘れてしまったが※、電力会社を移って電気料金を減らそうと思った。

※発端は以下のどちらかだった気がする。ただ、いずれにしても最初の「何か」は不明だ。

• • 何かで検索? → みんなの評判ランキング → 電力会社?
  • 何かの記事? → その中の単語を検索 → みんなの評判ランキング? → 電力会社?

以前にも、ちょっと検討して余り安くならないので止めた覚えがあるが、今は収入がないので、少しでも減らしてみたい(半分趣味だｗ)。あと、東電は未だに原発を推進しているので、そこから脱却する(意思を示す)のは意味があると思う。会社を変えても、(自分の使用する電力のうちで)原発の割合が0になる訳ではないのだろうが、何もしないよりはいいだろう。

検索や比較サイトで調べて、いろいろな会社から選んだ。以下に検討した候補を示す。

ENEOSでんき, 出光シェル, グリーナでんき, HIS, HTB, SymEnergy, ジャストエネルギー, (今のガス会社), ミツウロコ, サーラ, エルピオ, あしたでんき, ファミリーエナジー, 自然電力のでんき, ジニー, ぴたでん

比較の際、各サイト・各社のシミュレーションや削減額計算の際には、いろいろな落とし穴があった。

• 電力会社の数がやたらに多くて、全部は比較し切れない。
• 比較サイトにはすべての会社が載っている訳ではない。なぜか落とされている会社がある(利益の関係なのだろうか)ので、いろいろなサイトを見る必要がある。
• 比較サイトは、そのサイト経由でのキャンペーンやキャッシュバックで削減額を多く見せることが多い。ひどい場合は、全然安くならないのにキャッシュバックですごく安く見せている場合がある。
  • しかも、キャッシュバックなしの額は示されていないことがほとんどなので、自分で計算しなければならない。
• シミュレーションが貧弱な・ない会社がある。
  • 単月の使用量でしか計算(推算)できない会社があったし、シミュレーション自体できないところがあった。後者は論外な態度なので却下し、前者はスプレッドシートで自分で計算した。
  • 各サイト・社のシミュレーションごとに1年分の使用量を打ち込むのは、面倒だった・・・
• 後述するように削減額の差が小さいので、可能な限り正確にシミュレートする必要があったが、複雑な料金体系にイライラした。
  • 多段階の単価、再エネ賦課金、燃料調整費(毎月変動する?)があって、単純には計算・比較できない。
  • 正確に比較するには、賦課金、燃料調整費を除いた、「真の電気料金」を使う必要がある。
  • 東電の真の電気料金は過去の伝票を見て求めるしかないが、面倒なので、「でんき家計簿」に記載された毎月の使用量から、他社のシミュレーションと同様にスプレッドシートで計算した(ある社のシミュレーション結果に記載された値と比べて検算した)。
• 東電の「でんき家計簿」で毎月の使用量・支払い額などが分かるのだが、請求月ごとに記載されているので、使用量は(当月でなく)概ね前月の分になっていて紛らわしい。請求額は正しいが、使用量としては正しくないだろう(まあ、月ごとに電気代の単価が変わる訳ではないから、月がずれていてもシミュレーション結果は正しいのだろう)。
• 消費税の扱いにも注意が要る(おそらく、ほとんどは税込みと思われる)。

各社のシミュレーションに、過去1年分(2018/8-2019/7月分)の使用量を入れて計算した。現状は、年間使用量が約3200kWh、支払額は約9.2万円だった。

いろいろな社を比べたが、結局、5千円/年(約5%)すら減らなかった。最大の会社で4800円程度だった。一人暮らしで使用量が少ないせいだろう。削減額(キャンペーンなど抜き)が4500円以上の社は以下の順になった。

1. ENEOSでんき(V+2年)
2. ジニー(あお)
3. SymEnergy
4. (今のガス会社の電気・ガスセット割引)
5. エルピオ
6. サーラ

1位と6位の差は約130円と全く些細なものなので、どこでも良さそうだが、その中から最も失敗のなさそうな、ENEOSでんきの「Vプラン にねんとくとく割」にした。2年縛りだが、違約金は1000円(税抜き)くらいなので、約3か月でペイするし、引越しても継続すればいいので問題ない。ここはキャンペーンがいいこともポイントだった。経由するサイトによっていくつかの種類があったのだが、一番高価な5500円のキャッシュバック(価格com)を選び、申し込んだ。

ENEOSなんて大きくて古そうだから、どうせ事務が遅いんだろうとたかをくくっていたら、意外に速くて、申し込んでから2日後のさっき、使用開始予定日の連絡が来た。来月頭に切り替えられるそうだ。

という訳で、今のところは、電話連絡や立ち会い(と、そのすっぽかし)など一切なく、全くストレスなく切り替えができそうだ。

それにしても、たった5千円未満のために「どんだけ」の手間を掛けたかと思うと、苦笑しかないｗ まあ、キャッシュバック分を加えれば余裕でペイしそうだし、数年経てば削減額も増えるから更にいいだろう。あと、お金持ちは常に節約を心がけている※というから、間違ってはいないのだろう。

※でも、それは十分条件であって、常に節約を心がけているだけでお金持ちになれることは全くない。みんな、そこに気付いてないｗ

PS. 再エネ賦課金について: シミュレーションの時、なかなか高くて馬鹿にならないのに気付いた。自然エネルギー由来の電力を使う会社は、今はまだいいが、そのうち賦課金が減って料金が高くなりそうなので、注意が要ると思った。

PS2. お金と同様、電気に色はない。ただ、お金と違って、多少「色」はありそうだ。というのは、会社ごとに発電施設が違い、それらの安定度や精度が(もちろん、基準以内で)違うだろうから、電圧の変動や周波数の安定度や雑音の量に微妙な違いが出るだろう。ただ、家に来た時点で、いろいろな会社の電気が混ざっているので(想像)、どんな会社のどんな発電所からの電気が配合されているのかは全く分からない。音に関係するのは、会社でなく、変電施設やトランスからの距離、周囲にある施設(工場など)辺りだろうか。

だから、例のコピペなどのような、電力会社を変えるとオーディオの音が変わるなんてことはないが、住むところによって音が変わる可能性はある。ただ、僕に言わせれば、電源の影響を受けて音が変わるオーディオなんて、碌なものではない(と思うが、違うのかねぇ・・・ｗ)。

(前にも書いた気もするが、広告を見て気付いたから暇つぶしに)

デジタル音楽プレーヤーやDACユニットで、DACチップの複数の出力チャネルをまとめることで音質向上をうたう製品が多いが(↓例)、

L/Rにそれぞれ1基ずつを割り当て、8chをフルに使ったD/A変換により正確なサウンドを出力できる。

本当にそうかな?

そもそも、上の例文の「正確なサウンド」って何だ? DACの出力の正確性は、DACチップの精度とLPFと出力部の性能で決まるはずだ。この場合、DACチップの出力をまとめているので、LPF以降は関係なく、DACチップの出力の精度を向上させると言っているのだろう。

だけど、DACチップの出力の精度を向上させるとしたら、高精度なチップを使うのが適切だし、そもそも、今のチップなら大抵のものは家庭用には充分過ぎる精度だろう。重要なのはLPF以降のアナログ回路だ。正確なサウンドを出力したいなら、高精度なDACの出力をそのまま外に出すことに注力すべきで、チップの出力をまとめてどうこうするのは苦肉の策みたいなもので、売りにするのはナンセンスだと思う。

上の例だと8本もの出力を1つにまとめている(= 加算している)ようだ※。確かに、複数の信号を加算(平均)すれば雑音は減るが、DACチップの出力チャネル間の時間差は無視していいのだろうか。こういうのにこだわる人は、nsとかpsオーダーでクロック精度を追求していると思うが、果たしてDACチップの各出力はそこまで合っているだろうか? 厳密に合っていなければ、折角のクロック精度(に意味があるかは知らないがｗ)が台無しになるし、微妙な時間差のために波形が鈍るだろうから、例えば、高域が劣化したり位相特性が悪化したりするだろう。オーディオ的表現では、音の「鮮度」や「立ち上がりの鋭さ」が減るはずだ＊。

※そもそも、複数チャネルをまとめる理由は何だろうか。変換誤差を減らすため? とは言っても、もともと、オーディオ用DACは例え32ビット品でも20ビット前後(高々24ビット)程度の精度しかない(しかも、出力段ではもっと雑音が増える)から、いくらまとめたって有意に変換誤差は減らないだろう。

2つのチャネルを合わせた時にどの程度雑音が減るかは忘れたが、仮に、雑音が1/2になって精度が1ビット相当増えると仮定したら、8本合わせても3ビットしか向上しない。24ビットを32ビット相当にするには全く足りない。

そもそも、音源(曲)がそこまで低雑音だとも思えないし、20ビットの最下位ですら、一般家庭では(普通の音量で)再生しても聞こえないだろう。意図が分からない。

＊実際には、DACとLPF・出力アンプの間にはホールド回路があるはずなので(LPFで兼ねているのかも知れないし、(DACの特性を信じて)ないかも知れないが、詳しくは分からない)、チャネル間の時間差は吸収される可能性があるから、最初に問題にした時間差による音質の劣化はなくなる。この場合、複数出力を合わせる意味は、もともと精度がおかしいチャネルを多数決で隠すことと雑音の低減になる。前者は検査で落とすべきものだから、結局は雑音だけだろう。その場合でも下記の逆流の問題はあるだろう。

それから、仮に出力チャネル間の時間差が全くないとしても、各出力チャネルの電圧(または電流)に微妙な差があるだろうから、その影響が出そうだ。例えば、高いチャネルから低い方に電流が逆流して歪が増えるかも知れない(ここは良く分からない)。

整理すると、複数チャネルをまとめた時のメリット・デメリット(いずれも量は無視している)は、以下のように推測できる。

• メリット
  • 雑音がわずかに減る可能性がある。
  • (精度が悪いチャネルの影響を多数決で減らせる。)
• デメリット
  • チャネル間に電位差が生じ、歪みが生じる可能性がある。
  • DACとLPF・出力アンプの間にホールド回路がない時、チャネル間に時間ズレが生じ、
    • 高精度なクロックを使っている場合は無駄になる。
    • 周波数・位相特性が悪化する可能性がある。

まあ、いずれにしても、聴感上は何も変わらない気はする。単に無駄なだけだろうから、どうでもいいｗ いや、もしかしたら、上記の時間差のために音がわずかに良く聴こえるかも知れない(例: オーケストラの多数のバイオリンの音が厚くなること)。だから、「音の厚み・深みが増した」とかいうレビューが出るかも知れない。でも、それは自分が高いお金を掛けて求めていた方向とは真逆で、言ってみれば棚ボタ的な結果のはずだ。

4/16の日記より(少し改変)

久しぶりに"Let it be"(2009リマスター)。当たり前だが、中学の頃聴いたレコードよりずっと音がいい。細かい音まではっきり聞こえて、いつも感動する(ありがたく思う)。ところが、今は、音が悪いうえに手間も掛かるレコードを好き好んで買う人が居るのが不思議だ。。。

レコードの音や雑音がいいのなら、レコードじゃなくたって、(あるかどうかは知らないが)レコードの音にするエフェクタ・シミュレータでいいではないか。レコードを掛けるために手間を掛けるのがいいのか。レコードはコーヒーじゃないので、手間暇掛けて掛けること自体に意味はない。たとえ高速回転の高音質盤を買い込み、クリーンルームで再生して、最高の結果が出せたとしても、マスターの音には全然敵わない。そもそも、今はカッティングに使っているマスターがデジタルなのに、それをまたアナログに変換して(、ピチパチ雑音と一緒に)聴きたいっていう気持ちが理解できない。段階が増えれば、それだけ音質は劣化する(レコードの場合、物理的に転写する工程があるから、かなり劣化すると思う。CDも転写するが、エラー訂正があるから、レコードの比ではない)のだが、それがいいのか?

仮に、「レコードは掛け方・機材で音が変わるのがいい」とか言うのなら、それは全くおかしい。そんなのだったら本当にエフェクタで充分だ。その方がずっと自分の出したい音が出せる。コーヒーの淹れ方で香りや味が変わるのは本質的だが、掛け方や機材でレコードの音を変えるのは全然違う。

あと、面を裏返すのや盤を入れ替えるのは鑑賞の妨げにはならないのだろうか。音楽を楽しむのなら、音質(仮にいいとして)だけじゃなくて、演奏に集中できることはかなり重要だ。例えば、本来は短時間で繋がるべき(あるいは曲間なしで連続する)楽章や曲の間が何分も中断してもいいのだろうか? 謎だ。余程の物好きだ。インスタ映えみたいに、レコードを掛ける自分の姿に酔いたいのだろうか。もしかして、「掛ける体験がいい」とか言うのかｗ そんなに体験がいいんだったら、楽器を買って自分で演奏しようとした方がずっといいよ。

せいぜい、大きなジャケットが欲しいからレコードを買うのはありだろうが、ジャケットだけでも手に入れられるだろうし(それ以前に、今はいくらでも画像が出回ってそうだ)、曲はCDや(ハイレゾ)配信で聴けばずっと楽ではないか。

いずれにしても、そういう人たちは音楽を楽しむことが主目的ではないようなので、僕は全然共感できない。そして、ブームに乗って安直に手を替え品を替え(45回転盤、重量盤、カラー盤、復刻日本盤・帯ｗ, etc.)レコードを出すレーベルは全く情けない限りだ。

PS. レコードの音にするエフェクタ(またはシミュレータ)はあった(WebLP)。カセットのも見付かった(WebCassette)。どちらもブラウザ(Chrome)で動くし、カセットはVSTなどのプラグインになっているから、本当の再生にも使える。ただ、僕からすれば、レコードは音質が良過ぎる(雑音が少ない。ただ、歪は多過ぎる)し、カセットは悪過ぎる(いろいろなつまみを高品質側に回して、CHROMEかMETALポジションでないとちょっと・・・: デジタルに慣れ過ぎているせいかも知れない)感じでまだおもちゃ的で実用には物足りないが、もっといいものはできるだろう。

あと、WIN32用なら、Vinylizerというレコードシミュレータがあった。これはVSTプラグインなので、本格的に使えるだろう。

更に、Calf Studio Gearにもレコード(Vinyl)とカセット(Tape Simulator)のシミュレータがあった。だから、Linux(JACK)でもできる。こちらはいろいろ調整できるが、やっぱりどこか不自然で納得行かない。もっとちゃんとシミュレートしないと実用には耐えないと思う。JACKにはVyNil (Vinyl Effect)というのもあり、Calfよりはマシだがやっぱり物足りない(というか、僕はもう、そういう音を受け付けない身体なのかも知れない)。

そういう意味では、手軽に自然なレコードやテープの音を出すには(それに意味があるとして)、本物のレコードやテープを使う価値があるのだろうｗ

そして、(仮にまともなシミュレータがあったとしても、)もちろん僕は、「使ってみますか?」→「まさかー」だｗ

PS2. さっき噴飯物を見つけた。妙にレコードに力を入れている店、HMVの「ブラックヴァイナル・アナログレコード」って、普通のレコードじゃん!! なに気取ってんだよｗ しかも、見出しは字が抜けてるし。こういうのを中学生くらいの子が見ると、なんか特別な物のように思ってつい注文するのだが、届いた実物を見てがっかりするのだ(僕の経験よりｗ)。 (4/19 17:41)

「ブラックヴァイナル・アナログレコード」か・・・ｗ

(「志向・趣味の違いか。 (その2)」(投稿予定)の前半にする予定だったが、繋がり・まとまりが悪いので単独で投稿)

先日書いたように、JACKのパッチベイアプリ、Catiaの動きがどうも怪しい(勝手にPulseAudioを直結する)ので、代わりにPatchageを動くようにした。

Patchageの問題は、起動するとすぐに下記のエラーで強制終了してしまうことだ。

BDB2034 unable to allocate memory for mutex; resize mutex region
cannot open DB environment: Cannot allocate memory
Segmentation fault

メモリ不足と出ているので、設定で直らないかと思って調べたのだが、関係するものは見つからなかった。それで、このエラーがどこから出るか調べたのだが、実は2箇所に分かれており、最初の2行と最後の行は別の要因で出ているようだ。ただ、最初の問題があるために2番目の問題が出ている可能性もある。

まず、最初の問題(BDB2034)は、JACKのライブラリ(libjack)の関数jack_client_open()で起こっていることが分かったが、原因は分からない。検索すると、このエラーは他のプログラムでも出るのだが、明確な解決策はないようだ。また、他のJACKクライアント(例: jack_lsp)でも出るが、問題なく動作しているので、致命的な問題ではなさそうだ。近頃Linuxのカーネルを更新したので、それに関係しているのかも知れない。それで、ひとまずこの問題には対処しないことにした。

次に、2番目の問題(Segmentation fault)もJACKライブラリの関数jack_get_property()の中で起こっていることが分かった。jack_get_propertyの使い方は正しいようなので、JACKライブラリ自体の問題か、関数の仕様が変わったのかも知れない。あと、記憶ではしばらく動いていたので、何度も試行錯誤するうちにシステム(OS?)の状態がおかしくなっているのかも知れない(そうであれば、再起動すれば直るだろう)。あるいは、上に書いたようにLinuxのカーネルを更新した影響かも知れない。幸い、この関数は1回しか使われておらず、しかも、その処理をスキップしても大きな問題がないので、そうすることにして無事動くようになった。

ただ、前にも書いたように、使い勝手の問題があったので、それも何とかした。一番大きな問題は、ウインドウ内のJACKクライアント(モジュール)の表示位置が保存されない(再起動すると位置がおかしくなる)というものだ。ただ、Patchageのウインドウを見ると、全部のクライアントの位置が保存されない訳ではなく、入力または出力だけのものが駄目(入出力があるものの位置は保存される)なことが分かったので、その部分(Configuration.cpp: Configuration::save())を修正した。

それから色を調整して(プログラムの変更は不要)、最終的には大分いい感じになった。これなら、充分にCatiaの代わりになりそうだ。

思ったより簡単にできて気分がいいが、前にも書いたように、やっぱりJACKは枯れていないことを実感した。あと、この修正を作者に知らせるのはいいと思うのだが、今まで(別のプログラムで)何度も無視されて来たので、躊躇している。

↓

(15:32) 気分が良かったのも束の間で、Patchageを使っていても変な接続が起こってしまった。結局、システム(JACK、PulseAudio、OSのいずれかまたは全部)がおかしくなっていたようなので、再起動したら、すべての問題が起こらなくなった(Catiaでの勝手な接続も、Patchageがエラー(BDB2034やSegmentation fault)で起動しないのも起こらなくなった)。とりあえず直ったのはいいが、原因不明なのでまた起こる気がする。

そして、Patchageのクライアント位置の保存の修正は有用だが、Catiaに問題がなかったので、わざわざ使う理由がなくなってしまった。まったく何とも言えない・・・

補足: プログラマーは、プログラムを修正することや修正のためのモジュールを「パッチ」と言います。単純なバグ修正の場合も多いですが、(何だか良く分からない問題などで)根本を直さずに対症療法的に修正することをそう呼ぶことも多いです。Windowsで山ほどあるもの(KB*)ですｗ

(12/1 15:42訂正) 新しい投稿にも書きましたが、本文の勝手に接続される問題は、Catiaが悪いのはでなく、システム(JACK、PulseAudio、OSのいずれかまたは全部)が異常になっていたためなので、初めに訂正します。

昨夜だったか今朝だったか、JACK(Linuxのオーディオ)のちょっとした問題(余計な信号入力ができてしまう)を修正しようとしていたら、動きがおかしくなった。なぜか、PulseAudio(もう一つのLinuxのオーディオ)の接続が勝手にできてしまって、本来の接続と重複してしまうのだ。接続図を使って説明すると、本来は、信号を

本来の接続

のようにA→B→C→Dと接続しているのに、なぜか、

おかしい接続 (再現図: 赤枠内が余計)

のようにAとDを直結する接続(図の赤枠内)ができていることがあるのだ(この状態で音を出すと確実におかしくなる)。それで、自作のJACK開始プログラムの不備かと思って修正したり、PulseAudioの設定も変えてみたりしたのだが、一向に直らない。ところが、ふと、Catiaというパッチベイ(音の配線をするもの。上図がそう)アプリを起動したり起動していると問題が起こることが多いことに気付いた。それで、試しに別のプログラムにしたら嘘のように問題が起こらなくなった。それでCatiaが悪さをしている(自分で接続状態を保存しているのか、頼んでもいないのに勝手に配線するようだ。日本人でもないのに、余計なお・も・て・な・しはやめろ! むしろ空気読めよ、クソボケｗ)ようなので、使わないことにした。

そういえば、この問題は以前にもあった覚えがあるし、最初に書いたそもそもの問題もCatiaが原因だったようだ。確かに、接続を見るとおかしくなっているのだが、再生していておかしいと感じたことはなかったので、Catiaを起動する時におかしくなっていた可能性が高い。

が、「別のパッチベイプログラム」といってもいいものがない。いくら探してもほとんどなかった。一番まともなのはClaudia(開発元はCatiaと同じ)だが、使い勝手がCatiaに劣る。次はPatchageだが、何度も試行錯誤したせいか、エラーで起動しなくなってしまった。OSを再起動すれば直るのだろうが、問題が起こるたびに再起動したくはないので、使いたくない。そもそも、Patchageは使い勝手も余り良くない(QjackCtlやPatchMatrixの10倍くらいいいが・・・)。

CatiaやClaudiaだの、名前が紛らわしいアプリが何個もあって、しかも、それぞれの機能や操作性が微妙に違うのを見ると、開発元(KXStudio)はなってないと思う。まあ、お世話になっているし、そもそも、中身がどうであろうと使える物を出すことは重要だし、"Studio"とは書いているものの、個人でやっている雰囲気もあるので強くは言えないが、もっとうまくやればいいのにと思う。同じ部分には同じ部品を使えば(当たり前のことなのだが、それができない)、機能や操作性が同じにできるうえに、手間も省けると思うのだが・・・

やっぱりCatiaが使えないものかと思って、プログラムの取得元を変えてみることにした。今まではOSのパッケージ版を使っていたのだが、開発元(KXStudio)の版はパッケージのものとは違う(開発元のものなのに、なぜかバージョンが古い)ので試したら、ちゃんと動いた。気持ちが悪いが、とりあえずは今までどおり使えるようになったので良しとした。が、また忘れた頃に問題が出て、今日のように無駄に苦しみそうだ。

↓

(20:57) 早くもその問題が出た。古いCatiaもClaudiaも、起動すると勝手に接続してしまう(それらを起動せずに別のプログラムで接続一覧を出すとその接続はないので、確かだ)。なかなか困った。。。

↓

(12/1 8:24) その後、Catiaの設定を削除すると問題が起こらないことが分かった。何かの設定が悪いのだろうか。いずれにしても、どうせそのうち駄目になりそうだ。なお、Patchageの設定を削除しても、エラーは直らない。

JACKは僕にはすごくいい(でも、何がいいのだろうか? テクニカルなところか?ｗ)のだが、情報は少ないし、そのせいで最初にまともに使えるようにするのが大変だし、今回のように、たまに変な問題が起こったりするせいか、余り使われていないようで、いいアプリが少ない点が難点だ。それに、システムもアプリも古く、10年くらい前から更新されていないものがザラにある(それでもちゃんと動くところがすごい)。ユーザーが減って、誰も新しいものを作る気がなくなってしまったかのようだ。みんなはどうしているのだろうか? Linuxでまともにオーディオや音楽をやる人は絶滅してしまったのだろうか。演奏のミックスやマスタリングなど、ヘビーに使う人はMac(かWindows)に移り(というか、最初からLinuxに来てもいないｗ)、Linuxの残りの人はPulseAudioで音が出れば事足りているのかも知れない。確かに、配線とかイコライザとか細かくをいじる人でない限り、PulseAudioで充分ではある。

蛇足: 題の「枯れる」は、僕らは、ソフトなどを作ってから時間が経って、(不具合が出尽くして、)落ち着いた状態を差します。そういう意味で、JACKと関連ソフトは随分時間は経っているものの、まだまだ枯れていないようですが、その前に朽ちているのかも知れません。将来が心配です。

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となり、上の変換式はそのままで正しい。最初は最大音量と考えてその式を書いたのに、実際の動作を見ているうちに誤解したのだろう。 (だから、この節は書かなくても全く問題ないのだが、忘れるために書いておくｗ)

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

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

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

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

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

(10/5 10:50)

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

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

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

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

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

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

(10/5 21:28)

[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の正規化後の音量が違うようで、あまり合わない感じだ。

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

それから、MP3デコーダの問題はダウンロード購入したMP3音源の音質劣化を起こすことに気付いて確認したら、確かに若干音がおかしくなっていた。具体的には、ルプーのモーツァルト ピアノ協奏曲 第21番(1975)で弦(バイオリン)の音量が大きい箇所で違和感がある。実際、今年の頭に音が悪いことに気付いて書いている(これはこっちの問題だし、苦情を言ったら確実に泥沼化して疲弊しただろうから、黙ってて良かったｗ)。今聴くと、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の人)・・・

頻度は減ったものの、相変わらず自作のSpotifyミニプレーヤー(minisp)の改良・デバッグもやっているｗ 昨夜辺りだったか、ブラウザなどのフォントをいじっていて、ふと、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」のロゴの傾き」というニュースを目にしたが、僕は全然気付いてなくて、アイコンを見てようやく分かったｗ なかなか妙だし、おもしろい。

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

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

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

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

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レコードと同様に盤の交換が頻繁そうだｗ しかも、事前に何枚ものレコードを読み込ませてから(85分分を読みこませるとしたら、10枚分なので、460分= 7.7時間も掛かる)でないと聴けないのは不便だ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

僕は、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ではやる必要のない作業なのかも知れないｗ

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

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

今はそんなことを全く意識する必要がなく、自由に接続できるので、すごく便利だ。機器にしたって、「ミキサー(あるいはミキサーのチャネル)がない・足りないからから増やそう」と思っても、お金を工面して買いに行くｗ必要などなく、即座に無料で増やせる。もちろん、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 若干修正)

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

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

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

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

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

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

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

↓

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

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

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

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

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

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

暇があると、特にやりたくはないのだが、つい、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フィルタの実現方式の特徴を調べたところ、方式によって演算誤差の影響が異なり、直接型は誤差の影響を受けやすく、余り使われていないとのことだった。

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

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

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

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

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

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

• Calf Jack Hostの8バンドPEQ ("Calf")
• bmc0のdspのDouble-pole peaking filterのeq ("DSP")
• TAP-pluginsの8バンドPEQ, バンド幅指定付き ("TAP")
• Steve Harrisの3バンドPEQ+1バンドPEQ ("TBPWS+SBP")

次に、問題の原因を探るため、以前から疑っていた、混変調歪み(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の値が大きいことなのか小さいことなのか、山が鋭いことなのか分からないが(某有名オーディオ機器メーカーの広告なので、表現がいい加減なのだろうｗ)、いずれにしても、設定によっては音質が劣化するのだろう。そして、僕の設定(多分、低域の幅広く深い減衰)が良くないような気がして来た・・・

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

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

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

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

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

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

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

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

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に出すメリット(音質がいい?)があるのかは全く不明だが、余計なものを通さないので(何かしら)良いと考えて、そうしている(はっきり言って、気分の問題であるｗ)。
• 以前も書いたかも知れないが、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)

苦節3年じゃなく、教師生活25年じゃなく、41歳の春でもなくｗ、1か月に満たない期間ではあったが、謎が解けずに試行錯誤の連続だったJACKのイコライザの調整は、おそらく今日で終わりだ。見事、耳を痛くせずにRushの"Power windows"と"Hold your fire"を完奏できるイコライザ(PEQ)の設定ができたのだ。もちろん、前回書いたように、グライコタイプのイコライザmbeqを使えば問題なかったのだが、どうしても気に入らないので、PEQ(パラメトリックイコライザ)で実現した。

ただ、残念なことに、耳が痛くなった原因は分からず仕舞いだから、どうして解決できたのかも判然としない。今回、mbeqを実測値に基づいて調整しつつ簡素化・最適化した後で、試しにPEQ(前回使って印象が良かった、FIL-pluginsの4バンドPEQ(以下、PEQ4))を同様の特性にしてみたら、信じられないことに、耳が痛くならなかったのだ。

問題が解決できた理由を推測してみると、前にも書いたように、イコライザの使い方(設定)が悪かったのと、イコライザの特性(作り方)が関係しているのではないかと思う。今までは、右チャネルの80Hz付近の山を抑えるために、幅の狭いフィルタをそれ以外の低域の音量を下げるための広いフィルタに重ねていた(→ 参考: 図中のグラフの左の方の"P I"が"P II"に重なっている)のだが、今回はそれを止めて、フィルタが重ならないようにした(帯域の端では重なるだろうが、それは問題ないようだ)。

元々のグライコ(DEQ2496)のPEQはフィルタが重なる使い方をしても大丈夫だが(ただし、PEQの数が多いと駄目だった)、JACK(正確にはLADSPAやLV2)の多くのイコライザは駄目(混変調歪みが生じる?)なようで、そこが特性の違いなのかと思う。DEQ2496はプロ(「演奏者」という方が適切か)用なので、そういう問題が起こりにくい作りになっているのかもしれない。

一言で書けば、今回はPEQをグライコのような使い方にしたのだ。だったらmbeqを使えば良いのだが、フィルタの数(=補正処理の量)を減らして(mbeqでは6個だったのが3個に減らせた)、補正曲線をシンプルで美しくしたかったのだ。その方が音質の劣化が少ない気がする(実際、高調波歪みは少ない)し、趣味としての満足感があるｗ

大変マニアックだが、何をもって「綺麗」かそうでないかという話を書くと、グラフの左チャネル(上)だと、mbeq(紺)は1.2kHz辺りでの水平線との接続部が角ばっていて滑らかでなく、そこから200Hzまでの凸凹が急だし、200Hz辺りでの低域の曲線との繋がりに無理があって、滑らかでない。繋がりについては右チャネル(下)でも同様だ。そういう雑さは、mbeqがグライコだからであり、PEQ4(青)では全く問題ない。ただし、曲線の綺麗さが音質の違いに現れるかというと、まずないだろうと思うｗ が、一つ、急な凸凹は余り良くないとは思う。PEQはそういう点を細かく調整できるのがいい。

なお、耳が痛くなった原因が分からないので、他のイコライザでも同じ設定をすれば同じ結果になるかは分からない(設定は容易だが、試聴するのが面倒だし耳が痛くなるのは嫌なので、少なくとも今は試す気はしない)。

以下に、PEQ4の設定(識別記号="PEQ4-5")や補正後の特性を示す。僕の部屋用なので、設定自体には余り意味がない。特性はmbeq(識別記号="mbeq-2-4")や元のグライコ(DEQ2496)と比較した。

去年DEQ2496を設定してから部屋の特性が変わったようで(本棚をスカスカにしたせい?)、山の位置が変わったり(右: 80 → 144Hz)、新たな山(900Hz付近)ができていたので、それを解消するために設定を調整した。その新たな山が耳が痛くなった原因の可能性もあるが、同じ条件のDEQ2496では問題なかったので、違うだろう。

PEQは4個使った。ただし、2つ(図中のSection 1と2)はそれぞれ片チャネルだけで使っているので、実際には3個である。当初は430Hzのフィルタ(Section 4)は入れずに3(2)個だけだったのだが、そこの山が気になったので追加した。

設定した特性の比較グラフは、イコライザで処理した音を(実際にDAC・スピーカーで出力してマイク・ADCで収集するのでなく、)PC内で直接分析した値(理論値)を比較している。

実測値の比較グラフを見ると分かるように、PEQ4-5ではDEQ2496と同等以上の特性が得られた。mbeqと異なり、PEQ4にはLowShelfフィルタが入っていないので、mbeqで気に入らなかった超低域(50Hz以下)の音量低下が回避できた(が、部屋の特性に起因する深い谷が55Hz付近にあるので、余りメリットがない)。また、サウンドカード(ASUS Essence STX II)のLPFは限界ギリギリ(約22kHz)まで通すため、DEQ2496での超高域(16kHz以上)の音量低下も緩和できている(ただし、僕には聴こえない)。なお、左右同時出力(グラフ: 上)での超高域の低下は、左右のスピーカとマイク間の距離差による干渉が原因である。右(グラフ: 下)の超高域の低下は原因不明で、測定に何らかの問題があったのかも知れない。

それから、今回、スピーカーの音を測定するために新しくマイクスタンドを買った。今までのカメラ用三脚を改造したものが駄目になりかかって(ポールを固定する結束バンドが緩んで来た)、マイクの固定が不安定になったためである。

新しいマイクスタンドを使って特性を測定

キクタニのMS-150Bにした。ヨドバシで約3700円だが、サウンドカードを買った時に貯まったポイントを使って約半額になった(他社では売価がもっと安いものがあったが、これが最安に近くなった)。高いだけあってしっかりしているし、つや消し塗装もちゃんとしていて、いい物だ。ただし、説明書は何もなく、組み立て方法が今ひとつ不明だったし、用途不明の金具があったりした。プロ用だからか?

なお、ブーム型のマイクスタンド(アコースティックギターで使うような物)は安かったのだが、脚(3本の棒)の設置場所を食うし、組み立てと分解(大き過ぎて、分解しないと恐らく収納できない)が面倒なことに気付いたので、ストレート型にした。

PS. こうやって特性が簡単(?)に測定・調整できるのはいいのだが、作業中はマイクの位置を動かしてはいけないので、椅子に座ってPCを操作することができず、マイクスタンドの脇に膝立ちせざるを得ないのが辛い。測定・調整用のサブPCでもあるといいのか? ああ、スマフォで(操作)できるといいな・・・