piu lentoの日々 (piu lento days)

自作ソフト2個※の改良をしていて間が開いた。プログラムの変更・修正は面倒だが、動作確認に時間が掛かるものは大変だ。これは そのうちの1個で、動作確認が比較的短かく済んだものだ。

※面倒なことを同時にするつもりはなく、片方が片付いてから もう片方を始めたのだが、片付いたつもりがミスが見付かったりして、結局 同時進行になってしまった。途中で、いろいろなことが同時に起こり、頭がおかしくなりそうになって全部ぶちまけたくなるような、危ない場面もあった・・・

 

はじめに・概要

題は当たり前のことだけど難しい。: 以前 自作ソフト(Spotifyのミニプレーヤ Minisp)を新版(現行)のSpotifyアプリに対応させた時に手を抜いた※ために いくつかの問題(問題Aとする)が起こったが、別の問題(問題Bとする: PCのスリープからの復帰後にMinispがハングすることがある。: これも手抜きが発端の可能性がある)を直すために試行錯誤したら、そもそもの問題Bについては不明なものの、問題Aは直せた。 (ここの記述は いくら手直ししても、自分で読んでも分かりにくかったので、下のように時系列のリストにした。: 6/5 6:03)

1. 以前 自作ソフト(Spotifyのミニプレーヤ Minisp)を新版(現行)のSpotifyアプリに対応させた時に手を抜いた。
   • 元々動いていたものがSpotifyの都合で動かなくなったので、そういう しょうもないことのためにSpotifyを使って居る訳ではないので、時間・手を掛けたくなかったのだ。
2. いくつかの問題(→ 問題A)が起こったが、暫定対処(手抜き)で しのいで居た。
   • 問題の内容は下の「経緯・詳細」を参照のこと。
3. その後見付かった別の問題(→ 問題B)を直すために試行錯誤した。
   • PCのスリープからの復帰後にMinispがハングすることがある。: これも手抜きが発端の可能性がある。
4. 問題Bについては不明なものの、問題Aは直せた。

Minispは結構前に作ったので、細かいことを忘れていて、なかなか苦労した。ただ、そのおかげで、作った当時の思い込み・誤解がクリアされて居て、再度考え・調査して作ったので「ちゃんと」できた。けれど、プログラム自体は ぐちゃぐちゃだ。綺麗にしたいが、やっぱり面倒だ。

また、以前書いたことで、現行のSpotifyアプリは旧版に比べてDbusの動作がおかしい(特に、再生開始や一時停止のイベントが来ない)というのは、僕のプログラムの問題による誤解で、若干の動作の変化はあるものの、Spotifyアプリに問題は なかった。

結局、現行版対応時の手抜き以外に、元からの問題(一部のDbusイベントを捨ててしまう)があり、それが現行版で顕著になったようだ。

経緯・詳細

Minispを現行のSpotifyアプリに対応させた時にDbus(正確にはMPRIS)の動作仕様が変わったと思い込んで以下の対処をしたが、正しくなかった。アプリの動作の変化以外に僕の誤り(Dbusイベントのフィルタがキツ過ぎたなど)があった。

• Dbusイベントのフォーマットが違う。 → △ デコード処理を変更し、情報が足りない場合はSpotifyのAPIで取るようにした。
  • → イベントのフィルタがキツ過ぎて落としていたのと、イベント書式がNuvola Player(以前のもの, 今は不明)に近いことが分かった(単に、イベント内の情報の順序が旧版と違っているだけかも)ので、その処理を改良・追加した。
  • Dbusのデータの解釈を ちゃんとすれば※ こういう問題は起こらないのだが、なかなか難しくて手を抜いたので、こういう羽目になっている。
    • ※Dbusのデータフォーマット(JSONに似ているが、違う)の解釈をするコマンドなどが ありそうだと思って検索したが、見付からなかった。
• 再生開始や一時停止のイベントが来ない。 → × 定期的(1.5秒)にSpotifyのAPIやDbus(修正初期)で状態を取得するようにした。
  • 新版で出なくなったと思い込んでいた。
  • → 実はイベントが出る(フィルタがキツ過ぎて落としていた)ので、それを利用することにして定期的に状態をチェックする必要が なくった。
  • APIを使っていた時(修正前)は、下のシークとともに数秒ごとに呼び出していたので、API呼び出し回数が激増した(この作業をするまで気付かなかった)。 (→ グラフ: 左側)
    • API呼び出しは無料だが(頻度の制限はある)、無駄に実行するのは良くない。
• シークがDbusでは取れない。 → × SpotifyのAPIを使って(無理やり)取るようにした。
  • → 実はイベントが出るので、取れるようになった(プロパティでも取れる)。今は、曲が変わる時だけAPI呼び出しをするようにできたので、回数は激減した。定期的な再生位置の較正はローカル(d-busだけ)で出来るようになった。

なお、誤りに気付く前はSpotifyアプリのログファイルからイベントを取ることも考えたが、不要になった。

ログを使うほうが簡単・確実ではあるが、書式が いつ変わるか分からないので、良くない。

それから、そもそもの問題(スリープからの復帰後にMinispがハングすることがある)の原因は分からないので直接の対処は していないものの、再発していない。※ ただ、おそらく、頻繁にAPI呼び出しをしていたため、たまたま呼び出し中にスリープした場合、復帰後しばらくは それが終わらないためではないかと推測している。

※2週間以上様子を見ているが、まだ問題が起こっていない。

効果・おまけ

上記修正前後のSpotify API実行回数の変化のグラフを示す。

修正前は、気付かずに再生状態の取得(player)を一日に3万回くらいも実行していた※のが、0になった。曲とアーティスト情報の取得(tracks, artists)は、修正・動作確認中は増えたものの、以降は元々と同様の妥当な回数(= 1日の曲の再生回数)に落ち着いている。

※こんなに頻繁アクセスして良くエラーにならなかったと逆に感心した。ただ、たまにアルバム画像や曲情報の表示が遅いことがあったのは、実行頻度制限のためだったかと推測している。

それから、現行のSpotifyアプリには謎がある。: 曲の再生開始後、数回シークイベントが来るが、その位置がふらつく(前後する)のだ。※ なぜ、再生しているだけなのにシークイベントが来るのかもも分からないが、再生処理の状態(通信も?)で較正しているのだろうか? その較正の結果でふらつくのかと推測している。

