Archive for the ‘PC・技術’ Category

実家で聴いたスマフォ(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

近頃始まった話ではないのだが、僕は自分でも妙だと思うタイプミスをする。例えば以下だ。

  • で → 「て」、が → 「か」
  • l → "1"

キーが隣とかなどは分かるが、そうではない。どうも、読みや見た目で間違うようだ。僕はそういう風に文字を打っているということなのだろう。読みでの誤りに関しては、頭の中でそういう音を出して(読んで)打っていると考えれば腑に落ちる。しかし、見た目に関しては、別に(80年代のようにw)紙のリストを見て打ち込んでいる訳じゃないので、全く謎だ。

見た目について考えてみた。思い出すと、それはプログラムを入れる時に起こった。打つ時は頭の中にプログラムが浮かんでいる(でも、ずらっとしたリストではなく、打ち込みながら、「トラックのRG情報を計算する」のようなふわっとした処理内容から漠然とした行が浮かぶ)のだろうが、プログラムのキーワードは文章のようには読めないので、見た目で間違うのではないか。

余談だが、"l"と"1"は間違うが、"l"と"I"はフォントによっては区別が付かないけれど、おそらく間違わない気がする。これも理由が良く分からないが、昔の小型タイプライターは"1"と"l"を共用していたせいか? (確か、"1"のキーはなかった気がする。) ← うわ、Courier Newだと、"l"と"1"の区別が付かないよ・・・

逆に、英語の文章は読んで打つらしく、"l"と"r"を打ち間違う(というか、どっちか分からない※)ことがあるが、それは読みではあるけど次元が違う問題だw

※「計算機」や「図書館」は鬼門だ。打つスピードが必ず下がる。しかも、大抵間違っているw

仕事をしていないのでボケが始まったのかとも心配したが、まあ、プログラミングはできるから大丈夫だろう・・・

 

でも、もしもいつか完全にボケてしまって、パスワードマネージャのマスターパスワードを忘れたら、それから一体どうやって暮らして行けるのかと心配になった。手帳に書いておいたって、きっと(その存在すら)分からなくなるはずだ。会社に良く居ると言われる情弱おじさんのように、ポストイットに書いてディスプレイでも貼っておく? (でも、今は、それはそれほど悪くないらしい) いや、それも意味が分からなくなるはずだ。

まあ、その時はパスワードマネージャを使う必要がなくなっている(PCを使うことすら思い付かない?)から問題ないのだろうか?

そもそも、そういうITのない生活に戻るってのは想像の域を遥かに超えている。そうなる以前前に、いつかPCは終息するのだろうが、その時に、今蓄えているデータはどうなるのか、新しいものに移行できるのか、する気力はあるのかなどと、ちょっと心配している。

例えばデータフォーマットの問題だ。いつか廃れてアクセスできなくなってしまう。JPEGやPDF、HTMLだって永遠に有効ではないだろう。データベースなんて結構危ないな。MP3やFLACはどうなんだろうか。そういう世の中は他人事ならなかなかおもしろいが・・・ 最後はプレーンテキストとか紙とか石が最強なのかね・・・

でもまあ、急にそうなる訳ではないだろうから、まあ、おいおい考えればいいかw

  •   0
  •   1

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

どっかの国の政府とか軍隊みたいに、勝算がないのに精神論(利権も?)で金・労力を投入して無理な行軍を延々と続けて、最後に、さまざまな言い訳をしながら形式上は「成功」などと発表してドヤ顔して(それどころか、首謀者が逃亡・知らん顔して、)煙に巻くのは愚の骨頂だ。駄目なものはなるべく早く気付いて切る(少なくとも、再検討や方向転換する)のが重要だ。

試行錯誤しているSpotifyの音量正規化処理の改良だが、ポップ音楽モードがそこそこ うまく行って、クラシック音楽モードも調整して目処が立ったものの、今朝寝ながら思い付いた(気付いた)。Spotifyアプリの(標準の)音量正規化機能がどのくらいのものなのか、それと今回の自作の方式にどのくらいの差があるのか確認しようと。特に、曲の特徴量のデータが誤っているのではないかというくらい大音量になるいくつかの曲(例: "Take My Breath Away", "Catacombae")は、Spotifyアプリの音量正規化ではどうなるのか興味があった。

やってみたら、多くの収穫があった。

  • Spotifyアプリの音量正規化の性能はいい。自作の方式よりずっと音量が揃う。ポップ音楽での音量幅(ラウドネスの不揃い度)は、自作の方式では、(試した数曲の音量の範囲が広かったとはいえ、)おかしい音量になる曲を除いても、目分量でSpotifyの2倍(LUFS値の幅)くらいだった。おかしい音量になる曲を含めれば数倍になる。
  • Spotifyアプリの音量正規化のうち、Quietモードでは、Normalモードと違い、すごく静かな曲(例: "Speak to me")を不自然にしてしまうコンプレッサー(のような処理)が働かないようだった。
  • Spotifyアプリの音量正規化用の値は、ログやコンソール出力から取得できる。ただし、音量正規化をonにしていないと出ない。

Spotifyアプリの結果を聴いたら悔しいくらいだった(上記の困った曲が何の問題もない音量で出ていた)。悔しいけれど、結局、自作の方式でいくら頑張っても苦労ばかりで余りメリットはなさそうだ(そもそも、目的はそこにない)。それよりは、Spotifyアプリの音量正規化をうまく使えばいい。

一番手軽なのは、音量正規化をする場合は常にQuietモードを使うことだ。これなら、ポップ音楽でもクラシック音楽でも切り替え不要で、静かな曲でも音が不自然になることはなさそうだ。ただ、目標音量が-23LUFS程度と小さいので、もったいない気がする。特に、ポップ音楽では、もっと音量を上げてSN比を向上させたりダイナミックレンジを減らさないようにできる(だからNormalモードを使いたいのだが、例のコンプレッサーが邪魔だ・・・)。が、そもそも、音量正規化して聴くというのは、BGMのように気軽に聴いている時であり、その時にSNだのダイナミックレンジだのと言っても無意味だ。逆に、真剣に聴く時には音量正規化を使わないから、これで問題ないとも言える。

少し前に試行錯誤中に知ったのだが、Spotifyアプリの音量正規化はトラックモードとアルバムモードを自動で切り替える(アルバム再生時は後者になる)とのことなので、自作しようと思った切っ掛けの一つの、アルバムモードがないことも解決できた(この機能は後から追加されたのか、最初からあったが公表されていなかったのか)。そういう点でも、特にモバイルなどで切り替えずに使いたいなら、Quietモードにしておけば不便はない(まあ、モバイルでは周囲が騒がしいので、すごく静かな曲が不自然でも問題なさそうだから、Normalでもいいとも言える)。

ただ、Quietモードのもう一つの問題は、音量が小さいので他のプレーヤー(僕の場合は、gmusicplayer, GMB)と合わないことだ。これは結構厄介だ。Spotify(音量正規化)からGMBに切り替えた途端に大音量(約+11dB, 3.5倍)になるので、常に注意が要るし(大抵忘れて驚くw)、アンプの音量調整が煩雑だ。アンプの音量を変える代わりに他のプレーヤーの音量を下げる手もあるが、やっぱり「もったいない」から避けたい。逆に、Spotifyアプリの音量を後で大きくして合わせる手もあるが、一旦小さくしているのを増幅すると音質が劣化するから嫌だ。

書いた後で気付いたが、小さくしたのを増幅すると音質が劣化するというのは本当だろうか? (アナログでなく)ディジタルなので、増幅でオーバーフローしない限り、小さくした時より劣化することはない気がして来た。あとで検討したい。 ← データフォーマットにも関係ありそうだ。 → 検討結果を付録に記載した。 (12/19)

調べると、-23LUFSというのはEUの放送の基準レベル、あるいは、クラシック音楽向けだそうで(USや日本の放送は-24LUFS)、それに合わせるのは悪くないとは思うものの、自分の閉じた環境なのに一律に低く合わせるのはやっぱりおかしい気がする(実際、SpotifyやYouTubeの基準は-14, -13LUFSと、-23LUFSよりかなり大きい)。

以下に、候補とそれぞれの欠点をまとめる。

  • 自作の音量正規化
    • 音量を揃える能力がSpotifyより低い。
    • 全然揃わない曲がある。
    • 原因: Spotifyから音量正規化のための値(ReplayGain)が取れないので、音響的特徴量から推測しているため。
  • Spotifyの音量正規化: Quietモードのみ
    • ポップ音楽でダイナミックレンジがもったいない。
    • 音量が小さいので、音質が劣化する?
    • 他のプレーヤーと音量が揃わないので不便。 → 増幅すると音質が劣化する(要確認 → 検討結果を付録に記載した。 (12/19))。
    • 原因: Quietモードは音量が小さいため。
  • Spotifyの音量正規化: Normal, Quietモードを切り替える。
    • Normalで不自然になる曲(静かなもの)がある。
    • 原因: Spotifyアプリの処理(コンプレッサー?)が入ることがあるため。

上述のとおり、自作の音量正規化が駄目なのはSpotifyからReplayGainが取れないためなのだが、どうにかして取る方法はないかと試行錯誤していたら、思わぬことで取れた! 既に書いては居るが、アプリのログやコンソール出力に表示されるのだ。以下に"Speak to me"での例を示す。太字がトラックのReplayGainである。

02:05:55.089 I [libvorbis_ogg_decompressor.cpp:401] track gain: (13.25Db), track peak: (0.409425dB), album gain: (-5.09dB), album peak: (1.02865dB), normalization: trackgain

ちなみに、それらはGMBでの同じ曲(同じマスターと思われる)でのReplayGainの値と概ね合っていた。

なお、peakの単位が"dB"と書いてあるが、誤りであろう(正しくは単位なし)。同じく"Db"もtypoだろう。ここら辺は そうなる状況が分かる。つい指が動いたとか、余計にコピペしたとか。「(見ると気になるけど、)デバッグ用だからまあいいか」、みたいなw

それで、自作の音量正規化にSpotifyのReplayGain(以下、"RG")値を使う(苦肉の)策を考えた。理論的には、RG値取得用と再生用の2つのSpotifyアプリを使えばできそうだ。以下に手順概要を示す。

  1. 再生用Spotifyアプリを音量正規化offにする。
  2. RG値取得用Spotifyアプリをログまたはコンソール出力ありで起動する。
  3. RG取得用Spotifyアプリの音量正規化をon(NormalまたはQuiet)、音量=0(-∞ dB)にする。
  4. RG取得用Spotifyアプリで再生開始する。
  5. ログまたはコンソール出力からRG値を取る。(すぐに出るはず)
  6. RG取得用Spotifyアプリを一時停止する。
  7. 得られたRG値で再生用Spotifyアプリの音量を調整する。(現在の自作と同じ方法)
  8. Spotify APIを使い、有効なプレーヤ(デバイス)を再生用Spotifyアプリに切り替える。
  9. 再生用Spotifyアプリで最初から再生開始する。

ちょっと手で試して、やればできそうな気はしたが、(すっかり忘れて居た)昔のGoogle play musicの時(→ )と同様に、余りにもトリッキーで嫌になるくらいだ。また、アプリが2個なのでメモリも2倍食いそうなのも嫌だ。そもそも、ログにRG値が表示されるのは仕様でもなんでもないので、出なくなったら元の木阿弥だ。。。

だから、やっぱり筋が悪い。

そして、作るのは面倒だw

それで、とりあえずは、Spotifyの音量正規化機能を使うことにし、ポップ音楽とクラシック音楽でNormal(ポップ)とQuiet(クラシック)を切り替えて使ってみて、Normalでどのくらい不自然な曲があるかで判断することにした。Normalで駄目な曲は(DBに記録しておいて)自動でQuietに切り替える手が考えられるし、多かったらQuietだけ使うとか、上のトリッキーな手を使うことも考えられる。

それにしても、「とりあえず」のNormalとQuietを手で切り替えて使うにも自作ミニプレーヤー(minisp)に多少の変更が要るので、「ちょっと疲れたから、まあ明日にするか・・・」と一休みしているw ← イマココ

相変わらず寄り道が多く、先は長いw

 

(12/19 16:40) 付録: (デジタルで)増幅すると音質が劣化についての検討

結論は、「理論的には劣化しないが、現実には劣化する」である。以下に理由を書く。

まず、本文に書いた状況での音質劣化は、音量を下げた時点で生ずるものが主である。音量を下げることによってデータの有効ビット数が減るため、振幅分解能が減る(例: ものすごく小さい音が消える)ためだ。音を格納するデータフォーマットが浮動小数点型であれば、おそらく分解能が減ることはないが、整数型の場合には減る。その程度は以下のように試算できる。

音量を-23dB下げた場合、1ビットは約6dBなので、23/6= 約3.8ビット減る。

これによるダイナミックレンジの減少量は、データフォーマットを16ビットとすれば、3.8*6= 22.8dBである(音量を下げた分(23dB)そのもの)。

(2020/1/2 12:28記) 注: その後、Spotifyが音量正規化値の計算に使っているReplayGainの基準音量は-14LUFS相当であることが分かった。そのため、実際に下がる音量は9dB程度で、減るビット数は1.5ビット程度と少なく、特にポップ音楽では、音質の劣化もダイナミックレンジの減少もほとんど問題にならない。

実害について考えれば、対象はポップ音楽であり、そのダイナミックレンジを高々18dB(約3ビット分)程度と推測すれば、音量を下げた残りのビット数は16-3.8= 12.2ビットで、音源の3ビットより充分大きいので、記録された振幅がよほど小さくない限り、問題ないと考えられる。

次に、増幅の影響を考える。増幅は乗算なので全く音質が劣化する要素はないが、現実には、処理系や出力のデータフォーマットは整数型で取り得る範囲が有限なため、大きく増幅すると上限を超えて(オーバーフローして)音質が劣化する。つまり、波形の超過分がカットされるので、音が変質する(例: 歪む)。

この検討中に気付いたのだが、私が"Speak to me"で感じた不自然な感じは、オーバーフローによるものだった。具体的には、音量正規化時に過大に増幅するとオーバーフローが生じ、その超過分をカットすると生じる(これはリミッターの動作であり、本文中の「コンプレッサー」は実際にはリミッターであった)。

不自然さが起こる原因を詳しく推測すると、この曲は低音(鼓動)が強いため、それがオーバーフローしてカットされるのだろう。カットされるのが単発的(不定期)や短時間(瞬間的)に起こるのなら気づきにくいからまだいいのだが、この曲の場合は、定期的に起こる鼓動で、テンポが遅いために比較的長時間音が大きい状態なので、カットされる期間が長く、その間の他の音の聞こえ方が変わって不自然になるのだろう。

この現象はSpotifyアプリの音量正規化だけでなく、私の環境でも起こったので気付いた。具体的には、次のような処理をした時に、Spotifyアプリの音量正規化(Normal)と同様の不自然さが生じた。

Spotifyアプリの音量正規化(Quiet) → アンプ(増幅率: 6-9dB程度) → リミッター

また、Spotifyアプリの音量正規化(Quiet)だけでは不自然さは生じなかったので、問題はリミッターに起因する可能性が高い。

なお、「リミッターが原因だったら使わなければいい」ということはない。リミッターがなくても、超過分はどこかで(例: DACで出力する時)カットされ、それはリミッターよりもひどい音質劣化を生じる可能性が高い。

(12/19 22:23) 補足: 上でデータフォーマットを16ビットと想定したのは、Spotifyアプリの出力がそう("s16le")だからで、通常のOSのサウンドシステムはもっとビット数の多いフォーマットをサポートする。例えば、私の使っているJACK Audioは32ビット浮動小数点である。だから、音質の観点ではSpotifyに音量正規化をさせるのは得策でない。上述の、音量を下げることによるダイナミックレンジの低下などが起こる。が、もし仮にJACKの中やその手前のPulseAudioで行うなら、劣化する可能性はほとんどない。

その後の増幅はJACKで行っているので、通常の増幅率ではオーバーフローしないから、音質劣化も発生しないはずだ。しかし、元々のデータが最大値に近いほうに詰められているためにオーバーフローするし、そうでなくてもDAC(サウンドカード)に出す時にオーバーフローする。それを防ぐには、リミッターを入れるか、音量を下げて(= 適当な値で除算して)全体的なレベルを小さくして(= 小さい方にずらす)DACに出すことが考えられる。

結局、後者はSpotifyの音量正規化(Quietモード)の小さい音のまま出力することと同等である。もちろんそれでも良かったのだが、他のプレーヤーと音量を合わせたいから増幅しようとした。

 

PS. SpotifyアプリからのRG値取得には、音楽圧縮フォーマット展開用ライブラリ(vorbisを使っているようだ)をすげ替えればできるかと思ったのだが、自前で作っているかスタティックリンクしているらしく、外部のものは使っていなかった。考えが甘かったが、まあ、そうれはそうだろう・・・ あとは、逆コンパイルしてバイナリエディットとかいう手もあるかも知れないが、「うーん」だ。それに、プログラムの改ざん検証をしているかも知れないから、できないかも知れない。

なんてことを考え出すから、寄り道が増える訳で・・・

  •   0
  •   0

使っているうちに不満(例: うるさい曲がある)が出て来たために、Spotifyの自作ミニプレーヤー(minisp)の音量正規化処理で、音量の補正量をやはり自作再生履歴DB(Mlhi)に記録しおいてそれがあれば使えるようにしようと思ったのだが、そもそも、元々の方式がいい加減では補正ばかりになって良くないことに気付いた。それで、まずは音量正規化処理を改良することになり、今は、その改良した方式の評価のために、Spotifyで再生している曲の音量を自動で測定する機能を作っている※。音量はできるだけ聴感に近い方がいいので、ラウドネス(Integrated loudness: "I", 参考)にした。随分目的から離れてしまった気がするが、きっと気のせいだろうw 自分でやり出したこととはいえ、なかなか面倒だが、いろいろな物を組み合わせて機能を実現するのはおもしろい。

※なぜ自動化しようと思ったのかというと、ラウドネスメーターはあらかじめ曲の先頭で計測開始しておかなければ、正確なIntegrated loudnessの値が出ないので、だらだらと評価がてら聴いていて「大き/小さ過ぎるかな?」(調整がおかしい?)と思ってからでは遅く、再計測しなくてはならないからである。再計測にしたって、曲全体を再度聴くのは苦痛なので、先頭だけなど一部になって、正確でなくなってしまう。曲間で自動リセットしてくれるような測定アプリがあればいいが、そういうものはなかった。また、GUIに表示された測定値を見て手で記録するのは面倒だし間違い易いから、自動でファイルに記録できれば好都合だ。

更に、複数の補正条件・設定の比較についても、それぞれの条件で評価用のプレイリストを再生しておけば(僕が聴いて居なくても、スピーカーで音を出さなくても)通して測定できるので、(この機能が完成した暁には)容易になるはずだ。

更に、普通に再生しながら、補正条件とその結果の音量を測定してDBに記録しておき、次回はそれに基づいて最適な音量に調整するってことも可能な気がしていて楽しい。

更に、今思い付いたが、AIみたいな機能で、長時間いろいろな曲を自動再生して勝手に学習させて、設定を自動調整するなんてのもいかにもおもしろそうだが、先は長いし、そもそもSpotifyを聴くだけなのにそこまでする必要があるのかと・・・w

こうやって風呂敷夢を広げるから、大変になるのだ。

詳しくは別に書くつもりだが、音量正規化の基本的な処理は、従来と同じようにSpotify APIで取得できる曲(トラック)の特徴量(loudnessとenergy)を組み合わせて、曲の本来の音量を推測(復元)し、それを元に正規化している。今回は、その推測の方法を改良しようとしている。今までは思い付きで対数あるいは指数関数を使っていたが、今は下のグラフのような、energyによって特性(係数)が変化する式を試している。グラフはいかにももっともらしくて うまく行きそうに思えるが、そんなことはないw それに、これは何かの理論に基づいている訳ではなく、やっぱり思い付きや試行錯誤からの経験によるものである。試すとまあまあうまく行く(しないよりはずっといい)のだが、やっぱり限界はあるし、値に問題はなくても聴覚に合わないことがある(合わないものが充分に少なくなったら、補正量をDBに入れようと思っている。が、いつになることやら・・・)。

あと、以前のように、公開DBに音量正規化用の値(再生ゲイン)などがないか探したたら、2つ見付かった。一つは前回も見付かったDynamic range databaseで、もう一個はAcousticBrainzだ。前者は、前回は(記憶している限りでは)APIがないのとレパートリーが狭そうなので止めた。後者は、言い方は悪いが「玉石混交」(「ゴ○屋敷」などもっとひどい言い方はあるが、それは言い過ぎだろう)で、全く手軽に使えないので却下した。確かにデータは多いのだが、全然整理されておらず、ただ数字があるだけで、同じIDなのにそれぞれ随分違っていてどれが正しいのか分からず、禄に検索もできなかったら、どうやって使うのかと思う。

作業の途中で分かったことも多かった。SpotifyのAPIから得られるloudnessは多くの場合はIntegrated loudnessまたはReplayGainと同様(同等)のものなのだろうが、そうでないことも多い。中で変・特殊な処理(音量(loudness)が小さいけどenrgyが大きい曲では更にloudnessを小さくしているフシがある)をしている可能性と、データが誤っている場合もありそうだ。そもそもSpotifyアプリで使っている再生ゲインを出してくれれば、こんな苦労をしなくて済むのだが(アプリの一時ファイルを見たりしたが、それらしい値は見つからなかった)・・・

そもそも、Spotifyアプリの音量正規化処理が「普通」だったら、こんな苦労は全くしなくていい(実際、したい訳じゃなくて、ただ音楽を聴きたいw)のだが、前回書いたように、やっぱり謎の処理をしていることが分かった(何人かの方が書かれていた: )。どうやら、アプリにコンプレッサーとかリミッターのような処理が入っていて、特にすごく音量が小さい曲(僕が気付いた曲: Pink Floyd: "The dark side of the moon"の"Speak to me")でおかしくなるようだ。再生ゲインの値がおかしい可能性はあるにしても、せめてその余計な機能がなければまだ良かったのに、どうもお節介な感じだ・・・

ラウドネスの測定プログラムは、GUIのものならいくつかあるのだが、測定・記録を自動化するのは困難なので、スクリプト(jack_captureで音を録り、ffmpegのebur128フィルタでラウドネスを計算する)を作ってミニプレーヤーに組み込んだ。基本的には、ただ再生しているだけでデータが貯まるから楽ちんなのだが、例によっていろいろ凝るから本末転倒になって、処理が複雑になればバグは増えるからデバッグが大変で、また勝手に疲れている。 ← イマココ

 

PS. 以前、「Spotifyには満足している」と書いたが、誤りではない。が、それはあくまでも曲目と音質についてであって、機能は別であるw

PS2. これを書いていて、技術バカにありがちな、「フラット(あるいはリニア)信仰(あるいは症候群、至上主義)」という言葉を思い付いた。やっぱり、こだわり過ぎは駄目なんだろうと思う。が、気軽に聴いている時に、曲のたびに「うるさい!!」とか「小さい・・・」とイライラしてボリュームを調整するのは嫌だってのは大いにある。

PS3. Evernoteやスマフォ・PCのおかげで紙やペンとは無縁の日々なのだが、さすがにグラフの形を考えるのはEvernoteでは無理で(タブレットなら手描きできそうだが、それも煩雑な気がする)、紙が必要だった。が、すぐに使えたのは小さい電話用のメモ帳しかなかったw

(12/14 13:11 少し修正)

  •   0
  •   0

お名前.comの解約に数か月要している。最後に残っていた仕事用ドメインの期限切れから2か月くらい待っても一向に解約できないので問い合わせしたのだが、一週間経ってようやく回答が来て、来年の1月中旬に解約できることが分かった。 随分先だと思ったが、良く考えれば一か月も先ではないか。。。

解約できなかった原因は先日の台風だった。僕の住んでいる市が先日の台風の被災地に指定されていたらしく、そのために、失効ドメインの復活期間のようなものが延長されていた。そんなの全然知らなかった。それはwebやあそこからの(スパム)メールを見れば分かったのだろうが、メールなんてゴミばかりなので受信してない。大体、こっちから「退会したい」って言っているのに、「台風の被災者でしょうから期限を延ばしたので、その間は解除できません!!!! (キリッ)」てのが全然理解できない。被災者だったら退会の連絡なんてしないだろうに・・・ 誰か理解できる???

日本人は、おそらく、こういうのが日本ならではの「おもてなし」だと誇りに思って居るのかも知れないが、僕にはまったくありがたくない。鬱陶しいだけだ。多くの外国人だってそうだと思う。ありがたがるのは一部の変人だけだ! そんな無駄なことしなくていいから、もっとまともになれよ!!

この点に関しての想像を書くと、実は海外の方が融通は効くと思う。多くの国に行ったことはないが、困った時に頼んだり相談すれば、いろいろ対応しくれることが多いと思う。困ってなくたって、細かいオーダーをしても嫌がられないと思う。日本は全然そうでなくて、頼んでもいないのに(向こうが思う)「親切」を押し付けられ、逆に、向こうの規則に外れることは全力で拒否されるのが嫌だ。

そもそも、お名前.comのサポートすら、そういうことが即座に分からなかった(問い合わせしてから一週間掛かった)時点で終わっている。会員DBにすら書いてないのだろうか。もちろん、僕が何度解約しようとしても失敗して出て来た、「解約できないです」ダイアログにはそんなことは書いてなかったし、「マイページ」をいくら見たってそんなことは書いてなかった。クソ過ぎる。いや、クソ以下だ。

「お名前.com 解約 できない」や「お名前.com  クソ」などで検索すれば、文句は大量に出て来るが、(そういう文句があっても知らん顔しているほどだから、)あそこには本当に関わらない方がいい。サポートの「人」はまだいいのだが(でも、処理が遅過ぎる)、会社のシステムやwebや自動送信メールがクソ過ぎる。お偉いさんや技術者はクソばかりで、まともなシステムを作ろうとしない・作れないようだ。

そういうのに嫌気をさしてGoogleのドメインサービスに移った(その時にも書いたが、あそこは本当に、普通に/でいいw)のだが、そのあとでお名前.comを解約しようとしたら、それすらマトモにできないというオチだった。いやあ、本当に絶句だ。先日ムカついたNRTの会社よりひどい※。

※そのFocusrite Scarlett Soloの故障の件は、その後、予想外にも動作確認されたが、「(海外の)メーカーからパーツを取り寄せ中」だかで、数週間待たされている。いやあ、普通は在庫の新品と交換だろう。それに、そもそも「は? お前のところでパーツなんて交換できる訳ないだろ!」って言いたかったが、まったくの無駄なので止めた。ここで突っかかると、難癖付けられて修理してもらえなくなるような気がする(苦情を投稿している人は、そういう目に遭ったのではないか?)。

無駄とは思いつつも、昨日来た、「台風のため」の回答に文句を書いて出したが、それへの返事が来る前に、ワンパターンのアンケートメール(サポートの質を知りたいらしい。(それ以前に、会社の質を答えたいが!) 担当者が「完了」ボタンを押したのだろう)が来て、思わずイライラが沸点に達した。もちろん回答なんてしない。あんなの飾り以下で、"/dev/null"あるいはブラックホールに書き込むのと同じで、本当になぁぁぁぁぁぁんにも意味はないんだから!

 

注: 以上はすべて個人的な感想です。各自の条件・状況によって変わる可能性は0ではないかも知れないです。僕は0だと思いますが。知らんけどw

PS. 今日のエポックメーキングかつ哲学的な、まさに"Nothing is real"な世の中の真理を突いた閣議決定にならい、すべての言葉の意味は状況によって変化するために、定義することは不可能、かつ、定義する気もないので、そこんとこヨロシクw

  •   1
  •   0

何かで"others"という単語を見たら(もう、何だったか忘れたw)、「アザース」という読みが浮かび、そんな流行語があったと思った。

調べたら、偶然にも、近頃復活したとかいうコメディグループの番組が発祥らしい。

 

だけではおもしろくないので、ついでに: さっきSpotifyからこんなメールが来た:

2019年にSpotifyで聴いた曲数

平均すると約13曲/日で(重複を除いているのか不明だし)、多いのかどうかは分からないが、Spotifyには大変お世話になっていることは確かだ。

それで、そのメールに記されていた2019年のまとめページを見たら、トップのアーティストは意外にもカーズだった。ページに"Say thanks"というボタン(ツイートするようだ)があったが、写真(にもあり)に写っているのは(オールが死んでしまっているため)3人で寂しいうえにオケイセックも死んでしまって、まさに「ありがとう」と言いたい。

ちなみに2位はユジャ・ワンだった。これも意外だが、彼女はいろいろといい^^ ただ、5位までに大好きなルガンスキーが入ってないのは不思議だ。何かおかしいのかも知れないが、まあいい(彼はもっぱらSpotifyでなく手持ちの音源で聴いていたからかも知れない)。

なお、1位(loved most)の曲は去年と同じく、ヒューイ・ルイス&ザ・ニュースの"The power of love"(1985)で、これは本当に大好きだ。

他には、59か国の曲を聴き、特定ジャンルに固定せず("refused to let one sound define you.")、436もの新しいアーティストに触れたそうで、まさにSpotifyならではだ。

ページの最後に「良かったら(SNSなどに)どうぞ」みたいな画像があったので、ここに貼る。

2019年のSpotifyのまとめ

Spotifyにも「ありがとう」と言いたい。

(と、オチを付けてみたw)

 

PS. 投稿を見直して思い付いた。自作の音楽再生履歴管理システムMlhiを使って、手持ちの音源も合わせた順位も出すとおもしろそうだが、SQL(検索コマンド)を考えるのがちょっと面倒だw 日々、聴いた履歴は記録されているのだが、その活用まではなかなか手が回らない。

ちなみに、MlhiのDBに入っているのは延べ約4500曲(今年の中頃から)なので、ほとんどはSpotifyで聴いているはずだ(感覚とも合っている)。

PS2. Spotifyが出て来たのでついでに書くと、今年は1枚もCDなどを買わなかった。それでいいか悪いかは別として、(曲目も音質も)何も不自由していないどころか充分に満足しているから、きっといいことなのだろう。

  •   1
  •   0

例の「データは破棄したから残ってないよ」の件で、ちょっと逆張りしてみる。

北から「隅々何一つ欠かない完璧な馬鹿」と絶賛のトップが分かってないのは当然として、それを叩くマスコミもそれに情報を流す「ITジャーナリスト」も分かってない。以下、日刊ゲンダイDigitalの記事「名簿破棄の大嘘 安倍首相「シンクライアント」でまた墓穴」記事の2ページ目より引用:

「それでも元データが消えるなんて、あり得ません」と言うのは、ITジャーナリストの井上トシユキ氏だ。こう続ける。

「シンクライアント方式は完全なデータ消去が困難なシステム。単なる中継サーバーならともかく、集中管理している大本のサーバーが現在も稼働していれば、元データは確実に残っています。削除しても特殊なソフトウエアを使えば復元可能です。

(以下略)

「へー、そうなんだー。すごいね」(棒読み)と言いたいw

一般論ではそうかも知れないが、仮に政府のサーバ(この記者が「サーバー」でないのはおかしいとか言っているのは こそばゆいし、逆に、某トップが「サーバ」と言ったのは、なぁんにも分からないながらも、一応、レクを覚えていたってことだろうw)が、USの国防総省にあるような(想像)すごいシステムを採用していて、削除したファイルが本当に復活できないようになっているかも知れないし(これは可能だ。良くある、完全消去アプリと同様)、普通のサーバだって、常時稼働しているのなら、削除してから長時間経ったら、ストレージの使用領域が一周して、ファイルが上書きされてしまって復活できない場合もある。後者だったら、どんなソフトでも復活は無理だろう(まあ、それでも些細な物理的な痕跡を元に復活させることもあるようだが、「確実に残っている」と言えるかねえ・・・)。

論理的に考えれば、いかなるストレージも有限の容量なので、元の記録に上書きすれば記録はなくなってしまう。もしそうでなくて、いかなる記録の履歴も後から自由に取り出せるとすれば、「(経済的に)無限の容量を実現できた」ってことで、ノーベル賞くらいはもらえるのではないかw 無限でなくても、書き込んだらすぐに削除すれば、少なくとも2倍には使えるはずなので、僕は是非その方法を教えて欲しいくらいだwww

それにしても、この記者も「ITジャーナリスト」も、実物(サーバや構成)を見てもいないのに、良くこんなことを自信満々に言えるものだ。野党も、こういう筋で突いて本当に復活できなかったら、折角の穴が塞がれてしまいかねないではないか。一休さんのように、「削除したデータを復活させられるのなら、端末をお貸ししますので、是非お願いします。丁度困ってたんですよー」とか言われて駄目だったらどうするんだろうか?w

まあ、実際問題としては、データはどこか(例: バックアップ(の履歴)、担当者のPC(「シンクライアント」と言っても、きっと誰かのノートPCにあるよw)、紙)に残っているのは確実だ。でも、この件の一番の問題は、国政の情報を余りにも短期間に削除する(恣意的にそうすることが可能な)規則にしたことだと思う。

まあ、情弱(ITどころか、政治だか行政だかの基本すら分かってない)の極みというか、逆に斜め上を行っているというのか、「すごい」と言って絶句するしかない・・・

 

PS. データの復元(一般論)、それから、記録を残すことの重要性については、こちらの記事が正しい。ちゃんと分かっている人も居た。 (12/4 16:20)

  •   0
  •   0

銀行振り込みって、基本的には平日の昼間しか実行されず、限られた「進んだ」ところ同志でだけ24時間できるイメージだったが、それはもう間違いのようだ。夜に(地元のしょぼいw)地銀に即時振り込みできてしまったのだ。

僕がメインに使っているネット銀行は、口座引き落としの対応する相手が少なく、しかも、地元の自治体や業者は地元の地銀や郵便局にしか対応していないことが多いため、どうしても地銀に口座(と残高)が要る。先日、気が早くも※来年の引き落とし分を振り込もうと思って処理したのだが、後で良く考えたら多過ぎたことが分かった。住民税が掛からなくったり国民年金が免除になったりしたから、前もって再計算しようと思っていたのに、それを忘れて、以前計算していた額を振り込んでしまったのだ。

※PCに古い予定の通知が出たのが切っ掛けだった。新しい予定には、ちゃんと、「金額を再計算」と書いてあったのに、その古い予定に書かれていた額を再計算後と思い込んでしまった・・・

ただ、夜だったから余裕で取り消せると思って再計算を始め、その途中で地銀の口座を見て目を疑った。さっき手続きしたお金がもう入っていたのだ。まさに「は?」だwww

そういえば、少し前※に24時間即時振り込みできるようになったとかのニュースがあったが、意外にも僕の地銀も対象だったようだ(その時は「(その銀行)は遅れているから関係ないよなあ」とか思っていたw)。

※ 少し前どころか、去年から始まっていたようだw → 参考

まあ、振り込め詐欺wに引っ掛かったとか騙されて変なものを注文した訳ではないから何も損はないが、数年間は無駄にその地銀にお金を置いておくことになるので、ちょっと気分が悪かった。

言ってみれば、いつの間にか世の中の進歩に遅れた浦島太郎だったってことで、まったく忸怩たる思いだw

 

PS. だけど、その地銀もメールで「便利になります!」とか連絡してくれたっていいと思うのは、(いつも「うるせえ!!」とか思う僕には)自分勝手な言い草なのか? 実は来たけど読まずに捨てた? そういえば、近頃何も連絡がないが、何かおかしなことになってなければいいが・・・

  •   0
  •   0

前の稿で「無料に依存していない」と豪語したものの、どうしても無理なことはある。ことあるごとに代わりを探しているが、いいものがないのでMozillaの製品を使わざるを得ないが、どうにもイライラすることがある。

  • Firefox: 言うほど省メモリじゃない。近頃はメモリを食うようになった気がして、「Chromeよりはマシ」程度だ。それだけの理由で使っているので、もしChromeが省メモリになったら、確実に移る。
  • FirefoxとThunderbird: 勝手に構造を変えて、今までのアドオンを全然使えなくして、開発者もユーザーも減らす。 → だったら、Chromeのアドオンを使えるようにした方が・・・
  • Thunderbird: 新しいバージョン(68.*)は練れていないせいか、動作や(ただでさえ少ない)アドオン間の連携がおかしかったりする。更に、互換性の問題があるからか、複数のバージョンを併存させて、自分たちの首も締めている。 → 何かいいものはないかー??
  • 「行き止まり」が多い。: 抜けてしまった開発者の後がなくても、(とりあえず動くから)長年放置されている箇所が多い。
    • 例: Thunderbirdのアドレス帳のファイルフォーマット("Mork")が謎のまま長年放置されている。とりあえず、JSONとかにすればいいのに・・・ (クソ分かりにくいけど)IndexedDBでもいいじゃん。
  • 全体的に(「進歩」はあるものの)改良がない。: 誰得の最新技術は取り入れているものの、できて当たり前のことが普通にできない。
    • 例: Thunderbirdのアドレス帳をコマンドラインでインポートすることなんてできない。

まあ、まさにオワコン、クソそのものなんだけど、本当になくなったら困るから困っているw

こういう点ではGoogleは賢いと思う。PCのアプリは、基本的にはブラウザ(とサーバ)で全部済ませている(Thunderbirdや互換Officeのようなアプリは作っていない)。僕はそれが不便だと思う(例: メールも予定もブラウザってのは、やっぱり使いにくいと思う)から使わないのだが、時代に乗り遅れているのかも知れない。それにしても、Chromeはメモリを食い過ぎる。。。

ああ、でも、クソイライラするThunderbirdやLightningなんて止めて、(GoogleやChromeじゃなくて、)自分のサーバとブラウザだけで済ませる手もいいかも知れないなあ。必要な機能があればの話だが・・・

サーバのwebアプリをちょっと試したが、余りにもショボくて止めた。予定の通知(アラーム)さえ随分遅れて出るありさまだ。これでは非常用にしか使えない。今のは知らないが、昔のGoogleの方がずっと良かったw (12:56)

 

(11/30 14:29) まとめサイトを見て思い付いて、久し振りに目新しいブラウザをいくつか試したが、やっぱり気に入らず、Firefoxに落ち着いてしまったw 以下に概要を書く。

必須条件

  • タブ一覧が横(左)端に縦に並べられる。
  • パスワードマネージャ(KeePass)対応
  • メモリ使用量が過大でない。

試した候補と評価結果

  • × Opera: メモリ使用量が多い。
    • 使い勝手
      • タブが左に出る。: アドオンTree tabsなどで対応
      • KeePass対応: アドオン: KeePassHelper Password Managerあり。: 便利ではない。
    • × メモリ使用量: 多い: 7タブで2.2GB (Firefoxは数百タブ(サスペンドあり)で3GB)
  • × Pale Moon (Mozillaベース): KeePass非対応
    • × 使い勝手
      • タブが左に出る。: アドオンTree style tabs for pale moonで対応
      • × KeePass対応: アドオンなし (なくなってしまったようだ)
    • ○ メモリ使用量: 少ない: 3タブで約480MB
    • その他
      • 設定が細かくできていい。
      • スピードが遅目。
  • × SeaMonkey (Mozillaベース): KeePass非対応。とにかく古い。
    • × 使い勝手
      • タブが左に出る。: アドオンSeaMonkey Vertical Tab Barで対応
      • × KeePass対応: アドオンなし
    • その他
      • スピードが遅い。
      • 使い勝手が古めかしい(「昔のFirefox」)
      • アドオンも古い。
  • × Brave (Chromeベース): メモリ使用量が多い。劣化版Chrome
    • × 使い勝手
      • × タブが左に出る。: アドオンvTabsはまともに動かない。Vertical Tabsは使い勝手が違う。: Vivaldiと同様、アドオンの仕様が微妙に違う?
      • KeePass対応: アドオンKeePass Helperで対応
    • × メモリ使用量: 多い: 4タブで1.5GB
    • その他
      • モダン
      • "Rewards"(広告を出せばお金?)など、いろいろ押し付けがましくて鬱陶しい
      • 使い勝手は「劣化版Chrome」。

せいぜいOpera(メモリ使用量が多い)だが、ChromeやVivaldiよりいい点はなさそう。
→ 結局、全部駄目。どれも「劣化版Chrome・Firefox」。

  •   0
  •   0

ツイッターの休眠アカウント削除が、死んだ人のツイートを保存すべきだ(という「意見」)から延期になった件。

僕に言わせれば、ツイッター社は甘過ぎだろう。「いつからツイッター社は慈善事業になった?」だ。

故人のSNSなどの資産に価値がないとは言わないけど、そういうのは、残したい人がやるものだ。それができない(技術的に不可能の意)のか? 僕には、できるのに文句を言って、ツイッター社に重荷を負わせているだけのように見える。

(11/29 7:53追記) 寝ながら思い付いた。「アーカイブプラン」とか言って、有料で、退会した(する)とか死んだ人(「有志」が払う)のツイートを保存するようにすればいい。でも、実際にやると、「金取るのか?!」とか、非難轟々なんだろうな・・・ それに、本人が消したかったものを赤の他人が残せるってのも問題がありそうだから、せいぜい家族か。

まあ、ツイッター社のそもそもの失敗は、(僕は知らなかったが)ツイートを全部記録しておいて無限に見られるようにしたことだ。過去一か月までとか個数限定にして(期間とか個数でお金を取るのも良かったね)、それ以上は消えるようにしておけば、こうはならなかったものを。"tweet"って単語にはそういうイメージがあるから、その方が自然だ。それに、そういう仕様の方が、ある時誰かに昔のを引っ張り出して来られて、思わぬ惨事を招くこともなくなるからいいだろうw 要は「策に溺れた」ってこと?

 

PS. Googleなら、彼らの都合でスパっと切り捨てるだろうが、それはいいの?? 逆に、著名人のアカウントなどで「ツイッター社にすごく利益があるから残す」ってのは(、きっと叩かれるだろうが、)まっとうだろうと思う。

PS2. 誤解(する人は居ないと思うけど)のないように書けば、僕は営利事業がいいとか悪いとか、それに従っていればいいとか言うつもりはなくて、営利企業にタダ乗りして言いたいことばかり言うのはどうかと思うとか、そんなに寄りかかったら、全体的な終わりが近くなって、却ってみんなの不利益だろうって気がしたのだ。まあ、僕は(無料サービス全般について)そこまで想定して、いつ終わってもいいように、依存せずに使っているからいいけど。

(11/29 7:53 追記と少し修正)

  •   0
  •   0

昔から、サポートには喜怒哀楽している(というか、怒ることが多い)。近頃の体験から思ったことを並べてみる。

  • rclone (クラウド対応バックアップソフト。rsyncのクラウド版)
    • 書けば話が通じるし、試行錯誤しながらもちゃんと対応してくれたので、なかなかいい感じ(海外のフリーソフトで時々ある、マトモな対応。昔はこういうのが多かったのだが・・・)。
  • REW (音響特性測定ソフト)
    • いかにもイギリス人らしく※なかなか頑固で、こっちの不満・不便や作りがおかしい点を何とかする気はなさそうで、自分の作りたいものを作っている感じ。 (※雰囲気がMusicBeeの人に似ているのでそう思った。なお、単語の綴りからイギリス人だと思っているが、実際は違うのかも知れない。)
  • duplicacy (クラウド対応バックアップソフト。rcloneとは若干階層や方式が違うというのか)
    • 結構前に僕が出した時はそうでもなかったが、フォーラムを読む限り、サポートには余り熱心でなさそうな感じ(海外のフリーソフトで良くある、ちょっと冷たい対応。近頃は多い)。
    • フォーラムの過去ログに僕のところでも起こった問題が載っていて、「新バージョンにすればいい」などと書いてあったが(この時点で大抵眉唾だw)、実際には更新しても直らず、暫定対処(僕と同じことをしていた)で誤魔化したのに放置されていた(聞いた人がそれで引き下がったせいもあるが)。それが、どうして気付いたのか、今日コソッと対処されていた(別件かも知れないので、直るかは怪しい)。
  • 千葉の国際空港辺りの楽器関連販売会社 (営業妨害とか言われるのが嫌なので、名前は出さない)
    • (今後の状況によるが、)最悪に近い。故障したオーディオインタフェースを返送しても、「届いた」なんて連絡はなく、数日経っても状況の連絡がない(電源が入らないのだから、確認は一瞬で終わるはずだが)。
    • 評判を検索すると、最低一か月は掛かるとか、こっちから催促するまで放置とか、「再現せず」で着払いで返送されることまであるそうで、あるサイトでは「もう使わない」率が4割近いありさまだ。
    • 今にしてみれば止めておけば良かったが、どうなることやら・・・

 

(12/15 9:59) 千葉の楽器関連販売会社のその後

一週間経っても連絡がないので聞いたら、現象が再現してパーツ交換するとのこと。取り寄せのため、数週間掛かるとのことだったが、一週間くらいで送られて来た。発送される時も連絡はなかったので、その後「再現せず」扱いになって着払いではないかと心配していた。故障の詳しい原因は伝えて来ず。この会社はコミュニケーションを粗末にしているのか、余りにもブラックで連絡する時間すらないのだろうか。

「安いなり」とか結果的には問題なかったのかも知れないが、余りにも世間の常識から外れるとか客に不安を抱かせるような会社とはもう付き合いたくない。

  •   1
  •   0

午前中は血圧で内科に行った。血圧は定常状態で、非常に簡単な診察だった。血圧の値すら聞かないのは手抜きのように思えるが、もしかしたら、顔色を見ただけでいろいろ分かるようなすごい人なのかも知れない。あるいは、単に、月曜の朝で混んでいて面倒なのか(前回も同様だったので、今回は週明けを避けようと変更しようと思っていたのだが、面倒だったので止めた。でも、次回はそうした)。いずれにしても、僕は自分で管理していて、おかしかったら自分から言うから、大きな問題ではない。いつものように明るい医院で良かったのだが、なぜか妙に疲れたので、昼食後に少し寝た。

それで、午後に行こうと思っていた耳鼻科(耳の不調の件)は延期しようと思ったのだが、延々と延ばしていたので、頑張って行った。数年前に行ったきりだったので、すっかり場所や勝手を忘れて居たが、受付の方に見覚えがあって、雰囲気もその人らしくて懐かしかった。顔がどことなく鳥居みゆきに似ている(でも、あそこまで変ではないw 単に、色白とか顔の形が似ているとか美人的なだけなのかも知れない)。あと、雰囲気が大昔の知り合いにどことなく似ていたのも、良かった。

聴力検査*をしてもらったところ、左耳の低域の聴力が落ちていた(確かに、他より長く音が聞こえず、なかなかボタンが押せなくてちょっと焦った箇所があった)。ただ、病的というほどではないとのことで安心した。そのグラフは、以前測定した時却下したものに似ていた。ただ、そこまで曲がっておらず、中高域はその時の仮のオージオグラム2のように平坦で、左の最低の音(おそらく、125Hz辺り)だけ低く、20dBの「正常な線」より少し下がっていたから、以前の測定の後に状態が変わったのかも知れない※。

*ちなみに、聴力検査装置の防音は結構ちゃんとしていて、無音の時は鼓動や呼吸の音が聞こえて邪魔だった。「お前らのせいで聞こえなかったらどうするんだ」って感じだったw

※その投稿では右の聞こえ方がおかしいとあるが、実は左のせいだったのか、やっぱり状態が変わったのか。

結局、メニエール病ということで、以前罹ったものが再発したようだ。そう言えば、その医院には数年前に行ったのだが、その時も耳鳴りだった(すっかり忘れて居た)とのことだから、そういう火種はあったのだろう。あと、耳閉感は左右の聴力の差によるらしい。おそらく、夏に就職活動だの退職だので疲れたあとで、オーディオの配置で更に疲れ、しかも、悪い音に曝露したのが原因ではないかと思う。

なお、医師や看護師さんに、オーディオの配置とか「悪い音ガー」とか言ってもまず理解されないと思ったので、言わずにおいた。

ここは朝の内科とは違って、(コスプレじゃなく)至って普通ではあったが、受付の方や看護師さんが丁寧で良かった。あと、年始めに行った眼科のように、診察室に助手だか看護師さんたちがずらっと並んで居た。依然としてその理由は不明だし、僕は余り好きではないが(恥ずかしいとかいう訳ではなく、意味不明なのが嫌なのと、なんか無駄な気がするのだ)、まあ、そういうやり方があるのだろう。

そして、久し振りに、「まずい」と定評の薬(メニレットゼリー)を服用することになった。でも、僕は全然余裕で、(八名さんのように)おかわりできるくらいだw ブラックコーヒーを少し甘くした感じ、あるいは、コーヒーゼリーをちょっと苦くした感じで、もっと苦くたっていいくらいだ。それより、薬が一気に4種類に増えたのが面倒だ。飲み忘れないように、PCに定期的に「予定」を作った。

短距離だったが、久し振りの車の運転が とても気持ち良かった。耳鼻科に定期的に通うことになったので、乗る用事ができたのは好都合だ。

帰宅してから、なぜか耳の調子が良い。久し振りに、曲が綺麗に(しかも、耳閉感が起こらず、疲れもせず)聞こえるのがうれしい! 少し休ませたせいか、病名や原因が分かって安心したせいか、車に乗って気分が良かったせいか、医院のはしごで元気が出たせいか?w

 

PS. カテゴリ名と親子関係を、以下のように変更・更新した。

  • 高血圧? → 高血圧
  • 突発性難聴 → 耳の不調 (+「過去の話題」の子からトップレベルへ)

PS2. 低域の聴力が低いということは、バスレフポートを調整したら低音がわずかに減った(「すごく」はなくなった)ように感じたけど、実はそれでも充分なのかも知れない。いずれにしても、状態が落ち着くまでは余計なことを考えない方がいいだろう。

  •   0
  •   0

人でなく電気・電子機器やコンピュータ関連の話だが、「相性」の問題は確かにあるようだ。正確には「ないとは言えない」だし、実際にはもっと正確な表現はあることが多いと思うが。

単に「相性」と言ってしまうから、原因が伝わらず、謎に包まれて、多くの人が思考停止して納得したり、逆に訝しむ人が出るのだ。実際にはちゃんとした原因があって、もっと正確な表現があるはずだ。ただ、それを簡潔に分かりやすく説明するのが難しいから、「相性」と言うのだろう。もちろん、言う本人が原因を分かってなくて、「相性」と言えば素人を誤魔化せそうだからそうしている場合もある。世の中ではそれが多いのかも知れない。

先日、使う機器によって測定結果の超低域が増えるあるいは減る問題を「相性」と書いたのは、まさにそれだった。そして、上に書いたように、原因が分かっていない。「原因が(分からないのでなく、)ピンポイントで突き止め切れなかった」と言うのが正しいが、まあ、似たようなものだ。

以下にその経過と仮の結論を書く。

現象

オーディオ再生系の周波数特性の測定に使う機器が違うと、超低域(40Hz付近)の振幅が変わる。現在の測定結果(現在の測定系を使用)は昔の測定結果(昔の測定系を使用)より3dB程度大きい。

原因の候補

  • マイク(Dayton Audio EMM-6)の劣化 (劣化して低域が増加するとは考えにくい)
  • 昔の測定系
    • マイク電源(Behringer PS400)の特性 (最初は候補に入っていなかった)
    • マイクアンプ(オーディオテクニカ AT-MA2, 以下、「旧マイクアンプ」)の特性
    • サウンドカード(ASUS Essence STX II)の特性
  • 現在の測定系
    • オーディオインタフェース(Focusrite Scarlett Solo 3G, 以下、"Scarlett")のマイクアンプの特性

調査と結果(概要)

  • サウンドカードのライン入力にテスト信号を入力して、特性を測定した。 → 問題なし。
  • Scarlettのライン入力とマイク入力にテスト信号を入力して、特性を測定した。 → どちらも問題なし。
  • 旧マイクアンプにテスト信号を入力して、特性を測定した。
    • Scarlettのライン入力に繋いで測定した場合 → 問題なし(低域はほとんど下がっていない)。
    • サウンドカードのライン入力に繋いで測定した場合 → 低域が下がった(40Hzで2dB程度)。
  • 昔の測定系と現在の測定系でスピーカーの音で特性を測定し、比較した。 → 昔の測定系では低域が減少した(40Hzで約2.3dB)。
  • マイク電源にテスト信号を入力して、特性を測定した。 → 外付けの直流カットコンデンサの容量によって特性が変化した。
    • ここまでで候補が出なかったので、新たに検討した。
      • 実際には旧マイクアンプ-サウンドカード間で現象が出ていたが、最初に気付いた3dBには足りないので、他にも要因があると思った。
    • マイク電源の回路を見てみたところ、単純にコンデンサ(47μF)で直流カットをしているようなので(→ 類似の回路: 基本的にはこれの上側と同様。ただし、2種類の電圧(12, 48V)用の回路が並列に繋がっている)、その影響を疑った。
      • 測定の前に、直流カットコンデンサとGNDへの抵抗でCRハイパスフィルタになっていると考えて、特性や定数を求めても(→ 計算ツール)、なかなか腑に落ちるものにはならなかった(47μFで40Hzをカットオフ周波数にするには、R(100kΩ)が大き過ぎた)。
    • 入力端子には電圧(48V)が掛かるから、そのままサウンドカードの出力端子に繋ぐと壊れる可能性があるので、まずは電源offで測定した。 → 問題なし(低域はほとんど下がっていない)。
    • 次に、マイク・電源間にコンデンサを入れて電圧をカットして測定した。 → コンデンサの容量によって特性が変化した。旧マイクアンプ経由でサウンドカードに入力した場合、20uFでは40Hzで2.6dB減少した(容量が小さいと、減少度はもっと大きくなる)。
      • コンデンサの影響が出るのでしたくなかったのだが、上で変化がなかったので試した。

測定結果のまとめ

  • サウンドカード → サウンドカード(ライン入力): 問題なし → サウンドカード単体では問題ない。
  • サウンドカード → Scarlett(ライン・マイク入力): 問題なし → Scarlettには問題ない。
  • サウンドカード → 旧マイクアンプ → Scarlett(ライン入力): 問題なし → 旧マイクアンプ単体では問題ない。
  • サウンドカード → 旧マイクアンプ → サウンドカード: 40Hzで2dB程度減少 → 旧マイクアンプとサウンドカードの関係に問題あり?
  • 昔の測定系と現在の測定系でスピーカーの音で特性を比較: 昔の測定系では40Hzで2.3dB程度減少(問題の現象(3dB減少)に近い) → マイクは劣化していない。
  • サウンドカード → コンデンサ → マイク電源(48V on) → 旧マイクアンプ → サウンドカード: 超低域が減少(コンデンサの容量による) → 旧マイクアンプの入力条件によっては問題がある?
    • マイク → マイク電源 → 旧マイクアンプ → Scarlettでは40Hzで1dB未満減少する? (現在の差は2.3dBなので、ほとんどなさそう)
    • マイク → マイク電源 → 旧マイクアンプ → サウンドカードでは40Hzで3dB前後減少する?

※マイク電源からScarlettのマイク入力に入れて測れば、マイクとマイク電源間の状況が分かったかも知れないが、Scarlettが故障したので今はできない。

仮の結論(推測)

  • マイク、マイク電源、旧マイクアンプ、サウンドカードそれぞれの間の結合状況(例: 直流カット処理やインピーダンス)によって低域が減少する。減少度が一番大きいのは、旧マイクアンプとサウンドカード間。
    • マイク → マイク電源 → 旧マイクアンプで1dB未満旧マイクアンプ → サウンドカードで2dB前後、それぞれ減少し、合計3dB前後の減少となるのではないか。(いずれも40Hzにて)
    • なお、旧マイクアンプとサウンドカードの入出力インピーダンスは公開されていない。
    • また、旧マイクアンプの周波数特性(仕様)は20Hz-20kHz -3dB、サウンドカードは10Hz-90KHz -3dBなので、充分にそれらの範囲内なのかも知れない。ただし、サウンドカードの入出力を直結した場合や旧マイクアンプをScarlettに接続した場合には低下しないので、「相性」の問題ではある。
  • Scarlettは問題ない。

その他

  • マイク電源は予想外に大雑把な作りだった。
    • 直流カットはコンデンサのみで行っており、アンプなどの能動素子は使っていない。
    • 2種類のマイク電源電圧(12, 48V)出力をスイッチで切り替えるのだが、それぞれの電圧を掛ける2つの回路がマイクの信号経路に並列に接続されていた。
      • そのせいで、パターンを追って回路を調べる時に戸惑った。
      • Off側の影響はないのかと思うが、分からなかった。
      • 個人的には2つの電圧で同じ回路・配線を使う(使えるように工夫する)方が綺麗でいいと思うが、そこは国民性なのか設計者の思想なのか。
    • それでも、マイク接続時の超低域の低下は1dB未満と推測される(しかも、これは電源と旧マイクアンプとの関係によるものが大きそうだ)ので、実用上は問題なさそうだ。
      • これは、マイクの静電容量が小さいとかインピーダンスが高いことと関係があるのかも知れないが、分からない。
  • 10uF程度のコンデンサでも、充電状態で端子をショートすると、「パチッ」と音が出る。びっくりした。
    • 耐圧(35V程度だった)を良く調べずに使ったので、それで壊れたのかと思ったが、幸い、膨らまず、煙も出なかった。
  • そもそも、数値的には3-4dB(約1.4-1.6倍)で、客観的にはすごく大きい訳ではないのだが、共鳴で強調された音が耳に悪さをしているのではないかと考えているし、超低域はいかにも耳にガツンと来そうなので、そういうちょっとした増加も気になって調べた。あと、グラフで見ると結構大きくなっているように見えることもある。それに、1.4-1.6倍といったら「50%増し」なので、本当に影響が大きいのかも知れない。

(11/24 12:41 若干加筆・修正)

  •   0
  •   0

前の投稿に書いたように、USBオーディオインタフェース(Focusrite Scarlett Solo)の超低域の特性が気になったので、いろいろ測定していたら、突然、お亡くなりになってしまった。

知らないうちに電源が切れた後、もう入らなくなった。USBケーブルを繋ぐと一瞬ランプは点くが、消えてしまう。ケーブルの交換などいろいろ試したが全部駄目だったので、店に連絡した。電源ヒューズのようなものが切れたのだろうか? 本当に、「何もしてないのに壊れた」のだ。

まだ3か月経ってないのだが・・・

いつもの僕なら、たとえ見ても何も分からなさそうでも箱を開けるが、この製品はネジがゴム脚の下に隠されており、剥がすと保証が無効になりそうなので、止めた。「だったら、壊れないようにしろっ!」て言いたいが、開けても手が出せないから仕方ない。

調べたら、機種は違うものの同様に壊れた方が居るようで、C国製で歩留まりが悪いのだろうか? でもまあ、今や「日本国製だからいい!」なんて言ったら情弱の時代だがw

初期ロットでたまたま外れだったのならいいが、交換品もやっぱり駄目になったら送料や手間がかさむので、ちょっと考えるなあ・・・ でも、買い直すよりは送料の方が安いか。保証期間(3年)中に10回くらいまでなら、壊れても大丈夫そうだw ただ、平均2か月で壊れるとすると、ちょっと足りないかも知れないwww

(11/22 19:21) 送料は着払いだったので良かった。ただ、現象が起こらないなどの場合は、着払いで返送されるそうなので心配だ(それを想定して、なるべく小さい箱で送ったw)。あと、「Linuxはサポート対象外」などと言われて、それはもちろん分かっていて、それを想定してサポート依頼を書いたのだが、もしかしたら、「Linuxに繋げたせいで壊れたから、保証対象外」などと言われるのではないかと、ちょっと心配してる。余計なことだった。相手が「分かっている人」ならいいのだが、最初の回答がそうでなかったので、心配になった。

ちなみに、受け取りに来た運送会社の人は、うろ覚えながら購入時に配達に来た方のようで、顔や雰囲気が どことなく最初の会社に居た派遣の方を連想させたせいか、僕にしては珍しく、気安く少し砕けた話し方をしてしまったw

 

PS. いずれにしても、3年保証の店にして良かった。受け取りには難儀したがw

  •   1
  •   0

これは以下の投稿の完結編です。

やっぱり、「無料のランチ」はないようです。最初の投稿では「ある」と豪語しましたが、撤回します。未完成の投稿は、補足・修正・訂正しました。 (11/22 12:48)


結論・結果

聴く位置を動かすのもスピーカーの位置を動かすのも副作用(特に共鳴)が大きくて駄目なので、元に戻した。

概要

僕の部屋は共振がひどくて、元々の位置(出窓にスピーカーを設置)以外は使い物にならないことが分かった。問題になった周波数は、例えば40, 60, 90, 143, 450Hz(いずれも付近)などと多い。それらの周波数で共振(共鳴)による強調(山)や干渉による減衰(谷)がある。更に、500Hz以上の高い周波数でも、机の天板や天井や床面での反射による干渉による減衰がある。すごく手強い、というか、ほとんど手に負えないことが分かった。

最初に聴く位置を動かした時に音が良くなったように感じたのは、気のせい(プラシボ効果)か、元の場所より共鳴が強くなって音の構成が変わったためではないかと思う。その時点では「おかしな音」に曝露した時間が短かったせいか、まだ耳に影響はなかったが、スピーカーも動かしたら更に共鳴が強くなったせいか、耳閉感が出てしまった(疲れのせいもあって、今でもまだ調子が悪い)。

イコライザを調整して、共鳴で強くなっている箇所を下げてみたが、下げ切れないのか、下げ過ぎあるいは下げる箇所の数が多過ぎて音が劣化するのか、やっぱり耳閉感が起こった。更に、使用するイコライザの種類(適性?)によっては耳痛も起こり、耳の問題は解決できなかった。この時点で完全に駄目になってしまった感じだった。

調整が少なくて済むよう、共鳴がマシな場所・配置を探してみたが、見つからなかった。シミュレーションアプリはあてにならず(なぜか、共鳴の山が余り出ない。反射率の設定が関係しているのかも知れない)、部屋の見取り図を描いて、駄目そうなところを避けて良さそうなところ(配置)を数箇所試したが、測定したら一番問題の143Hzが駄目だったので、元の場所より良くなることはないと判断して諦めた。

試したことと結果

  1. 聴く位置(椅子と机)を後ろにずらす。 → 最初は良かったが、長時間聴いたら耳閉感が起こっただろう。
    • スピーカーとの距離が増えて音が遠く感じたので、スピーカーを近付けようと思った。↓
  2. スピーカーを手前にずらす。 → 耳閉感が起こって駄目だった。
    • 使っていなかった本棚を横に倒して載せ、30cm程度手前に移動した。
    • スピーカーが近過ぎるせいで耳閉感が起こったと推測し、スピーカーを少し離して試すことにした。↓
  3. スピーカーを少し奥にずらす。 → 耳閉感は治まらなかった。
    • 本棚と出窓を併用し、20cm程度奥に移動した。
    • 聴く位置を後ろにずらしたことが良くないと判断し、全く新しい配置を試すことにした。↓
  4. 全く新しい配置にする。 → 窓際の数箇所を試したが、一番問題の143Hzの共鳴が改善することはなかった。
    • どうしても無理なことが分かって、諦めた。↓
  5. 元々の配置に戻した。 → 耳閉感はほぼ治まった。
    • それでも、場合(曲や調子による?)によって耳に違和感が起こるので、以前耳痛の起こったイコライザを使っている超低域カットフィルタ(low shelf, LS)が悪いのかと思い、イコライザでなくバスレフポートで調整できないか試すことにした。↓
  6. バスレフポートの調整 → 概ねOK
    • 全閉(付属のスポンジ使用)にしても聴感上は問題なかったが、なるべく低域の減少を減らしたかったのと、背圧を抜いたほうがいい気がした。
    • 細長く切った段ボールを巻いて、小さい穴の開いたプラグを作った。穴の直径が約1.3cmの場合(元の直径は約4cm)、(20から)65Hzまで、上記5で追加したLSフィルタとほぼ同等の特性が得られた(→ グラフのピンク)。
      • なお、ポートの形状と共振周波数の関係(ここを参照した)より、穴の径の増減はそれほど感度が高くないようだ。半分などにしないと、特性の変化は目立たなかった。
    • 聴いて試したら、耳閉感はほとんど起こらなかった(音作りのせいか、曲によっては危ない、あるいは、わずかに起こった場合があった)。また、耳痛は起こらなかった。
    • 低域に不満はなく、全般的に(特に高域は)ストレートな音に聞こえる。
    • これはまさに「ナチュラルフィルタ」だ。

(元に戻したのだから当然なのだが、)ようやく耳閉感や耳痛が解決し、音質にも満足できているが、音が余りにもストレートとかダイレクトで、曲の音作りによっては疲れることがあるので、気軽に聴くための「デチューン設定」(低域と高域を下げる?)はあったほうがいいかも知れない。ただ、逆に悪化する可能性はある(上記1か2の後にそれをやろうとして耳痛が始まった気がする)。。。

「だったら、もっとテキトーに調整(妥協)すればいいじゃん」と言われそうだが、僕としては、まずは「ちゃんとした音」(原音に近い音)を耳の手前まで届けることが基本・大前提で、その後で、状況や好みに合わせて調整すべきというスタンスだから、(たとえ疲れても、)可能な限りいい特性に調整する意味はあると考える。

前に書いたかも知れないが、水が(味付きでなく)無色透明、無味無臭の「普通の水」として入手できないと困るのと一緒だ。

調整後にストレートに聞こえるようになったのは、イコライザの設定を調整したためか、バスレフポートの調整で不要な超低音が減り、それが中高域に影響を及ぼさなくなったためか、やっぱり気のせいかw

特性の測定結果、イコライザの設定など

各配置の特性の比較(イコライザでの補正前)のグラフを以下に示す。すべてのチャネルを表示するとグラフが煩雑になるので、左チャネルのみを示す(なお、右チャネルは143Hzの共鳴が左よりひどい)。同様に、配置による差異が顕著な周波数帯域(30-500Hz)だけを表示する。

  • グラフ1: 元(変更前)の状態(青), 聴く位置を後ろに45cm移動(緑), スピーカーを手前に(30cm程度)移動(赤)
    • 聴く位置を後ろに移動すると(緑)、共鳴によって143Hzの山が高くなった(そればかりか、他にも共鳴ができた)。一方で、低域が増して60Hz付近の谷がなくなった(そもそも今回の作業は、この低域の補完を狙ったのだ)。
    • スピーカーを手前に移動すると(赤)、143Hzの共鳴は悪化し、低域(80Hz付近)も悪化する。
  • グラフ2: 元(変更前)の状態(青), スピーカーを手前に(30cm程度)移動(赤), スピーカーを少し(20cm程度)奥に移動(ベージュ)
    • スピーカーを少し奥に移動すると(ベージュ)、聴く位置を後退しただけの状態や元の状態に近くなるため、143Hzの共鳴は改善する。
  • グラフ3: 元(変更前)の状態(青), 新しい配置の試行(朱: 「窓際2」)
    • 窓際への設置(朱)は、143Hzの共鳴がかなり悪化することが分かる。超低域の共鳴らしきものも良くない。
  • グラフ4: 元(変更前)の状態(青), 元に戻して(緑), バスレフポートの調整後(ピンク)
    • バスレフポートの調整によって(ピンク)、超低域が幅広く(40Hz付近で6dB程度)下げられていることが分かる。

結局、元々の設置状態が一番まともだったと言える。

最終的な補正後の特性(左図: 主要部)とイコライザの特性(左図: 上部)と設定(右図)を以下に示す。

結局、問題の60Hz付近の谷は解消できていないが、今のところ、どうにもならない。ここを我慢するか、埋める代わりに他(例: 143Hz)の共振をひどくするかの選択となり、総合的に、特に耳との相性を考えると、前者の方が得策だと判断した。

今気付いたが、最初に試した、聴く位置を後退させて60Hzの谷を埋めつつ、(今の)バスレフポートで超低域を減らす構成なら143Hzがそれほど大きくならないから、結構いいかも知れない。しかし、80Hz付近は逆に悪化するし、音が遠くに聞こえる問題があるし、なかなか体力と気力が追いつかないので、保留する。

また、右チャネルのイコライザのフィルタ数が4個と多いのが気に入らないが、減らす(高い方の2つを1個にまとめる)と、共鳴を減らしきれないせいか、今一つ耳との相性が悪いようなので(耳の調子によるのかも知れない)、この設定にしている。高い方2つの減衰量は小さいのだが、他のフィルタと重なることで効果があるようだ。

配置を変えて良くなったと思った曲を改めて聴いてみて

配置変更後と戻した今で、同じ曲を数曲試した結果を示す。

試した条件の記号

  • 「後退」: 聴く位置を後ろにずらした後
  • 「本棚」: スピーカーを手前に動かした後(横に倒した本棚に載せた)
  • 「戻す」: すべての配置を元に戻した後

比較結果

  • The Knack: "My Sharona" (Spotifyにて)
    • 後退: 左の音の小さいギターが初めてちゃんと聞こえた!
    • 戻す: (後退がどれを指しているか分からないが、中央辺りから始まるものとする) 左の音の小さいギターは他の音に混ざってしまって、今ひとつはっきり聞こえない。
  • ビートルズ: "Strawberry Fields Forever - Remastered" (Spotifyにて)
    • 後退: イントロの笛がリアル。エコーの掛かったドラムも。
    • 戻す: イントロの笛もエコーの掛かったドラムも聴き慣れた感じで、特にリアルさは感じない。
  • ビートルズ: "Abbey road" [2009 remaster]
    • 後退: [全体的に] 中高音(例: ギター)がクリア・リアルになった気がする。
    • 本棚: "Here comes the Sun"や"Sun King"などで低音が弱い感じ。
    • 戻す
      • Come together: 聴き慣れた感じ。クリア・リアルさが増したとは感じない。
      • Here comes the sun: 低音が少し厚目な感じ。アコースティックギターがいい感じ。
      • Sun King: バスドラの低音は弱い(これは曲(音源)自体の問題)。
  • YMO: "Solid state survivor"
    • "Absolute Ego Dance"
      • 後退: 頭の音のキレがすごい。バスドラもいい。ちょっと身体に響く感じ。
      • 戻す: 頭の音のキレは「すごい」とまでは行かない。バスドラは身体に響くとは言えない。
    • "Rydeen"
      • 後退: イントロも、今までになくいい。低音が分厚くなった感じ。
      • 戻す: イントロは聴き慣れた感じ。低音は少し厚い感じ。音の押し出しは強い。

配置を戻したら、変えた後に良く聞こえた感じはほとんどなくなって、元の聴き慣れた音に戻っている。元に戻したのだから当然なのだろうが、変更後に良く聞こえたのは、実は良くなかったのか本当に良かったのかは不明だ。ただ、気のせい・思い込みや共鳴での強調による影響はあったと思う。それとは別に、「戻す」を試した今日(11/20)は耳の調子が悪いせいもあって、それほど良く聞こえないのかも知れない。

改めて比較して意外なのは、自分の印象がそれほどブレない(配置を戻せば元の聞こえ方になった)ことが分かったことだ※。ということは、配置変更後に音が変わって聞こえたのは、気のせいばかりではなく、(良し悪しは別として、)音の成分・構成が変わっていたことによる影響があったと考える方が良さそうだ。

※とはいえ、記録していた曲・箇所とは別に、やっぱり、元に戻したあとに聴いた曲で「初めて聞こえた」のような感想はいくつも出た。だから、正直なところは良く分からない。。。

設置について分かったこと

  • 定在波の観点では、スピーカーは壁の近くに置いた方がいい。
    • この部屋では、スピーカーも聴く位置も出窓と壁に近くまとめた方がいい。
  • 部屋には、網の目のように定在波による共振(腹)と干渉(節)があるようだ。
  • 部屋を横より縦に使うほうがいい。
  • 部屋の中央はどうしても駄目。
  • 「38%ルール」(→ 参考)は結構当たっている(ただし、生活との共存には無理がある)。今までは中央付近が一番いいと思っていたが、そうではないようだ。コンサートホールではどうなのだろうか?
  • 机も結構影響があって、良くない。
  • +20dBなどという山は調整不可。破綻している。
  • この部屋では、クローゼットの扉を閉めると全然駄目。扉での反射が強いようだ。

山・谷と原因の推測

この部屋は周波数特性の山・谷が非常に多い。L, Rの次は周波数(Hz)、「(谷)」以外は山、周波数の次は波長(m)、最後に推測した原因を示す。太字は特に強い(鋭い)ところである。

  • L: 42: 8m → 4m= 横?
  • R: 55(谷): 6.2m: ?
  • L: 61(谷): 5.6m: 奥行き(出窓込み)?
  • LR: 68: 5m → 2.5m= 上下?
  • R: 80(谷?): 4.3m= 横(クローゼット込み)?
  • L: 84(谷?): 4m= 横(クローゼットなし= 3.9m)?
  • R: 85: 4m= 横(クローゼットなし= 3.9m)?
  • L: 93: 3.7m: → 1.85m?
  • R: 111(谷): 天井での反射(経路差= 3.1m)
  • R: 125(谷): 床での反射(経路差= 2.7m)
  • LR: 143: 2.4m → 天井(2.4m)
  • LR: 175: 1.9m → 3.8m= 横?
  • LR: 226: 1.5m= 出窓の幅
  • R: 285(谷): 1.2m → 天井(2.4m)?
  • R: 332: 1.02m= 出窓の高さ
  • R: 380(谷): 89.5cm (94Hzx4?)?
  • LR: 450: 75.5cm → 38cm, 1.5m= 出窓の幅(1.54m= 221 → 442Hz)?
  • L: 530(谷): 64.1cm: 机の天板での反射(593Hz(経路差= 57.4cm)が少しずれて出ている)?
  • L: 586: 58cm: 机の天板での反射(593Hz(経路差= 57.4cm)が少しずれて出ている)?
  • R: 573(谷): 59.3cm: 机の天板での反射(593Hzが少しずれて出ている)?
  • R: 610(谷): 55.7cm: 机の天板での反射(593Hzが少しずれて出ている)?
  • L: 687(谷): 49.4cm: 出窓の幅(226Hzx3)?
  • R: 1.4k(谷): 24.2cm: 机の天板での反射(530Hzx3)?
  • R: 1.5k(谷): 22.7cm: 机の天板での反射(530Hzx3)?
  • L: 1.6k(谷): 21.2cm: 机の天板での反射(530Hzx3)?

※反射の計算はFloor/Ceiling Reflection Calculatorを用いた。

原因はどうであれ、山・谷が多いことは確かで、それらを全部補正することはできない。しようとしたら、フィルタが多くなり過ぎて音が悪くなる(鮮度が悪く聞こえたり、耳が痛くなる)。もちろん、フィルタで(増幅して)谷を埋めようなどと思ってはいけない。なので、できるだけ「いい位置」を探し当てることが重要だ。

耳の問題の原因を推測

今までの経験から、以下を推測している。

  • 耳痛、「刺さる」感じ: イコライザの種類や設定の問題?
  • 耳閉感: 強過ぎる超低域、共振での大振幅(特定周波数の強調)、イコライザの設定の問題?、耳の不調
  • 耳鳴り: 耳の不調

その他

  • 定在波と対処の方針については、このページが一番わかりやすかった。
  • 低域の共鳴は人体の影響で1-2dBくらい強まるようだ(聴感ではもっと大きくなるように聞こえたが、移動して聴く位置が変わったせいがあるのだろう)。

まとめ

一か月近くの悪戦苦闘の結果は、最初に書いたように、「元の位置がベスト」だった。ただ、何も収穫がなかった訳ではなく、超低域(40Hz)の共振とその悪影響に気付いたのが良かった(今分かったのだが、新しくADCを導入する前は、マイクアンプの特性なのか、超低域が低目に出ていて、その分に気付いていなかった※)。

そもそも、僕の大きくないスピーカーでそんなに低い音が豊富に出せる訳がなく、共鳴で強調されていたのを「意外に出る」などと思っていたのが間違いで、その横(60Hz)の谷を埋めるのでなく、共鳴でできた山を削ってフラットに近づけるべきだったのだ。最初に聴く位置を動かして60Hzの谷が埋まったのは共鳴に近かったのかも知れないし、その場所では40Hzの共鳴が更にひどかった。

※今ちょっと不安になったのは、実は、新しいADC(Scarlett Solo)のマイクアンプが超低域を強調していることはないのかということだ。でも、さすがにそれはないと思う。いずれにしても、あとで測ってみたいが、可能なのだろうか?

(11/21 21:53) 可能な範囲で調査・測定したところ、Scarlettには問題なく、それ以前に使っていたマイク電源(Behringer PS400)とマイクアンプ(オーディオテクニカ AT-MA2)とサウンドカード(ASUS Essence STX II)に原因がある可能性が高いことが分かった。

詳しくは別に書きたいが、マイク電源は、マイクに掛けている電圧(48V)が出力側に出ないようにカットする仕組みが簡易なため(コンデンサを使っている)、言ってみれば「相性問題」が生じやすいのではないかと推測する。そして、電源に繋がっているマイクアンプの入力部も同様の仕組みで電源の影響を受けるのか、あるいは、コンデンサマイクのようなハイインピーダンスの機器は想定していないのか、やっぱり相性が悪いようだ。更に、サウンドカードも若干相性が悪い。これらが重なって、超低域が数dB低下していた(例: 40Hzで3dB前後)ようだ。

そして、超低域他の共鳴への対処のためにバスレフポートやイコライザを(再)調整したせいか、音が少し良くなった(変わった)気がする(例: 移動前より音のクリアさが増した気はするし、今まで気付かなかった音も聞こえる)が、やっぱり気のせいではないか。特に、「気付かなかった音」なんて今までも何度もあるので、聴くたびに新たな発見があるのではないか。そして、疲れのせいもあって、今でもまだ耳の調子は悪く、曲(音作りによるのだろう)によっては耳閉感が起こる。

それから、バスレフポートの穴の径の調整が効果的なことが分かった。超低域のlow shelfフィルタと同等の効果が得られた。イコライザで超低域の調整をすると耳との相性が悪いので、ポートで調整できたのは良かった。

という訳で、今回は負けだ。今以上に音質を良くすることは無理だ。

でも、これで終わりではないと思う。性懲りもなく新しいアイデアが出るかも知れないし、今回の失敗を忘れて同じことをするかも知れない。でも、すごく疲れたので、しばらくは休む。

 

... とはいえ、備忘録としてTODOを書いておく。

TODO(または「今後の課題」w)

  • 聴く位置を後退させて60Hzの谷を埋めつつ、バスレフポートで超低域を減らす構成を試す。
  • [済] Scarlett Soloのマイクアンプの特性を測定する(超低域を強調していないか?) (11/21実施済み。本文に追記した)

 

(11/21 21:53 超低域の低下の調査結果の概要を追記, 22:37 若干修正、完成とする。)

  •   0
  •   0

可哀想に、エリカちゃんも捕まってしまった。某押し売り放送局は時代劇の撮影をどうするか慌てているような話を読んだが、こういう時こそ、国民から巻き上げた金ででっち作り上げた最先端技術で解決すればいいのに。

彼らには美空ひばりを強制復活させた技術もあるではないか。今こそ実用する時だ。それに、全然詳しくないけどw、今は動画の顔をすげ替えるdeep fakeとかいう技術があって、手軽に使えるらしいではないか。

それにしても、番組に出演した問題のある人をどうしても消せない時に、モザイクを掛けることはあるだろうが、顔(声も?)をすげ替えて、(身体だけ)出演させるのは(視聴者に)許されるのか興味あるところだ。「けしからん」という人は、何に怒るのか。問題のある人をTVに出すことか、出演料を払うことか、そういう人は一切観たくないのか。(では、そういう自分は清廉潔白なのか? と書くと面倒になるので、今回は止める。)

でも、そもそも、誰にすればいいのか? あ、代役にすればいいのか。それならすごく適切だ。撮影が間に合わない分を処理すればいいのだ。

こういう考えが進むと、「もう、出演者なんて本物の人じゃなくてもいいや」って話にもなるのかな。架空の人はもちろん、死去してしまった人で完全にクリーンなことが分かっている人、あるいは、古過ぎて確認できない人なら、こういう問題は全く起こらないだろう。

 

PS. 全く余計なことだが、(今の)顔が似ているから、代役には鈴木京香(名前が出てこず、検索して分かったw)が良さそうだと思っていたが、年齢が2回りくらい違うから無理そうだ・・・ (11/18 17:49)

  •   1
  •   0

近頃はGDPRの関係で、ウェブページの下の方に(ほとんどは英語で、しかも読みにくい文字で)クッキーがどうのこうのと出ることが多いが、それが結構危ない気がしている。多少詳しい人は、良く読まずに「あ、例のクッキーね。いいよいいよ」とか思って"Accept"とか"OK"のボタンを押しそうだが、もし、その文章がクッキーとは全然関係ない、詐欺的な購入とか契約、あるいは、押すことを契機に個人情報を抽出するような仕組みだったら恐ろしい。

実は僕は、押さないと表示されたままで鬱陶しいし、いろいろなサイトで何度も決まった文章を読むのが面倒なので良く読まずに押していたのだが、近頃危うさに気付いた。

まあ、実際問題として、そんな悪質なサイトに行くだけでも危険なのだが、事前に分からないことは多いから、そのうち「情弱」と呼ばれてしまう被害者が出そうな気がしている。何もしないのと違って、自分で許諾ボタンを押したら言い訳しにくいからね・・・ 例えば、(英語の小さい文字で)「Acceptボタンを押すと、USD1000を支払うことに許諾することになります。その取り消しはできません。」とか書いてあったら怖いよ。言ってみれば、「クッキー詐欺」とか「GDPR詐欺」か?

という訳で、自戒を込めて、条件反射的にボタンを押すのは止めよう。

 

付録: GDPR opt-in(というのかな)のいろいろ

 

PS. 調べていたら、やっぱり、本質を理解せずに、「なんか自分のサイトの下の方に変な英語が出ていて邪魔だぞ」と、出しているのは自分で入れたプラグインにも関わらず、メッセージを邪魔者扱いして、必要かどうかを考えずに、単に消して満足しているサイトがあって、別の意味で危うい気がした。

「消したら問題がなくなると思うなんて、まるでどこぞの政府と同じじゃないか」と思った件については、一言も言及しないでおくw

  •   1
  •   0

「一体何なんだ」と言いたいが、前回の投稿の後、昨日から今日に掛けて更にトラブルが重なって起こった。

  • スマフォ(AQUOS sense lite)のアイドル時の消費電力率が増える現象が再発した。: 原因不明
  • 自宅とサーバのオンラインバックアップのエラー: 原因不明(「たまに起こる」としか言えない)・・・
  • サーバからの上記のエラーやその他の通知が、Gmailの迷惑メール判定で何通か届いていなかった。: 近頃、誤判定が増えた感じ。

スマフォの消費電力率の問題は今までにも起こっていて、何度も試行錯誤して直ったと思ったのに解決していなくてがっかりした。増えるといっても、長時間アイドル時に平均0.6%/h以下のものが1%/h近くになる程度なのだが、アプリ(My battery monitorなど)で見ると、アイドル状態なのにアクティブ率が100%のままで(= スリープしていない)下がらず、どうも気分が悪い。どうしても直らないようなら、定期的に再起動させようかと思う。が、再起動も電力を食うのでどっちが得だろうか?

オンラインバックアップの問題も今までにも何度か起こっていて、主な直接的な原因は、たまにバックアップソフト(duplicacy)の内部状態とストレージ(Backblaze B2)の状態が合わなくなることのようだ。起こる都度、暫定対処や様子見(再実行で直ることがある)をして来た。それで大きな問題はなさそうなのだが、本当に問題ないかが分からないのが怖い。

本当の原因はネットワークかバックアップソフト(自作+duplicacy)かストレージのどれかなのだろうが、どれかは不明だ。おそらくduplicacy(通信エラーに対するロバスト性が足りない)だとは思うが、サポート依頼を出すにも説明が困難ではある(でも、出せばスパっと分かってくれることもある)。エラーはサーバのバックアップで起こることが多いので、とりあえず、ネットワークへの送信速度を下げてみた。

Gmailの問題は初めて気付いた。今までにも迷惑判定で落とされたものがあるかも知れないが、仕方ない(「なんかおかしい」ということはあった)。たちが悪いのは、Gmailの迷惑メールはThunderbirdの迷惑メールフォルダには出ないことが多くて(出ることもある)気付かないことだ。Googleの商売のせいか、G Suite(有料版)でないと迷惑メール判定の強度調整(そういうのがあればの話)ができないようなので、落とすと困る差出人からのは迷惑メールにしないフィルタを登録してその場しのぎをし、更に、サーバからの通知メールはGmailに送らないようにした。

根本的な対処には、可能な限りGmailを使わない方がいいのだろうが、(アカウントの生成や破棄が)手軽で容量はふんだんだし、Androidには必須なので、根絶はなかなか難しい。。。 とりあえずは、重要な用途には使わない方が良さそうだw

あんなの飾りです。普通の人にはそれが分からんのですよ??

 

題は見直し中にSpotifyで掛かったより。(9:52)

PS. 更に、ついさっきはUbuntuの更新リポジトリの国内サーバにも接続できなかった。一時的なものだろうが、随分重なるものだ。 (8:42)

  •   0
  •   0