Archive for the ‘オーディオ’ Category

一旦終わりと思っていた、部屋のオーディオ特性の調整であるが、数日前にクラシック音楽(ルガンスキーのラフマニノフのピアノ協奏曲第2番(2005))を聴いていたら、(「気のせい」にしとけばいいのにw)低音が弱い気がしてしまった。ポップ音楽は問題ないのにである。。。それで、特性を位置の変更前と比べたら、どうも90Hz辺りにある谷(グラフ: 赤枠内の灰色)が原因のような気がした。これは移動前からあったのだが、移動後に120Hz辺りが改善されて目立つようになったのかも知れない。

それで、(止めときゃいいのにw、)思い付きで全体を窓側に数十cm移動(聴く位置を部屋の中央に近付けた)してみたら、90Hz辺りの谷※が解消できて(グラフ: 赤枠内の緑色)、低域が改善された気がするものの、耳閉感が再発してしまった。また底なし沼に足を踏み入れてしまったのである・・・ まさに、音のいい位置を探して移動する「流浪の民」状態だが、果たして見付かるものだろうか?w

※その谷(約10dB, グラフの赤枠)は、聴く位置が低音の消えてしまう位置(「ブラックホール」)に近いせいで生じたように思う。そこに移動した時は、ブラックホールの時よりは谷が浅いから問題ないと思ったのだが、やっぱり良くなかったのだ。

なお、新しい(今の)位置では、90Hzの代わりに75Hz以下が少し弱い(3dB程度, グラフの黄枠)が、移動前の90Hz辺りよりはいいので、(今は?)我慢している。

移動前後の低域の特性の比較 (移動前: 灰: LR, 青: L, 赤: R; 移動後: 緑: LR, 水色: L, ピンク:R) どちらもイコライザで補正後

問題を解消すべく調整しているのだが、(以前と同様、)以下のようなさまざまな要因で耳閉感が起こったり起こらなかったり、音の良し悪しの印象(例: 低音が強く聞こえたり、逆に高音が強く聞こえたり、「なんか音が悪い」感じだったり)が変わって、どうにも難しい・・・

  • オーディオの設定(設置・補正)の具合、従来からの変化
  • 曲(演奏)の音作り、録音の音質、マスタリング
  • ジャンル(ポップ、クラシック)
  • 耳の調子(朝は悪くて耳閉感が起こりやすく、夜は良い)
  • 僕の気分・体調・疲労、曲・演奏・アーティストの好き嫌い

結局、毎日のようにイコライザの調整をしている。今日は、昨夜寝る前にシミュレーションで調整したものが意外にも大丈夫な感じだが、時間を掛けないと本当にそうかは分からない。

もし、今日のイコライザがいいとすれば、特性の違いは本当に微妙なので、以前も問題になったイコライザの作り(構成・設定)によるものだろう(今回のものはシンプルにした)。だが、まだぬか喜びの可能性は高い。

なお、同様なことは音量にもあって、Spotifyの音量正規化をonにしていても、大きく聞こえたり小さく聞こえたりすることがあるので、なんとも厄介だ・・・

音(特に音楽)は、部屋や機器などの影響はもちろん大きいが、身体的な影響、そして、心理的な影響が大きいようだ。

  •   1
  •   0

あるところに「やってる感」の超達人が居て、この先どうなるのか大変楽しみだが、僕は例によって逆張りで「やってない感」で行きたいw そして、大好きなサボり先輩もきっと、やってない感を全開にしているからサボっているように見えるんだと思う。

だから、先日「ようやく出来た?」と投稿したばかりのオーディオ設定にちょっとした不満すら出やしないから、改良なんてことも全然やっていなくて、日々ダラダラ過ごして居るから、全然疲れもしていないwww

 

PS. 偶然、今日サボり先輩が公開されていた。そして、昔の僕もいつも有給を使い果たして困っていたのを思い出し、親近感が高まったw

  •   1
  •   0

引越して約一か月、ようやくオーディオの調整が終わった(正確には、政治家のように、「一定のレベルに達した」辺りか。何が「一定」なんだか、逆に「変動」もあるのか謎だがw)。旧居でも解決できずに諦めた147Hzの共振(山)と耳閉感が起こり、それらの対処に手を焼いていたが、それぞれの原因らしきものが分かって概ね対処できた。

耳閉感について先に書くと、音が悪いために起こるのと、引越し疲れのために耳の調子が悪くて耳閉感や耳鳴りが起こるのが混ざって(あるいは誘発し合って)、何が悪いのかなかなか分からず、そのためにどう調整すればいいのかも分からなかった。結局、今回は、(音に関しては、)超低域(30Hz辺り)が共振して強くなり過ぎるのが良くなかったようで、後述のように50Hz以下をカットしたら大丈夫になった。耳の不調は薬を飲んで休養するしかない。

次に、147Hzの共振(→ 参照: 一番最初に設置した時の特性)の原因は、どうやら、横にした本棚にスピーカーを載せたためのようだ(正確にはスピーカーの高さが悪かった)。この配置ではスピーカーの発音部(中心)の高さが約110cmとなり、天井の高さ(約230cm)の約半分になることが関係していると想像している。その他になぜか机も関係していて、スピーカーを載せた本棚の前に机を置くと最悪になった(旧居でもそうだった)。机については謎だが、その高さ(約70cm)に広い板を置くと共振が増長するのかも知れない。

謎は多いが、とにかく、本棚と机が147Hzの犯人だった。

原因が分かったとはいえ、本棚はいいとしても、机を排除することは難しい。本棚だって、「台に丁度いいと思っていたのに、どうしたらいいんだ!?」だ。