※現行と書いたものの、実際には旧版からあったのかも知れず、そのふらつき(少なくとも、連続して複数のイベントが出るのは分かっていた気がする)が嫌で、Minispではシークイベントを捨ててしまっていて、そのために必要なイベントも捨てたりユーザのシークが検出できずに苦労し、処理が複雑化したりAPI呼び出しが多くなっていた。

なぜ、こんなことに気付き気にしたかと言うと、Minispの再生位置のバー(→ 参照: ジャケット画像下の灰色の部分)の位置を決めるのにアプリからのシークイベントも使って居るため、そのふらつきでバーもふらつくからである。まあ、ふらつくと言っても1秒程度なので注視して居ない限り分からず、僕はそんな面倒なことは しないので、気分の問題である。

細かく書くと、バーは曲の再生開始後、Spotifyアプリとは独立に定期的に(約0.7秒ごと)動かしている。が、それだと時間が経つとアプリとズレる＊ので、時々(数十秒ごと)、アプリの再生位置を取得して較正している。 (→ 参照: 再生位置が合っている様子) その較正に アプリから来るシークイベントも使って居る。

＊ズレると言っても、アプリとMinispを同時に注視する(やっぱり、そんな面倒なことは しない)か、曲の最後でなければ分からないので、これも気分の問題である。

気分の問題と言えば、そもそも再生位置なんて分かる必要はないので、この動くバー自体が無用のものなのだが、技術的に おもしろそうなので付けた。

とはいえ、僕は「この曲が終わったら＊しよう」とかいうことが多く、その目安には使えるから、全くの無駄でもなさそうだ。

もう一個のおまけ: 本当に現行Spotifyアプリの問題: 曲によっては、アプリ内のリストでの長さと再生位置表示での長さが異なる。 (→ 参照: ピンクの下線部) 秒未満の部分の丸めの問題だと思う(Minispでも起こった)。まさに気分の問題で何の実害もないので、全然問題視していない。単に詰めが甘いと思っただけだ。

 

まとめ的なもの

結局、手抜きは良くないが、いつも正しくやっていたら時間や手間が掛かり過ぎるので、

「ちゃんとする価値・必要性のあるものか」、「テキトーにやって あとで問題が出た場合、どういう影響が出るか」、「問題が起こる頻度は どのくらいか」、「その対処にどのくらい苦労するか・手間が掛かるか」

(あるいは、天使の声と悪魔の声の どちらに従うかｗ)

のような判断は必要で、その判断を しないと・誤ると今回のようなことになる。だから、手抜き自体が悪いのでなく、テキトーに手抜きすることが問題なのだろう。

(と、いかにも もっともらしいことを書いたｗ)

うまく行かなかった話なので簡単に書きたい(でも長くなったｗ)。

前回などに書いた、嫌なボット、邪悪な企業、不正アクセスのブロックや、以前書いた(初歩的な)国際化の作業をしていて、再び、このブログのアクセス解析(例: どのページが人気あるか、どの地域からアクセスされるか)をしたくなった。

実際、何かをした効果を知るために測定することは重要だ。

ちなみに、プラグインの評価のために、WP Staticticsを短期間使って調べたところでは、以前試した時と同様にMusicBee関連ページへのアクセスが最も多かった。アクセス元は、当然ながら国内が最も多く、次は中国だった。また、アクセス頻度は少なく、訪問者(ユニークIPアドレス)数は1日100件前後、アクセスページ数は1日200件前後だった(どちらもボットを除く)。

数年前にSlimstat Analyticsなど試したが、機能や出来が今一つだったのと、解析することに大きな意味がない※と思って止めたため、今回も同じような結果になりそうだと思いつつも始めたが、やっぱり駄目だった。

※「エゴサーチ」に近いものがあると思っている。熱中したり一喜一憂すると、良いことはない。そして、アクセス数が多くなるような稿を書くのが目的でなく、書いたものが結果的にアクセスが多くなれば良しだ。

そもそも、良い(僕の用途・要望に合う)アクセス解析プラグインがなかった。(プラグインではないが)Google Analyticsも含めて いろいろ検討したが、どれも以下の問題があって今一つだった。

• アクセスを捕捉できない。
  • 正しく or 全く捕捉できない。
• 機能が不足している・貧弱。
• 問題・不具合が多い。
• 無料でない/有料サービスに誘導する。

それでも いろいろ探して以下を試してみたが、ボロボロだった。それらの重要な問題を書く。

• WP Statictics: アクセス捕捉のために訪問者のブラウザからREST APIにアクセスさせるのは、現在の一般的なセキュリティの認識からは不適切で常識に欠ける。
  • 近頃の更新でREST API(wp-json)にアクセスさせるようになったようだ。
    • 変更履歴にサラッと書いてあったが、もっとちゃんと説明すべきだと思う。このプラグインは そういう説明不足な点が多い。
  • WPのセキュリティ面での弱点になるため、ログインユーザ以外からのREST APIをブロックするセキュリティプラグインがある。それを有効にしている場合はアクセスを集計できない。
  • そもそも、後述のadmin-ajaxも含め、多くの弱点を作り出しているWPが悪いのだが、今は置いておく。
• Slimstat Analytics(以下、Slimstat): (まともに使えるようにするための)設定に手間が掛かり過ぎるうえに、問題・欠点・我慢すべきことが多過ぎて、使う気が失せる。
  • IPv6アドレス(範囲)での除外ができない。
    • 以前使った時はIPv4アドレスでの除外処理に不具合があって、修正案を連絡したものの随分長く放置された(どうも、作者が(メンタル面で)調子悪かったようだ)。
  • 余りにも問題が多い。最初は連絡して直してもらおうと思って居たが、多過ぎる!: 以下に例を挙げる。
    • リダイレクト(HTTP 301)を除外できないため、アクセス数が重複してカウントされてしまう。
      • このブログは、現在の一般的な規範?に従い、HTTPをHTTPSに自動リダイレクトしている。
    • ブラウザのad-blockerを解除しないと、管理画面が ちゃんと出ない。
      • 変なサイトから部品を取り込んでいるのだろうか?
    • トラッカーをクライアント(JavaScript(以下、JS)でアクセスを捕捉する)にすると、最近のブラウザ・サーバのプライバシー・セキュリティ強化(例: トラッキング拒否, CSP)のため、アクセスを捕捉できない場合が多い。
      • 特に、Edgeは ほとんど駄目だった。
    • グラフの日付の処理が まともにできていない(これで使う気がなくなった!)。: 過去1か月や1週間の表示の時に、表示期間全部のデータがない場合に期間の頭からグラフを描くので、日がズレる。
      • 以前使った時もそうだった気がする。

      • 

        WP Slimstatのグラフの処理がおかしい例: 5/24から過去1か月の表示が4/27からになっている。 (使用開始は5/23)

  • 機能は多いが、それらの詰めが甘い。
  • アクセスを捕捉するために、訪問者のブラウザからadmin-ajaxにアクセスさせる。
    • REST APIと同様にセキュリティ的に不安がある。
      • ただ、簡単に塞ぐことができないし、塞ぐことは一般的でないので、仕方ない。
