Archive for the ‘Linux’ Category

オーディオ系の改良、あるいは「作り直し」作業(主に耳への問題を改善しようとしている)は なかなかキリがなく、昨年末に書いたことの ほとんどが更新となっているうえに、新しいことも増えた。ちゃぶ台返しもあった。それでも、分かったことが少しずつ増え、耳にも良い方向に進んで居るので、そのうち終わりそうな感触ではある。

それにしても いろいろなことが あり過ぎて、今回も概略程度しか書けない。いつか、それぞれの詳細を書きたい(と書いておくw)。

 

サウンドカード(ASUS Essence STX II)のDAC部: カップリング回路

  • 出力のカップリング回路(下図を参照): 随分試行錯誤して代替カップリング回路("AltCC")を調整し、ようやく、「マイベスト」や「ファイナルアンサー」は東信のUPZというコンデンサを抵抗なしにした場合でありそうなことが分かった。
    • カップリング回路周りの概略
DACの出力 → カップリングコンデンサ ―→ ボリューム → アンプ
                                                  |
                                                (抵抗)
                                                  |
                                                GND
  • これまでに以下のような構成で試した。
    1. ASUSのオリジナルのカップリング回路("OCC")に、外付けのカップリング回路を追加(直列接続)
      • 「ちょっと試してみよう」の乗りだったが、意外に変化があったので、以下に繋がる・・・
    2. OCCを残したまま、DAC出力に代替カップリング回路(AltCC)を接続
      • この時は、OCCを残しておいても使わなければ(出力端子に接続しなければ)影響はないと考えていた。
    3. OCCを無効にしてAltCCを使用 (現在)
      • OCCでは抵抗でGNDに繋がっているために、弱いながらも電流が流れてDAC出力に影響があったので、OCCの手前で切り離して無効にした
  •  現在のAltCCの順位(耳に合う&音が良く感じる順)※
    1. ○ 東信 UPZ(0.22μF, 抵抗なし): 馴染める音。高域は丁度良い。
      • UPZだけは、試し始めた時から ずっと悪い印象がなく、せいぜい「地味」とか「華がない」のようなものだけだった。特性からは そういうことが想像できず、全く不思議なコンデンサだ。
      • カットオフ周波数: 約9Hz
    2. △ パナ ECHU(0.1μF, 抵抗なし): 音が いい感じはするが、高域が わずかに強目で派手な感じ。
      • カットオフ周波数: 約34Hz: 高いが、実用的には問題ない。
    3. △ パナ ECPU(1μF, 抵抗なし): 悪くはないが、高域が弱目で物足りなくなる。
      • カットオフ周波数: 約3.4Hz (測っていないので推定)
    4. △- ECPU/2(2個を直列接続 → 0.5μF, 抵抗なし): わずかに耳に問題が起こる。行けるかも知れないが、あえて選ぶことはない。
      • カットオフ周波数: 約7Hz
    5. △- ルビコン PMLCAPx2 (合計0.2μF, 抵抗なし): 少し耳が痛くなる(1個(下記)よりはマシ)。高目の帯域が近く聞こえた。あえて使う理由はない。 (AltFBCのついでに買ったものが届いたので、少し試した。: 1/24 18:00)
    6. 以下は不可(耳に問題(耳閉感など)が起こる)
      • ECPU(1μF)+20kΩ: 以前(アンプのフィードバックコンデンサが有効の時)は1-2番目に良い印象だった(今はECPU/2と同じくらいかも)。
        • 他もそうだが、なぜか抵抗を付けるのは良くないようだ。
        • カットオフ周波数: 約11Hz
      • ECHUx2(合計0.2μF, 抵抗なし): 少しキツい。少し前までは一番良かったのだが、確か、アンプのフィードバックコンデンサを無効にしたら(後述)駄目になった。
        • 試し始めた時は2-3番目くらいに良い印象だった。
        • なぜか、並列接続も良くないようだ。
        • カットオフ周波数: 約11Hz
      • PARC Audio(1μF)+20kΩ: 買った時の聴感が悪くて死蔵していたもの。今回も諦めずに数回試したが、やっぱり駄目だった。
        • カットオフ周波数: 約11Hz
      • ルビコン PMLCAP (0.1μF, 抵抗なし): 耳に問題(痛みや耳閉感: どちらも軽い)が起こる。音が不自然な感じ。 (AltFBCのついでに買ったものが届いたので、少し試した。: 1/24 18:00)
      • ルビコン MPS(0.22μF, 抵抗なし): 高音が強過ぎて耳が痛くなる。シャリシャリ感がすごい。うるさい。 (AltFBCのついでに買ったものが届いたので、少し試した。: 1/24 13:38)
        • あるページの歪み測定結果で良好なので試してみたが、音は良くなかった。
          • おそらく、そのページは単一の周波数(1kHzだったか)だけで歪みを測定しているため、それ以外の帯域の歪みの発生状況が異なるためだろう。一般的な方法ではあるが、余り有効・便利ではない気がする。(僕からすれば古い方法だ)
            • 余計なことだが、その方はその実態に合わない結果をもとに何かしただろうが、失敗しなかったのだろうか?? (まあいいかw)
        • まあ、電力用なので音が悪いのも仕方ないだろう。それにしても、容量はUPZと同じで特性も他と同様なのに、音が全然違うのが謎だ。
      • WIMA MKS2もどき?(1μF)+20kΩ?: 音がひどい(高音のギラつき)。以前の聴感も悪かった。抵抗は記憶が曖昧(記録を調べるのも面倒)。
        • カットオフ周波数: 約11Hz
      • オリジナルのカップリング回路(ニチコン FG 220μF+50kΩ(推定), OCC): 不思議なことに、この件を始める前は問題ないことも多かった。
        • そう言えば、音が良く感じる時と そうでもない時があったのは、僕の耳・体調や気分の影響や気のせいかと思っていたが、本当に音が変わっていたのかも知れない。
        • 電解コンデンサなので、カップリング回路に使うのは今一つ無理があるから、その関係があるのかも知れない。
        • カットオフ周波数: 約0.0015Hz(単体の場合): かなり低い。そのため、時定数も約25秒と長い。
      • DC(直結, コンデンサなし)
        • 「コンデンサを排除すれば(≒ DC構成にすれば) いい音になる」とは全く限らず!、カップリング回路が必要なことがある。
          • そもそも、聞こえない領域を苦労して伝達・増幅して弊害を出すなんて何と馬鹿らしいことだと、今は思う。
          • でも、安直な・にコンデンサを入れると僕のようにひどい目に遭うので、そのリスクを事前に回避する意味では意味があるかも知れない。
          • が、直流付近から そのまま出しても耳に問題が起こるので、やっぱり意味がない。
          • だから、直流付近を綺麗に切る必要があるが、それは難しい。そういうところが腕の見せどころの一つなのかも知れない。
  • 耳に合うものは、DACからアンプへの接続形態、アンプのフィードバック回路によっても変わる。今は、上記のように、DACとボリュームの間にカップリング回路を入れるのが一番良い。また、アンプのフィードバック回路のコンデンサ(詳細は後述)は無効(なし)にしている。
    • カップリング回路とボリュームの順序を入れ換える構成も試したが、アンプの入力抵抗(合成抵抗)が大きくなって出力のオフセットが増大するのと、雑音に弱くなるのに加え、手持ちには丁度良い容量のコンデンサがないので止めた。
  • ボリュームやアンプの入力抵抗やフィードバック回路とAltCCのコンデンサの関係で、カットオフ周波数やアンプのオフセットや全体的な超低域の挙動が変わるようだ。

※注: カップリング回路は前後の機器(回路構成)によって特性・挙動が変化するうえに、僕の耳は変な音に過敏なようなので、上に書いた感想や順位は僕の環境だけのもので、一般的なものではない。

だから、良く「コンデンサの聴き比べ」(オペアンプなども)とかあるけど、全く同じ環境でないと、そういうのは余り宛てにならないと思う。傾向をつかむ材料にはなるかも知れないが(全く違うかも知れない)、おそらく同じ結果にはならないと思う。そういう点で、事前検討なしでコンデンサやオペアンプを気軽に交換するのには賛成しない。

交換するにしても、一気に全部交換するなんてのは全く良くない。コンデンサの役割も効き方も全部同じではない。全部交換してしまったら、どこが効いたか/効かなかったか分からないではないか。

それにしても全く不思議なことは、上のどの回路もカットオフ周波数以外の特性(位相、歪み、雑音)は ほとんど変わらないのに(下にグラフを載せる)、耳が駄目とか高域が強いだの弱いだのといった、聴感の違いが生じることだ。想像だが、動的な特性や、(単純な正弦波でない)複数の音が混じった場合の特性(例: 混変調歪み)に違いがあるのだろうかと思う。

それぞれのコンデンサの特性(例: tanδ, 周波数-インピーダンス/位相特性)が関係しているのかも知れないが、知識が足らず、分からない。

 

DAC(TI PCM1792A)のフィルタとJACK(Linuxのサウンドシステム)のサンプリング周波数

  • 元: 44.1kHz /slow → 前回: 96kHz/slow → 今: 44.1kHz/sharp
    • 96kHz/slowで問題なかったものの、高品質なアップサンプル(speex-float-10)は負荷が高く、全体的な負荷が高い場合に音切れすることがあるので、止めた。
    • なぜか、耳の問題はDACのカップリング回路/AltCCやアンプのフィードバックとも関係があり(超低域の変動に関係があるようだ)、そこらを改良した今は44.1kHz/sharpでも問題ない。

さまざまな苦労の甲斐あって、ようやく、「普通」(デフォルト)の設定で問題なくなったようだ。

今までは その普通の設定で耳が駄目だったので どうしてかと思って居たし、他の人は良く大丈夫だと不思議に思って居た・・・

駄目だったのは決して気のせいや思い込みではなく、以前は44.1kHz/sharpにするだけで耳閉感が起こった(何度試しても同じ)のだが、原因が確定していないだけに証明が難しい。

それにしても、DACのフィルタやサンプリング周波数が耳の問題の起こり方に関係するのは謎だ。少し前までは以前書いたサンプリング定理を誤解した方の話から、ナイキスト周波数付近のAM変調成分が超低域に出て、それが耳に影響しているのかと思って居たが、そこまで高域が出ていなくても起こるので、そうではなさそうだ。

それに、元々44kHzではslowが良かったのだが、それだとエイリアシングの漏れが多いので、超低域に出るAM変調成分もsharpより多いはずなので、耳の問題が ひどくなるはずだ。だから、AM変調成分と耳の問題は関係なさそうだ。

それよりはDACチップの特性が気になって居る。データシートには可聴域外(20Hz以下, 20kHz以上)の雑音などは書いてないので、どうなっていようがTIは我関せずだ。

「我関せず」と言えば、Scarlett Solo Gen.3のフォーカスライトも同じようなスタンスで、仕様は20Hz-20kHzなのだが、30kHz以上で雑音が増大することを指摘しても、可聴域外だから全く問題ないと言われた。聞こえなければ いくら雑音を垂れ流してもいいのだろうか?

雑音といえども、仕様として書いている範囲外に それほど小さくない音を出すのは問題ないのだろうか? その論理なら、アンプが数百kHzで発振して とんでもない音量で超音波を出しても、壊れなければ問題ないことになりはしないか?

 

アンプ(BA3886, 自作(キットを改変)): フィードバック回路

  • 前回: サーボ基板が使い物にならないので撤去した。 → 今: サーボの代わりのフィードバックコンデンサ※も容量が大き過ぎて耳に問題を起こすようなので、変更しようとしている(→ 代替フィードバックコンデンサ, "AltFBC")。それでも駄目なら撤去する。
    • ※超高域でのゲインを下げて発振を防ぐため、フィードバックループとGNDの間の抵抗(下図のRi)の前にあるコンデンサ(下図のCi)。

フィードバック回路の説明図 (TI LM3886のデータシートのFig. 1): 図中のCiが本文のフィードバックコンデンサ

      • オリジナルのキットの容量は100μFと大きい(抵抗Riは1kΩ)。 → カットオフ周波数: 約1.6Hz (推定) (上図のTIのサンプルでは約7.2Hz)
      • なお、僕はゲインを下げるために抵抗Riを2.5kΩにしている(抵抗Rfは22kΩ)。 → カットオフ周波数: 約0.64Hz (推定)
    • 替わりのコンデンサAltFBCはルビコンのPMLCAP(10μF)を注文中で(→ 結果は後述: 1/25 16:51)、今はコンデンサなし(抵抗をGNDに直結)で試しているが、オリジナルより随分良い。
      • 問題がないならコンデンサなしでいいのだが、直流まで増幅するために出力のオフセットが大きくなるためか、入力を開放した状態で電源をoffにするとポップ音が出るのが気に入らず、小さいコンデンサで試そうとしている。
      • それから、キットでは100μFに並列にWIMA(0.1μF, 外見は上記の1μFのものより本物らしい)が付いており、実害がないのは分かりつつも、ボーカルの「かすれ」(後述)の原因ではないかという疑いや、上記の「もどき」で懲り懲りなので、一緒に排除したい。
        • 同様に、出力に付いている発振防止回路のコンデンサ(WIMA 0.1μF)もPMLCAPに交換する予定だ。
    • このような状況から、前回同様、あのキットを作った人の見識や技術力に疑問がある。
      • 以前も疑ったが、別の人が作った(考えた)ものに安易に自分の色付けをしたり、良かれと思って(逆効果な)変更をしたのかも知れない。
      • フィードバックコンデンサの容量以外にも、「ん? 分かってない?」と思われるものがある。あとで詳しく書きたい。
        • これらは今にして気付いたことで、そのキットを選ぶ時には知識が全く足りなくて、何の疑問も感じなかった。。。
        • そういう点で、今のアンプが とりあえずちゃんと音が出ているのは、結構な僥倖かも知れない・・・

(1/25 16:51) 届いたPMLCAP(10μF)をAltFBCに試したところ、意外にも※AltCCの0.1μFと同様に耳に問題(痛みや耳閉感)が起こって駄目だった。

※フィードバックコンデンサも音に影響があるのが意外だが、上に自分で書いているように、フィードバックコンデンサでも耳に問題が起こることを疑って交換したのだから、「何を寝ぼけてるんだ!」で、何に換えても いい訳は ない。

そもそも、フィードバックコンデンサはアンプのゲインを決める(低い周波数ではゲインを減らす)ので、出力する音自体を通しては居ないものの、言ってみれば出す音を決めているので、音に影響しない訳がない。

特性を測ると、低域(概ね60Hz以下)の歪みが大きいのと15kHz辺りに雑音があるのが気になった。ただ、前者は他の場合にも出ることがあるが問題のないことが多く、後者は基板や配線などが悪いのだが、やはり他でも出ていて問題ない。コンデンサを直列・並列にしたり、部品の取り付け方や配線を いろいろ改良してみたが、耳の問題は解消できなかった。だから、上にも書いているが、普通の測定では測れない違いがあるのだろうと思う。

一つ気になるのは、PMLCAPはメーカーの技術情報でも低域の歪みが大きいことだ。特に、今回のように直列に使う場合が良くなく、500Hz以下で増大するようだ。* (→ 参照: PMLCAPのテクニカルノート: P.7 「高調波歪み率」のグラフ(右側))

*実は、それが気になってAltCCに使うのを止め、同じくメーカーの情報で、通常使用時の振幅での歪み率が かなり小さい(→ 仮に低域で増大しても問題ないレベル)ECPUにした経緯がある。

そのグラフの形は僕の結果に少し似ている(歪みが増大し始める周波数は違う)ので、それが原因なのかも知れない。が、上にも書いたように、元々のフィードバックコンデンサやコンデンサなしの場合にも同様な歪みが出ることがあるので、それが耳の問題の原因なのかは確かではない。

結局、フィードバックコンデンサを改良する手立てが何もなくなってしまい、苦し紛れ、あるいは、いつもの思い付きで、試しにAltCCで却下したECPU(1μF)を2個並列にして使ってみたら意外に良く、今のところ耳の問題は起こっていない(いつものことだが、コンデンサを換えると「耳の感じ」の違いが劇的なので驚く)。ただ、合計容量が2μFと小さいため、カットオフ周波数が34Hzと高くなり、「ちゃんと」するには4-5個並列にしなくてはならず(→ カットオフ周波数は17または13Hzと、「まあ許せる」値になる)、なかなか大変だ。

とはいえ、偶然ながら(耳の問題を減らすため)部屋の特性補正フィルタで33Hz以下は切っているから丁度良いし、そもそもスピーカーの再生可能低限は42Hzだ。その関係もあって、この状態で低音が足りないとは全く感じないので、実用上の問題は全くない。気分の問題だ。

それにしても、「気分の問題」なのに、実用上不要な帯域までサポートして耳に問題を起こして、結局気分が悪くなるのは全く矛盾しているし、一体何のために頑張っているか分からないな・・・ うむ。

