piu lentoの日々

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

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

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

以前にも、ちょっと検討して余り安くならないので止めた覚えがあるが、今は収入がないので、少しでも減らしてみたい(半分趣味だｗ)。あと、東電は未だに原発を推進しているので、そこから脱却する(意思を示す)のは意味があると思う。会社を変えても、(自分の使用する電力のうちで)原発の割合が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 写真を載せ、少し加筆)