• Koko Analytics: ちゃんと集計できない。機能が少な過ぎる。
  • ちゃんと集計できないのはWP Staticticsと同じ原因(REST API)だろうか?
  • IPアドレスでの除外設定ができない。
  • アクセス元の地域を調べられない。
• (プラグインではないが)Google Analytics (以下、GA)
  • プラグインが全滅だったので、手軽に ちゃんと動きそうなので試した。
  • ところが、最近のブラウザ・サーバのプライバシー・セキュリティ強化(上を参照)のために、アクセス捕捉用のJSが実行できず、アクセスを全く捕捉できなかった。
    • 上記のSlimstatよりひどく、僕が主に使っているVivaldiとFirefox(どちらもプライバシー設定を一番厳密にしている)ではJSが実行できないために、全く捕捉できなかった。
    • 他の訪問者からのアクセスも、全く捕捉しなかった。
    • 捕捉用JSをローカルに持って来て使っている方が居るようだが、見てみると、(どんな複雑なことをしているのか分からないが、)異常にサイズが大きく、難読化されていて論外なので、全くその気が起こらなかった。

 

使えるものが何もなくなったので、自分でサーバのアクセスログから集計するプログラムを作るほうが良さそうだと思った＊ものの、それも大変なので、ログを集計するソフト※を探して使うのが良さそうだという結論になった。

＊サーバのログにはアクセス履歴が全部あるのだから、それを使えばサイトやページを変更することなく解析できるし、嫌われている・問題になっているユーザのトラッキングを しなくて済む。

ただ、サーバのログを集計するのは問題でないのかは不明だ。: 例えば、GDPR的には どうなんだろうか?: まあ、自サイトだけの集計は「トラッキング」(追跡: 他サイトへのアクセスも含めて調査することを指すと思われる)とは言わなさそうではある。

※探したらいくつかあったが、まあ、やる気が継続していたら試すことにする。

 

おまけ: Internet Archiveの謎

アクセスログのチェックやアクセス解析をしていて不思議に思ったのは、Internet Archive (Wayback Machine)は一体どうやってページを収集しているのかということだ。

というのは、先月以降のログを検索しても、それらのUAが全く出て来なかったからだ。※ とすると、以前書いた邪悪な企業と同様に、「あらゆる手段」＊で収集しているとしか思えない。: 調べると、公式ページにはアクセス元を識別するための情報は見付からなかった(UAは あったかも知れない)し、他者の情報によれば、UAやドメインは複数あるし、IPアドレスは随時変化するらしいからだ。

※更に、Wayback Machineの このブログの最終収集日(5/6)に サーバにアクセスはなかった。

＊他の団体からの情報提供も受けているのかも知れない。

いかにもUS的な、「正しいことは何でも独断で やって良い」みたいな思想なのだろうか。それで嫌ってブロックする人も居るから、ちゃんとすればいいと思う。

全くの想像だが、これや以前書いた邪悪なセキュリティ企業は、密かにUSの情報面での戦力として位置づけられているので、「やり放題」なのかも知れない。

なんて書くと、「おや、誰か来―」になってしまうかも? 危ないな。

 

おまけ2: WPとプラグインの危うさ

良く「＊プラグインの脆弱性が見付かった」という記事が出るが、危ないものを「無効」にしているだけでは危険を防げないことを、(本文に書いた)アクセス解析や不正アクセスの検出のためにログを見ている時に気付いた。というのは、「無効」にしてもプラグインのファイルはそのままなので、外部からURLを推測されてアクセスされれば、脆弱性を突かれてしまうのだ。。。※ だから、プラグインのディレクトリごと削除しないと駄目なのだ。

※ログには、そういう脆弱と思われるプラグインのファイル(PHP)をアクセスしようとしているものがあった。PHPの前に、プラグインの有無を調べるためか、テキストファイルにアクセスしているものもあった。

以前、「無効にしているだけでは不充分」と読んだのは このことだったのだ。

WPのクソさに呆れている。

なぜ、WPは そういう問題があるのを知っているはずなのに直さないのだろうか?

先日も結構前にもあったのだが、何かの作業でサーバのアクセスログを見ると、不正アクセスや攻撃の試行が見付かって頭に来る。しばらくは対処するのだが、結局イタチごっこでキリがなくて諦めるのの繰り返しだ。

パケットフィルタでブロックした直後は不正アクセスは減るのだが、しばらくすると、敵は新しいアドレスで来て また増えるから、まるでゴキブリや鼠だ。。。

不正アクセスして来たアドレスを自動でブロックすることも考えるが、そのうちにフィルタ処理が重くなったり どこからもアクセスできなくなったりしそうなので、保留している。今は、毎月自動集計して回数が多いところをブロックするようにしている。

今回は、ブロックしても しつこくアクセスして来る企業(E𑀋panse (Palо Aｌtо Neｔwоrks)とІnｔernet-Mеaｓuremеnｔ.cоｍ ※)に、ストーカー的な気味悪さを感じた。それらは「スキャンを停めて欲しければ連絡しろ」などと書いているが＊、そんなことをしたらスパムが来るとか更に悪いことになるに決まっている＠。

※どちらの名前も いかにも公的とか研究機関風だが、そんなことはない。検索されて更に攻撃されたくないので、(今は効果がないかも知れないが)一部の文字を見た目が似ている別のものにした。以下も同じ。