(1/25 19:09) まあ、(自称)技術者なので、制作するからには、「なんか分かんない・偶然だけど、丁度いいからいいや」じゃなくて、ある程度自分で考え・理解し・求めたとおりに動くものにしたい。それに、今の環境が変わっても そのまま使えるような汎用性を持たせたってバチは当たらないのではないか? というのを免罪符にするw

結局、仕事じゃなくて趣味で作っているってのが一番大きいw

それで、もう一回だけ別のコンデンサを試すことにして、パナのECQEを注文した。正直言って余り期待していないが、アンプで もう一箇所交換したい、出力の発振防止回路(Zobelフィルタ)用コンデンサにPMLCAP(MPSも)が使えなくなった(音が悪いため)ので、一緒に買い直すことにした。それが駄目なら、AltFBCはECPUを追加して4-5個並列にし、発振防止回路は現状のWIMAで我慢か。

(1/25 21:48) ちょっと思い付いて、PARC Audio(1μF)を上の暫定AltFBC(ECPUx2)に追加して、合計3μFにしてみた。これだとカットオフ周波数は22Hzになり(実測値は約24Hzだった)、少し「世の中のレベルに追い付いていそう」になる(それだけ。表面だけのこと)。

試す前から、「良いことはなく、あるとすれば悪いことだろうな・・・」と思って居たが、本当にそうだった。: 試聴開始して1分で少し耳が痛くなった。3分で耳が駄目なので止めた(あと、聴きたくなくなった)。

付ける前より音が良くない感じなのは確かだが、何が悪いのかは表現できない。ただ、外したら、明らかに音が違う(良い)ので驚いた(というか、安心した)。高域の抜けが良い感じ、あるいは、曇りが さっと晴れるような感じだ。

一応書いておくと、PARC Audioを けなすつもりはなく、逆に、「きっと、何かいいところがあるのだろう」と思って何度も試しているが、毎回駄目で がっかりしている。ネットでは良い感想が多いようなので、使う環境・回路の違いや僕の耳が過敏なせいだろうか。

これに限らず思うのは、音の良さで売るのなら、せめて詳しい特性を公開して欲しいとは思う。グラフ一つすらないってどうよ。「音の良さは数値には出ない」という考えなのだろうが、買う方としては一体何を宛てにすればいいのだろうか?: 良くある健康食品みたいに、「個人の感想」を信じろと?

 

前回以降に出た新たな問題

  • アンプのフィードバックコンデンサの影響 (上にも記載)
    • サーボを外した少しあとでフィードバックコンデンサを有効にしていたが、それで大分音が悪くなったようだ(当初は気付かなかったが、以降、耳の問題が増えた)。
      • 無効にしたら耳の問題が随分改善した。聴感的にも、音がすっきりした気がする。
    • ただ、この状態だと直流まで増幅するため、アンプの出力のオフセットが増大するのと、DACの超低域の変動(推測)の影響が防ぎ切れない感じ(推測)はある。
  • オーディオインタフェース(ScarlettやASUS)のADCの入力カップリングコンデンサの影響
    • 大容量のようで、アンプ出力のオフセットの電荷が溜まって、あるいは、時定数が大きいために音(超低域)がふらつく(推測)のが良くない感じ。
      • ScarlettやASUSの振幅-周波数特性の下限は それぞれ20Hzや10Hzなので、そもそも対応範囲外の領域を測ろうとしていたので無理はあるのだが、接続した先に影響を及ぼすのは いかがなものか・・・
    • それが測定対象のアンプに影響を及ぼし、耳に問題を起こしていた。
    • そのため、再生音の超低域の特性を正しく・頻繁に測定することができず、今は聴感(耳に問題が起こるかどうか)だけに頼っている。
      • これを良しとはしていないが、測定できる機器がないので仕方ない・・・
      • この問題が分かるまでは、低音(80Hz)の正弦波や実際の演奏(クラシック, ポップ)の超低域(録音には入っていなさそうな帯域: 約0-20Hz)の振幅から、試しているAltCCのコンデンサの変動抑止能力を調べ・比較していた。 → 破棄した測定結果の一部を最後辺りに載せる。

 

再生音と耳の問題について

当初はDACの超低域の変動*が耳の問題を引き起こす一因と考えていた。それが、試行を続けているうちに、それらやカップリング回路と耳の問題は余り関係がなく、耳や身体の調子によって起こり(要するに「不可避」)、起こったら治るまで待つしかない感じなのか※と諦めモードになっていた。

*この稿を書く時、あるいはカップリング回路の調整をしていて思ったのは、現代のデジタル技術の粋()であるDACでも昔のレコード時代にあったサブソニックフィルタの類が要るのかということだ。おそらく同じ現象・問題だと思う。でも、誰も言わないのを見ると、僕のDACが劣化して変動が大きくなっているのだろうか?

いや、手持ちの別の機器(Scarlett)でも、別のDACの試用でも同様なことはあったから、今でもあるのではないか? ということは、多くの人は感じないのか。

※ただ、起こりやすい(誘発する)・起こりにくいものや音が悪いものは確実にある。どうしてか・何が違うのかは まだ分からない。あと、体温や身体の活度にも関係ありそうだ。: 朝など、体温が低いとなりやすい感じだ。

が、近頃はそうでもなさそうなことが分かって来た。大きなコンデンサによる超低域の変動(DACのカップリング, アンプのフィードバック, ADCのカップリング※)は耳に効くようだ。

※ADCについては全くの想定外で、それまでの超低域の変動成分の測定結果を破棄する羽目になった(ちゃぶ台返し)。その変な測定結果のために、上に書いたように「余り関係がない」と思いつつあった。

