Archive for the ‘Linux’ Category

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

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

→ その後、大きな問題が起こっておらず、意外にも音も随分いい感じになったので、ひとまず大丈夫そうだ。 (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
Keys: , , , , , , , ,

いつからだったか、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
Keys: , , , , , ,

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

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

 

(本題)

先日、以前にも起こっていた、たまに左のスピーカーから小さい「ポツ」という雑音が出る件が ぶり返したので、自作のアンプ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
Keys: , , , , , , ,

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

文字化けの暫定対処

メーラーは(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
Keys: , ,

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

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

以前にも何度か、目に付いた時に そのアクセス元近辺の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
  •  1
Keys: , , , , , , ,