どうするか考えて、昔(2014年まで)スピーカーの台に使っていた木箱があったので、再びそれを台にすることにした※。ただ、そうすると、スピーカーの高さが約64cmと低いので、スピーカーの前や斜め前に机が置けない(置くと机に隠れてしまう)という問題が生じる。昔のように机の横にスピーカーを置くのでは、耳との角度が急過ぎて高域が劣化する。

※箱の中が空だと共振しそうなので、引越し時の梱包で中に入れたCDのリーフレットをそのままにしている。また、立てても中身が出ないように、マジックテープ(買った)を巻いて蓋を固定した。

半分冗談だが、低いスピーカーに合わせて ちゃぶ台でも買って床に座ることも考えたが、さすがに脚腰や膝が疲れるので却下した。まあ、ソファーのような低い椅子ならいいのかも知れないが、そんな物を買うお金も気持ちもないw

それで、あまり気が進まなかったのだが、机を90°回転させて脇に置いて、スピーカーの前を開けることにした。試しに特性を測ってみたら、悪くなかった。床での反射か、多少の凸凹はあるものの、何をしても駄目だった147Hzの山が見事に消え(→ 設置変更後の特性: イコライザなし: 灰: 左右, 青: 左, 赤: 右; イコライザ※で補正後: 緑: 左右, 水色: 左, ピンク: 右)、イコライザなしでも行けそうなほど素直な特性になった。

※イコライザの名前を見ると、少なくとも7回は大きな変更(≒ 設置の変更)をし、それ以外に細かい変更・修正が多数ありそうなことが分かる。実際に数えたら、全部で32個(版)もあった。随分手こずったものだ。

「そんなことなら早く言ってくれよ!」って感じではあるが、僕の事情など誰も知らないw そして、旧居で本棚を使わなかった時も同様の高さだったのに147Hzの山が出なかったのは、偶然だったようだ。出窓にスピーカーを置いていたので、共振する位置の条件からずれていて机が前にあっても大丈夫だったのだろうか。そして、旧居で本棚を使って前に机を置いたら全然駄目だったのは、これだったのだ。

また、この部屋は位置によっては30Hz付近の超低音の共振が強くなるようで、そういう時に耳閉感が起こるようだ。それで、シミュレーションや実測で随分試行錯誤して、超低音と147Hzの共振が強くなく、しかも「ブラックホール」(低音が消えてしまう位置)でない位置を見付けた。制約条件が多くて大変だったが、最後は勘で試した場所が良かったw 結局、部屋の中央付近(ただし中央からは少しずれている)で、ブラックホールの脇(数十cm横)だった。

なお、机の端がスピーカーの前に来て若干障害になるので、5°くらい斜めに置いた。なんか、ここまで来ると、「オーディオ専用ルームかな?」って感じであるw

それから、スピーカーが耳の下にあるためか、曲によっては高域が少し不足する気がしたので、スピーカーの前を少し持ち上げて上下方向を耳に合わせれば改善するかと思ったのだが、実際にはほとんど効かず、それよりも左右方向の向きを合わせた方が効くように感じた。ただ、スピーカーを耳の真正面に向けると余りにもダイレクトで結構キツくなってしまうので、少し外に向けた。

ところが、特性を測ると、不思議なことに向きを合わせても少し外してもほとんど違いがなかった(高域で1dB程度)。実は、高域が少なく聞こえた原因は向きではなかった。イコライザで低域(250Hz辺り)を下げる量が足りなかったのだ。少しくらい(数dB)大き目でも問題ないと思って余り下げなかったのだが、大き目になった帯域が広かったためにパワーが大きくなって、相対的に高域が不足して聞こえたようだ。それにしても、低域が高域の聞こえ方に関係するなんて、思いもよらなかった。

位置とイコライザが決まったあとで試していたところ、概ねいいのだが、まだわずかに耳閉感が起こることがある感じだった。それで、フィルタを追加して超低域(50Hz以下)をカットしてみた。50Hzを切るのはもったいない気がするのだが、実際にはほとんど出ていない(スピーカーからは出ているが、定在波の影響で小さくなってしまうのだろう)ので仕方ない。それでも随分低音が出ているように感じるのは共振のせいかも知れないし、聴覚の特性で100Hzなどの倍音を低く感じているのかも知れない。

これで良ければ、設置を確定してイコライザを微調整する予定だ。

と、ここまでの「素」を書いたのが3/7の朝までで、その時には音や耳閉感は落ち着いてはいたのだが、その後、窓に向かって座ると眩しいことが分かって、全体を窓の正面から少し(数十cm)ずれた位置に移動して再調整した後で充分に確認することにし、今日(3/14)の夜、どうにかこうにか「大丈夫」な感じになった(耳の不調が治っていないので、「確信」とまでは行かない)。

以下に、今までに感じた・気付いた この配置の長所と短所を書く。