不思議なのは、こういう話を聞いたことがないことで※、僕の耳に問題・原因があるのだろうと思う。ある種の音に過敏なのではないだろうか。そして、過敏という点で似たようなことが過去にもあったことを思い出す。

  • アンプ(ビクター A-X5)のライン出力にビデオデッキ(三菱, 電源off状態)を繋いでいると、ピアノ曲(内田のK.333 (1985)の頭辺りの単音(音が少ないの意)で鋭く弾く部分(記憶が あやふやになっているうえに今聴くと印象が違うが、おそらくこの辺り)で歪みを感じた。
    • 修理に来た人(当時はビデオも訪問修理してくれたようだ)は分からず・・・
    • 推測だが、ビデオデッキがoffの場合、入力部にある素子(コンデンサ? トランジスタ?)がアンプの信号に影響を与える(クリップさせる)のではないか。
  • 電子ピアノ(カワイ PW800)に、1個だけ音が歪んでいるキー(中央のA辺り)があった。
    • やはり、修理に来た人は分からず・・・
      • 自分でも、故障ではないし、修理(調整)もできないだろうなと思いつつも問い合わせてみた。
    • 明らかに隣のキーとは音の感じが違っていたのだが・・・

※検索していて近いと思い、ヒントになったのは、低周波音での健康被害である。僕が「耳閉感」と書いているのは その症状である。

 

現状・効果

まとめると、ASUSのDACのカップリングコンデンサをUPZ(0.22μF)に換え、アンプのフィードバックコンデンサを無効にしたところ、耳の問題(例: 耳閉感)は滅多に起こらなくなった。ただし、上述のように、午前中や疲れている時など耳の調子が悪い時(推測)は起こることがあるが、それまでよりずっと軽い。

音も良くなったように感じるが、いかんせん、通常の特性(振幅、位相、歪み、雑音)は何も変わっておらず、機器の性能・仕様の限界のために 疑っている超低域の変動の測定もできず、客観的な比較・証明ができないので、あくまでも「個人の感想」である。

 

書いたあとに見付かった問題 (1/26 11:54)

アンプの代替フィードバック(AltFBC)や発振防止回路(Zobelフィルタ)用コンデンサなどを追加注文したあとに思い出して それらの耐圧を確認していたら、公称値が数百Vと高いものでも高周波の交流については意外に小さいことが分かった。: 例えば、今回注文したパナ ECQE 0.22μF 250VDCの交流の許容電圧は、100kHzで約5Vrms, 200kHzで約3Vrmsでしかない。アンプの出力の最大振幅は約±15V(約10Vrms)なので、最悪の場合はコンデンサが壊れるが、そこまでひどいことは なさそうだと思った(その前に耳が壊れるか、電源の容量オーバーで落ちる?)。

LM3886の超高域発振防止回路とフィードバック回路の説明図 (TI LM3886のデータシートのFig. 3): 図中のCSN, RSNが発振防止(Zobelフィルタ)用コンデンサと抵抗, Cf, Rf2が超高域のゲインを下げるコンデンサと抵抗: なお、図は単一電源のものだが、正負電源でも同様である。

とは言え、念のため、アンプが どのくらい高い周波数まで増幅できるのか調べようと、フィードバック回路中にある超高域のゲインを下げるコンデンサ(上図のCf)でのカットオフ周波数を調べようと思った。

ところが、(以前も書いたように)アンプICのLM3886のデータシートの式が謎だ。下に示す。

"External Components Description"のRf2の項にある、カットオフ周波数fcの計算式(ママ):

fc = [Rf1 Rf2 (s + 1/Rf2Cf)]/[(Rf1 + Rf2)(s + 1/Cf(Rf1 + Rf2))]

式に不明な変数sがあって困っていたのだが、たまたま全く別のフィルタの特性を計算するページを見たら、どうやら周波数らしいことが分かり※、式が何か間違っている感じだ。この式はカットオフ周波数でなく、そのフィードバックの伝達関数(G(s))を求める式なのではないかと思う。

メーカーは修正せず、ユーザーも気付いて居ないのは謎だが、分かり切ったことなので飛ばしているのか、分からないけど とりあえずそのまま作っているのか、うやむやにしているのか。

※アンプを作る時の検討でも、"s"には見覚えがあったのだが、周波数だと分かって すっきりした。周波数fに2πを掛けたものだったか? 「角周波数」? (習ったのは大昔のことだし、不真面目だったので すっかり忘れて居る・・・)

伝達関数からカットオフ周波数を求める方法が分からない(怠惰なので考えていない)が、どうやら、その式から見るに、コンデンサ(Cf)と抵抗(Rf2)によるカットオフがコンデンサのない抵抗(Rf1)だけのフィードバックによって上がるだろうから、それらを「平均」※しているのではないかと推測した。(→ その後、式の意味が分かったので、下にカットオフ周波数の求め方を書く。)

上の式で、G(s)が与えられている(何らかの定数, 想定ゲインG)として変形して、回路のゲインがGとなる角周波数sを求めるようにすると、以下のようになる。

s= ((1 - Rf1 G )/Cf) / (G (Rf1 +Rf2) - Rf1 Rf2)

また、今回の回路に合わせてRf1= Rf2= Rfとすると、カットオフの角周波数sと周波数fcは以下式で求められる。

s= (1 - Rf G)/(Cf (2 Rf G - Rf2))
fc= s/(2π) (Hz)

※データシートのサンプル回路でのコンデンサCfと抵抗Rf1, Rf2の値を上の式に当てはめてカットオフ周波数fcを求めると、

Rf= 20k, Cf= 50p, G= 0.71 (カットオフの-3dB)
s= (1- 20*1000 * 0.71)/(50/1012 * (2 * 20 * 1000 * 0.71 - (20 * 1000)2))
= 710000
fc= 710000/(2*3.14)= 113057 (Hz)

と、カットオフ周波数は約113kHzとなり、この式は当初想像した相加平均でなく、相乗平均を求めていたことが分かった。

そして、データシートの問題の式の"fc"は"G(s)"などの誤りで、説明としては以下のよう感じが正しそうだ。

... A high frequency pole (lowpass roll-off) exists at angular freq. s in the next eq., where G= 0.71 (← -3dB):

G= [Rf1 Rf2 (s + 1/Rf2Cf)]/[(Rf1 + Rf2)(s + 1/Cf(Rf1 + Rf2))]

うむ。我ながらスッキリした!!!

そして、キットとデータシートのサンプル回路(Test Circuit #2)での、単体(コンデンサ+抵抗)と合成(抵抗だけの回路との相乗平均= データシートの式を変形した式(上記)で求められる値)のカットオフ周波数を求めてみた。少なくとも単体は正しいだろう。

  • キット (15pF+22kΩ)
    • 単体: 482kHz
    • 合成: 340kHz
  • データシートのTest Circuit #2 (50pF+20kΩ)
    • 単体: 159kHz
    • 合成: 113kHz

キットの300kHz以上は余りにも高い。100kHzでも充分なのに意味が分からない。ここでも不用意に部品の値を変えている感じだ。「帯域は広ければ広いほどいい!」といった馬鹿な考え?

それで、カットオフ周波数やコンデンサの容量はどのくらいが良いのか更に検討した。LM3886のオープンループ周波数応答のグラフ(データシートのFigure 49, 下に引用)を見ると、約100kHzまでは位相は概ね90°で一定だが、それ以上はズレが増し、約3MHzで180°になる。データシートのカットオフ周波数(120kHz辺り)は これに合わせてアンプの安定性を高めようとしているのだろう。

LM3886のオープンループ周波数応答 (TI LM3886のデータシートのFig. 49)

ところが、キットは400kHz近い。まあ、その辺りでも位相は115°辺りなので実害はないだろうが、「何考えてんの?!」だ。これは超音波用アンプじゃないよ?

他と同様に実害はないけど気になるので、気に入っているUPZ※を追加注文し、運良く間に合った。そして、「パンドラの箱」が閉じられるのが更に先になったw

※50pFがないので100pFにした。: それでもカットオフは約51kHzと充分な計算だ。それでも、もし低過ぎる場合には直列接続して50pFにできるように、多目に買った(一個16円と安いので できた)。

結局、このキットはLM3886以外は ほとんど全取っ替えだ。まあ、趣味だし勉強になるから いいけど、結果的には このキットは「駄目なもの」だった気がする。さまざまな変な値の部品には作った方の意図があるのかも知れないが、そうであれば それを資料に書くべきだ。その点で、作った方は技術者では ない感じがする。

そもそも、特性が一切書いてない時点で違う。キットだって、参考特性を載せてもバチは当たらない。とは言え、どういう訳か、載せているキット(それどころか、完成品の基板でも!)は滅多にないが。

 

その他

今使っている機器以外に、今までに耳に問題の生じた機器では、上のような大容量のカップリングコンデンサによる超低域の変動が起こっていたのではないかと想像している。ただ、それ以外に、雑音(超高域など※)でも耳の問題は起こるから、更に調べる必要はある(そういうのが、この「パンドラ」のそもそもの始まりだった気がする)。

※耳の調子もあるのだろうが、測定で超高域の雑音を目にしたものの、小さいからと気にせず出していたら、すぐに耳に来た。

それから、新年に買ったデジタルテスターは、アンプやDACのオフセットやカップリングコンデンサに溜まった電圧の測定に役立っている。上記のように、手持ちのADCでは正しく測れないことが分かったためである。クリップ付きリードもフルに稼働している。測定以外に、テスト的に部品を付けたり、端子を短絡させるのにも使える。線が細くて長いため雑音は乗るが(それが上記の超高域の雑音)。

 

参考: コンデンサの超低域の振幅変動抑止能力の比較 (破棄した測定結果)

AltCCの振幅変動(ゆらぎ)抑止能力を比較するため、低音(80Hz)の正弦波や実際の演奏(クラシック, ポップ)の超低域(録音には入っていなさそうな帯域: 約0-20Hz)の振幅を測定していたが、上述のように、測定に使ったインタフェース(Scarlett)の入力のカップリング回路の影響があることが分かったので破棄した。

それでも、グラフを見ると それぞれのAltCCのコンデンサの違いが出ているようだし、聴感にも合うことが多かったので、参考までに測定結果の例を載せる。いずれもアンプのフィードバックコンデンサが有効な場合のものである。

どういう訳かコンデンサ間で差が生じており、いずれでも10Hz以下のピークは概ねECPUが一番大きく、変動抑止能力が良くなさそうだと推定していた(それは聴感に合っていた)。

そして、得られた測定結果は疑わしいものの、測定・評価方法は それなりに正しいのではないかと考えている。直流から測れるスペアナがあれば確認できる。

 

おまけ: 録音の瑕疵?について

上記の過敏な耳に関連しているかも知れないが、以前からポップ演奏のボーカルの音で ちょっと気になることがある。

  • ELO: Last train to London (1979): 0'48"辺りからのサビの"Last train to London"からの声(摩擦音)が かすれる。
    • 検索しても出て来ない。
    • 公式のAudio(上)では かすれが聞こえる(これも15kHzで切られているが、公式MVより音質が良い)。
    • YouTubeの公式MVでは かすれは小さい。高域を落としているせいか(15kHzで切られている)。
    • カップリングコンデンサによって聞こえ(かすれの強さ)方が違うように感じたので詳しく調べたら違いはなかったので、気のせいだと思う。
      • 最初のrepeat("Last-")のかすれが一番目立つ。それ以降は小さくなるので、全部同じと思って聞くと差があると感じることがありそうだ。
  • Wings: With a little luck (1978): 1'14"辺りの"And a little luck, we can clear it up"の"we"に雑音(金管楽器かシンセ?)らしきものが被る。
  • John Lennon: #9 Dream - Remastered 2010 (1974): 曲を通して、ボーカルの声(摩擦音)が かすれている。

 

という訳で、まとまりがないし、以前の伏線(じゃないけど)の回収もできないが、少しずつ書こう。

 

PS. 参照のため、すごく久し振りに内田のモーツァルトのピアノソナタ(K.333 (1985))を聴いたが、結構いい(まあ、それはそうだ)。昔は大好きだった。ただ、今聴くと音(録音)が当時の印象に比べて ちょっとくすんだ感じなのが妙だ。そういう音作りだったのか、今は僕の耳が不調なのか、オーディオが不調なのかw

あ、思い出した! ピアノの音を ちゃんと出すのはすごく難しいんだ。これもそれではないか?

PS2. 草稿とかメモには書いたけど、いかにもなので使わなかった文言(を消化するw)

認めたくないものだな(コンデンサに音があるなんて)

いいもの(コンデンサ)もある、だけど、―

  •  0
  •  1

意図していた訳じゃないのだが、近頃の稿がオーディオの話ばかりになって居るとおり、延々と続いている作業に、自分でも「何でこれを始めたんだったっけ?」と確認するくらいだ。大晦日の今日ですら いじって居たが、ようやく大丈夫そう、あるいは、許せる音になった(気がする※)。

※耳や身体の調子で聞こえる音の感じ(耳に合うかどうか)が変わるので、なかなか安心できない。

→ その後、大きな問題が起こっておらず、意外にも音も随分いい感じになったので、ひとまず大丈夫そうだ。 (1/3 7:58)

細かい話は あとで書きたいが、結局、オーディオ再生系のほとんど全部(ソフトもハードも)に手を入れた感じだ。全部作り直しとまでは行かないが、そういう部分もある。主なものを以下に示す。

以下で「感じ」のような表現が多いのは、今のところは特性のような値や理論が出せず、自分の印象・感想でしか良し悪しを表現できないためである。更に、おそらく僕の耳は過敏なようなので、それに合うことが音の良し悪しとして一般的かどうかは分からないこともある。

それから、オーディオで良く見る「数値で表せない音の良さ」のような言い方に近いが、そうではない。僕としては、適切な理論・測定方法が見つからない・実施できないだけで、何かしらの値で(定量的に)音の良し悪し(≒ 忠実度の高さ)が表せると考えている。

  • サウンドカード(ASUS Essence STX II)のDAC部
    • 出力のカップリング回路: オリジナルが駄目な感じ※なので、コンデンサの手前から出力を取り出して、外付けの暫定版(AltCC2a)を自作した。 → 耳閉感・音が聞こえにくくなる症状の防止に かなり効いた。
      • ※コンデンサの容量が220μFと大き過ぎるために、超低域(直流から30Hz辺りと推測している)の変動が出力されて耳閉感を引き起こしている感じ。
      • 使ったコンデンサ*の歪み特性が今ひとつ(とは言え、今は結構いい音になっている)なので、年明けに良さそうなもの(パナのECPU)を買って正式版を作りたい。
        • *以前買って気に入らずに死蔵していた、PARC Audioのフィルムコンデンサ 1μF
        • カップリング回路は実際にはHPFになっており、カットオフ周波数は後続の回路で変化することがあるが、参考までに単体と僕の環境(()内)での値は以下になる。 (→ グラフ: 振幅特性の比較)
          • オリジナル: 0.015Hz (0.030Hz)
          • 暫定版(AltCC2a): 8.0Hz (11Hz)
        • 細かくなるが、手持ちにWIMAのコンデンサ(MKS2?)も あって試したが、ものすごく音がひどかった(高音がギラつく感じ)ので止めた。
          • 1度だけでなく、数回試して いつもそうだった。どうしてかは分からないが、電源用で音を通しては いけないのかも知れない。
          • ↑書いたあとで調べたら、偽かも知れないものが出回っているようで(→ 参照)、マーキング(ロゴなし、天面に数字)や音の悪さが僕のと合う。。。 あとでもう少し調べたい。 (1/1 13:20)
            • ↑真偽・偽物については上のページと その関連ページ以外に情報がなかった。その情報が正しいにしても そうでないにしても、メーカーのロゴのないもの・音がおかしいもの(、あるいは、同一型番で数種類の音のもの)が正規品として出回っている(いた)時点で※、そのメーカーの信頼性はマイナスだ。
              • ※僕のは店で買ったのでなくキットに入っていたものなので、実際にはWIMAでない、色と形が良く似た偽物というオチも充分あり得る。
                • ↑キットの説明書を見たら、その1μFはWIMAとは書いてなく、しかも、どうでもいいところ(音は通らない)に使われていたので、本当に良く似たものだったのか(無指定で使われたものが あれだった? 「訳あり品」??)。それで音がひどかったのかな・・・ うむ。
            • いずれにしても、僕は あの音も色も懲り懲りで(それが正規品だったのなら なおさら!!)、使うにしても どうでもいい電源だけだ。 (1/1 20:35)
      • コンデンサの音を排除したいのでコンデンサなし(直結)も試したが、DACから直流(オフセット)や超低音が出るようで※、どうしても耳に合わなかった。
        • ※理論的には、I/Vのあとのバッファ(LPF)で打ち消されるはずだが、劣化のために どこかがアンバランスになっているのではないか。
      • (他もそうだが)この件については別途詳しく書きたい。
    • 出力切り替えリレー: 接点が音に良くない(という情報・定説がある)ので、試しにI/V変換部のあとの2個を排除した(直結した)。
      • 予想通り 特性は全く変わらなかったものの、確かに音が変わった(特に高域が少し良くなった)。
    • DACチップのデジタルフィルタ: なぜか、sharp(デフォルト, 遮断特性(傾き)が急)よりslow(傾きが緩やか)が音が良さそう(「slowでないと駄目」に近い)なことが分かった。 → 音のキツさが和らぐ以外に、sharpは音が悪く感じる。
      • それらの違いは超高域(ナイキスト周波数付近)だけだと思って居たが、実際にはそうでもない感じで、超低域にも影響があるのかも知れない(まだ良く分かっていない)。 (→ 参考グラフ: 右端の落ち方が違う)
      • サンプリング周波数44.1kHzのsharpが良くなさそうなのは分かるが、(理論的にはあり得ないのだが、)どうしてか96kHzのsharpも良くない感じだ。
  • JACK(Linuxのサウンドシステム): 上のDACのフィルタの関係でサンプリング周波数は44.1kHzでなく96kHzが良いので、変えた。
    • なぜか44.1kHzのslowより96kHzのslowのほうが音が良い印象だ。
      • 44.1kHzのslowはエイリアシング成分が漏れて超高域(20kHz付近)の音が劣化するが、僕には聞こえない帯域である。それ以外に何か違いがあるようだ。
    • 本当は44.1kHzの整数倍の88.2kHzが良いのだが、サウンドカードがサポートしていないので96kHzにした。
    • 無駄にアップサンプルしているが、急なフィルタは音に良くないのは確かで、その急な部分が44.1kHzでは可聴域ギリギリ(22kHz近く)だけど、96kHzなら聞こえないところ(48kHz近く)に移る点で音に良さそうだから、全くの無駄ではなさそうだ。
      • なお、更に周波数を上げて192kHzなどにすると、DACの歪みが増えるなどデメリットがあるので、96kHz辺りが良さそうだ。
  • 部屋の特性の補正用フィルタ: 一新(簡素化)した。 → 音のボヤけが結構減った感じ。
    • 左右を別の設定(補正値)にすると良くない気がしたので、同じにした
      • 左右別に細かく補正しても意味がなく、大体合わせればいいようだ。
      • 別にすると、左右で音が変わってしまう(位相差の影響が大きそう)弊害が大きい感じだ。
      • あと、そもそも、音に対する処理は なるべく少ないほうが良い。
    • 超低域をカットするフィルタを、パラメトリックイコライザでなく緩いHPFにした。
    • 以前書いた、DACの歪みの左右差を補償する処理(HD2C)を止めた。
      • この差が本当に起こっているのか(測定時にだけ起こっているのでは?)疑問なのと、補償処理によって低域と高域の振幅と位相特性が劣化し、かつ、左右でアンバランスになるためである。
      • そもそも、歪み率が充分小さいので、左右に差があっても大きな問題でないこともある。
        • が、いつか解決したい。
  • アンプ(BA3886, 自作(キットを改変)): サーボ基板が使い物にならないので撤去した。 → 耳閉感・音が聞こえにくくなる症状の防止に結構効いた感じ。
    • (耳閉感や動作が)どうも怪しくて いろいろ調べたら、設計(回路)が「なってない」感じで、付けても大した改善がなく(オフセットや超低域の低減能力が低い)、メリットよりもデメリットのほうが多そうなので外した。
      • まあ、良く分からず・考えず・テキトーな売り文句を信じて買った僕が悪い。: 微小なアンプの出力オフセット(数十mV)を補正するだけのために、出力に常に補正信号を加算するのは愚の骨頂でしかない。
      • これに ついては(も)いろいろ書きたいが、長くなるので別にしたい。

 

以上の成果として、耳のトラブル(耳閉感・音が聞こえにくくなる症状、音が悪く感じる現象、痛み)が起こりにくくなるとともに、随分音が良くなった感じだ。前者は確認継続中だが、音の良さは従来比2-3割増しくらいか。試した中には効果のないものや逆効果なものもあったが、上に書いたものは全部効果があった。

どういうふうに良くなったかというと、(毎度書いているが、)音がクリア・ストレートに聞こえる、以前は分からなかった繊細な部分が聞こえる(≒「情報量が増した」)、高音が良いといった感じである。

ただ、そういう感想は、音が悪くなっている場合(例: 歪みが増した)にも出るので難しい。その場合は、長く聴くと耳が痛くなったり、キツく感じたり、不自然な感じがして来るので分かる。

そして、CDなどには想像以上に さまざまな音が入って居るようだが、残念なことに長らく気付かず、こうして再生系を改良して初めて気付く。そういうことが今までに何度もあったことに驚くとともに、一体全体どのくらいの音が入っているのか考えると恐ろしいものがある。

ただ、いつも書くが、一つ明記したいのは、どれも音を「自分の好み」にするためでなく、スピーカーから出て来る音が自分の耳に合わなくて(例: 耳閉感が起こることがある)聴き続けられなくなるのを解消しようとして やっている。だから、音源(収録された演奏)の音は可能な限り そのまま出し(それが僕の「いい音」の定義)、音と一緒に出て来る(まだ明確にできていない)「耳に悪い要素」を減らす方向だ。

僕は、スピーカーから出すのは音源そのものだけにしたいと考えている。だから、音源の音が悪かったら悪いままで聴くより仕方ないと考える(あるいは、リマスターされるのを待つ)。

そういえば、以前、ダウンロードで買った曲の音が悪くて、自分でリマスターもどきをしたことがある。個人的には、明らかに音源の音がおかしいなら、再生系で音を変えるよりは音源自体を直すほうが ありかと思う。

それから、以前(サウンドカードを買った時)は問題なかったのに、どうして耳のトラブルが起こり出したかを考えると、サウンドカードの劣化、アンプを交換して特性が変わった(かなり向上した)こと(+余計なサーボがあったこと)、自分の耳の調子の変化(経年的なものと日々の時間的なもの)が絡み合っているのではないかという仮の結論になっている。が、まだ続きそうだ・・・

 

(1/3 7:58) 最初に追記したように、その後、耳の問題が ほとんど起こっていないので、現在の構成・設定で ひとまず大丈夫そうなことが分かった。そして、随分 紆余曲折して見付けた、耳閉感の原因の一つ(超低域の変動)が正しかったようで一安心だ。なお、耳の問題の原因は他にもあると推測しており、追って それらの確認を再開したい。

 

という訳で、まさに取って付けますが、来年も(こんな感じと思われますが、)よろしくお願いします。

 

(2023/1/1 7:52-12:19 加筆・修正, 写真・図を追加, 構成を改良; 13:20, 20:35 WIMAについて加筆; 1/3 7:58 現状で問題なさそうなことを追記)

  •  1
  •  2

いつからだったか、PCのサウンドカード(ASUS Essence STX II, 以下ASUS)で収録した音の右の歪み(全高調波歪み率, THD)が左より大きいことに気付いていた。劣化だと思って放置していたのだが、先日 とあるDACを試用した時の測定で気になって、ちゃんと調べてみた。

すると、振幅(音量)が大きい(例: -10dBFS)場合に2次高調波が大きくなっており(例: 左チャネルの約3倍)、それでTHDが大きくなっている(例: 左チャネルの約2倍)ことが分かった。

問題の部位を探す。

原因として、サウンドカードのDACまたはADCの右チャネルの特性が劣化していると考え(最初は、以前壊して直した(+性能が悪いので嫌いなw)ADCだと思った)、右(出力)→右(入力), 同右→左, 同左→右のように たすき掛けで特性を測定・比較したところ、入力するチャネルに関わらず、右で出力した場合に歪みが大きいので、右のDAC部が劣化していることが分かった。

過去の測定データから 劣化が始まった時期を調べたら、どうやら2021年3月辺りのようだ。この頃に過大入力でADCの入力部のオペアンプを壊して直したが、それに関係あるのだろうか?: グラフでは、最後の正常だったデータ(上の青: L, 赤: R)では左右の差が小さいが、ADC修理後(黄緑, ベージュ)は左右に差ができ、その後差が出る帯域が広がって現在(下の青, 赤)に至る。

なお、不思議なことに雑音に左右差はない。ここに何かヒントがあるかも知れないと思ったが、DACから出力していないので なさそうだ。まあ、(雑音の多い)ADCに問題がない証拠では あろう。

DAC部の劣化する要素としては、以下の可能性がありそうだ。

  • DACチップ
  • 周辺のアナログ回路
    • I/V変換回路(DACの出力を電圧に変換する)
    • ライン出力バッファ(等倍アンプ: マニュアルにはLPFと書いてあるが、旧版ではバッファとなっている)
  • 電源回路(上の3つのそれぞれ)
    • 特に電解コンデンサ

DACチップの片チャネルだけおかしくなるということがあるのか、分からない(ただ、以前はオペアンプの半分だけ壊れたのであるかも知れない)。電源の電解コンデンサが劣化することは大いにあり得る。ただ、気軽には交換できない。

(11/28 10:47) DACチップPCM1795Aのピンを見ると、左右チャネルの出力用電源(VCC2L/R, AGND3L/R)が別になっているので、その右側用(バイパスコンデンサ?: 写真右側のぐるっとチップを取り囲んでいる金・銀色のうちの一つ・・・)が駄目なのかも知れない。

そこで、たまたまサウンドカードに交換用オペアンプ(LME49720)が添付されていたので、I/V変換回路と出力バッファのオペアンプを交換して試してみた。: まず、出力バッファのオペアンプ(1個)を換えてみたが、歪みに変化はなかった。次に、I/V変換回路(2個)の左右を入れ替えてみたが、これも変化はなかった。

すると、残りは、周辺回路の受動部品(コンデンサ・抵抗)か電源回路かDACとなる。どれも容易には交換できず、交換しても成功するとは限らないので、新しいサウンドカードや外付けDACに交換するのが良さそうだ。

とは言え、今までに書いて来たたように、なかなか「これ」という候補がないので、ソフト(信号処理)で暫定対処してみた。

暫定対処1: 振幅を下げる。

ます、振幅が大きい(約-16dBFS以上)場合に左チャネルより右チャネルの歪みが増すので、DACに入れる振幅を下げれば歪みは増えないと考えて、DACの前にアッテネータを入れてみた。試行錯誤したところ、アッテネータの減衰量が16dB以上なら歪みは増えないので、16dBにした

目論見どおり、歪みの左右差はなくなった。が、何となく音が悪い気がした。16dBは約2.7ビットに相当するので、それなりに音は劣化しているはずだが、それ以前に気分が良くない(数値もそうだが、趣味なので これは重要だ)。それに、振幅が小さいため、全体としての歪み率は減らないし(元のグラフ対処後のグラフの左上の囲いの中のTHDの値を参照)、小さくしたものを再度アンプで大きくするのは とても馬鹿らしい。

再考

そこで、そもそもに戻って2次高調波が増える原因を調べたが、なかなか分からなかった。が「KAKUSAN真空管アンプ」の「2次歪みの打ち消し その1」という、おっ!と思わせるページがあった。このページは、(自作アンプの製作の際にも参考にした、)「私のアンプ設計マニュアル」の「真空管で発生する歪み(負帰還の予備知識)」を参考にされており、それを読んだら、2次高調波が増えるメカニズムが少し分かった気がした。

要するに、回路(アンプなど)の正負の特性が非対称になっているようだ。非対称になる原因は分からないが、やっぱり電源、特に電解コンデンサの劣化で正負電源の能力が非対称になっている、つまり、負荷の高い時にどちらかが電圧降下してしまうのではないかと想像する。

上は良くありそうな考えだが、良く考えると、PCの電源はそんなにヤワじゃないし、DACやオペアンプが そこまで電力を消費するとも思えない(とは言え、DACやオペアンプの周りに電解コンデンサが並んでいるところを見ると、やっぱり消費するのか)。それに、調べては居ないが、元々DACやオペアンプはPSRR(電源電圧変動除去比)が高そうではないか(でも、コンデンサを並べるってことは、それほどでもないのか)。

ASUS Essence STX IIのDACとI/V, バッファ(LPF)周辺

仮に電源でないとすれば、DACやオペアンプの劣化(損傷)なのだろうか?

(11/27 9:55) 上の他に、リレー(写真の白い長方形)の接点の劣化の可能性も ありそうだ(こういう症状になるかは不明)。

結局、電解コンデンサの交換に帰着して容易でないことに変わりはない。が、最初に挙げたページから「歪みを打ち消す」という発想に気付き、回路でなくソフトでやってみることにした。

暫定対処2: 歪みを補償(キャンセル)する。

つまり、右チャネルの信号をDACに出す直前に、DACで発生するであろう歪みを引いておけば、歪みが出なくなるのではないか。早速JACK(JACK rack)のモジュールを探すと、Harmonic generatorというのがあり、まさに2-10次までの高調波が加えられる。それで、波形(1kHzのスペクトラム)を見ながら、加える量(係数)を調整したところ、0.000035が良さそうで、見事に歪みが減った。予想に反して符号が正だった(引くのでなく足した)が、参照したページと逆の歪み方をしているのかと想像している。 (以後、HD2Cと呼ぶ)

その後、広い周波数帯域・振幅で調整して係数を0.000017とした。※ グラフ(再掲)で、右チャネルの歪みは下側の赤(補正前)からピンク(補正後)まで減り、左チャネル(下側の青)に近くなっている。

※補正係数に単位はなさそう(比)だが、歪み率の差に近いようだった。

なお、いいのか悪いのか、音(聴いた感じ)に特に変化はない模様だ。そもそも、歪みが多いと言っても絶対値は小さい(増えている場合で0.002%など)し、今まで聴いていて歪みが多くなっていることに気付かなかったのだから、その歪みが小さくなっても違いが分からなくて当然な気がする。※ 逆に、数値としては問題なくても、補正処理で音が何らかの劣化をすることや、時間経過でDACの劣化具合が変わって係数が合わなくなることが心配なので、しばらく様子を見たい。

※聞こえないからと言って放置する気には全くならない。それではラジオと一緒だ。: まず趣味(オーディオだけでなく、計測・測定も)だし、良くない状態を なかったことにして使い続けるのは嫌だ。

とは言え、僕は数値特性至上主義ではない。数値が良いだけで いい音は出ないのだろう。かと言って「耳・感性がすべて」などと言うのには大反対だし、似非・疑似科学なんて もっての他だ。もちろん、何の根拠もなく・提示せずに「音がいい」などと言うのは論外だ!

では何かと言うと、「腐った機器で いい音は出せない」だ。最低限クリアすることがある。例えば、特性のしきい値、実装の常識があるはずだ。「音がいい」とい言うのは それからだ。

あるいは、おいそれと物理法則を覆すことはできないってことだ。もし覆したなら、隠さず・誤魔化さずに論理的に説明して欲しい。

でも、そんなことより重要なのは、音の良さと演奏の良し悪しは全く関係ないことだ。どんな機器でも いい演奏を楽しみ、感動することはできる。

それに、そういう微小だけど広範囲な歪みは ちょっと聞いただけでは分からないけど、再生音の微細な ところや全体の雰囲気に影響を及ぼすかも知れないと思う(それは時間を掛けて検証しないと確認できない)。

 

ところで、こういう歪み低減方式は見たことがないが、アナログアンプのフィードフォワードみたいなものだろうか。そして、この方式なら、2次高調波に限らず幅広い高調波歪みが減らせ(補償・キャンセル)そうだが(実際、試した時は左チャネルより歪みが小さくなった)、採用しないのは何か理由がありそうだ。

そもそも、固定の小さくない歪みが出るのは回路がクソ駄目だからで、設計時や出荷前に直す・調整するだろうし、出荷後や稼働(再生)中にダイナミックに歪みをキャンセルするのは困難だからだろう。それでも、電源on直後とかの初期化時や無音時やマニュアルで補正係数を求めれば それなりに効果がありそうな気がするが、きっと余り良くないことがあるのだろう。

大体、自分で やっておいて なんだが、効果が すご過ぎて信用できないw

まあ、微細な歪みを測定できるADCは高いし、プロセッサを付けるのも面倒だし、それで雑音が増えるだろうから、手軽ではない。

今気付いたが、これは処理としてはイヤフォンやヘッドフォンのANCみたいなものだ。だから、そのうち出て来るかも知れないな。そういえば、デジタルアンプであった気がした。 (→ 例: DDFA: これはフィードフォワードでなく、普通のフィードバックのようだ。)

 

One more thing... (また思い付きだよ・・・w)

これとは別に、歪みの値や交換用オペアンプ(LME49720)を眺めていたら、例によって思い付いた。: 折角だから、現状のもの(I/V: MUSES8920, バッファ: MUSES8820)よりLME49720のほうが特性が良いなら交換したくなった。調べたら、MUSES8820は歪み率やスルーレートが他より悪いようなので、(標準をこれにした理由は 何かあるのだろうが、)LME49720に交換してみた。

ちなみに、「オペアンプの音」というのは余り信じてはいないし期待もしていないものの、音質比較のページもいくつか参考にした。 (→ 参照1, 参照2, 参照3, 参照4: これに一番「背中を押された」かも?^^)

個人的には、本当に音が変わるとすれば、オペアンプのチップを換えることで特性が変わる以外に、それで微妙に回路の挙動が変わるために、特にダイナミックな特性や消費電力の変動特性が変わるためではないかと思う。そして、僕は その変化があることが良いとは思えない。特性の違いによる変化は あるべきだが、それ以外の変化は想定外の事象だと思う。

特性は全く変わらなかった※ものの、(気のせいや耳の調子の関係やプラシボ効果だとは思うが、)音は変わった。: 高音が少し強い感じで、音が軽目になった気がする。これもしばらく様子を見たい。

※ADCやサウンドカード(実装)の限界で 違いが測定できなかった可能性もある。

 

本題に戻るが、LME49720に交換しても特性(歪みの左右差も)が変わらなかったということは、少なくとも出力バッファ回路、特に電源関係の劣化は問題なさそうだ。もし劣化しているなら、オペアンプの交換で消費電力が微妙に変わって歪みの出方が変わるはずだと思うからだ。

 

その後 (11/28 9:32)

例によって、とりあえず対処出来ただけで安心することなく、(飽きずに)再挑戦、見直しなどをしていた。疲れたので簡単に書く。

  1. 再度、歪み増大の原因(箇所)の究明とハード的な対処の試行をしたが、成功せず。
    1. 問題の起こるライン出力とヘッドフォン出力の歪みを比べてみた。 → ヘッドフォン出力の歪みは大きいものの、左右の歪みの差がなかった。 (→ グラフ: 濃色: ライン出力, 淡色: ヘッドフォン出力)
      • ヘッドフォンアンプへ信号が分岐される、I/Vのあとのリレーの接点、バッファ、もう一個のリレー、コンデンサが悪そう。 (信号経路は下の接続図を参照)
        • だが、ヘッドフォン出力は左右ともに2次高調波が大きい(歪みは ほとんど2次)ので、違うのかも知れない。
        • が、ここにヒントがありそう。
    2. 基板を見てDACから出力までの回路を推定した
      • DACからライン出力までの接続は以下である。部品番号は基板の写真を参照のこと。
        • ライン出力 ← RL2 ← C3/4 ← バッファ (A3) ← RL1-1/2 ← I/V (A1/2) ← DAC
          • A1/2: I/V用オペアンプ (2個: LR)
            • 1個ずつ、左右それぞれの正負を処理する。
          • A3: バッファ(LPF)用オペアンプ
          • RL1-1/2: ライン出力とヘッドフォン出力切り替えのリレー(2個: LR)
          • RL2: ライン出力ミュート用リレー?
          • C3/4: 出力のカップリングコンデンサ(2個: LR)
    3. 出力のカップリングコンデンサの劣化の可能性を考えてスキップしてみた(コンデンサ(C3)の手前から出力を出した)が、効果なし。
      • まあ、電源でなく信号だし、それほど熱くなるとは思えないので、劣化している可能性は低い。
        • しかも、片チャネルだけどいうのは余りなさそうだ。
    4. リレーの接点の劣化の可能性を考えて、I/Vのあとの1個(右用: RL1-1)をスキップしてみたが、効果なし。
      • まあ、寿命になるほど使っていないと思う。
    5. カップリングコンデンサとリレー(2個)をスキップしてみた(リレー(右用: RL1-1, RL2)とコンデンサ(C3)を短絡させた)が、効果なし。
      • 出力端子に並列に抵抗※があるのを忘れていて、最初のコンデンサのスキップでは不充分だったかも知れないと思って試した。
        • 論理的に考えてもシミュレーションでも影響がないのは分かっていたが、試した。
        • ※アナログテスターのため、抵抗値が50Ωか50kΩか判然としなかった。が、もし50Ωだったら、小さくてオペアンプが過負荷になっている可能性もある。
          • が、そんなに小さい抵抗を付けるほど常識がないとは思えないし、左では問題が起こらないのには合わない。
    6. → やっぱり「手に負えない」 → DACを買う必要がある。 → 細かい条件の検討を開始した。
  2. 上の変更を元に戻す時に、再度オペアンプを交換してみた。
    • 思い付き・直感(毎度懲りないw)でやったのだが、その後、PCM1792Aのデータシートの外付けアナログ回路の推奨オペアンプの説明("APPLICATION CIRCUIT"の"I/V Section", "Differential Section")を参考にLME49720とMUSES8920の特性を比較したら、(後付けの論理ではあるが)悪くなさそうなことが分かった。
      • I/V: LME49720
        • TIのデータシートによれば、バンド幅, セトリング時間, スルーレートが重要そう。
        • → バンド幅が広いため これで良さそうだ。また、低歪み・低雑音でもあるので、これを前に入れるほうが良さそうだ。
      • バッファ: MUSES8920
        • 同、低雑音が重要そう。
        • → 測定方法によるが、こちらも低雑音な感じなので良さそうだ。
    • 特性を測ったら、全域で わずかに右の歪みが下がったが、なぜか左は変わらななった。 → この辺り(DACからI/Vの辺り?)が歪みの問題に関係ありそう。
    • また、右チャネルの歪みキャンセル処理(HD2C)後の歪みが より左に近くなった
    • ちょっと聴いてみると、LME49720をバッファにした時より良い感じ(馴染める、耳閉感が起こらなそう)と右の高域がクリア(だけどキツくない)になった感じだが、まあ、気のせいや体調の関係だろう。
      • ただ、好みの音ではある。
      • 全体としてはオリジナル(I/V: MUSES8920, バッファ: MUSES8820)に近い。
  3. HD2C(DACに出す前に高調波を加えて歪みをキャンセルする方法)の副作用などが見付かった。
    • 高調波を加えるために振幅が大きくなって、DACでオーバーフローする可能性がある。
      • → たまたま、部屋の特性補正のためのフィルタの前に(念のため)1dB下げている(約0.89倍)ので、問題は起こらないことが分かった。
    • 低域の位相が少し進む(50Hzで約8°)。
      • 気にはなるが、部屋の特性補正のためのフィルタでは もっと変わるので、大きな問題ではない(止むなし)とした。
    • 低域の振幅がわずかに下がる(20Hzで0.5dB程度)。: 高調波を加えるために使ったHarmonic generatorのため。
      • 微小な差なので問題はない。
    • どれも致命的な問題ではないが、調子に乗って「全部の高調波を減らして歪み0にしそう!」なんてやったら ひどいことになってそうだ。(上に書いたように、)「(余計でもそうでなくても)処理は増やさないほうが良い」という直感は正しかった。
  •  0
  •  0

良く考えたり調べれば分かることは多いが、分からないこともある。ただ、それが本当の謎と言えるかは怪しく、自分に知識や経験が ないからかも知れない。

だから、それらをすぐに謎(だから分かりようがなく、どうしようもない)と決めつけて思考停止したり、(いかにも権威ありそうな)他人の言うことを盲信するのは大嫌いだ。

 

(本題)

先日、以前にも起こっていた、たまに左のスピーカーから小さい「ポツ」という雑音が出る件が ぶり返したので、自作のアンプBA3886に問題がある・生じたのか不安になって原因を確かめている。

雑音の原因の可能性は いろいろある。以下に示す、音の経路にある要素のすべてが そうだ。

PC

再生アプリ → ドライバ類(JACK, PulseAudio, ALSA) → サウンドカード(DAC)


再生機器

コード1(L/R) → ボリューム → コード2(L/R) → アンプ → コード3(L)/4(R) → スピーカー(L)/(R)

アンプに問題があると厄介(対処が面倒、気が重い・・・)なので、そこには目を瞑る。のでなくw、まずはアンプに焦点を当てることにした。: 具体的には、アンプの入力(コード2-L/R)と出力(コード3,4)で左右(LR)チャネルを入れ替えて試している。それで雑音が右から出たらアンプが おかしく、左からなら それ以外のはずだ。

 

(なぜかScarlettのドツボにハマる・・・)

一方、他の大きな原因としてサウンドカード(ASUS Essence STX II, 以下、ASUS)も考えられる。古いものだし、一度壊して(無理やり)修理したことがあるからだ。仮にASUSが駄目になっているとしたら交換することになるが、次のものは すぐには決まらないから※、まずは手持ちのオーディオインタフェース(Focusrite Scarlett Solo Gen. 3, 以下、Scarlett)の可能性を調べた。以前試したら今ひとつだったが、再度試してみることにした。

※実際にAmazonなどで探したが、手頃なものでは「欲しい」と思えるものがなかった。しかも、近頃は その辺りの業界は様変わりしていて、日本メーカーのものは ほとんどなく、中国がほとんどだ。(先入観は良くないが、)手頃なものでも仕様・特性が すごいものはあるが、本当にその値が出るのか、そして音は いいのか、結構疑問だ。

参考までに、少し前の候補は以下だが、後述の「すごく良い特性が必要だ」という誤った結論の時に選んだので、現在(自分に合う音のものが良い)は もう少し違って来そうだ(が、音が自分に合うかを確かめる術はない・・・)。

MOTU M2; Native Instruments Komplete Audio 1; Sabaj A10d(2021年版); S.M.S.L SU-6, D-6; TOPPING E50, E30II, D10s

更に、(いつになるかは未定だが)次期PCではUSB接続のDACにする(せざるを得ない)だろうから、その使い勝手も試したかった。

Scarlettの音を聴いてみると、最初は低音が豊かでパワフルに聞こえたが、実際には駄目な音だった。: 少し聴くと、豊かだと思われた低音は締まりがない こもった感じで、聴き続けたら少し耳閉感が起こった。あと、前のアンプ(改造後?)やイコライザ(BEHRINGER DEQ2496)をDACに使おうとした時にも あったのだが、音に雑物・不純物が混じっているような、ザラついたような埃っぽい感じ(要するに「音が悪い」)もした。

何が悪くて そうなっているか分からなかったので 接続や音量などを調整してみたが、改善できなかった。

それで、Scarlettの(ライン出力の)オーディオ特性を測定し、音が悪い原因を探ってみた。: すると、なぜか、振幅の周波数特性や歪みが局所的に変動する箇所があった。(→ グラフ1: 右下のインパルス, グラフ2: 左の山) また、歪みがかなり多かった(仕様の量を超えていた)ものの、決定的ではなかった。(→ グラフ)

それで、「仕様・特性がASUSより悪い(雑音: 約6倍, 歪み: 約10倍)ためだ」という、にわかには信じがたい※結論に なり掛けた。*

※というのは、確かにScarlettはASUSに比べると悪いものの、絶対的には、ダイナミックレンジは100dB以上だし、歪みも0.002%と大きくないからだ。これで駄目なら、普通の機器(すべてのCDを含む)は全部駄目なことになる。

*なので、この時は、「ハイレゾのオーディオ機器は本当に必要だった」という、それまでの持論を覆す結論にすらなり、そういう流れで書こうと思って居た。

ところが、その後、偶然にも問題の本当の原因が分かり、Scarlettの特性は充分良い(= 「最高」ではないが、実用には全く問題ない)ことが確認できた。

Scarlettの出力の接続の仕方が悪かった。: すっかり忘れて居た(というか、最初から意識して居なかったかも)のだが、Scarlettのライン出力は実はバランス(TRSジャック=ステレオ標準ジャック)で※、特性測定時にTSプラグ(モノラル標準プラグ)を使ったために負出力がGNDにショートされた*のが良くなかったようで、TRSプラグに換えて負出力を開放したら直った。 (→ プラグの比較, 参照: 「バランスーアンバランスのケーブル接続について」: 「4、電子バランスOUTPUT → アンバランスINPUT」)

それに気付く前も、歪みの多さからScarlettの出力アンプが飽和しているのかと思って、入出力振幅(レベル)を調整したりしたが、直らなかった。

※問題の原因が分からないので、何かヒントがあるかとマニュアルを見直していたら、仕様のところにバランス出力であることが書いてあって気付いた。

*バランスであることは忘れて居たが、無意識に(そこら辺にあった物を使って)した接続が偶然マニュアルどおりのアンバランスへの変換だった(けど、駄目だった)。

問題が起こる理由を考えるだが、今ひとつ分からない。: バランス出力だから出力アンプは正負別のはずで、しかも、正負それぞれの出力ジャックの前に直列抵抗が入っているだろうから、負出力をショートしても正出力側には影響は出ないはずだが、振幅が大きい場合に終段のアンプ(オペアンプ)の負荷が高くなって局所的に電源電圧が変動(低下)したためではないかと想像している。他に、アンプの発振や、GND電位が局所的に変動して正出力が変動することが考えられるが、実際に起こるのかは分からない。

(11/9 15:13) 想像を元にシミュレートしてみたら、やはり、負出力をショートしてアンバランスに変換した場合はオペアンプが過負荷になって居る可能性がありそうなことが分かった。

まず、Scarlettの回路図は手に入らないので、出力部が(僕の想像どおりの)AKMのDAC AK4393のデータシートにある回路例(「Figure 11. 外部LPF回路例 2」)のようになっていると想定した。※ シミュレーターを用いて、その回路の通常時(バランス出力)と負側をショートして(無理に)アンバランスに変換した場合をシミュレートした。

※が、もし本当にこのような回路で負側をショートしてアンバランスに変換させているしたら、それこそアマ以下だ。なお、AKMのデータシートでは、これのあとに ちゃんとアンバランス出力回路があるので問題ない。

すると、想像通り、ショートした場合にはオペアンプから大電流(5Vの場合、100mA前後)が流れることが分かった。

次に、同様に負出力をショートしてアンバランスに変換する方法をマニュアルに記載しているDEQ2496の出力回路(仕様には"servo-balanced"とある。: そのものは入手できないので、姉妹品DCX2496の出力回路を使った(→ 掲載例))でもシミュレートしてみた。知識が足りないため、この回路の動作が全然理解できないのだが※、出力をショートしてもオペアンプから大電流は流れなかった(5Vの場合、5mA以下)。

※それでシミュレーターを使った。シミュレート結果を見ていたら、ショート時と開放時の動作が ちゃんと連続していて、実に良く出来ていると思った。

まあ、Scarlettの回路は想像でしかなく、実際にはDCX2496と同様になっているのかも知れないが、電源off時のポップ音(DCX2496では ちゃんとミュートしようとしている。: 回路図の"AMUTE")といい、Behringerに比べて随分杜撰な作りをしているようなので、想像どおりなのかも知れない。そうであれば、僕の測定結果と推測が裏付けられる。仮にそうでなくても、いろいろ杜撰なので、どういう異常が起こってもおかしくないという想像は覆せない。実際に駄目だったし!

まあ、DCX2496の回路にも言いたいことがある(例: DAC(バランス)→アンバランス→バランス(XLR出力)でいいのか?)が、堅実だというのは確かだ。

(ここまで11/9 15:13)

 

(更にDEQ2496にもハマる・・・)

(11/10 1:04) ついでに、死蔵していたDEQ2496(以下、DEQ)がDACとして使えるかと思い、特性を測ってみた。※: 振幅は問題なかったものの、歪みは約500Hz以上が単調増加する ひどいものだった。他者の評価でもそういう傾向で、僕の測定が間違っている訳でなく、製品の作りが悪いようだ。* (とりあえず)歪み以外はASUSと同等なのに、詰めが甘いのか。もったいない・・・

※なぜかASUSのデジタル出力が うまく使えないため、別の出力(オンボードのRealtek)を使ったせいか位相が正しく測れなかったが、振幅と歪みは測れた。

*実際、アナログ部分をそっくり交換して特性を向上させる(本末転倒的なw)基板が売られていたくらいだから、筋金入りだw

なお、歪みがひどいので、上のシミュレーションが合わず、バランス出力をアンバランスに変換するのに負出力をGNDにショートしているのが良くないのかと思って開放したら、ものすごい雑音が出た。それで、正出力と負出力を使うようにしても雑音が大きかったので、DEQはマニュアルどおり、負出力をGNDにショートするのが正しい。

ということは、Scarlettも一応ちゃんと作ろうとしたけど、詰めが甘くて今ひとつなのかも知れない。

それから、昔はDEQをイコライザ兼DACとして使っていたが、このひどい歪みに気付かなかったか気付いても気にしなかったのは、全く しょうもなかった。

この歪みのせいで、DEQの音が悪く感じたのかも知れない。今日少し聴いた感じでは、耳閉感は起こらないものの、なんか落ち着いた・地味な感じ(高域がちょっと物足りない)に聞こえた。歪みの影響だったのだろうか。 (ここまで11/10 1:04)

(11/10 13:28, 17:19) DEQの歪みの原因が気になって回路図を見ていたら、ミュート用のトランジスタが悪いように思えた。シミュレートしてみたら、確かに繋がっているだけで高調波が出た。※(→ : 左下のスペクトラム) 更に、ミュート機能も不充分で、半分(正の信号)しか消せないことが分かった。* (→ : 右下の波形)

※BA3886でも 似たようなことがあった。その時はダイオードだった。

*あの回路は一見ちゃんと動くように思えるが、そうではなかった。トランジスタは片方向にしか電流を流さない。

それで、試しにミュート用トランジスタを無効にしてみたくなって基板を見たら、どうも回路が違うようだ。※: どうやら、トランジスタの代わりにリレーでミュートしているようだ。メーカーが駄目なことに気付いて改良したのではないか(実際、どこかに"Rev. 2"とか書いてあった気がする)。

※確かにトランジスタはあるが、配置が想定と異なるので、使われ方が違うようだった(リレー駆動用のようだ)。

リレーにしても、なぜか2回路のものが2個もあるのが理解不能だった。: 入力もミュートするのか、正負左右独立にミュートするのかと思ったが、どちらも無駄な気がする。

と思って再度DCX2496の回路図を見たら、入力にリレーが使われていた(入出力レベル切り替え用のようだ)。すると、別に出力ミュート用トランジスタがあるのかも知れない。 → もう少し探す。

→ やっぱりリレーでミュートしていた。どうしてか、ミュート時(リレーのコイルがoffの時)には出力を入力に繋げているようだ(ここは理解が浅い)。電源off時にパススルー的になって好都合と考えたのだろうか。

更に、(上のDCX2496の回路とは異なり、)アナログ基板内は完全にバランスで処理しているようで、そのためにリレーが2個(1個ずつ正負、左右で2個)実装されている。随分改良した感じだ。

ただ、そのミュートは電源on時には効くもののoff時には間に合わないのか、小さくポップ音がする。それは そうだろう。電源スイッチがメカニカルなので難しいと思う。

他に気になったのは、出力のサーボ回路で歪む可能性※で、その前(リレーの辺り)から信号を取り出せば比較できそうだと思って回路(部品間の接続)を解析しようとしたが、イメージと随分違って分からず諦めた。 → その後、上記のように概ね理解し、サーボ回路の前のバッファアンプらしきところから+側だけを取れば良さそうに思った。

※Scarlettの出力回路を想像している時に参考にしたページに、正側と負側のオペアンプの出力が微妙にズレる(正負で動作が違うため)というふうに書いてあったので、それが関係していると思った。

が、そもそも、信号の経路(カップリング)に普通の電解コンデンサが多用されていたりして元々音質への配慮が余りない製品だから、いくら頑張っても無駄な感じだ。なので、「もう これしかない・・・」状態になったら頑張ることにした。 (ここまで11/10 13:28, 17:19)

(11/11 17:05) DEQの歪みの原因が気になって、サーボ回路での正負の時間差と、0近傍での不感帯?(トランジスタのスイッチング歪みの類)をJACKでシミュレートしたが、今ひとつ合わなかった。シミュレートが良くないこともあるだろうが、どちらも2次から連続した高調波が発生して歪み率が周波数によらず ほぼ一定なのに対し、DEQでは奇数次だけが発生して、周波数に応じて増加するのだ。

諦め掛けた時に、少し前に読んだ「DEQはセラミックコンデンサが使われているから性能(歪み)が悪い」(その時は余り信用しなかった)というのを思い出して調べたら、本当にそのようだ。種類(それぞれの規格)にもよるが、電圧に応じて容量が変化する(高電圧で減る)とのこと。 (→ 参照) だから、基本的にはオーディオには向かないということだ。

もちろん、ちゃんと種類を選べばセラミックだって いいのは分かるが、何かを作る時に まずは失敗しないこと・安全性を目指すなら、「オーディオ回路にセラミックコンデンサは避ける」という馬鹿の一つ覚えでも、僕は いいと思う。「君子危うきに―」だ。失敗は掛け算(か足し算か不明w)で効いてくる。本質でないことにパワーを使う必要はない。

詳しくは確認していないが、例えば、ブログ:「コンデンサの歪率」の後半のLPFに使った時の周波数-歪み特性のグラフは周波数とともに歪み率が増していて、まさにDEQと同様の傾向だ。他の例では、通電してみんべ:「DACのアナログ追求⑧コンデンサその2」では歪みの傾向が逆(周波数とともに歪み率が下がる)だが、おそらく、左の例と違ってHPFにしているからではないか(未確認)。

全然知らなかった。以前どこかで読んでイメージとしては知っていたが、ここまで効くとは思っていなかった。安物の部品は駄目だね・・・

そして、仮にセラミックコンデンサがDEQの歪みの原因だとすれば、かなりの数を交換しなくてはならず(しかも小さい!)、非現実的だ(やってられない!!)。だから、上に書いた「全取っ替え」のアナログ基板が出たのだろう・・・

全部交換する前に、いくつか外して効果があるか確かめる手はある。想像だが、出力コネクタの直前にある、正負の出力とGNDの間にある2個(左右なら合計4個)が一番効きそうな気がする。もちろん やらない!w

ただ、僕のDEQに本当にセラミックコンデンサが使われているかは未確認だ。というのは、「セラミックコンデンサが−」のとはリビジョンが違うせいか、その写真とコンデンサの形状が異なっているためだ。僕のは良く見るオレンジの円盤状でなくチップ部品なので、種類が分からない。容量や色からして積層セラミックの気はするが、詳しくないので分からない。

DEQ2496のアナログ基板の入出力コネクタ付近(裏面): ベージュ色の四角がチップコンデンサ

(ここまで11/11 17:05)

 

(やっとScarlettに戻る)

Scarlettの出力プラグを直したら(写真: 下側(アダプタを挿したもの)のプラグを出力ジャックに挿し、上側を測定に用入力に繋ぐ)嘘のように特性が良くなり、ほとんどASUSと同様になった(下のグラフを参照)。

「今度は大丈夫か!?」と思って聴いてみたら、大分良くなった(かなりクリア・自然になった)ものの、やっぱり耳閉感の兆候が出る。いつものように その原因は分からず、「謎」としか言いようがないが、Scarlettには以下の気になる点がある。

  • 歪み: 振幅が大きい時に低域で増大する。(グラフ: 緑の左側の傾斜) → 入力の振幅を小さくすれば解消できそう。
    • これが一番もっともらしいが、他の機器でも起こることがあるので、測定上の問題や電源容量不足の可能性も考えられる。
  • 位相: 高域(6k-12kHz辺り, 特に9kHz)が不自然。 (グラフ: 右側の波の形の緑と他の違い)
    • 振幅特性のグラフを見ると分かるように、かなり急(グラフには出ていないが、20kHz以上の約2kHzで数十dB落としているはず)なフィルタのためのような気がする。
    • 測定に用いたScarlettのADCのフィルタの特性の可能性もある。
      • → 書いたあとで、JACKで使える数種類のフィルタ・イコライザで超高域(15kHz)をカットした時の特性を見た限りでは 上のような変な特性にはならなかったので、この不自然さはDACとADCのフィルタの特性が掛け合わさったためだと考えられる。 (18:36)
    • 音楽再生時に使っている、部屋の特性補正用イコライザの位相特性を調べたら、中低域は不自然なものの高域(約2kHz以上)では素直(単調減少)なので、これが関係あるのかも知れない。 (→ グラフ: 青: L, 赤: R)
      • もしそうなら、DAC出力のフィルタが選択できるものが良さそうだ。 (← 下記のように、僕には必須条件のようだ。: 18:36)
    • → 書いたあとで思い付いて、JACKで使えるフィルタ・イコライザで超高域(15kHz以上)をカットして試してみた。 (18:36)
      • フィルタは上のグラフに最も形状が近かったCalf plugin packのEQ5のHigh Shelfを使った(Q=1で傾きを最も急にした)。
      • すると、開始20分後から わずかに耳閉感の兆候が現れ、1時間後に耳閉感が起こった。
      • よって、高域の急なフィルタは耳閉感の原因の可能性が高そうだ。
      • また、今までの経験から、他の帯域(中低域)でも急なフィルタを使うと耳閉感が起こった(そのために「急さ」を制限している)ので、要するに、急なフィルタによる信号の劣化(おそらく位相の急変)が耳閉感の原因(の一つ)である可能性が高そうなことが分かった。
        • 実際、今のASUSのフィルタはデフォルトでは急なもの(fast)だが、(確か耳閉感とは関係なく、)「より自然そうだ」と思い付いて、緩いもの(slow)にしている。 (グラフ: 振幅, 位相: 青: fast; 紫, 赤: slow)
        • その効果があったかは不明だが、確かに、(良く書いていた)「それまで聞こえなかった音が聞こえた」とか、クリアに聞こえることが多い。 (19:14)
          • こういうところが、メーカーが「マエストロが経験と感性でチューニングした」とか うたうところかも知れないな(実際に やっているとすればw)。 (19:23)
    • また、ScarlettのコーデックのDACのフィルタの特性をslowに変えれば耳閉感を緩和できるかも知れないが、添付の制御ソフトですら出来なさそうなので難しそうだ(やる気・必要性が出たら、メーカーのFocusriteに聞いてみる)。 (18:36)
  • 振幅: ASUSと違い、20kHzまでフルに出ている。 (グラフ: 右端の下がり方の緑と他の違い)
    • そもそも僕は約15kHz以上は聞こえないし、15kHzくらいで切っているASUSでも耳閉感は起こるので、このこと自体は関係なさそう。

 

(11/9 19:35) 試しに、ASUSのフィルタを高域が より広く出る"fast"(上のグラフの"fast roll-off"の特性のもの)にして聴いているが、大きな問題はない。確かに、わずかに高音がキツい感じはある(それがfastの証拠?)が、耳閉感には なっていない。まあ、買った当初はデフォルトのfastで問題なく聴けていたのだから、当然ではある。

どうして大丈夫なのかは分からないが、ASUSは何かがいいようだ。だから、ASUSは僕に合っているDACだと言える。正確には、ASUSというより、それに使われているDACチップ(TI PCM1792A)を作った老舗Burr-Brown(その後TI)の功績が大きい。

ただ、良いDACチップを使っただけでは まともな特性や音は出ないので、ASUSの技術も重要だと言える。

あと、Scarlettのコーデック(Cirrus Logic CS4272)のデータシートを少し読むと、サンプリングレートによって動作モード(速度)が変わるようで、上で「不自然」と書いた44.1や48kHzは"single speed mode", 96kHz辺りは"double-", 192辺りは"quad-"となっていて、それに伴ってフィルタの特性も違う。だから、下のグラフの位相特性の違いも そのためだろう。なんで そんなクソな仕様にしたのだろう。

僕としては「全くない」。手抜きだ。こういう製品は どんなサンプリングレートでも同じ特性を出すべきで(でないとサンプリングレートで音が変わってしまう)、使うならサンプリングレートが固定の用途だ。そういうのをオーディオインタフェースに使って平気な顔をしている(それどころか、「音にこだわってこれ(CS4272)にした」とか書いているのを見た覚えがある)。見識を疑う。そもそも、その こだわった音がイマイチだ。まあ、僕とは全く合わない製品だったってことだ

そして、次のDACを買う時は少なくとも、Focusriteの製品とCirrus Logicのチップを使ったものは却下する。旧Burr-Brownのものがあればいいけど絶滅危惧種なので、AKMかESSしか選択肢はなさそうだし、今は入手性でチップどころかメーカーすらコロッと入れ換わるほどなので、音にこだわって選ぶのは難しい・・・

ASUSのDACチップの"PCM1792A"で検索してみたら、随分いいものらしい。しかも、僕はグラフを見ても良くは分からないが、フィルタが素晴らしいとのこと。(→ 参照1, 参照2) 我ながら耳がいいのかな? というか、そういうのでないと駄目だとすれば、なんと面倒な・・・

そして、昔、そのPCM1792Aを搭載したDAC(Styleaudio Carat-Topaz)を持っていたのだが、(音の良さや貴重さに気付かずに)手放してしまったのを今になって残念に思う。が、上にも書いたように、チップだけでは いい音は出ないので、「本当に音が良かったかは分からない」としておこう。

(ここまで11/9 19:35)

 

Scarlettの出力の接続方法の問題に気付く前は、音の悪さや耳閉感から、ASUSが壊れた時に新しいDACを買うとしたら、仕様・特性が ものすごく良いもの(少なくともASUS以上)でないと駄目かと思ったが、仕様・特性だけでなく、「音が良い」(正確には「自分に合う」)ものを選ぶ必要がありそうで、なかなか難しい。

この、「自分に合う」というのが、オーディオ機器にまつわる いろいろな謎の原因の一つかも知れない。大抵の人は、自分に合う(あるいは 好む)音が いい音だと認識・表現するだろうから。

耳閉感は ほとんどの方には起こらないだろうが、例えば、仮にレコードや真空管アンプには 耳閉感に限らず、各自が不快に感じる原因因子が少ないのだとすれば、それらを好む人の気持ちが理解できる。

あと、以前良く言われていた「デジタル臭い」とか「デジタルの音は硬い」というのは、上に追記したような、フィルタが良くないこともあったのではないかと思う。音楽の配布形態にデジタルが加わる頃は、(とりあえず、出すべきでない周波数をカットすることが最重要で、)フィルタの聞こえ方の評価までは充分に できていなかったのではないだろうか。 (20:26)

更に、仮にScarlettの耳閉感が解消したとしても、以下の実使用上の問題が見付かったので、そう簡単には入れ替えられなさそうだ・・・

  • スリープ時や終了時(Scarlettがoffになる時)に雑音(ポップ音)が出る。
    • 他の人も出ているので、どうにもならないようだ。もちろん、出ない機種(別メーカー)もあるから、メーカーが手を抜いたか そういう思想のようだ。
    • ScarlettのCodecチップ(CS4272)のデータシートにはミュートの回路の例が載っているが、それが有効に働くか(ちゃんと制御しているか)不明だし、正負左右の4回路を作るのは面倒だ。
      • それよりは、PCからスリープなどの前にアンプをミュートさせるほうが簡単そうな気がした。
  • PCの負荷が高い場合、「ジッ」という雑音が出ることがある。
    • プライマリ出力のASUSでは起こらないので、Scarlettから音を出すために使っているプログラムalsa_outの関係だと想像している。
    • alsa_outを使わなければいいかと思ったが、なぜか、JACKのプライマリ出力にできなかった。
      • JACKの設定が誤っていたようで、その後、プライマリに出来て雑音は出なくなった。
  • JACKからScarlettに音を出すalsa_outが今ひとつ不安定で、突然終了してしまうことがある。

以上のことから、ASUSがずっと壊れないことを祈るしかない。

 

(11/8 19:47) その後、寝ている時に、「Scarlettのフィルタ(LPF)のカットオフ辺りの特性が悪いなら、サンプリングレートを高くして(オーバーサンプリングして)カットオフ周波数を可聴帯域外に移せばいいのではないか?」と思い付いて、一日掛けて試したが(例によって)駄目だった。

寝ている時の思い付きに碌なものはないのだろうか??

いろいろ苦労してサンプリングレートを88.2kHzや176.4kHzにしてみたが、やっぱり耳閉感の兆候は出たし、音が悪い感じもした(疲れなどもあったのか、その後、耳鳴りまで出た)。それで、可聴帯域上限(20kHz)近くの音が出るのが駄目なのかと考えて、JACKで15kHz辺りで切るLPFを追加してみたが、効果はなかった。

結局、急なフィルタと可聴帯域上限(20kHz)近くの音(12-15kHz以上か)が耳閉感を引き起こすような感じだ。不思議なことに、ASUSでは問題ないので技術的に不可能ではないのだろうが、耳閉感を起こさないように(何らかの特性を良好に保って)高域を切るのは難しいようだ。

そこら辺が、「音の良いDAC(チップ)」という評判の正体(?)の一つなのかも知れない。

不思議なのは、サンプリングレートを変えてScarlettの特性を測ったところ、44.1kHzと48kHzだけがカットオフ周波数付近(当初は9kHz辺りが不自然だと思って居たが、比較するとカットオフ付近も変化が激しい)の位相が不自然だったことだ。それより上の88.2kHzや96kHzでは素直な特性だった。(グラフ: 黄緑: 44.1kHz, 紫: 48kHz, 赤: 88.2k, 水色: 96k) だから、不自然な位相は(上に書いた)測定に使ったADCのフィルタの影響ではなく、おそらく、Scarlettのコーデックの使い方が今ひとつなのかと想像する。

そこら辺は、「音の良いDAC(機器)」という評判の正体(?)の一つなのかも知れない。

44.1-96kHzのサンプリングレートでのScarlettの出力の位相の比較: 黄緑: 44.1k, 紫: 48k, 赤: 88.2k, 水色: 96k

そもそも、この思い付きの駄目だったところは、必要もないのにオーバーサンプリングすることだ。処理が増え、音が悪くなる(少なくとも良くはならない)から、いいことは何もない。そういうのはDACの中でやることで、このやり方に芽はない。

その他に、ScarlettのUSB Cコネクタ(ジャック)はプラグが上下に動くと接触不良になるようで、ケーブルを触ると電源が切れて音が切れてしまう問題が見付かり、Cコネクタ(無意味なんだからBやmicro Bにしておけば良かったのに!)が弱いのか、Scarlettや使ったケーブルの出来が悪いのか、それらの相性なのか分からないが、一応プロ用的なものなのに 随分お粗末な気はする。これでは収録中に落ちることがあるのではないか?

そう言えば、(上に書いたように、)マニュアルどおりにアンバランス接続したら駄目だし、電源off時にポップ音が出るし、まあ、「Scarlettは音が悪いうえに それ以外も いろいろイマイチだ」とガッカリし、これ以上深く関わっても おもしろいことは ない気がしている。 (ここまで11/8 19:47)

 

(ようやく本題に戻る。)

なお、そもそもの本題の時々出る雑音については、その後1-2度左から出たので、アンプは問題なさそうだ。また、DACをScarlettに入れ替えている時にも出たので、ASUSの問題でもなさそうで、ソフト(JACK)の可能性が高い。あるいは左のスピーカーや窓のシートの音かも知れない。: 原因が分かるには しばらく掛かりそうだ。

 

PS. Scarlettがバランス出力だったので、アンプもバランス入力に対応させれば わずかに音が良くなり(正確には雑音が減り)そうな気がしたが、まず面倒だし、壊す可能性が高いし、途中のボリュームをどうするんだという話もあるし、そもそも、使っているアンプ基板(ICも?)がアンバランスな気がするので止めた。まあ、僕には気分の問題だ。

PS2. 製品を選ぶ時にはレビューサイトが役に立つ。が、中にはメーカーから送られて来た製品を評価しているところ※があり、公平性に疑義があるとは言わないが、そうして出費なしで気軽に評価していいものかとか、評価対象に偏りが出ていいのだろうかと思う。

※どことは書かないが、なぜか変てこな日本髪(昔の結婚式?)の女性のアイコンの人のレビューが多いところ。

とは言え、日本の多くのメディアのような提灯記事ではない(客観的な測定結果に基づいている)し、メーカーから提供されたことを明記しているから、公平性には問題なさそうだ。

PS3. DAC(製品)を調べていたら、チップ単体について おかしなことに気付いた。: なぜかデータシートに歪み特性などの重要なグラフを載せず、フィルタ特性だけを載せているメーカーがある。: ESSとAKMだ。 (→ 例: ESS ES9038Q2M, AKM AK4393)

データシートには特定の点(例: 最大出力と小出力の2点)での値が載っているから、全く測定していない訳ではないようだが(当然だ)、なぜかグラフは載せたくないようだ。もちろん、外付け回路で大きく変わるのはあるが、開発した時のリファレンス回路での例を載せても誰も文句は言わない。そういうのがあれば、大いに選択や設計の参考になる。何か後ろめたいことがあるのか? 逆に、そういう情報がなくて、良く採用できるものだと思う。

例えば、ESSは、あるレビューサイトが指摘しているIMDの盛り上がり("ESS IMD hump")を放置しているようだ。(→ , スレッド: ESS THD ‘Hump’ Investigation(良く読んでない)) だからグラフを載せないのかと疑ってしまう。

おもしろいのは、上の例の記事に中国のメーカー(TOPPING)が その盛り上がりに対処できていると書いてあることだ。すごい。

だけど、グラフを見ると、問題の盛り上がりはないものの、最大振幅付近で盛り上がってしまっているので、完璧ではないようだ。それでも、歪みはかなり小さいので 大したものだ。

上に挙げたスレッドに解決策らしきもの(概略: I/V変換をESSの特性に合わせていないため(でも、そうするとアンバランス出力になってしまう)。: 全部読んでないので、確定かは不明)がある。以前から感心していたBenchmarkの人の投稿だ(そこのDACでは解決していて、その方法を書いてくれて居る)。

一方、TI(旧BB)は 様々なグラフを載せている(例: PCM1792A)。そして、今はそのTIのHi-Fi DACを載せているものは ほとんどなく、まったく希少になって居る。

技術者としては、ESSやAKMの態度(弱気とか卑怯)が全く許せないので、その点でTIのもの、しかも、最高峰と言われているPCM1729Aを使った 良いDACが欲しい。が、もう絶滅しているようだ。ますます今のサウンドカードが壊れないことを祈るしかない・・・ (11/12 20:49)

 

(11/8 19:47 Scarlettで追加で試した結果などを追記; 11/9 5:33 わずかに加筆, 15:13 バランスをアンバランスに変換する回路のシミュレーションなどを追加, 19:35 ASUSをfastで試した結果とScarlettのコーデックがクソな件を追加。おそらく完結; 11/10 1:04 DEQ2496の測定結果について追加。本当に完結?, 13:28, 17:19 DEQ2496の回路について調べた結果を追加, 19:30 題を変更; 11/11 7:17 小見出しを付けた。, 7:29 わずかに修正, 17:05 DEQの歪みの原因がセラミックコンデンサだかららしいことについて追加, 19:12 小見出しをわずかに修正; 11/12 7:28 わずかに変更・修正, 20:49 PS3を追加)

  •  1
  •  0

実際の化ける・詐欺メールで動作確認してから公開しようと思っていたが、どちらも いつ来るか分からないので(分かっているのは文字化けが今月末)、とりあえず公開する。誤りや修正があれば、その都度更新する。

文字化けの暫定対処

メーラーは(Thunderbirdに業を煮やしたため)Evolutionを使っていて、概ね問題なく使えている。が、ある会社から来るメールが文字化けすることがある。分かっている限り、化けるパターンは2つあって、以下である(文頭を抜粋)。

  • 「㈱クレ」 → 「螢レ
  • 「コス」 → 「●(I:=
    • 注: ●は(とIに重なっている。

最初はEvolutionの日本語対応が今一つなのかと思い、もしかして送信するメールも化けることがあるのかと思って、心配していた。が、近頃 やる気が出て詳細に調べたら、そうではなかった。上の2種類の問題は、元のメールのcharsetがISO-2022-JP(7ビットJIS)の時に起こり、化ける原因は以下だった。

  • 「㈱」のような特殊な文字※がある場合(?)、なぜかその先頭と次の文字の最後の1バイトが抜ける。
    • 元のコード: 2d 6a 25 2f 25 6c : 「㈱クレ」 (下線のまとまりで それぞれ1文字。取り消し線の文字が抜けて化ける↓。)
    • 化けたコード: 6a 25 25 6c : 螢レ
    • ※「文字コード表 JISコード(ISO-2022-JP)」によれば、これはJIS X 0208 (1990) to Unicode変換表にない文字で、それらが駄目なようだ。
  • 半角カナ(正確にはISO-2022-JP-MS)は非サポート(正しく表示できず、全角に変換も されない)。
    • 元のコード: 1b 28 49 3a 3d : 「ESC (Iコス」 (ESC ( IはISO-2022-JP-MSの開始を示すらしい。 (→ 参照) コスは半角カナ)
    • (化けた)コード: 1b 28 49 3a 3d (元の半角カナのISO-2022-JP-MSのコードがそのまま出る。 → ESCは●になり、そのあとの記号とカナはASCII文字と解釈される。)

元はと言えば、メールを送って来る会社が「ちゃんと」(特殊な文字や半角カナは使わない)すればいいのだが、そもそも、メールにそれらを使うことを禁止する規則はない(ないこともないが、強制力はない)ので、一般的なアプリ(例: Windowsやスマフォ)で ちゃんと出るようにしているなら文句は言えない。

その会社にしても、情報提供元からのテキストを勝手に変換して誤変換などでトラブルが起こるリスクを抱える気・価値はないだろうから、元のまま送るのが適当だろう。

それで、簡単な対処(ちゃんとやるには それなりの手間が掛かる)を試行錯誤したところ、nkfコマンドで何とかなることが分かった。下のようにすれば、ちゃんと表示できるようだ。 (注: 本物の化けるメールでは未確認)

  • ヘッダのContent-TypeのcharsetがISO-2022-JPの場合は特殊な文字があるかも知れないので、本文をnkfに通す。(nkfが「うまく」やってくれるようだ)
  • 上に加えてContent-Transfer-Encodingがquoted-printableの場合は半角カナがあるかも知れないので、本文をnkf -mQに通す。(上と同様にnkfが「うまく」やってくれる)
  • 上のいずれかの結果をEvolutionに入れる(メールとして送る)。

そして、Evolutionのメッセージフィルタの機能でメールを外部コマンドにパイプで送ることができるので、上の処理をするスクリプトに送り、化けた可能性のあるメールを修正(nkfでコード変換)して自分(のデスクトップのローカルなアカウント)にメールで送るようにした(それを再度Evolutionが受信して、正しく表示される)。

処理を簡易にしているためと化けるメールがマルチパートなので、変換した本文の先頭にContent-Typeなどが入ってしまうが、まあ使えそうだ。

 

書いたあとに確認していて「ISO-2022-JPとISO-2022-JP-MS」というページを見付けて気付いたが、「㈱」の化けの原因もISO-2022-JP-MSなのかも知れない。「㈱」も変換表にないことから「環境依存文字」で、ISO-2022-JP-MSで追加された文字なのではないだろうか? そうであれば、メールを送る側がcharsetに"ISO-2022-JP"と書くのが良くないのだろう。

それなら、nkfで変換するのでなく、charsetを"ISO-2022-JP-MS"に置換すればうまく行くのかも知れないが、Evolutionが対応しているか不明なので、今は何とも言えない。

 

詐欺メールチェックの補助

それから、近頃Amazonを騙るメールが時々来るようになった。全部中国のドメインからなので、AliExpressか その店、または、そのあとで握力計を買った楽天の店(中国製品を扱っている)から漏れたのではないかと想像している。

そういうメールは、最初に詐欺と見抜いたらEvolutionのスパムフィルタに指示すれば、以後は自動で判別されて見えなくなるから、大きな手間やストレスではない。が、もう少し補助したくなった。

詐欺メールのヘッダを見ていたら、DKIM-Signatureがある場合があることに気付いた。その内容をdkimverifyコマンド(→ 参照1, 2)でチェックしたら※"ERROR:root:missing public key: default._domainkey.Xyz.co.jp."(ドメイン名は架空)のようなエラーになった。

※dkimverifyには-vを指定すること。

わざわざ、チェックしてエラーになるsignature(署名)を付けるのも間抜けだが、更に間抜けなアプリは騙せるのかも知れない。

そこで、上の文字コード変換と同じような段取りで受信メールのDKIM-Signatureをチェックするスクリプトを作り、Evolutionのメッセージフィルタは戻り値がエラーだったら「DKIM不正」のラベルを付けるようにした。

なお、Evolutionが文字コード変換をするのか、正常なメールでもbody hash(本文のハッシュ)が合わないというエラーが出るので、それは無視するようにした。それだと本文が改ざんされても分からないが、さすがに そこまで手の込んだものは少ないのではないだろうか。

↑ Evolutionの設定を見て気付いた。: Bogofilterのオプションの"Convert message text to Unicode"のせいでメール本文が変換されてハッシュが合わなくなっているかも知れないので、スパムフィルタを(変換する設定のない)SpamAssasinにしてみた。: 次のDKIMがあるメールで本文のハッシュが合うかで分かる。

→ SpamAssasinにしても合わなかったので、Convert message-は関係なかった。そもそも、BogofilterでもSpamAssasinでも、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だった。 (10/9 6:39)

Bogofilterのためにメール本文をUnicodeに変換しているのなら、文字化けもそれが原因かも知れない。EvolutionがISO-2022-JP-MSをそのまま(Unicode(UTF-8?)に変換せずに)表示できるなら、化けないのではないか?: 次の化けそうなメールで分かる。

→ 上述のとおり、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だったので、関係なかった。 (10/9 6:39)

また、想像や期待だが、SpamAssasinの"Include remote tests"を有効にすれば(しなくても?)、ひょっとしてDKIMのチェックもしてくれる気がしたので、有効にしてみた。: これも次の詐欺メールで分かるはずだ。

Wikipediaによれば、SpamAssasinはSPFやDKIMにも対応しているようだ。

でも、今後は本文を改ざんするものが出るかも知れない。メールの中継サーバを乗っ取ればできるだろうか。

こうすれば、不正なDKIM署名を付けた間抜けな詐欺メールはメールのラベル(色)だけで分かるので、自分で判断する手間が省け、誤認する可能性が減りそうだ。 (注: 本物の詐欺メールでは未確認)

 

PS. Ama.を詐称するメールをAma.のそういう窓口に転送すれば何かしてくれるかと期待して数通送ったが、結局また来た。別のところから来ているのかも知れないが(確かに、今までのものは大きく2種類ある)、それも含めて意味がないと感じた。

不正アクセスと同様に、そういう組織を根絶やしにしない限り、ゴキブリのように次々と現れる。「来たら対処する」のような対症療法では駄目だ。

 

(10/8 6:53 いろいろ修正; 10/9 6:39 Bogofilterの"Convert message text to Unicode"を止めた結果(関係なし)を記載)

  •  0
  •  0

先日ちょっと書いた、ブログにボットが良く来る件でアクセスログを見ていたら、不正ログイン試行や悪質なアクセス※が結構多くて気になってしまった。

※例: シェルのコマンドを実行しようとするもの、大量のバイナリデータを送って来るもの。

以前にも何度か、目に付いた時に そのアクセス元近辺のIPアドレスをブロックするように設定したのだが、設定するスクリプトを変更するのは面倒だし失敗する可能性があるので、ブラックリストのファイルにIPアドレスを書いて、適宜追加できるようにしてみた。動作確認した時は うまく動いたのだが、たまたま翌日にカーネルの更新で再起動になった あとは繋がらなくなってしまった・・・

それでサーバ(VPS)のコンソールで調べたら、起動はしているもののNWが全然使えない状態になっていた。: ホスト名の検索(DNS)は駄目だし、プロバイダのDNSサーバにすらpingが通らなかった。

ログを調べると、networkd-dispatcherが"Unknown state for interface NetworkctlListState"という訳の分からないエラーを出していた。更新されたカーネルの問題・相性を疑っていたのだが、検索しても ほとんど出て来ないので、僕の環境の問題だと思った。

結局、(上のエラーの前に出ていたのだが、)systemd-networkdが起動しなくなっていたためにNWが使えなくなっていた。その原因は、上に書いたブラックリストのために追加した処理にバグがあり、必須のNWアクセスも遮断するようになっていたためだった。

そのバグというのが しょうもなくて、たった一個の余計な空白(下の $var のあと)が原因だった。シェルスクリプトに

if [ -n "$var " ]; then

のように書いてしまったのを気付かなかった(近眼+老眼+白内障(進行中)のコンボに加え、そもそも眼が不調だ)。$varが空の場合に以降を実行するのに、これでは 全く実行されない。その処理が重要で、実行されないとNWが全部遮断されてしまうのだ。。。

そもそも、空かどうか調べるのに"$var"のように " で挟んで書くのが良くなく(しかも面倒)、もっと間違い にくい書き方がある気はするが、今まで見たことがない。少し考えたい。

そこを直してサーバは回復し、ファイルに入れたブラックリストも ちゃんと動いた。

 

そして更にもう一個、隠れた問題が見付かった。Linuxの仕様なのか、NW-IFを有効にする前のスクリプト(/etc/network/if-pre-up.d/*)が何度も実行されるのだ。僕は そこに上述の悪質アドレスのブロックを設定するスクリプトを入れたのだが、今回初めて、それが何度(4回)も実行されていることに気付いた。

内訳は、実際のNW-IFに対するIPv4, IPv6が各1回、全体に対するもの?(IFACE="--all")、loopback(IFACE="lo")だった。

もちろん使う前に調べれば分かる・調べるべきことだが、余りにも おかしな・杜撰な仕様だ。今まで問題なかったので、スクリプトは何度実行されても問題ないようだが、念のため、一度だけ実行されるように修正した。

スクリプトに渡される環境変数のMETHODが"none", IFACEが"--all"の時だけ実行するようにした。ただ、これはどういう契機なのか分からず、将来は なくなるかも知れないので、実行されなかったら警告が出るようにした。

 

起きてから延々と作業して午後遅くまで掛かったが、そもそも、こんなIPアドレスのブラックリストなんて意味ないことに気付いた。

まず、不正・悪質なアクセスをするサイト(のIPアドレス)は無限にある。※ 良いブラックリストを手軽に入手できないかと検索したら、山のようにブラックリストが出て来たが、それらの いくつかと僕のブラックリストに共通のアドレスはなかった。

※今はまだIPv4がメインだが、v6なら本当に無限だ。それに、v6のアドレスは(プライバシー処理のため)基本的に「日替わり」だから、アクセス時のアドレスに永続性・再現性はない・・・

仮に 良いブラックリストを合わせて使うにしても、無限に多くのアドレスでフィルタリングできる訳はなく、段々重くなり、最後は破綻するだろう。

そして、悪質サイトはブラックリストに載ったらアドレスを変えるだろう。載らなくても随時変えるのではないか?※ 実際、以前アクセスして来たアドレスは、(ログを見る限り、)何度か失敗したあとはアクセスして来ない。それに対応するために余分な幅(例: v4なら256-65536個?、v6なら264個??)を持たせてブロックするとしたら、そのプロバイダの他の人までアクセスできなくなる。

※日本ではそうだが、固定IPアドレスの人が少ないこともありそうだ。そもそも固定にする意味がない。更に、上述のようにv6は基本的に固定でない。

そうやっているうちに、誰もアクセスできなくなりそうだ。

だから、IPアドレスでブロックする仕組みを作りは したし、定期的に不正・悪質なアクセスを調べようと思っては いるが、無意味だと思う。どこかで見たが、リアルタイムに挙動で判定するのが良さそうだ。それがWAFなのだろう。

手軽に使えるものがあるか、気になるところだ。

(23:30) 少し探したら、手軽(無料・簡単)なWAFは なさそうだが、無料のものは いくつか見付かった(例: NAXSI, ModSecurity)。

が、インストールや設定は容易では なさそうなので今後の課題とし、まずは現状の脆弱性などの問題をチェックしようとした。: Nikto2というツールとオンラインのスキャナ(例: InnuniWeb, Mozilla Observatory (HTTP), SSLTrust Free Website Safety & Security Check, WordPress Security Scan)を使った。その結果、軽微な問題は見付かったものの、概ね大丈夫そうだった。

ただ、脆弱性に関して余りチェックをしないもの(HTTPヘッダ辺りが中心の感じ → クライアントに被害を及ぼさないかがメイン?)が多かったので、もっとサーバにキツそうなもの(例: w3af, OWASPのいろいろなツール)でチェックする必要がある。

とりあえず、チェックで見付かったHTTPヘッダ周りの問題を修正した(できないものもあった)。

  • WebサーバとWPのセキュリティプラグインAll In One WP Securityが同じヘッダ(X-Frame-Options: SAMEORIGIN)を出していたため、設定値がおかしい(重複している)という警告が出たので、プラグイン側(Misc. → Frames → Enable iFrame Protection)を解除した。
    • 最初は どうして重複するのか分からず、苦労した。
  • (サーバ・OS依存のようだが、)ETagはリスクがあるとのことなので削除した。
  • httpsでのgzip圧縮にはリスクがある(BREACH攻撃)とのことだが、問題の起こらないタイプだけに制限しているので問題ない。
  • 一番の問題は、Content Security Policy(CSP)に対応していないことだ。: ページの修正が要りそうなので、容易には対応できない。

その他に、TLSの問題・互換性をチェックするものもあったので(例: Observatory (TLS), TLS Checklist inspector)、チェックして修正した。

  • 今はTLS 1.3に移行しつつあるようなので、(obsoleteらしい)1.1を止めて1.2と1.3に対応させた。
    • AEADというものに対応していなかったので、対応させた。
    • 1.3に対応させる時、Mozillaの、サーバの設定例を作るページが役に立った。
      • が、その設定と他のチェックが競合・矛盾する場合があって、(細かい問題ではあるが、)どうするか悩ましい。

あと、SQLインジェクションについても いくつかツールが見付かった(例: sqlmap, jSQL Injection)ものの、そもそもSQLインジェクションを良く理解していないので、正しくチェックできる方法を考える必要がある。

良く考えると、(考えなくても、)SQLインジェクションどころか、サーバのセキュリティ向上は2年以上前からTODOに入っており、今回も少ししたら忘れた振りをして放置する気がする・・・

 

PS. 全くの脇道だが、HTTPヘッダ関連を修正している時、Mozillaの設定サンプルにHTTP/2の設定もあって、調べたらサーバは対応しているので(もちろん、パフォーマンスが劇的に向上するなんて期待は しておらず、興味本位で)ちょっと試したくなった。

が、この「ちょっと」が いつもトラブルを招くのだ・・・w (9/24 8:31)

(9/24 14:39) やっぱり、ちょっとHTTP/2にしてみたw 今度は大きな問題は起こらず、webサーバの設定にHTTP/2を追加しただけで すんなり動いた。ただ、予想どおり、HTTP/2にしても速くならないどころか、わずかに遅くなった(例: このブログは約3%(約11ms)遅くなった)。ページの生成は並列に できないので、基本的には仕方ない。とりあえず試したかったのと、世の中の流れに追従するのが目的なので、まあいい。

このサーバをHTTP/2に対応させた。: Vivaldiの開発者ツールでプロトコル(中央辺りの"Protocol")がHTTP/2を示す"h2"と出ている(最後の"http/1.1"は外部サーバのもの)。

HTTP/2にしても速くない(遅い)原因を考えてみたら、当たり前の気がする。: そもそもHTTP/1.1では複数の接続で同時に転送していたのを、わざわざ1本(想像)にまとめて その中で多重化しているのだから、スケジューリング・多重化・非多重化処理が増えて遅くなりこそすれ速くなる訳がない。

HTTP/1.1の複数の接続では両端の機器や経路へのリソース的な負荷が重くなるが、それが問題なければ、1本にまとめるより ずっと効率が良いと思う。

あと、ヘッダをバイナリにするとデータ量は減るだろうが、元々ものすごく大きいものではないし、エンコード・デコードの処理が増えるから やっぱり少し遅くなるだろうし、ボディ(本体)は もともとバイナリ可なので、何も変わらない。

結局、接続を減らして処理が多くなるのに速くなるという理屈が不思議だ。HTTP/2はリソース面でエコだとは思うが、速度は期待できない。

不思議なのは、JoplinのデスクトップアプリがHTTP/2を使わない(なぜかモバイルアプリは使う)ことで、最新版に更新しても同じだった。良く分からないが、Joplinには構わないことにしているので良い。

他のアプリでは、PC(Linux)ではEvolutionは1.1だったが、意外にもSeamonkeyは2だった。Thuderbirdの新しいコードを取り込んでいるのか。スマフォ(Android)ではDAVx5は2だった。

作業に付随して起こった ちょっとした問題(これで疲れた)は、CLI版を更新したら なぜか起動しなくなり(以前もそうだったので、頭に来て更新しないことにした気がする)、ちょっと調べたらnodeのモジュール@aws-sdk/middleware-endpoint※が不足していたので、自分でダウンロードして追加したら動いた。

※パス: ~/.joplin-bin/lib/node_modules/joplin/node_modules/@aws-sdk/middleware-endpoint

構成ファイルが駄目なのか、nodeのバージョンの関係か。誰も指摘しないのが不思議だが、Joplinには構わないことにしているので、ここまでとした。

(9/24 18:12) 下のPS2にも書いたが、正直言ってHTTP/2はイマイチなので(実際、すぐにHTTP/3が出た)、対応したばかりだが止めた。処理が複雑な割に効果がないし、余計な機能はバグなどを生んでセキュリティ上のリスクになるから、ないほうがいい。

PS2. ようやくHTTP/2に追い付いたと思ったら、HTTP/3が出て居た。開発者ツールでGoogleのサイトを見ていたら"h3"というのがあって気付いた。今度はQUIC/UDPベースだそうで、応答は速そうだ。となると、結局HTTP/2はイマイチだったようだwww でも、HTTP/3も目論見ほど いいのか疑問はある。 (9/24 17:31)

  •  0
  •  0

(他にも書きたいことはあるが、眠いので軽く。)

近頃、ちょっとしたことが いつの間にか良くなっていた、あるいは、わずかな手間で良くなった。

一番はVivaldi(Linux版)+日本語入力(Fcitx+Mozc)とツイッターの相性問題で、以前は日本語が まともに入らなかった※のが、ちゃんと入れられるようになった。ただ、元々他のサイトでは起こっていなかったので、ツイッター側の問題だったのかも知れない。

※入れている途中で消えたり、文字が抜けたり、消した文字が残って居たり・・・

少し前は、DM(チャット)は まだ今一つな感じもしたが、今は大丈夫かも知れない。

何だか分からないが、とりあえず直って良かった。

次もVivaldiとツイッターだが、ツイート中のビデオの再生開始直後と終わってから少しの間、ブラウザが動かなくなっていたのが解消できた。これは何かが直った訳でなくVivaldiの設定の問題だった(Tabs→"Mute Tab Audio"を"Prioritize Active Tab"から"All Tabs"にした)。本当は元の設定が いいが、無理なものは仕方ない。

最後は、このブログで使っているWordPressが、いつの間にか画像のlazy loading(遅延読み込み)をサポートしていたことだ。僕は、結構前にそのためのプラグイン(Lazy Load - Optimize Images)を入れていたのだが、挙動が ちょっと気に入らなかった(画像の出方が もったいぶっている、それで遅く感じる)ので、早速無効にした。

WPのlazy loadingは そうなっているのが全然分からないので、本当に働いているのか疑って開発者ツールで調べたら、ちゃんとページのスクロールに合わせて画像のアクセスが起こって居たからOKだ。 (→ 画像: 上半分あるいは下の右半分の右側にポツポツとある点のところで、画像を遅延読み込みしている。) きっと、画像が表示される直前に読むのだろう。賢い。某プラグインのように、画像が出てから変に凝ってフェードさせて出すなんて愚の骨頂だ。

WPのlazy loadingでのネットワークアクセス (Vivaldiの開発者ツール)

  •  0
  •  1

最初に断ると、正確には「(Linuxなどの)疑似乱数生成器(PRNG)の一様性の問題」だ。乱数自体の話は いろいろあるだろうけど、それではない。

前の稿に書いたように、乱数で画像の表示順序をランダムにしようとしたら、全然一様でなくて、偏りが大きくて  ばっさり棄てた。頻度の最多と最少の比が2以上もあるのでは、全く使えない。 (実験結果を最後に書く)

単に試行回数が少ないせいなのかと思ったが、階級(分類)数約30に対して1000回実施しても偏りは解消しなかった(約1.8)ので、永久に解消しないように思う。

ある掲示板で見たのだが、僕と類似の質問に対して、統計あるいは数学のプロらしき人が、「そんな試行回数じゃ全然足りない。文句を言う前に統計を勉強しろ」みたいな偉そうなことを書いていた。そういう連中は10万回とかが最低レベルで、基本は「無限の回数」なのだろうが、そんな前提では全く実用にならない!

そもそも、一様な乱数なら、なぜ試行開始から しばらく または ずっと 偏りが生ずるのだろうか? 階級数は少ない(= 狭い)ので偏る理由がない。確かに確率論的には ばらつくこともあり得るが、階級の数より充分大きい(例: 30倍)回数でも依然として偏ったままなのはおかしい。確率論での「充分大きい」は1000倍とか1万倍なのだろうか?

不思議なのは、それを使っているであろう多くのアプリケーションが問題ないことだ。僕の使い方が悪いのか、偶然問題が起こらないのか、そういうものなのか、実際には問題があるけど隠れているのかのどれかは分からない。

 

以下、細かい話である。

上に書いた、乱数のバラつき(階級数29の場合、最多と最少頻度の比が大きい)が気になったので、Linux、特にPHPで使える乱数機能を いろいろ試してみた。

なお、試行回数は階級数(29)の20倍の580回とした。また、頻度の集計には、Stack overflowの"How to generate a random number from a uniform distribution in php?"の回答1に書かれていたものを使った。

以下に、試した方法ごとの最多と最少頻度の比を示す。なお、実行するたびに比は変動するので、2回実施した。

1回目

  • PHP: rand: 5.6※
  • PHP: mt_rand:2.7※
  • PHP: random_int: 2.4
  • PHP: statsパッケージのstats_rand_gen_iuniform: 2.8
  • /dev/urandom (4バイト読み出し): 4.7 (処理に誤りがあったので取り消し。やり直した値はPSを参照のこと。)
  • opensslコマンド(openssl rand 4)*: 3.0 (処理に誤りがあったので取り消し。やり直した値はPSを参照のこと。)
  • shufコマンド(shuf -rn 1 -i 0-MAX): 2.5
  • Python: numpy.random.uniform*: 6.7
  • rand+僕の改良案2@: 2.3

2回目

  • PHP: rand: 2.6
  • PHP: mt_rand: 2.6
  • PHP: random_int: 2.7
  • PHP: statsパッケージのstats_rand_gen_iuniform: 2.8
  • /dev/urandom: 3.1 (処理に誤りがあったので取り消し。やり直した値はPSを参照のこと。)
  • opensslコマンド: rand: 2.8 (処理に誤りがあったので取り消し。やり直した値はPSを参照のこと。)
  • shufコマンド: 2.6
  • Python: numpy.random.uniform: 4
  • rand+僕の改良案2: 4.1

メモ

  • ※ ドキュメントではrandとmt_randは同じものなので、差が出るのはおかしい。mt_randをrandのあとに実行した関係があるのだろうか。実際、2回目はrandとmt_randの比は近かった。
  • * Pythonのnumpy.random.uniformは/dev/randomを使っているのか、随分時間が掛かった。opensslのrandも遅かった。
  • @ randの出す値の密度や間隔と実際の値域のそれが異なることが悪いのかと思い、階級数より充分大きな範囲の乱数から縮小するようにしてみた。要するに、浮動小数点の乱数(0〜1)を任意の範囲の整数にする手順にしてみた。また、結果の整数の乱数を出すのに、以下の2とおりを試した。
    • 案1: mod(剰余)
    • 案2: 除算

 

結局、比較的少ない試行回数ではPHPのrandom_intとshufコマンドが一番一様そう(2.6付近)で、その次はstats_rand_gen_iuniform(2.8)となった。stats_rand_gen_iuniformは安定しているところが良さそうだ。

randやmt_randは悪くないが、変動が大きそうだ。opensslのrandは良くはないが、比較的安定している。なお、Pythonのnumpy.random.uniformや/dev/urandomは今一つだった(後者は使い方が悪いのかも知れない → opensslとともに整数化の処理に誤りがあったので値を取り消した。: 9/15 10:26)。

(9/15 9:03) numpy.random.uniformについては、参考にしたページにある分布のグラフは ほぼ平坦で、これなら許せる(と期待して試した)。その試行回数は10000回(個)なので、階級数(そこでは10)の1000倍くらい試行しないと一様にならないのかも知れない。この、どれだけ繰り返せば充分かというのは、どうすれば分かるのだろうか? また、本質的に そうできない用途では どうするのだろうか?

(9/15 9:12) と書いたあとにグラフを良く見たら、上の例で生成している乱数(グラフの横軸)は整数でなく浮動小数点数だった! 僕は整数に丸めて評価したので、その辺りに問題があるのかも知れない。丸めについては僕も気になっていて、上述の改善案で試行錯誤したけどうまく行かなかった。

グラフを目で見た時と同様に、積分して整数にすればうまく行くだろうか? 面倒なことだ・・・ ← 丸めるのは積分(個数を求める場合)でなく単なる整数化(例: 四捨五入)で良いから、問題なかったはず。

いずれにしても、僕にはまったく許容できない偏りである。

そういう問題または仕様あるいは注意事項があるなら、ドキュメントに書くべきだと思うが、まったく見たことがない。せいぜい"cryptographically secure"かどうかだけだ。

僕に言わせれば、こんなに偏るものがsecureとは思えない。まあ、見るところが違うのだろうけど。

 

(9/16 13:59) 元々の用途(このブログの「時替わりギャラリー」)に対する うまい対処方法(workaround)を思い付いた。: 画像を替えるのに乱数(PHPのrand)を使うが、それで次に表示する画像の番号を直接決めるのでなく、乱数と現在の画像の番号を加えたもの(と画像数の剰余(mod))を次の画像の番号にするのだ。現在の画像番号をn、全画像数をNとすると、次の画像番号n'は以下の式で得られる。

n'= (n + rand(1, N-2)) % N

rand: 整数の乱数: 引数: 最小値, 最大値
%: 剰余

これなら、仮に乱数に出やすい値xがあっても、今の画像からx枚目の画像が出やすくなるだけで、いつも同じ数種類の値(しかも、それらが画像数と「いい関係」にある)が出るのでない限り、特定の画像が出やすくなることは起こりにくいと考えられる。

が、実は そうでもないというオチはないか?: 少なくともrandは今の画像の番号は分からないので、特定の画像が出やすくなるような値は出せないはずだ。あるとすれば、周期的に同じような値が出ること(上の「いい関係」)だろうか? 考えると難しい(面倒だ)。

(9/17 16:28) ところが、そうは問屋が卸さなかった。表示される画像をチェックしていたら、やっぱり良く出るものがあった。想像だが、上のように乱数に何かを加えたものも元の乱数と同じ性質であり、その元の乱数に良く出る値があるなら良く出るスキップ数となり、そのスキップ数と全画像数の関係(割り切れるか)にも よるだろうが、結局同じ画像が良く出るのではないだろうか。

結局、ギャラリー内の画像の順序のとおりに表示するように戻した。

(9/18 12:22) その後、擬似的な乱数としてページのアクセス時刻(正確には この処理を開始する時の時刻, μs単位)を使ってみたが、不思議なことに やっぱり一様でなく、良く出る値(→ 良く出る画像)と全然出ない値が生じた。

例えば、(回数は多くないが、)71回(約4時間分)のアクセスでは、最高に出た値の頻度は最小(1回)の5倍だった。出ない値は2個で、全体の平均は2.6回だった。

アクセス時刻(の階級数での剰余)がある時刻に集中するとは考えられないので この原因も謎だが、出ない3個(各1回と想像)が出やすいところに回って、平均の2.6+2 → 5回になったのかも知れない。

画像数(= 階級数)が29個と、10の倍数でないなのが関係していることも疑った。: アクセスはランダムな時刻に来るが、その時刻を階級(各画像)に振り分ける時に偏りが生ずるのではないか? ただ、時刻は100μs単位(0-99)のように区切っては いないので、剰余が偏りを生むとは思えない。

が、頻度分布を見ると、後半の12から25までの頻度が比較的多いのが気になる。その幅は13で、100と29の剰余に合う。また、頻度の高い区間が始まる12は13-1だ。単なる偶然とは思うが不思議だ。

だから、これは たまたまアクセス時刻が偏ったためで、回数を多くすれ(長時間、数日?見れ)ば均等になるのだろう。が、僕には、起動後数時間経っても偏りが直らないのは許容できないので、この方法もボツにした。

 

PS. Pythonのページに関する追記から、試行回数を増やして一様性を比較してみたら、どうやら、階級数x500回以上試行すれば、僕が満足できる一様性(最多/最少が概ね1.2 → ばらつき20%以内)に できそうなことが分かった。 (9/15 10:37)

試行回数と各方式での最多と最少頻度の比を示す。

29階級x20回= 580回: 2.5辺り (Pythonは3辺り、opensslは5辺り)

  • PHP: rand: 2.38
  • PHP: random_int: 2.64
  • /dev/urandom: 2.42
  • shuf: 2.31
  • openssl rand: 4.5
  • Python numpy.random.uniform: 4.83 2.9

29階級x500回= 14500回: 1.3辺り (random_intとshufとPythonは1.2辺り)

  • PHP: rand: 1.26
  • PHP: random_int: 1.19
  • /dev/urandom: 1.26
  • shuf: 1.21
  • openssl rand: 1.31
  • Python numpy.random.uniform: 2.07 1.2

29階級x1000回= 29000回: 1.1辺り (random_intとshufは1.15辺り、Pythonは1.2辺り)

  • PHP: rand: 1.11
  • PHP: random_int: 1.15
  • /dev/urandom: 1.11
  • shuf: 1.24
  • openssl rand: 1.11
  • Python: numpy.random.uniform: 2.26 1.19

本文で懸念したように、/dev/urandomとopenssl randの使い方(整数化の方法)に誤りがあったので修正した。

また、Pythonの一様性が悪いのは、使い方が良くないせいかも知れない。 ← (9/15 13:42) Pythonのnumpy.random.uniformの出力に想定外の問題があった。: 生成する乱数の最小, 最大値での頻度が他のものの半分くらいになっていた(乱数を表示する時の丸めの問題かも知れない)。 → 仮対処として、生成する範囲を広く取って数を多目に生成して範囲内のものだけを使うようにしたら、一様性は改善された。 → 上を更新した。

それから、Pythonの1回の実行でその系統全部の乱数を生成するようにしたら、実行速度は速くなった。

結局、試行(繰り返し)回数を随分増やせば一様になることが確認できた。実際に使う時にはそうできないことがあるが、その場合は「シャフル」のように あらかじめ一様な分布を作っておくとか、分布が一様になるように調整(取捨選択)するのだろうか?

あと、この問題は「システムの起動後しばらくは(乱数が今一つなので)安全でない」ということには ならないのだろうか? (この辺りは全くの素人なので、単なる思いつきである。)

 

(9/15 10:37 若干修正, 10:37 PSを追加, 16:22 題を明確化; 9/16 13:59 対処方法を追記, 22:42 題を変更; 9/17 16:28, 9/18 12:22 乱数を諦めた件とその後の試行を追記)

  •  1
  •  0

昨夜、寝る前に突然やって来た。どうにか対処したものの、大変な寝不足になってしまった。

以下、簡単に流れを書く。

  1. なぜか、ブログの管理画面にログインできなくなった。2要素認証(以下、2FA)が失敗する。
    • 一瞬、サーバが(一種のランサムウェアに)攻撃されて、絶対に入れない状態になったのかとも思った。
      • ただ、sshは問題なく、別のシステムの2FAは成功したので、ブログだけの問題なことが分かってホッとした。
    • あとで分かったが、セキュリティのプラグインAll In One WP Security(以下、All-in-one)の2FAが設定していないにも関わらずonになったようだ。
      • 近頃の更新で、All-in-oneに2FA機能が追加されたけど全然気付いていなかったのが、そもそもの敗因だった。
      • 自分では その2FAをonにした記憶がないので、勝手にonになったか、元々の2FAのプラグインと勘違いしてonにしたのかも知れない。
      • ただ、何も設定していないのに有効になる(できる)のは、とんでもなく ひどい!
        • 間違えて2FAの機能をonにするだけなら有り得るが、どのユーザーを2FAにするか、どんな方式(例: OTP, ハードキー)にするか、OTPなら確認のコード入力など いろいろあるのに、間違えて そこまで設定することは全くない。
      • 元々の2FAのプラグインの設定を流用して勝手に設定されたのだろうか?
        • 書いたあとで分かったが、All-in-oneの2FAをonにすると、管理者などの権限を持っているユーザーは2FAが有効になってしまう。罠だ。
          • そこで、All-in-oneの設定で、2FAを有効にする対象(権限・役割)を なし(全部チェックせず)にしたら、2FAの設定タブがなくなったので、もう間違うことはなさそうだ。
  2. (元々の)2FAのプラグインが変な状態になったと考えて一旦無効にしようとしたが、管理画面に入れないからできない。
    • それで、コマンドラインでプラグインのファイルを削除したが、なぜか2FAを無効にできなかった。
      • その前に、元々の2FAのプラグインのサイトを参考に、設定ファイルで無効にする方法を試したが、効かなかった。
    • 良く調べたら、(上記のように、)元々の2FAのプラグインとは別の、All-in-oneが2FAのOTP入力画面を出していた。
      • 最後は、認証エラーで出ているエラーメッセージを、インストールしているプラグインのプログラムから検索して特定した。。。
      • 似たような画面なので全く気付かず、どうしてもログインできないのが不思議だった。
    • それで、コマンドラインでAll-in-oneのファイルを一時的に削除して どうにかログインし、All-in-oneの2FAを無効にして、今までどおりログインできるようになった。
  3. PHPがダウングレードできない。
    • All-in-oneが悪いと分かる前、近頃更新されたPHPの互換性の問題で元々の2FAのプラグインが うまく動かなくなったかと思い、ダウングレードして試そうとしたものの、いろいろな依存関係のために諦めた。
  4. メールがGmailに送れない。
    • ログイン画面のパスワードリセット機能を使おうとしたが、その案内メールが届かなかった。
      • 届くこともあるのが謎だったが、どうも後述のDNSの逆引きがうまく動いていないためのようだった。
      • 更に、そのメールはパスワードをリセットするだけで、2FAには何もしないので無駄だった。
        • そもそも、元々の2FAのプラグインにはバックアップコードがあるのだが、All-in-one(バックアップコードは有料)とは違うので使えなかった。
    • 調べたら、Googleがスパムと判定するためのようだった。
    • メールの送信元認証システムのSPFやDKIMなるものを設定しないとGoogleはスパム扱いするようなので、(深夜なので止めておけばいいものの・・・)「ちょっと」SPFを設定してみた。
  5. SPFの設定がうまく行かない。
    • 自分のドメイン名を管理するDNSサーバにSPFを設定しても、チェッカーでは「SPFの設定なし」と出た。
      • 原因が良く分かっていないが、DNSの逆引き設定の不良(未設定?: 後述)とDNS情報の伝達遅延のせいだったようだ。
      • 書いたあとで調べたら、原因が分かった。 (9/9 13:56)
        • DNSサーバにSPFを設定する場合、TXTレコードとして書くのが一般的なようだが、以前はSPFレコードとして書く方式もあったけど廃れたようだ(→ 参照)。
        • 一方、僕は良く分からずに、(DNS設定画面のプルダウンメニューに出て来たから)SPFレコードで設定したので、チェッカーが「設定なし」としていたことが分かった。
        • SPFレコードからTXTレコードに設定し直したら、チェッカーもGmailへのメール送信も成功した。
          • 想像だが、未だにSPFレコードをサポートするのはGoogleくらいなのではないか??
  6. DNSの逆引き(IPアドレス→ドメイン名)がおかしい(未設定?)。
    • このサーバの設定項目に逆引きがあるが、ドメイン名のDNSサーバに登録すれば不要だと誤解していて、設定していないのが駄目だったようだ。
    • ただ、今まで、ちゃんと逆引きできていたこともあるので、それは どこのを参照していたかが謎。
      • 記憶が定かでないが、一時設定していたけど止めたのが どこかに残って居たのかも知れない。
    • あと、不勉強なため、逆引きは どこが標準(権威を持つ)サーバなのか分からなかった。このサーバのプロバイダなのだろうか?
      • サーバのプロバイダに問い合わせたら、想像どおり、このサーバのプロバイダにしか逆引き情報は設定できないとのことだ。

 

悪戦苦闘して何とかなったが、All In One WP Securityの ずさんさに呆れたしムカついたので使うのを止めたい。が、代わりの いいものを探すのが面倒だ。あと、DNSの逆引きの件は もう少し調べて勉強したい。

それにしても疲れた。。。

 

PS. 今朝、どうにか片付いて力尽きた頃に、UKの女王が亡くなられたようだ。その頃のツイートに、「BBCの出演者が みんな黒い服になった」というようなものがあった。

頭の中で、時々、(Queenの)"God save the Queen"(1975)が流れ、メイのちょっと寂しげなギターや最後の余韻のようなドラムに浸る。

  •  1
  •  0

もちろん、宗旨替えなんてしてないし、しない。MacでLinuxを使うのだ(もちろん、エミュレータなんかじゃない)。以前にも書いたように、x86のような効率の悪過ぎるクソプロセッサは止めて、次のPCはARMで行きたい。が、時々探しはしているものの、デスクトップPCに使えるようなプラットフォームがない。

そこに現れたのが、ARMベースのAppleシリコン(M1, M2)だ。Torvaldsも言っていたらしいが、そのMacでLinuxが動けばいいと思って居た。そして今日、偶然「「Linux 5.19」が公開、トーバルズ氏はAppleシリコン搭載Macからリリース」という記事を目にした。Asahi Linuxというのが動き出しているらしい。まだ完全ではないようだが、もう少しではないか?: 個人的期待だが、来年くらいには ちゃんと使えるようになるのではないか?

だから、現時点では、ARMベースのLinux PCにはAppleシリコンのMacを使うのがベストだろうと思う。

とは言え、Appleが意地悪をしてAsahi Linuxが起動できないような「更新」をする可能性があるので、そこを何とかできればいいが、できるのだろうか??

もちろん、もっと安くて いいものがあればいいが、今 影も形もないのに数か月で突然現れるとは思えない。

未だにPC・周辺メーカーはx86に どっぷり浸かっているようだが、それでいいのだろうかと思う。「ガソリン臭い車が好き」とか宣う どっかの偉い人みたいだ。

とは言え、そもそも(狭義の)"PC"はIBM PC互換機から始まったので、x86を止めれば"PC"の前提条件がなくなってしまって、「何を作るの?」みたいになるし、PCのさまざまな規格はIntelなどが作って来たものなので、いきなり「他」を出せるメーカーは なかなかないだろう。

そして、今 広義のPCを独自に推めている会社を挙げるとすれば、AppleとGoogle(Android)だけではなかろうか。

 

PS. 細かいことを考えると、実際に移行するのは容易ではない。例えば、オープンソースでないソフト(例: Spotify)がARM対応にならないと使えなくなる(macOSのように実行時に変換して動かせればいいが、Linuxではできない)といった問題がある。まだまだ先は長い。 (8/5 7:09)

  •  1
  •  0