＊そもそも無許可でスキャン・攻撃して居る癖に、なんでそんなに偉そうなのだ?

＠以前、別のプロバイダのabuseの連絡先に、そこのユーザからスパムメールが来るので対処して欲しいと連絡したら、返事すらなくて、逆にスパムが増えた気がする。

被害者から止めてくれるよう申請する建前のせいか、robots.txt(サーバのボットに対する許可・不許可設定)を無視する(そもそもアクセスしない)し、パケットフィルタでIPアドレス(範囲)をブロックしても、少しすると別のアドレスから来るからキリがない。更に、Іnｔernet-は高速「大量」スキャンツール(MASSCAN)を使っているし、一度の連続した攻撃(試行)の種類ごとにアドレスを変えて来る(それらにはUA(User Agent)は付いて居ない)※ので、とても悪質だと感じた。

※そのため、IPアドレスで集計すると数が少なく見えるし、UAで検索・集計・ブロックできない。

全世界の、客のものでないサーバまで、頼まれても居ないのにスキャンしてセキュリティホールを探して、一体どうするんだろうか? 日本の省庁か関連機関(名前は不明: デジタル庁? ICC-Crawlerではないようだ)のように、(内容が不充分にしても)教えてくれるなら分かるし納得行くが。

と訝しんで居たのだが、その後、とんでもないことが分かった。: 一部の企業(例: Shоｄаn※, Ⅽеnｓуs)はスキャンして見付けたサーバのポート公開状況やセキュリティホールを客(有料)や一般に公開している。犯罪の支援ではないか。

妙なのは、USの政府機関(CISA)が そういう企業のサービスを使ったセキュリティ向上を推奨していることだ。 (→ 参照＊) 矛と盾みたいなものか。武器も使いようだけど、これでは政府公認サービスみたいになってしまって、文句が言えなくなってしまう。

＊どうしても この資料がUS政府の本物と思えなかったので、機関の名前やドメイン名やSSL証明書を確認したが、本物のようだった・・・

※今まで見た中でShоｄаnは最悪だ。アクセスにUAは全く付いてないらしく(攻撃ツールで試行しているだけ?)、IPアドレス範囲が広いうえに変化が激しいようなので、特定できない。だから、僕のサーバに来たかどうかも不明で、出所が不明な攻撃として集計していた可能性が高い。

そういう企業にネットへのアクセスを提供するプロバイダ(例: Digіｔal 𑀞ｃeаn)も同罪だ。調べると、Digіｔal-社に文句を言っても禄に対処しないらしい。 (→ 参照)

まあ、上に書いたように、「政府のお墨付きがある、セキュリティ向上のためのチェックだから問題ない」というスタンスで逃げられたら、どうしようもない・・・

結局、根本的に対処しようがないのが頭に来る。全部消えて欲しい。

US系とC国系の そういう企業で戦って、両方とも消滅してくれると ありがたいが、戦争になってしまう?

 

補足 (5/19 21:20)

書き忘れて居た。: 連中(E𑀋panseとІnｔernet-Mеaｓuremеnｔ.cоｍ)や その他のボットを少しでも排除したくて、基本的なrobots.txt(サイト全体のもの)にブログのサイトマップの定義を追加してWPの仮想robots.txtにするようにした。※ が、結局、(本文に書いたように、)行儀の悪い奴らはrobots.txtを無視するので無駄だった。でも、あとで使えるかも知れない(少なくとも保守が楽になるし、方法が分かったので、別の定義の追加なども楽だ)。

※WPのフックrobots_txtにrobots.txtの内容を生成(置換)するフィルタ(関数)を設定した。

なお、今のrobots.txtはE𑀋panseとІnｔernet-への渾身の怒りを込めて書いた。それが他のボットや検索エンジンに読まれて誰かの目に留まれば、少しは溜飲が下がるか。

 

PS. なお、UAは容易に偽装・詐称できるので、別人が悪い企業を詐称したり、悪い企業がGoogleなどを詐称することが充分考えられるので、発信者はアクセスごとのIPアドレスで検索・判断するしかなく、手間が掛かる。

PS2. 当然ながら、近くのC国からも多くの不正アクセスが来るが、そもそも悪役だし上に比べれば まだ素朴なので、極悪のイメージは少ない。あと、本来のアクセスが期待できないので、どばっと広い範囲をブロックするのに躊躇する必要がないのも良い。

もしC国に真面目に読んで下さる方が居られたとしても、自国の悪い連中の行動は分かっているはずなので、上のように書かれても悪い気分にはならないだろうと、勝手に思っている。

PS3. 今のところだけかも知れないが、日本(のプロバイダ)からは ここまで悪質なものは ほとんどないので感心している。それに、日本の企業だったら、連絡すれば ちゃんと対処してくれそうだ(面倒なので、しないでブロックするが)。

耳の問題の原因調査と昨年末からのアンプ・DACの改良の草稿や余りを捨てるのも もったいないので、最低限の加筆・修正で公開して「消化」する。僕以外の方に有用かは不明だ。

最終的に「分かった」こととは異なる内容や今までの稿と重複している内容もあるが、発端や経緯や試行錯誤が うかがえる。

稿を書き出した順序や内容から、アンプなどの改良をし出し(てしまっ)た切っ掛けが分かった。: まず、冬になって耳の問題が起こりやすくなり、その原因を調べているうちに、DACのカップリングコンデンサの劣化を疑い、試しにコンデンサを追加したら効果があったことから始まったようだ。

なお、補足を「注: ＊＊＊ (2023/5/16記)」のように書いた。また、公開する時に図(主にグラフ)を追加しようと思って居たが、概ね却下したもの または公開した稿で更新しているので、以下には ない。

---

「[耳・オーディオ] 耳の問題の原因が概ね分かった!」の余り (草稿: 2022/12/5-)

音が悪いと耳が辛くなる(耳閉感が多い)現象・症状

※身(耳)調の影響は大きい。それと外部要因を切り分けるのが難しい。かと言って、耳閉感が全部身(耳)調からのものという訳ではない。というのは、それまで調子は問題なかったのに、悪い音を聞いた途端に なることがあるからだ。