長所

  • とりあえず、普通に音がいい。
    • 147Hzなどの共振に起因する「ボワーン」という感じがなくなった。
    • 音がかなりダイレクトになった感じがする。: 今まで(旧居)は、スピーカーと耳の間にあった机やディスプレイが結構影響していたのだろう。
  • 外を眺めながら、気持ち良くPCが使えそうだ。
    • 実際には、晴れた日は眩しい・・・ → 上述のように少し移動した。
    • 更に、が良く来るのに気付いて、余計な仕事が増えてしまったw
  • 部屋を有効に使えている(気がする)。
    • なんか、「空間を贅沢に使ったリスニングルーム」って感じ。
    • 本棚が物置(旧居のクローゼットの代わり)になって便利だ。
      • なお、本棚は最初は窓側に置いていて、その方が見栄えや部屋の使用効率や音への影響の点ではいいのだが、日差しがモロに当たって暑く、箱の中身をいじれないし、熱で置いたものが劣化するかも知れないので、奥に移動した。
        • → と書きつつ、やっぱり見栄えや効率を優先したいので、窓側の隅に移動した。 (3/15 16:18)
  • モバイルルーターとPCの距離が近くなって、USBで繋ぐことができるようになった(→ ルーターのACアダプタとWi-Fiブリッジが減らせる)。 → どうも、USBで通信しながらの給電が不十分なようなので、止めた。
    • 試したら、PCで通信中は頻繁に充電することが分かった。おそらく、PCのUSB経由での充電速度が遅いせいではないか。
    • たまたまかも知れないが、(スピードテストをした時、)通信速度が速いことが多い気がする。 → 速いのかも知れないが、電源の問題があるので諦めた。

短所

  • 時々、わずかに耳閉感があるようなないような、危ない雰囲気が漂う・・・ ← 耳の調子の問題だと思う。朝は調子悪いが、夜は問題なくなるので(調整中は大分これに惑わされた)。
  • 音が下から来るのがちょっと変な感じだった。 → 大分慣れた。
  • 机に向かっている時は音が最適でない。 → 大分慣れた(割り切れるようになった?)。
    • モノラルのようになる。: 仕方ない。でも、次項の高域低下(に聞こえる)を解決したら、それほど悪くない感じだ。
    • 高域が低下するので、低音が強く聞こえる。 ← 上述のようにイコライザの調整不足か、超低域をカットしていなかったためだろう。
  • ケーブル類が剥き出しで美しくない。 → まあ、僕だけなので良しとするw が、もう少し何とかしたい。 → 箱に入れて、少しすっきりさせた。 (3/15 16:18)
  • 電気ストーブが一つしかなく、机の下にあるので、スピーカーに向かうと足が寒い。

 

最後に余談的な話だが、オーディオの設置・調整に欠かせないのはマイクやオーディオインタフェースのようなすごいものだけではない。メジャーやマスキングテープがなかったら無理だ。ところで、そのメジャーはオーディオのために買った訳ではなかったのだが、一体何のために買ったのか全然思い出せないし、いつ買ったのかすら分からないw

 

PS. これで引越し関係で溜まっていたネタがなくなった。めでたしwww

PS2. 車に乗っていて気付いたが、車で音楽を聴く時には耳が痛くなったりしないのに感心した。平行面が少ないせいか意外に反射が少なくて共振しにくいのと、超低域が出ていないか、騒音に混ざって超低域の音量が相対的に低下するためかと想像している。

でも、たまに居る、無駄に重低音を轟かせるDQNの車に乗ったら、きっと耳閉感や耳痛が出まくりだと思う。耳どころか頭まで痛くなるだろう。彼らは強いなwww

  •   1
  •   0

引っ越しで残っていた大きな仕事、オーディオの再生音質の調整(補正)。何度かやったのだが、どうも気に入るようにはならなかった。147Hzに鋭い山があって取り切れないのだ。その周波数は、(旧居でも問題になったのだが、)床と天井の間の共振と思われる。それだけならまだしも、厄介なことに、スピーカーと耳(聴く位置)の間に机があると強まってしまうことが分かった。机なしでうまく行ったと思っても、机を入れると台無しになった。

スピーカーと耳の間に机を置くと常に駄目なのか、「147Hzが駄目な領域」に机や耳があると駄目なのかは、まだ分からない。今は後者と推測して、配置に苦心している(駄目な領域ははっきりとは分かっていないうえに、机が大きいためにうまい配置がなかなかできないのだ)。

それで、配置をどうしたらいいか考えていたのだが、昨夜、なぜか低音の騒音(車のエンジン音とかエアコンの室外機のような音)が聞こえて来て、どうにも嫌な気分になった(騒音が音楽を濁すので、聴くのを止めた)。それで、それがどこから来るのか調べようと室内を歩いていたら、その音がほとんど聞こえなくなる位置があることに気付いた。数箇所あったので、マークした。

それで、そこを聴く位置にすれば、その騒音が聞こえなくなり、更に、「もしかしたら(あわよくば)、147Hzも少しは良くなるかも知れない」なんて都合のいいことを思い付いてしまった。それで今日やってみたのだが、大失敗だった。

事前にスピーカー一個で音(147Hz)と使い勝手が最適な位置を探し、そこにスピーカーや机・PCなど一式を仮設置して試しに聞いてみたら、随分音が変わった気がした。最初は音が良くなったのかと思っていたのだが、特性を良く見たら気付いた。

これ、低音が出てないんじゃ??

84-100Hzが谷になっていたのだ。最初の特性と比較すると、その帯域が10dBくらい低くなっていた。特性を測定したけれど、147Hzの高さに気を取られて、他をちゃんと見ていなかったのだ。馬鹿だね。

新しい位置(緑)では低域が出ていない(赤丸)。

実際、信号発生器で音を出してみたら、80-90Hzがほとんど聞こえなかった。これでは全く使い物にならない。だから音が違って聞こえたのだ。

ということは、昨夜の騒音もこの辺りの周波数だったか、あるいは、ファンの(電源の)50Hzの2倍の100Hz辺りだったか。まあ、車のアイドリングの周波数がどのくらいか分からないから、何かは不明である。

アイドリングの周波数について少し調べたら、計算どおりの値を当たり前のように書いてあるページが多くて面食らった。その計算とは、エンジンの回転数(rpm)と1回転当たりの爆発回数から周波数を求めるのだが、例えば、アイドリング時の回転数が750rpmで、4サイクル、4気筒のエンジンの場合、

