piu lentoの日々

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

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

まず、その机を置きたい場所は まさに埃の吹き溜まりになっていたので、掃除をした。気合いを入れて、足掛け二日(約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のロゴを見て気付いた(気になった)のは、線と枠の間隔が左右で違う(右に寄っている)ように見えることだ。でも、じっと見ると同じようにも見えるし、それよりも、色遣いが良くないせいか、目がおかしくなる・・・