• ASUSで44kHz(フィルタ: slow)は問題なく、sharpだと危うい(昔は問題なかったが、近頃は ほとんど駄目)が、96kHz(sharp)なら問題ないので、超高域の量ではなさそう。
  • 可聴域ギリギリの高音域(15k-20kHz)での位相(か何か)の急変が関係あるのかも知れない。
    • 実際、中低域でも急なフィルタは駄目だった。 → 高域・位相とは限らず、どの帯域でも急なフィルタが駄目なのかも知れない。 (原因候補1)
      • それが何(歪み? 雑音? 位相?)に関係して耳閉感になるのか、まだ分からない。
      • 超低域(原因候補4)との関係が不明。独立なのか、超低域を補強するのか。12/31の投稿を参照。 (2023/1/3)
  • slowは問題ないが、特性が物理的に正しくないことが分かったので、使わないことにした。 (12/15)
  • なぜか、96kHzのslowが良かった。次は44kのslow。sharpは ほとんど駄目な感じ。12/31の投稿を参照。 (1/3)
  • 注: "ASUS": Essence STX II (DAC);  "44kHz", "96kHz": サンプリング周波数; "sharp", "slow": DACのフィルタの特性 (2023/5/16記)
• また、Scarlett(96kHz)は駄目だったので、全体的な歪みと雑音の量も関係あるではないか。 (原因候補2)
  • 信じられないことに、それらの上限は とても低いようで、Scarlettの歪み: -94dB, 雑音(DR): 108.5dB(A)※では駄目だ。
    • ※ScarlettとASUSの差は約16dBなので、ASUSの約6倍。
    • 更に、(昔の?)CirrusのDACやADC(Scarlettのはコーデック)は、駄目なノイズシェイピングで可聴域外の雑音が多いせいか、耳閉感が起こる。
      • → 20kHz以上を落とす簡易なLPFを試したが失敗した。。。
        • LPF自体の性能(落とし方)の問題か、出力回路のドライブ能力の制限のために歪みが増えるためかは不明。
  • ASUSは歪み: -110dB, 雑音(SNR): 124dB(A)なので、仮に その2倍まで耐えられるとすると、歪み(THD+N): -104dB, 雑音(SNR, DR): 118dB(A)くらいだろうか?: ここらはCDの限界を超えているから、どうも信じられない。
    • 雑音の質(アナログ(ホワイトノイズなど)とかデジタル(量子誤差)とかのタイプや周波数的分布)にも関係するのかも知れない。
      • 例: 上のCirrusの可聴域外の雑音。
    • あと、小音量・SPの近くで聴いているのも関係あるだろうか。
    • 車とかヘッドフォンの音(特性・性能)は随分悪いはずなのに耳閉感が起こらないのが、謎。
      • アンプと関係ある?
        • 微細な雑音や歪みまで忠実に増幅するため?
        • 本当に発振していない? (以前測定した時は、100kHz辺りまでは大丈夫だったが・・・: スピーカーの上限が40kHzなので、100kHz以上は出なさそう。ただ、それより低い音が変質する可能性はある。)
          • 音を出していなければ症状は出ない。 → 発振していないか、音に合わせて発振することがあるか。
          • 音を出していても、「駄目なこと」(上記・下記)をしなければ問題ない。 → 発振していない可能性が高い。
  • 超低域(原因候補4)との関係が不明。独立なのか、超低域を補強するのか。12/31の投稿を参照。 (2023/1/3)

その後の追加

• 雑音(34kHzなど)の結果 → (原因候補3)?
  • 34kHz → (3-1)
  • 8kHzと高調波 → (3-2)?
  • 1kHz以下の広い雑音 → (3-3)?
• DACのカップリングコンデンサの劣化による超低域の変動? → (原因候補4)
  • DACのフィルタ(slow, sharp)や超高域の量や補正フィルタの傾きは無関係??
  • ただ、ASUSは そうでも、他のDAC(DS-200), インタフェース(Scarlett, DEQ)は無関係では。
  • なぜか、本当にコンデンサで音が違う。 (12/22) (DACのフィルタの稿に書く?)
    • 以前買って使わなかった黄色いものは悪くなかった(最初は少し違和感があった)が、WIMAは全然駄目だった。 (どちらも1uF)
      • 注: 「黄色いもの」: PARC Audioのフィルムコンデンサ (2023/5/16記)
    • 特性は全く同じ。
    • その前の電解コンデンサとの相性?
• コンデンサの劣化とは関係なく、容量が大き過ぎて超低域がスピーカーから出て来て・あるいは超低域が変動して耳閉感が起こったようだ。12/31の投稿を参照。 (2023/1/3, 2/7) → (原因候補4)
  • 気付いた切っ掛けは、クラシック音楽を掛けると耳閉感が出て、ポップ音楽にすると消えたこと。それがリピートした。 (1/3)
  • カップリングコンデンサをフィルムに換え、アンプのフィードバックの電解コンデンサもフィルムに換えた。 (2/7記)
• アンプのフィードバックのマイカコンデンサは音が悪いことが分かった。それが耳閉感に関係していたかも。 →  フィルムに換えた。 (2/7記) → (原因候補5?)
  • 誘電体吸収のため。 (2/13記)
• 音以外に耳の調子によるものはある。朝、食後に問題が起こりやすい。  (2/7記) → (原因候補6)
  • 太い道路の自動車(朝の通勤時間帯は渋滞する)の低周波騒音? (2/13)

 

新DAC: 今のところ、手が出せる価格帯で可能な製品が ほとんどない。: iD4とAXE I/Oだけ(ESSとサポートがクソなところを除外した場合)。だが、どちらもCirrusなので超高域の雑音が駄目っぽい。

注: "iD4": Audient社; "AXE I/O": IK Multimedia社; "ESS", "Cirrus": DACのチップメーカー (2023/5/16記)

---

「三歩進んで二歩下がる? オーディオは作っては壊し? (今のDACのフィルタの謎解き → なぜか他のフィルタを作り直し)」 (改良の発端の頃の草稿: 2022/12/11-)

僕のオーディオシステムはソフトの割合が結構多いので、ハードを いじらなくても、主に部屋の影響の補正関係の調整や改良ができる※のだが、それで却って堂々巡りみたいなことをしている。ソフトなので、指を動かすだけで いくらでも作り直しができるのが痛し痒しだ。