(750/60)/2*4= 25Hz (/2は2回転で1回爆発、*4は4気筒の意味)

となる。アイドリングの周波数を書いてあるページはあまりなかったが、数千回転での周波数も上の計算で出すので、すごく低くなっていた。例: 「4サイクル、4気筒のエンジンで6000rpmなら200Hz」

いや、さすがにそれはないでしょうと言いたい。確かに基本周波数はそうだけど、聞こえるのは倍音のもっと高い音ではないか。アイドリングなんてまさにそうだ。25Hzなんてほとんど聞こえないはずだけど(聞こえにくいので、低周波騒音として問題になっている)、僕らは「アイドリング音」をはっきり聞いている。それは倍音(2倍か3倍?)なのだろう。記事を書く時は自分でちゃんと確かめて欲しいと思う(と書いた僕も、まだ確かめてないw)。

つまり、(推測ではあるが、)低音の騒音が消える(聞こえなくなる)位置というのは、スピーカーで出した低音も消える位置だったのだ(定在波の影響なのだろう)。要するに、「ブラックホール」に入ってしまった訳だ。

仕方ないので、明日、最初の配置に戻すか、もう一つの候補の別な配置・位置を試すかする。あと、今の配置で聞く位置をずらせば低音は直るかも知れない。明日の元気次第だ。

こればかりはシミュレーションとかソフトだけでは済まず、実物を動かさないと確かめられないので、なかなかキツい。

疲れた・・・ さすがに(悪い音では気分が悪くなるので、)音楽を聴く気にもならない。

 

PS. 今考えると、最初の配置は「まあ、普通はこうだろう」と決めたのだが、それがこの部屋では(消去法的に)最良の可能性もあって、下手な考え休むに似たりなのかも知れない。

PS2. 昨夜の騒音は結構気になる。たまたま車が長くアイドリングしていたとか、工事か何かで機械を動かしていたのならいいが、そうでなかったら・・・

  •   0
  •   0

トヨタのおっちゃんじゃないけど、場所食って、重くて、電気も食って、ケーブルがスパゲティ状態の、そんな原始的なマシンが大好きでねえwww

てな訳で、ようやく新居でPCが使えるようになりました。もちろん、スマフォは引越しとか関係なく使えたけど、画面は狭い、文字入力も七面倒臭い、音も悪くていいことなしで(これは言い過ぎw)、全然使う気になれなかったです。ちょっとしたことならいいけど、腰を据えて文章を書くとかはできないです。

書きたいことはいろいろあるけど、PCを使えるようになったといえども体力の限界を超えることはできないので、おいおい書きます。ただ、とりあえず一つ書きたいのは、今のところ、「動物園の運動会」には遭ってないので、一安心してます。

 

PS. あー、PC、超重かったしめんどかったwww 梱包も設置もとんでもない手間だった。しかも、オーディオもまともな音なんて出やしなかったので、マイクも引っ張り出して暫定的な(「とりあえず」の、「テキトー」な)補正をして、なんとか、「聞くにたえない音」ではなくなった。こんなに手間が掛かるのは大っ嫌いだけど、僕にはなくてはならないようだ。

あー腰(どころか身体中)痛いw

  •   1
  •   0

僕は断然前者だが、やってみると結構失敗するので、やっぱり良く考えてからやった方がいいのかとも思うし、下手に考えても無駄かも知れないとも思う。あと、やってみれば、(失敗しても)思わぬ発見があることもありそうだ。実は、一見、それらは近くて相反するように見えるが、実際にはそうでもなく、間には広くて深い谷があるように思う。

つまり、「(細かいことを考えずに)とにかくやってみる」のも、「やるまえに良く考える」のも、「下手な考え休むに似たり」も全部正しいのだが、それらは同列にはない(カテゴリが違う?)と思うのだ。

  • とにかくやってみるのは確かに良さそうだけど、少し考えればやる前から結果が分かるとか全く無意味なことは、敢えてやる必要がない。
  • 上が正しいなら、やるまえに(ちょっと)良く考えるのは正しい。でも、考え過ぎて何もやらないのでは、何も生まれない。
  • 何かしようと考えるのはいいが、それが荒唐無稽だったり、考えが足らなくて、やってみたら失敗・無駄だったというのは、下手な考え休むに似たりなのだろう。

そして、こういう複雑な関係を逆手に取って人を誤魔化す(「詭弁」)手合いが実に多い(これについては今回は省略する)。逆に、天才とかは、一見何も考えずに荒唐無稽そうなことをやっても、最後は実にスパっと成功させてしまうのかも知れない。あと、個人的には、普通の人はしないかも知れないが、(前述の詭弁を真に受けるようなものだが、)字義通り実行すると意外にうまく行くこともある。だから、まあ、簡単に割り切れなさそうなことだとは言える。

 

先日買って失敗した、Bluetooth-FMトランスミッター(JF-BTFMEX)を改造する件は、まさにこれだった。スマフォからBluetoothで音を受けてアナログ信号にして、カーナビのライン入力に入れれば、FMでラジオに入れるより安定して音質が良くなりそうだと考え、実際にトランスミッターを分解して試したのだが、どうしてか失敗した。Bluetooth受信部の音声出力端子(と思われるもの)を見付け、確認のため、それに対応するFMトランスミッター部の入力端子に音を入れたのだが、FMラジオから音が出なかったのだ。

JF-BTFMEXを解剖してみたw

原因を考えたのだが、Bluetooth受信部(イヤフォン部)からFMトランスミッター部に送られる音声信号が、アナログでなくデジタルなのではないだろうかと思う。あの程度のものでわざわざそうするとは考えにくいことだが(オシロや信号発生器があれば、すぐ分かるのだが・・・)、今のところ、そういう仮説である。実際、この製品は何を考えているか分からないものなので、そういうこともありそうではないかw

原因はともかく、諦めたあとに気付いた。そもそも、カーナビのライン入力が使えるなら(調べた結果、使えそうだった)、スマフォのイヤフォン出力をそこに直接繋げばいいではないかと。確かにケーブルでの接続は鬱陶しいが、そうする方がシステムを作る手間が少ないし、構成要素も少ないから断然いい。

てな訳で、「細かいことを考えずにとにかくやってみた」ら、失敗どころか無駄の極みだった。が、まあ、おもしろかったのでいいことにしたw そして、前半に書いたようなことを思った次第である。

 

PS. 他にも、今朝は別件でやっぱり良く考えずにやったら、大失敗して大変だった。夜中にiVideoのルーターが落ちていた(LTEが切断されていた: 原因は確定していないが、夜中にAQUOSがディープスリープになり、Wi-Fiが落ちて、接続する機器が何もなくなったからのようだ)ようなので、それを何とかしたいと思って、どうしてか(今となっては理由が不明。寝ぼけたのだろうか?)TP-LinkのWi-Fiブリッジ(TL-WR802N)のモードを"WISP"というのに変えたら、全然繋がらなくなってしまって、困った。

Ethernet(PC)からもWi-Fi(スマフォ)からも管理webにすら繋がらず、初期化しても直らなかったので、初期化できない領域を書き換えてしまったために、交換してもらうしかないかと思った*。ただ、最後に、(ヘルプページ※に書いてあったが当てにはしていなかったものの、)別のスマフォから試したらようやく繋がったので、ブラウザのキャッシュが良くなかったようだ(クリアしても駄目だったので、再起動などが要るのかも知れない)。

交換だったら、少なくとも数日間はPCからネットに繋げられなくなってしまうので、まったく九死に一生を得た気分だった。

*口コミで「全然繋がらなくなった (クソが!)」と書かれている人は、こういうことも原因にあるのではないかと思った。なかなか奥が深いし、説明も再現も難しいから、普通の人は気付かないだろう・・・

僕は、別のスマフォで試す前に、中を開けて、電池があれば外して完全に初期化してみようとすら思った(ただ、ネジがシールの下にあって保証が無効になるので、止めた)。

※不思議なことに、外部に繋がっていないのに、Chromeで検索したらTP-Linkのヘルプページなどが出て来た。賢いキャッシュなのだろうか? 謎だけど、結構助かった。

  •   0
  •   0

大容量MVNO(iVideo)を用いた通信の完全無線化のための確認の一つに、「(車などでの)移動中の通信も問題ないか」がある。もちろん、元の回線は腐ってもSBMなので問題あるはずはないが、仮にSBMがクソだったり、僕の環境(使い方)では問題が生じたりする可能性があるので、一応確かめておこうと思った。

方法としては、車で移動しながら通信が途絶えたりしないかを調べればいいのだが、電話やブラウズしながら走るのは不可能で危険だし、今は違反になるからできない。あとは何か自動的に通信するプログラムを動かす手がある。そこで、ここは趣味を生かしてw、Spotifyを使うことにした。

最初は普通に(構成は以下のとおり)、スマフォ(AQUOS sense lite)でSpotifyを再生しながら(通信は通常どおり、Nexus 4でLTEをWi-Fiテザリングする)走り、途中で音が途切れないかなどを確認しようと思ったのだが、AQUOSのスピーカーの音はとんでもなくしょぼいから、走りながらイライラしそうな気がした。

Spotify → LTE(iVideo, SBM) → Nexus → (Wi-Fi) → AQUOS → 音

そこで、AQUOSの音を車のステレオから出せば、多少は音が良くなるかと思った。が、接続する手段がない。車のステレオ(ナビ)には外部入力(ビデオ・音声)はあるのだが、バックカメラで塞がっていて使えないようだ(カメラは映像だけなので、音は入るはずではある。が、それを再生できるかは不明)。そこで、FMでラジオに送信することにした。それにしてもFMトランスミッターはないので、買うしかない。

安いのを探したら千円くらいのがあったのだが、見ているうちに欲が出て来て、スマフォとFMトランスミッターを(ケーブルでなく)Bluetoothで繋ぎたくなった。そういうのは2千円くらいした。が、Amazonを丹念に探したら、なんと、千円以下のものがあった。J-ForceのJF-BTFMEXK(以下、BTFMEXK)というものだった。キャッシュレスの5%還元とポイントを適用したら約880円と、ケーブル接続のFMトランスミッターより安くなった。

当然落とし穴はあると思ったが、レビューを見てもそれほどひどいことはなさそうで、いろいろ駄目だったとしても、とりあえず通信の確認には使えそうだから注文して、今日届いた。

早速室内で試すと(これは電源が別体なので、車内でなくても手持ちのUSB電源アダプタが使えて便利だった)、ちょっと謎(リセットしないとNexus 4ではペアリングできなかった)があったものの、基本的な動作は問題なかった。ただ、早速思わぬ落とし穴があった。

これはイヤフォン・マイク(どういう訳か、これはBluetoothで通話もできて、そのヘッドセットになる)が付いているのだが、音をFMで送信している時も、そこからも音が出るのだ。全然思ってもいなかったのだが、FMに出る音は常にイヤフォンからも出て、消せないようだ(ボリュームを下げるとFMの音も小さくなってしまう)。イヤフォンの音は小さいけど気になるので、開口部をマスキングテープで塞いで小さくした。確認して実用になりそうなら、イヤフォンへの線を切断することなどを考えていた。