※この前提は、基本的に出力装置(DACやアンプ)が音を そのまま出すこと、(何度も書いている、)無色透明・無味無臭なことである。そうでなかったら、何を補正するのか分からなくなってしまう。

 

DACのフィルタの謎

(いつも困っている)耳閉感の原因調査をしている時に、サウンドカードのDAC(PCM1792A)のデジタルフィルタのsharpとslowの違いを調べたら、思わぬことが分かった。: sharpは きっちりと減らすべき成分を減らすのだが、slowは超高域で大量に漏らしているのである。その成分はナイキスト周波数(サンプリング周波数の1/2)より上なので、僕の普通の測定では分からなかったことで、たまたま、スイープ信号や正弦波で調べていて気付いた。

それでいろいろ調べたら、slowの「漏れ」は既知のことだったようだ。

そんなに漏れがあるのに、僕の耳に合って耳閉感を起こさなかったのが不思議だ。 想像だが、漏れた成分の位相が逆になっていて、ナイキスト周波数の反対側の成分(本来の音)とうまく打ち消しあっているのだろうか。僕の環境では、そこまで測定するのは難しい。それでslowの緩いカーブが実現できているのだとしたら、TI(BB)のエンジニアはすごいと思う。

逆に、以前も書いたが、サンプリングレートが44.1kHzの場合は きっちり漏れないsharpが耳にキツいのも謎で、まだ良くわからない。これも想像だが、やっぱり急なフィルタ(の謎の副作用)が良くないのではないかと思っている。更に想像だが、調べていて、sharpにある長いプリ・ポストエコー(リンギング)の影響かも知れないとも思うが、はっきりしない。そもそも、このプリ・ポストエコーを含めてDACの音が構成される理論なので、見た目はおかしくても※必要なんだと思う。

※slowとsharpのインパルス応答を比較すると、slowはプリ・ポストエコーがほとんどなくて綺麗だ。ただ、必ずしも それが正しいとは限らない。

正しい処理(フィルタリング)を実装してみた。

44kHz+slowの音は耳に合うが、ナイキスト周波数の上の漏れが多いのは物理的に「正しくない」気がするので、アップサンプリング(96kHz)と耳閉感を抑えるため、超高域を減らすslowに似せた特性の LPFを使うことにした。 (→ 参考? → 参考?: 偶然だが少し似たシステムがあった)

趣味なので、別に正しくなくても、耳に合って気分良き聴ければいいとは思うが、物事はなるべく綺麗にしたいという気持ちもあるので、敢えて苦労・苦闘した。

LPFは いろいろ試行錯誤して、音が悪くならず(耳を痛めず)、特性がslowに近くなるものを見付け・調整した。

これのインパルス応答はslowほどではないものの結構綺麗で、プリエコーがほとんどない。

まあ、全くの酔狂ではあるが、これがうまく行けば、あとでDACを買い替えた時に、仮にそのフィルタが耳に合わず、更に切り替えできなくても、この方法で音を調整できそうだから良い。

この音をしばらく試して問題なければ「一段落」となり、載せる図などを集めて文章を整えれば終わりのはずだったのだが、、、

ちゃぶ台返し! (フィルタ関係を ほとんど全取っ替え)

そのLPFを いろいろ確認・調整・改良している うちに、位相や振幅の周波数変化や左右差が大きいのは良くない(要するに、音に対する処理は最低限にしたい)と考えて、(苦労した)上のフィルタも(その前にちょっと思い付いた)HD2Cも止め、補正フィルタも左右統合して、処理を随分簡素化した。

部屋の特性補正用のフィルタの超低域(< 100Hz)の歪みが増大しているのが気になって、上で使ったフィルタにしてみたら うまく減ったのが切っ掛けだった。

注: HD2C: ソフトでDACの2次歪みを補償する(しようとした)処理 (2023/5/16記)

スピーカーから出した実際の特性は分からないが、聴感は良い。何となく、音がよりクリアになり(音が「一皮剥けた」感じ)、よりストレートに聞こえるのにキツくなく、却って聞きやすくなった気がする(例によって、たまたまとか耳の調子とか気のせいの気はするが)。

→ 実際の特性は問題なかった。その後、微調整したり長く聴くにつれ、本当に音がクリアになったのを実感している。いつものように、今まで聞こえなかった音が更に聞こえるようになった。「情報量が増した」ってやつか。

左右の特性(特に位相?)を揃えるのは重要そうだ。 (12/22)

その代わり、HD2Cも止めたので歪みは全域で左右がアンバランスだ。ただ、歪みが増大しているといっても、RがLの約2倍になって0.0012%程度なので、大きな問題ではない(実際、HD2Cを入れる前も気にならなかった)気がする。それでも何とか解消したくて、原因と対処案を考えている。が、それはソフトではできないので、貴重なサウンドカードを壊す可能性もある・・・ (12/13 17:37)

更にどんでん返しが!

昨夜寝る前に、96kHzへのアップサンプルは良くない気がした。というのは、96kHzは44.1kHzの整数倍でないので、複数のサンプルが混じるためだ(まあ、高精度な処理をすれば実害はないのだが)。

それで、44kHzに戻ることを考え、その時のフィルタをどうするかと、slowとsharpフィルタのエイリアシング成分の漏れを再度比較するためにグラフを見返していたら、おかしなことに気付いた。入力している周波数のエイリアシング成分でない、更に高い周波数に大きい漏れがあるのだ。どうも、測定時に意図しないレート変換があったようで、どうやら、測定のために44.1kHzのテスト信号を再生する時にALSAが48kHzに変換していたようだ。

が、それでも、slowフィルタが良くないことには変わりない。

それで、結局、一番最初に戻って44.1kHzでsharpフィルタで試すことにした。これが耳に合わないなら、96kHzにアップサンプルするか。。。 (12/15 7:39)

だがしかし、まだまだｗ

やっぱり44.1kHzとsharpフィルタは駄目で、数時間で耳に来た。耳閉感が起こり、音が悪くも感じた。それで96kHzにしたら、耳は嘘のように治り、音がクリアになった。それから丸一日聴いているけど、問題は起こっていない。

全く謎は深い。

その後、アップサンプルに使うリサンプラを比較して、PAのものだとspeex-float-10が一番良さそうだった。なお、soxr-vhqが良い説が強く、最初はそれにして居たが、比べたら1kHzくらいからの位相の遅れが気になるので止めた。speex-float-10はsoxr-vhqの半分くらいだった。