あと、イヤフォン部(実はこれが本体のようで、Bluetoothの処理をしている)とFMトランスミッター部が分離するのだが、それが結構軽くて、走行中に容易に外れそうだった(外れると、ラジオから音が出なくなる)ので、被覆付き針金で縛った

もう、届いた直後から見る陰もなく、散々なありさまだがw、とりあえず車で試してみた。実際の利用時を想定して、以下の構成にした。(なんか、狭い車内で電波(LTE, Wi-Fi, Bluetooth, FM)が渦巻いていて大丈夫かと思うが、実際にはどうなんだろう・・・)

Spotify → LTE(iVideo, SBM) → Nexus → (Wi-Fi) → iPhone 6s※ → (Bluetooth) → BTFMEXK → (FM) → 車のラジオ → 音

※iPhoneでなくAQUOSでもいいのだが、余っていたのと、ある程度車内に置きっぱなしにしたかったので、別にした。

すると、予想以上に音が悪い。まあAQUOSのスピーカーよりはいいけど、まさに「ラジオの音」だ(いや本当にラジオなのだが、FMなのにAMのように高音が出ず、電波状態が悪い時なのか、高音がシャキシャキすることがある)。FMの周波数を変えると音は変わるが、「バッチリ」にはならない。iPhoneのイコライザで高域が強まるようにしてみたが、やっぱり今ひとつだった(そうしたら、「シャキシャキ」の頻度が増えた気がする)。

音以外でとても残念なのは、車(エンジン)を停めても(= ACC off)再生が停まらず、エンジンを掛けても(= ACC on)再生が始まらないことだ。どちらも自分で操作しなければならない。この操作はイヤフォン部のボタンでできるので便利なのだが、いちいち操作するのはやっぱり面倒だ※。探している時は、BluetoothのFMトランスミッターは普通はエンジン(ACC)と再生が連動するそうなので、それを期待していたのだが、駄目だった。更に、イヤフォン部には電池が内蔵されているので、車から外している状態でも うっかりボタンを押すと再生が始まってしまい、不意にイヤフォンから音が出るという、悲しいことになる。

※今気付いたが、スマフォのAutomagicのような自動化アプリで、電源の状態に応じてSpotifyを再生・停止させることができるかも知れない(でも、できない気もするが、IFTTTとかならできそうな気もする)。

いずれにしても、BTFMEXKは全くのクソではないのだが、がっかりする(惜しい)ことが多かった。それから、BTFMEXKに限らず、FMラジオでの接続は音がひどくて使い物にならない※ので、最低でもオーディオ(アナログ)ケーブルでの接続にしたいところだ。そんな訳で、この構成で車内でSpotifyを聴くのは見送ることにした。

※なお、無線での音の伝送はLTE, Wi-Fi, Bluetoothでも行っているが、それらは(今回は)音質への影響はないと思う。というのは、音の劣化具合がいかにもアナログ的(例: 高音が出ない)だったからだ。音がブチブチ切れたなら影響が考えられるが、それは全くなかった。という訳で、アナログ伝送は脆弱なのを実感した。

ただ、そもそも今回の目的は、移動中もiVideo(SBM)の通信が問題ないかを確かめることで、約30km走って全く大丈夫だったので良しとする。

問題なかった理由の一つは、(回線の質がいいこと以外に、)Spotifyはリアルタイムに音のデータを取得しながら再生している訳ではなく、(最初などに)ある程度まとめて取得しておいたものを再生しているため、データ取得時でも再生時でも多少回線が切れたりしても、再取得する余裕があるからだと想像する。

電話(完全にリアルタイム)なら話は別だが、iVideoには電話サービスがないし、仮にIP電話にしたって、僕は滅多に電話はしないから、確認する必要はなさそうだ。

それにしても、BTFMEXKは「技術の極み」とうたっているが、僕に言わせれば「惜しい極み」だw 一体どういう考えで こんな奇想天外な機能・構成のシロモノを作ったのか想像もできないが、それぞれの要素の機能はちゃんとしているので、それらをもっとうまく連携して詰めれば結構売れたと思う(そして、こんなに安売りされることはなかっただろう)。もったいないことだ。

まあ、各要素が分離するので、気が向いたら改造したいと思う。トランスミッターとイヤフォンと電池は捨てて本体(Bluetooth→オーディオ変換機能)だけ使い、そのライン出力を取り出して、何とかステレオ(カーナビ)に繋がるといいが・・・※

※仮に改造できず、車で使えなかったとしても、USB電源アダプタ(2口、片方は大容量出力)は使えるから、それが880円と考えれば悔しくはないだろう(でも、実は既に持っている。まあ、今のは出力が小さいから、AQUOSの高速充電とiVideoのモバイルルーターに使えるだろう)。

それにしても、これって、まさに昔の車(VITA)でやっていたことだ。当時はiPodをケーブルで車のステレオに繋げていたのだ。やっぱり最初はFMで飛ばそうとしたのだが、音が悪かったので すぐに諦めたと思う。すっかり忘れて居たが、全然進歩がないものだwww

 

PS. BTFMEXKで一番感心したのは、USB電源ケーブルが柔らかくてしなやかだったことだ。ここまで柔らかいものは見たことがない。本当におもしろい製品だ。

PS2. カーナビで思わぬことが分かってしまった。アンテナは切断してB-CASカードも入れてないのに、なぜかTVが映ってしまったのだ。ワンセグが入ってしまうのだろうか? 全く危ないところだった。N○Kにしつこくカーナビのことまで聞かれたら、ドヤ顔で「映せるものなら映して下さい!」と言おうと思っていたのだw

それにしても、本当に迷惑だなあ・・・

  •   1
  •   0

実家で聴いたスマフォ(AQUOS sense lite)の音が大変悪くて、以前設定したイコライザを使ったり、再度耳で調整したのだが、どうも今ひとつだった。それで、もちろんスマフォに多くは求めないながらも、興味が湧いたので、どういう周波数特性なのか測り、その結果でイコライザを調整してみようと思った。

実は、そもそもは年末に修理から返って来たオーディオインタフェース(Focusrite Scarlett Solo)の動作確認に、PC(オーディオ)のスピーカーの特性を測定しようと思っていたのだが、スマフォの特性が気になったので、そっちをすることにした。なお、スピーカーの特性も測定したが、問題なかった。

手で持って聴く場合を想定して、(いつものように段ボールで)簡単なホルダーを作って測定してみた。すると、耳は全然あてにならないことが改めて分かって、毎度のことながら愕然としたw

なお、スマフォの特性を測定するには、PCの出すテスト信号をスマフォから出す必要があるが、PCのスピーカーと違って普通には出力できない。僕のスマフォでは(ネットのテザリングとは違って)AndroidがUSBのサウンドデバイスになることはなさそうなので、マイク端子に音を入れてスピーカーから出すアプリを使おうかと思って探したのだが、どうも直接的でなくて気に入らなかったので更に検索したら、すごく丁度いい方法があって助かった(→ 参照)。

それは、LinuxのPulseAudio(サウンド系)が出す音をネットでスマフォに送ってスピーカーから出すという、最も直接的な方法である。PulseAudioはなかなか高機能で、音をネットに出すこともできるようだ(JACK Audioでもできるようだが、やったことがないし、やるのは怖いし面倒だw)。スマフォ側は、それを受けるアプリ(Simple Protocol Player)をインストールして動かしたら、無事に音が出た。

ただし、使うイコライザ(例: Equalizer Pie(後述))によってはSimple Protocol Playerの音に効かないので、その時にはSoundWire (free)というのを使った。どうしてか、PulseAudioと違ってかなり(数秒)遅延があるのだが、特性を測定するソフト(REW)でトリガー音で測定開始するようにしたら、うまく測定できた。

SoundWireと同様の方法にVLCを使うのもあったが、やっぱり遅延が大きく、トリガー音で測定開始できることに気付く前だったので諦めた(トリガー音を使うなら、SoundWireよりも手軽でいいと思う)。エンコード用バッファの関係で遅延するのだろうか?

(1/4 4:50) スマフォの通信データ量をチェックして驚いたのだが、PulseAudioの転送はデータ量がとんでもない(測定のために1-数時間使っていただけで、1GB近くに達していた)ので、間違ってモバイル回線を使わないように注意が必要だ。圧縮していないせいはあるにしても、随分多い。また、SoundWireもPulseAudioの1/3程度と多かった。

耳で調整した時には、2kHzや4kHz辺りに山があるように感じた(その辺りを下げたら、感じが良くなった気がしたため)のだが、実際には山は7.5kHz付近にあった。。。

特性を見たら、2kHzや4kHz辺りなんて平らもいいところで、僕の耳は節穴かと言いたいが、聴覚特性に関係しているのかも知れない。等ラウドネス曲線では500Hz-4kHz辺り(特に4kHz)の感度がいいから大きく聞こえることや、錯覚のようなものがあるのかも知れない。

あと、うすうす感じては居たが、このスマフォは中低音が全く出ず、700Hz以下は期待できない。ここまではっきり出ないと、その割り切りに却って感心するw (某●ニー社とかだと、「何とかベース」とか言って、重低音を無理やりして出して宣伝しそうじゃないですか) 逆に、超高域(15kHz辺りまでは余裕だし、20kHz辺りまでも何とか)が出ているのが意外だし不思議だ。

それで、中低域は諦めるとして、イコライザアプリ(Equalizer Pro)で補正してみた。まあまあ山が下がったのだが、Equalizer Proは7.5kHz付近の調整ができないので、今ひとつ納得できなかった。それで他のイコライザを探したら、7.5kHzの近くの6.3kHzや10kHzが調整できる、Equalizer Pieというのが見付かって試してみたら、かなりいい感じに補正できた

ただ、どういう訳か、Equalizer Pieはイコライジングできるアプリが少ないようで、Spotifyには使えるのだが、YouTubeアプリやOperaには使えない。まあ、Spotifyに使えれば問題ないのだが、なんか気に入らないので、Equalizer Proを再調整してみたら、許せるくらいになった

最後に、実際にYouTubeにアップロードされていた曲(Sugar 「ウエディング・ベル」(1981))の冒頭に対して適用した例を示す(あらかじめ済みません(どうでもいいけど"Apology in advance."ってあるのだろうか?)。フリー音源を見付けるのが面倒だったので、好きな曲を使いました。権利者の方からクレームを頂いたら取り下げて入れ替えます)。

補正によって、高域のギラギラした感じ・うるささが大分改善された(でも、音量の違いやオーディオのスピーカーで聴くせいか、今聴くと余りうるさくない?)。ただ、オーディオのスピーカーでは中低域がちゃんと出ているので、そっちを聴くと「ああ、やっぱりこれだよなー」ってなってしまう。

てな訳で、このくらいの測定・調整なら、手軽にできて楽しいものだw