また、GMBはPAにもJACKに出せるので、JACKに出す時に設定するリサンプラGstreamerのaudioresampleの引数を変えてPA(speex-float-10)と比較したら、特性の測定が難しいこともあって、明確な答えが出なかった。今は、小さな差ではあるが、雑音は多いものの歪みが少ない(まだ結果に自信がない)ので、PAに出すことにしている。 (12/16記)

注: "PA": PulseAudio(Linuxのサウンド系), "JACK": JACK Audio(Linuxのサウンド系), "GMB": gmusicbrowser(Linuxの音楽再生アプリ) (2023/5/16記)

まだまだ!

(出力の追加コンデンサで、なぜか耳閉感が出なくなった話。あと、コンデンサの音の話)

注: 「出力の追加コンデンサ」: ASUSのDAC出力にコンデンサを追加したこと。代替カップリングコンデンサの最初。 (2023/5/16記)

 

最後に言い訳じみたことを書くが、僕は決してオーディオの音を良く・好みにしようとして こんなことをしている訳ではない。部屋の作りとスピーカーと聴く位置で音が変わるから補正は必要だし、DACは そのままの音で問題なければ何もしないが、たまたま元々の音が耳に合わない(例: 耳閉感)※ので、仕方なく調整しているのだ。まあ、おそらく一般の方は全く関係ないことで、僕の耳が過敏とかちょっと病気なためだろう・・・

※記憶をたどると、サウンドカードを買ったばかりの頃は問題なかったが、ここ数年で合わなくなったようだ。アンプを自作に換えたのと時期が合うのが気になる。: アンプが劣化して雑音が多いのか、逆にすごく良くなって微細な音(雑音まで)も聞こえるようになったのか・・・

 

(あと、ScarlettのLPFも書く? Focusriteへの問い合わせの結果(やっぱりクソだった)と一緒に別にする?)

注: 「ScarlettのLPF」: ScarlettのDACから30kHz以上の雑音が出ていたので、外付けのアナログLPFで抑制しようとしたけど うまく行かなかった話。 (2023/5/16記)

サーバ＊のクラウドストレージ(Backblaze B2)へのバックアップに使っているソフト duplicacyが時々エラーを出していた。※ 調べたら4年近く試行錯誤していたが、最後の対処をしてから半年くらい起こっていないので、ようやく直った感じだ。

＊デスクトップでも使っている。

※随分前に書いた気がするものの、探しても出て来ないので、対策しつつ様子を見ていたのかも知れない。

(耳や臭いの問題と同様に)原因が はっきり分からないのだが、バックアップ中のメモリ不足かディスクアクセス過多、あるいはその両方ではないかと推測している。: 通常は問題ないが、(サーバのハード(仮想マシン)は貧弱なので)他に大量にメモリを使うか頻繁にディスクアクセスをするプロセスが一緒に動いていると、問題が起こるようだ。

現象

• クラウドストレージのprune(古い変更履歴の削除)処理時に、いくつかのチャンク(ブロック)が ないというエラーが出る。
  • エラーメッセージの例(発生し始めた頃のもの, 一部改変した)

2019-07-17 03:41:18.960 ERROR CHUNK_DELETE Failed to fossilize
the chunk fdXXXXXX: URL request 'https://YYYY.backblazeb2.com/b2api/v1/b2_hide_file' returned 400 File not present: chunks/fd/XXXXXX

• • そのチャンクを含むリビジョン(履歴)を削除するかexhaustive prune処理を実行すると、エラーは出なくなる。
• 問題のリビジョンのバックアップ時にはエラーは出ていない。

謎と検討

妙なのは、デスクトップとサーバで同じようにバックアップしているのに、サーバだけでエラーが起こることだ。しかも、サーバ(VPS)のハードが交換された あとから起こるようになった。 ← 実は その前から起こっていた。(記録のために残す)

そのことから、(OSは同様なので、)サーバとデスクトップのハード(リソースや性能)の違いが関係している可能性がある。

対処

半年くらい前(2022/11)に以下のように対処したら、問題が起こらなくなった。

• duplicacyのバックアップ処理のパラメタを調整し、使用メモリ量を減らすようにした。
  • オプションに -max-in-memory-entries 51200 を指定した。
    • → 使用メモリ量が200MB前後になった。 (無指定時は600MB以上になる場合があった。: 下を参照)
    • 値を減らすと使用メモリ量は減るが、比例は しない(下限がある?)ようで、10240と かなり小さくしても200MBは使うようだ。
• バックアップ処理と、メモリを大量に使用してディスクアクセスが頻繁なclamscan(ウイルススキャンソフト)が同時に動かないようにした。
  • どちらもcrontabで定期的に起動している(周期や時刻は異なるが、どちらも実行時間が長いので同時に動く可能性がある)ので、起動前に片方が実行中の場合はスキップし、次回まで延期するようにした(片方が終わるまで延々と延期する)。
    • 今気付いたが、微妙なタイミング(例: たまたま2つが同時に起動時刻になった場合)で同時に起動してしまう場合があるかも知れない。 ← プログラム(スレッドやプロセス)でないので、開始時刻(分)を違えておけば大丈夫そうだ。
  • こちらは上より先に実施したが、問題が全く起こらなくなる訳ではなかったようだ。

分かった切っ掛け

対処方法が分かった(問題が起こらないようにできた)切っ掛けは、ある時のduplicacyの更新内容に「使用メモリ量の削減」というものがあったことだ。※ もしかすると、他の方がメモリ不足でのトラブルを報告したのかと思った。

※僕はそれまで、duplicacyがメモリを大量に使用する可能性があるとは全く意識していなかった。想像だが、duplicacyの重複排除処理(重複ブロック(チャンク)の検索?)でメモリを使うのではないか。

なお、更新されたduplicacyのストレージ(スナップショット/リビジョン)は新しいフォーマットになって使用メモリ量が少なくなるというので、全部のスナップショットが入れ替わるまで(変更履歴の保存期間が過ぎるまで)使用メモリ量の変化を見ていたが、余り減らなかった。最初(duplicacyを更新した直後)が一番減った気がする。