書いたあとで思ったが、楽器の音(調律ではない)は耳で作るのだと思うが(これはこれで、すごくおもしろそうだ!)、オーディオ機器・装置は耳では無理だろう。もちろん、後者は、あくまでも無色透明な音、平坦な特性を目指す僕の指向での話である。

 

PS. 測定中にスマフォがホルダから落ちてしまって、コネクタから着地して割れちゃったかなとか慌てたが、運良く無傷だった。

  •   0
  •   0

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

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

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

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

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

基本動作はできた※のだが、試しに少し(15分くらい)動かしていたら、RG値取得用アプリとSpotifyサーバの通信ができなくなってRG値が取れなくなってしまった。再生用アプリの動作は問題ないので、短時間(RG値取得用アプリに切り替わっている時間は約2秒)で切り替えるとうまく動かなくなってしまうのかも知れない。まあ、再生し始めたと思ったらすぐに切り替えるなんておかしな使い方を想定していないのはもっともだから、仕方ない。

※本方式での音量正規化処理自体は、全く問題なかった。性能(音量の揃い具合)はSpotifyアプリよりも良かった(とはいえ、大差ではない)。また、前回(「と思いきや」のあと)失敗した、プレビュー版のRG値とは異なる場合が多かったので、そちらには得体の知れない値が入っているようだ。

あと、不思議なことに、投稿用に動画を撮り直そうとして再度動かしてみたら、プレーヤー切り替えのタイミングがずれて※、曲間で余計な音(RG値取得中または曲の先頭に戻る前の音)が出るようになってしまった(上の動画はボツのテイクを投稿用に少し編集している。でも、ちゃんと動いていたのは確かで、夢や幻や捏造ではないw)。だから、SpotifyのアプリもWeb APIも、こういうタイムクリティカルな用途には無理があるようだ。

※アプリの切り替え時間(= RG値の取得・処理時間= 曲間)は最初は4秒くらいだったのだが、それでは遅過ぎるので(結構苦労して)高速化・最適化したら不安定になったようだ。元の遅い版ならもう少し安定なのだろうが、それでは気分が悪いw それどころか、最初は1秒以内にしたいくらいだった。

そもそも、(前回も書いたが、)これをやりたかった理由の一つはダイナミックレンジをなるべく減らしたくないことだが、再度計算してみたら、Spotifyの音量正規化のQuietモード(基準音量: -23LUFS)を使っても2ビットも落ちないことが分かった※ので、ポップ音楽でそこまでこだわる意味は全くないから無理する必要はない。

※先日の試算では、音量を-23LUFSにするのに23dB下げると考えたが、それは誤りで、SpotifyがRG値の計算に用いているReplayGainの基準音量は-14LUFSなので、(-14-(-23)=)9dB下げる程度であり、それは(9/6=)約1.5ビット相当である。

あと、RG値取得用アプリが駄目になる問題は、例えば、通信できなくなったらしばらく(数分?)待ってアプリを再起動すれば回復できるだろうが、たとえ自動的にするとしても、再起動されるまでは聴けなくなって気分が良くないし、音量正規化のon/off切り替え時にアプリを再起動したくないからこの方法にしようとしたのに、(再生用ではないけど)やっぱり再起動が要るのでは馬鹿らしい。それに、上に書いたように、タイミングが変動して安定して動かないのでは、とても実用にはならない。

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

 

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

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

 

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

  •   0
  •   0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

判定条件

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

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

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

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

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

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

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

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

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

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

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

 

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

昨夜、複雑なために一旦諦めたトリッキーなSpotifyの音量正規化用の値(以下、RG値)取得の方法を、なるべく簡単に実現するにはどうしたらいいかなどと考えながらSpotifyのログを眺めていたら、思わぬ展開になった。すごく簡単に取れるかも知れないことが分かったのだ。

RG値はSpotifyアプリのログに出ることは分かっていたが、音量正規化をonにしないと出ないし、その仕様がいつなくなるかも知れないのだが、SpotifyのWeb APIのGet a Trackなどで取れるプレビュー(試聴)用のMP3ファイルに入っていたのだ。全くコロンブスの卵というか、灯台下暗しだ。

その前に、RG値も入っていると思われる、ヘッダ部("head file")取得用URLがログから分かり、その中身はBase64エンコードされたOggだったので、「もしや!?」と思ったのだが、曲のデータ同様中身が暗号化されていてお手上げだった。

ただ、プレビュー用のファイルを普通にsoxiやexiftoolやプレーヤーで情報を表示してもなぜかRG値(例: REPLAYGAIN_TRACK_GAIN)が出ないので諦め掛けたのだが、ffprobeでは"Side data"として出た。だから、通常のMP3での格納方法ではないのかも知れない。あるいは、僕がMP3に詳しくないだけか?

↑調べたら、MP3のRG値は「LAMEタグ」というものに入るようだ(MP3の標準タグ(ID3v2?)に入らないのかは分からない)。eyeD3というコマンドに--lametagというオプションを指定すると見られる(そうしないと見られない!)。あ、lameはフリーのMP3エンコーダだから、LAMEタグという名前からして、それが独自に付けているようだ。ということは、入ってないものも、将来なくなる可能性もありそうだ。MP3は随分使われているのに、RG値すら標準で入れられないのだとしたら、なかなか面妖だなあ。。。 (18:51)

それで、その値が正しいかを確認するため、数曲で全体(全曲)とプレビュー版のRG値(track gain)を比べた。なお、全体のRG値はSpotifyアプリのログから抽出した。

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

↑イマココ

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

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

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

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

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

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

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

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

 

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

  •   0
  •   0