それで、duplicacyと一緒にclamscanが動く時にメモリ不足になって、エラーの原因になるのではないかと推測した。ただ、OSのログにはメモリ不足関連のエラーは出ていないので、正確には、実メモリ(RAM)が不足して仮想記憶(ディスク)が使用されて(スワップ)、処理が遅くなってエラーの原因が発生するのではないだろうか。

duplicacyのエラーメッセージから考えて、原因はバックアップ時にチャンクがクラウドストレージに保存されないことがある(ただ、その時にエラーは出ない)というものだろうから、実メモリが不足してスワップが起こると処理が遅くなって、チャンクのクラウドストレージへの送信が失敗するのではないかと推測している。

処理が遅くなって送信が失敗することがあるとは思えないが、例えば通信のタイムアウトやリトライ処理のタイムアウトなどであろうか。前者とすれば、送信するチャンクのデータをメモリにバッファリングせず、ディスクから読み出しながら送っていて、たまに遅くなると送れないことがある? : いずれにしても、duplicacyの処理のロバスト性が今一つなのかも知れない。

そう言えば、以前duplicacyのフォーラムを調べたら、僕と同様に「チャンクがない」というエラーが出る方が問い合わせていたが、結局「再現せず」や本質的でない回答のあとは放置されて、解決していなかった。

そしてその方は怒っていた気がする。: その方のKopiaのフォーラムへの投稿からduplicacyに戻って、上の問題を知った覚えがある。

そこで、試しにduplicacyのバックアップ時の使用メモリ量の表示をさせてみたら※、600MB以上消費する場合があることが分かった。普通は それくらいは問題ないのだが、サーバのメモリ量は1GBと少ないので＊、他のソフトも大量に使用するとスワップが起こりそうだ。なお、prune時は使用メモリ量は小さく、100MB以下だった。

※メモリ量削減と一緒に そういう機能が追加された。

＊以前、たまにメモリ不足の問題が起こっていたため、仮想記憶(スワップ)を有効にしていた。その問題が何だったか思い出せないが、やっぱりduplicacyだったのかも知れない。

メモリ不足の他には、duplicacyもclamscanもディスクアクセスが頻繁なために処理が遅くなって、上と同様にチャンクのクラウドストレージへの送信が失敗する可能性も考えられる。更に、メモリ不足と頻繁なディスクアクセスが一緒になると、余計処理が遅くなって更にひどいことになりそうだ。

ちなみに、過去1年のサーバの稼働状況を調べたところ、duplicacyの使用メモリ量を制限した頃からスワップ頻度(ページ/s, 下の左のグラフ: 中央辺りから制限した)が減ったようだ。ディスクI/O頻度(回数/s, 同右)に関しては変化は少なく、逆に少し増えた感じだ(ただし、なぜか今年4月以降は小さくなっている)。ディスクを複数プロセスで同時に使うと、効率が低下して全体的な性能が低下するためだろうか。

グラフから、duplicacyのメモリ使用量が大きくてスワップが多かったことは確かそうだ。

※なお、同じ期間のメモリの状態(memory usage)、ディスク動作率(utilization)、ディスクの遅延(latency)、NWの通信速度、システム負荷(load average)に目立った変化は なかったので、グラフは省略した。

考察

いずれにしても、送信失敗時にエラーが出るはず・べきだが出ないのはduplicacyの問題(異常時の処理が甘い)か、これらが原因ではないかの どちらかだろう。

今後問題が再発すれば後者だし、逆に、duplicacyの使用メモリ量の制限を止め、常にclamscanと一緒に動かして問題が起これば、僕の推測が正しいことが分かる。が、面倒だし ほとんど無意味(僕が作ったものでないし、サポートが やる気ない: おそらく「環境の問題」で終わり)なのでやる気は しない。

もしduplicacyの問題だとしたら、「バックアップしたつもりなのに(エラーになっていないのに)、できてなかった」という、結構ひどいものだ。が、起こるのは限られた環境のようだし、駄目になるのは一部のファイルだけなので、致命的とまでは言えなさそうだ。でも、これは遊びのソフトじゃないので、重大な信頼性の欠陥だと思う。

補足すると、特定の環境・状況で処理が失敗するのは仕方ない(すべての環境・状況で使えるものは作れない)が、使った時に失敗したことが分からないのが問題だ。

そう言えば、作者は こういうエラーメッセージ関係の重要性を軽視しているようで、以前、「エラーメッセージ(か終了コード)が誤解する・分かりにくいから変更して欲しい」という要求を拒否していた。

これは単なる表示・見た目の問題ではない。ちゃんと作る(起こり得る すべての失敗を想定・想像する)のは大変だが、製品には必要だ。

試行錯誤

対処方法が分かるまでに以下を試したが、ほとんど効果がなかった。若干良くなるように見えたが、問題は起こった。

• バックアップ時の送信スレッド数を減らす。: デフォルト: 4個 → 1個 (-threads 1)
• バックアップ時の送信速度を下げる。: 約250kB/s (-limit-rate 250)など
• B2のメンテナンス時間帯(毎週1回)のバックアップを避ける。

これより、問題の原因はduplicacy単体ではない可能性が高いことが推察される。 ← 上も動作環境(NWやB2)が関係していることを推測して行ったので、これは言えない。 (22:11)

 

余談

何度か この件をduplicacyに問い合わせようと思ったが、ハードが関係していそうだし、上述のようにサポートが余り親切・適切でなさそうで解決する見込みがないので、止めていた。そして、もし僕の推測した原因が正しかったら、問い合わせても全く解決せず、(いつものように)ただイライラするだけだっただろう。

duplicacyは通常時は問題なく動作しているのだが、上に書いたように異常対応やロバスト性が心許ない気がしているし、サポートの態度にも問題がある。あと、バックアップの対象・除外設定と動作が複雑で頭が狂ってしまう。

そこで、以前書いたKopiaなど新しいバックアップソフトを検討したいが なかなか面倒だし、そっちが良い保証もない。他に やることが溜まっているので、検討するとしても来年と考えている。

 

PS. 書く前は手短かに終わらせようと思って居たが、長くなったし熱くなった(ムカついた)。調べたら長年苦労して来たし、作者がテキトーなのを思い出したせいだ。それにしても、国内・国外関係なく、いい加減なソフト屋が多い。ハードも同様だ(以前も同じことを書いた)。