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でも起こった)。まさに気分の問題で何の実害もないので、全然問題視していない。単に詰めが甘いと思っただけだ。

 

まとめ的なもの

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

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

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

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

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

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

4年以上に及ぶ調査と実験・試行錯誤の末、分からないことは残って居るものの、耳の問題の原因が大体分かって対処できた。

過去のブログを調べたところ、2019年の10月末頃※から問題が起こり出した(以前あったものが ぶり返した)ようで、それから断続的に延々と続けて居た。

※このことから、問題は部屋(2020年に今のところに越した)やアンプ(2021年に今のアンプが出来た)には直接起因しないことが分かった。

症状

PCで演奏を再生して聴いていると、耳に以下の問題が起こることがある。

• 耳閉感, 圧迫感
  • 耳閉感と圧迫感は微妙に違う。耳閉感がひどくなると圧迫感になるのかも知れない。
  • 低周波音に曝されると起こるとのこと。 (→ 参照)
• 唾飲み時の違和感
  • 高所に行った時の感じ。
• 音が聞こえにくい感じ
  • 耳閉感や圧迫感のまま続けると起こる気がする。
  • 低周波音の被害のアンケートで症状を訴える方があったとのこと。 (→ 参照)
• 耳の痛み
  • (音が)よほど ひどい場合に起こる。
  • 低周波音に曝されると起こるとのこと。 (→ 参照)

なお、上は僕の耳の問題であり(一般の方に共通して起こるとは思えない)、過去の病気(突発性難聴)の後遺症かと推測している。そのためか、体調(「耳調」)の影響が大きく、今までの経験では冬(特に午前)に起こりやすい。血行の影響があるのだろうか?

妙なのは、耳鳴り(疲れているときや体調が悪い時に起こるようだ)と上の問題は独立なようで、耳鳴りしているからと言って上の問題が起こりやすい訳ではないことだ。いずれにしても調子は悪いのだろうが、問題の起こるメカニズムが違うのだろうか。

そして、耳鳴りは上の問題と違って演奏を聴いて居る時の嫌な感じが ほとんどないので、本稿での耳の問題には含めない。

原因(推定)

実験により、耳の問題の原因を推定した。耳に悪い順に示す。

• キツいフィルタ → 唾飲み時の違和感, 聞こえにくい感じ, 耳の痛み, 圧迫感
  • それらの何が悪いのかは分からないが、位相の急な変化(→ 例: 緑が位相)や歪みの増加が問題かと想像している。
• 超低音の過多 → 耳閉感, 唾飲み時の違和感, 聞こえにくい感じ, 圧迫感
  • 概ね50Hz以下の成分が関係しているようで、ある振幅(音量)を超えると「駄目」になるようだ。
  • 僕の耳が それらの成分に過敏なようなのと、部屋の特性(共鳴)で増幅されて耳に問題を起こすのではないかと推測している。
• 歪み → うるさい感じ, 唾飲み時の軽い違和感, わずかな耳の痛み
  • 再生音に歪みを加えて試行したが(後述)、明らかに歪んでいるとは分からない程度の小さい歪みでも耳に影響がある。

上記の外部要因以外に、上述のように身体や耳の調子(耳調)は大きい。調子が悪い場合は、いくら対処して居ても問題は起こる。今までの経験から、どういう訳か冬の午前は調子が悪いことが分かっている。

原因が上記以外にない確証はないが、上のポイントを対処したら(後述)問題が起こりにくくなったので、他にあるとしても大きな影響を及ぼすものではないと考える。

なお、今まで不思議に思って居たのだが、ヘッドフォン(オンボードのサウンド出力に繋いでいる)や車のステレオでは滅多に耳の問題が起こらないのは、超低音が出ない(ヘッドフォンや車のステレオ(純正のナビ)は元々低音は出ないだろうし、どちらも部屋のような共鳴はない)こととキツいフィルタを使っていないため※ではないかと推測している。ただ、歪みや雑音が多いので聴き心地は良くない。

※以前、ヘッドフォンに出す音に耳を保護するようなフィルタ(コンプレッサーなど)を掛けたら、却って耳がおかしくなった記憶がある。

それから、再生音中の微小な雑音(単体では聞こえない)では耳に問題は起こらないが、嫌な音(≒「音が悪い」)に感じる。雑音の種類によっては、一見、音が良く感じることがある。

対処

今までに以下の対処をした。なお、上述のように僕の耳の問題への対処なので、一般の方に共通して適用可能なものは少ない。ただ、一般論として正しいことはありそうだ。

• 部屋の特性補正用フィルタ(以下、補正フィルタ)の改良・調整
  • 使うソフトの選択
    • JACK(Linuxのサウンド処理系)のフィルタで耳に悪くないものは少なく、今使っているのは、"4-band parametric filter"と"High Pass Filter (One Pole)"である。
  • フィルタの特性をキツくしない。: 補正量を抑え、幅を狭くし過ぎない/傾斜を急にし過ぎない。
    • 4-band parametric filter: 最小バンド幅: 0.13, 最大ゲイン(絶対値): 9までにした。
    • High Pass Filter (One Pole): 傾きが緩いので良い。
  • 簡素化: 要素数を減らし、左右同じにした。
    • 当初は左右別で多かったが、今は4個にしている。 (→ 振幅のグラフ: 緑(HPFのカットオフ= 65Hz)を使っている)
      • ただ、今は4個でも多い気がして来た。(HPFは削れないが、)3個にできると良いが、減らすのが目的でないことを忘れてはいけない。
• 超低域(概ね100Hz以下)の抑制
  • 補正フィルタのHPF(低域カット): カットオフ周波数: 65Hz
    • 80Hzが安全だが、少しでも低域を増やしたいので、試行錯誤でギリギリまで下げた。冬の調子で調整する必要がありそうだ。
  • スピーカー(KEF Q300)のバスレフポートを塞ぐ。
    • 最近はポートを開閉した時の特性を比較して居ないが、以前の測定では、塞ぐと100Hz辺りから下がり出し、40Hz付近で6dB程度下がるようだ。 (→ グラフ)
  • DAC(サウンドカード: ASUS Essence STX II), アンプ(BA3886, 自作)のカップリング/フィードバック回路: カットオフ周波数: 約10Hz
    • 上記の補正フィルタのHPFとスピーカー自体の低域特性(公称の下限は42Hz, 実測は30Hz辺り)やバスレフポートを塞ぐことで超低域が抑制できるはずだし、約20Hz以下は聞こえないはずなので、これは不要な はずだが、実際にはサウンドカードとアンプを直結(DC)したりカットオフ周波数が低過ぎると耳に問題が起こったため、高目に制限した。
      • DACから直流に近い変動成分が出力され、後述の可聴域外(34kHz)の雑音と同様に可聴域に影響を与える(例: ふらつき・ドリフト)のではないかと推測している。
• PCのオーディオ(JACK, DAC)出力設定の調整
  • リサンプルしない。 → JACKとDAC(PCM1792A)は聴く演奏の主なサンプリング周波数の44.1kHzに設定している。
    • PulseAudioで最も品質が良いとされるリサンプラ(speex-float-10)を使っても音質が悪化する(少しだが、耳に問題が起こる)。
      • PCの負荷で変動する要素があるのかと想像している。
      • アップサンプルするとして、唯一使える96kHzが44.1kHzの整数倍でないのも、話を面倒にしている。
        • サウンドカードが88.2kHzをサポートしていないため、96kHzか192kHzを使うしかない。
        • PCM1792Aは192kHzでの特性が少し悪いので、余り好ましくない。
  • DACのフィルタ(sharp/slow)は余り関係なさそうだが、エイリアシングを抑えるためにsharpにした。
    • 僕は約15kHz以上は聞こえないので、エイリアシング成分が出ても聴感上の問題はなさそうだ。
    • アンプの改良前は44kHz, slowでないと耳に問題が起こったのが謎である。
      • Sharpとslowで超低域成分(直流の変動成分?)の出方が違うのかと推測している。
• 耳に/音の悪い機器・部品の排除, その他の改良
  • 排除した機器: (DACとして)Scarlett Solo Gen3(歪みと雑音が多い), (DACとして)DEQ2496(歪みと雑音が かなり多い), 以前試用した某DAC(さまざまな雑音があった)
    • 僕にすれば、最初の2つはオーディオ用途には使えない。最後のは それらよりはマシだけど、出来が悪くて買う価値はない。
  • 排除したDACの部品: 電解コンデンサ, リレー
    • 電解コンデンサ(カップリング回路)の容量が大きくて直流の近くまで通すために耳に問題を起こすことと、電解コンデンサ自体の音の悪さを排除した。
    • リレーは余り関係ない気がする(気分の問題)。
  • アンプ
    • 排除した回路・部品: DCサーボ回路, 電解コンデンサ, マイカコンデンサ, WIMAのコンデンサ(一部)
      • DCサーボ回路は直流の近くまで通すために耳に問題を起こすことと、大出力時に超低域で歪みが増大するので排除した。
        • また、オリジナルのキットの回路では、入力にダイオードがあって歪みを生ずるので、かなり以前にダイオードも撤去した。
      • マイカコンデンサ, WIMAのコンデンサは余り関係ない気がする(気分の問題)。
        • ただ、オリジナルのキットのマイカコンデンサの値は適切でなかったし、別の容量のWIMAらしきものの音は ひどいものだった。
    • クロストークの改善
      • 片チャネルずつ特性を測るだけでは分からないが、クロストークは(高域で増大し、)雑音や歪みのように働くのではないか。
  • ※アンプとサウンドカードの改良については別稿1, 2などを参照のこと。

今回試したことと結果

これまでに目星を付けていた、キツいフィルタ, 超低音, 微小雑音と、追加として歪みについて最終的な確認をした。いずれもABX法のような客観的な比較方法でなく、自分で 状態が分かって比較している点で客観性は低い。ただ、「どちらの音が良い」という印象でなく身体的症状の発生を基準にしているので、完全に主観的なものではなく、今までに何度も同様の試行を繰り返して同様な傾向の結果を得られているので、再現性はある。

• キツいフィルタ
  1. CalfのEQ 5bandのLPF(HSフィルタ)をキツくして試した。
     • 設定: カットオフ: 15kHz, ゲイン: -36dB(最大), Q: 0.76(ピークができない程度にした) (→ 特性: 青: 振幅, 緑: 位相)
     • 結果: 約25分で問題(唾飲み時の違和感、聞こえにくい)が出た。 → Offにしたら治った。
  2. Jack rackのC*Eq4pのHPFをキツくして試した。
     • 設定: モード1(通常のPEQと思われる), カットオフ: 65Hz, ゲイン: -30dB, Q: 1.0 (→ 特性: 赤: 振幅, 緑: 位相)
     • 結果: 約30分で問題(少し耳が痛い。あと、少し圧迫感)が出た。 → Offにしたら治った。

•  超低音
  1. 補正フィルタのHPF(65Hz)をoffにして試した。
     • 結果: 約30分で少し圧迫感と軽い耳閉感が出た。 → Onにしたら治った。
  2. 補正フィルタのHPFのカットオフを50Hzに下げて試した。 (→ 特性(赤, 他のカットオフもあり: 65Hzは青))
     • 結果: 約30分で問題(軽い唾飲みの違和感)が出た。
     • 低域が増す感じはしたが、ブーミーな感じもした。
  3. 補正フィルタのHPFのカットオフを57Hzにして試した。
     • 結果: 約40分(途中休憩あり)で問題(少し耳が聞こえにくい)が出た。→ 65Hzに戻したら治った。
     • 考察: 問題が起こらないカットオフ65Hzとの周波数の差は8Hzと小さく、超低域の振幅の違いも高々2dBと小さいにも関わらず耳の問題が起こることから、超低域の量の耳への影響は かなりシビアなようだ。

 

• 微小雑音: 先日試用した某DACで見られた雑音3種類を模擬した。
  1. 中域(数百Hz-1kHz辺り)に広がる雑音
     • 設定: REWの信号発生器で概ね440Hz-1.2kHzに広がるホワイトノイズ(出力: -104dBFS, BU4フィルタで500-1000Hzの帯域制限)を出して再生信号に加えた。 (→ 再生音と雑音の比較)
       • 雑音の音量: -85dBFS (A)
         • ボリュームを最大にしても雑音は聞こえない。
     • 結果: 約40分で問題らしきもの(わずかに耳が痛い)が出た。→ 元に戻したら治った(すっきりした、嫌な感じがなくなった)。
       • 他に、音が悪い感じやわずかな耳閉感や超低音とは違う良くなさを感じた。
     • 備考: この雑音の発生原因は想像できないが、回路の設計や実装(要するに「出来」)が悪いのではないかと思われる。
  2. 8kHzと高調波
     • 設定: REWの信号発生器で高調波を持つ約8kHzの正弦波(7600Hz, -83dBFS, 歪み制御で6次まで-6dBの高調波を追加)を出して再生信号に加えた。 (→ 再生音と雑音の比較)
       • サンプリング周波数96kHzで試すと上述のように、リサンプラの問題で何が悪いか分からないため、44.1kHzで試した。そのため、2次高調波までしか出ていない。
       • 雑音の音量: 約-86dBFS (A)
         • ボリュームを最大にしても雑音は聞こえない。
     • 結果: 約40分で問題らしきもの(少し耳が変な感じ)が出た。 → 元に戻したら治った。
       • 約20分で高音が ちょっとキツい感じになったが、高域が出ているようにも感じた。
       • 最終的には、耳はおかしくないものの、聴きたくなくなったので中止した。
     • 備考: この雑音の発生原因はUSB(High speed)からだと思われる。光や同軸入力では起こらなかった。
  3. 34kHz辺りに広がる雑音
     • 設定
       • REWの信号発生器で概ね30k-40kHzに広がるピンクノイズ(出力: -80dBFS, BU8フィルタで30000-37798Hzの帯域制限)を出し、Jack rackのGlame Highpass Filter(カットオフ: 33000Hz, Stages: 2)で帯域を狭めて再生信号に加えた。 (→ 再生音と雑音の比較)
       • 雑音の音量: 約-86dBFS (A)
         • 可聴域外のせいもあり、ボリュームを最大にしても雑音は聞こえない。
       • 注: 雑音が可聴域外のため、これだけはサンプリング周波数を96kHzにした。
     • 結果: 約30分で問題らしきもの(軽い唾飲みの違和感, うるさい感じ)が出た。 → 元に戻したら治った(耳が楽になった)。
       • なお、再生音なしで雑音をスピーカーから出すだけでは、数分間では問題は起こらなかった。
     • 備考・考察
       • この雑音の発生原因はACアダプタ(スイッチング電源)だと思われる。実際に、DACの負荷を変えたらピークの周波数が変動した。
       • 可聴域外の雑音が聴感や耳に影響を与えるのは信じられないが、例えば、混変調のような仕組みで可聴域に影響を与えるのではないか。
       • Scarlett Soloは適切でないノイズシェイピングのために30kHz以上に雑音が出るので、その影響も これと同様と考えられる。
       • (4/27 8:33) 書いたあとで調べたら、スピーカーの超高域(約30kHz以上)の振幅特性が増大している(40kHzで約+10dB)測定結果があった。(出典: 中央辺りの"Im Zeichen des Z"のグラフ) 物理的に疑わしいが、グラフのキャプションによれば、おそらくユニットの共振によるようだ(Google translateでの英訳: "Resonance well above the audible range.")。もしそれが正しいなら、このような超高域の雑音の影響が増大する可能性がある。
         • これで思い出したが、FocusriteのサポートはScarlettから30kHz以上の雑音が出ていることについて、「普通にあることだし、可聴域外だから全く問題ない」(概略)と返答したが、実際に こういうスピーカーがあるのだから、全く問題ないとは言えないことは確かで、連中の見識の浅さが証明できた。
         • それとは別に、僕のスピーカーの思わぬ欠点(Scarlettと同様)が今頃見つかって ちょっとがっかりした。

• 歪み: 先日、Spofityの音量正規化を試していてい気付いた、増幅とリミッターでの歪みの影響を調べた。
  • 設定: 再生信号をJack rackのFast Lookahead limiterでリミッター付き増幅(ゲイン: 6dB, Limit: 0dB, Rel. time: 0.5s)して出力した。(→ 設定と歪みの比較: 試したのは濃紫)
  • 結果: 約25分で問題(聞こえにくい感じ)が出た。 → 元に戻したら治った(音が透き通った感じになった)。

 

追加: スピーカーのバスレフポートを閉じる影響のチェック

上に加え、低域を減らすためにスピーカーのバスレフポートを閉じているので、冬などにスピーカー内部の温度変化の影響でコーンに圧力が掛かって(オフセットと同様の効果で音が悪くなって)耳に問題が起こる可能性(下を参照)を思い付いて試したが、関係なさそうだった。

温度変化でのスピーカー内の圧力変化の試算

ボイル・シャルルの法則: P(圧力)V(体積)/T(温度)= K(一定) を用いる。

スピーカー内部の温度が14℃(T₁)から7℃上がった(→ T₂)場合(冬の朝を想定)の、中の空気の圧力(P₁ → P₂)の変化率(ΔP)は、

P₁= K T₁/V, P₂= K T₂/V (Vはスピーカーの容積で一定)
T₂= T₁ +7なので、P₂= K (T₁+7)/V
ΔP= P₂ / P₁= (T₁+7)/T₁
T₁= 14なので、ΔP= (14+7)/14= 1.5倍

と、圧力が かなり大きくなってコーンに力が加わる可能性がある。

圧力変化の影響の検討

• • 圧力変化の結果、コーンが前後(上の場合は前)に動き、アンプのオフセット出力と同様にコーンの運動を制限する可能性がある。
  • ただ、「1.5倍」は大きく見えるものの、スピーカーの仕様・特性で全く影響がない可能性があるし(密閉型スピーカーでは当然のことである)、どこかから空気が漏れて(比較的短い時間で)外の圧力と同じになる可能性もある。

実際に、ポートにフィルム(PEのゴミ袋)を張って塞ぎ、暖房を停めて室温を1.3℃下げてみたが、フィルムの張りに変化は なかった。(→ 室温が下がる前, 下がった時) なので、このスピーカーは完全な密閉構造ではなく、どこかから空気が漏れていると推測した。同軸型ユニットなので、ウーハーとツイーターの隙間からか と思う。そもそも、これはバスレフ型なので密閉構造にする必要がなく、多少漏れても当然と思われる。

ただ、急な温度変化時の圧力を逃がすのは意味があると考え＠、今までの完全に塞ぐタイプのプラグ(純正品 → 写真: 黒いスポンジ)の代わりに、直径5mmくらいの通気口があるプラグを作って※交換した。なお、穴が小さいため、低域の特性には ほとんど変化がなく＊、聴感上の違いもなかった。

＠ただ、もし効果があるとしても、次の冬まで分からない

※ストローに古いバスタオルを切ったものを巻いた。

＊プラグからの漏れのせいか、左右別だと50Hz以下が少し(1-1.5dB)大きいが、両方出して測ると なぜか差がなくなる。部屋の特性の関係だろうか。

 

むすび

ひとまず、長年の謎と課題が片付いた(実際には次の冬まで分からない)。耳の問題が大きく、部屋の特性が拍車を掛けている感じだ。※ 設定や機材の問題もあるものの、おそらく、過去の病気で耳が敏感・過敏なために厳しくなっているのだろう。

※部屋に関しては吸音材で何とかなりそうに思われるが、超低域は そんなに生やさしいものではない。確か、数十Hz辺りでは数十cmの厚みが要る気がした。コンサートホールやスタジオの天井や壁の厚みとか そこに付いている拡散板(想像)を見れば分かる。

検索したら、ある波長の音の吸音に必要な吸音材の厚さの求め方として、波長/4や波長が出て来た。それらで例えば50Hzに必要な厚さを考えると、波長は6.8m※であるから、前者では1.7m、後者では約7mと、全く実用的でない値となる。

※吸音材でも空気中の波長で計算して良いのか分からない。吸音材の空間で吸収するからそうなのか。逆に、空気でないものには入って行かない(反射する)か。

しかも僕の場合は50Hzどころか20Hz辺りから対応したいから、天文学的だｗ まあ、吸音材の材質にもよるだろうから、あくまでも例として挙げたが、普通に吸音材で共鳴(反射)を防ぐのは難しく、部屋の構造から対処する必要がある(例: 共鳴しないように、平行な壁を作らない)。

実際、後者のページに載っている吸音材の特性は、最も良いものでも300Hz辺り以下には対応していない。前者のページには無響室で使われる吸音くさび(高いらしい)の例が載っている。が、超低域では性能が悪いようだ。(ただ、グラフでは平板の吸音材の60Hz台の性能が500Hzと余り変わらないことになっており、とすると1m以上もの厚さで測ったのか、測定結果には ちょっと疑問がある。)

まあ、残りは いずれも容易には解決できないことは分かったので、とりあえずは我慢だ。

 

その後の話 (2023/4/28 10:11)

いつものように、書いたあとで分かったことなどを書く。

マイクの特性について+補正フィルタは神聖にして変えるべからず。

本文に書いたように、部屋+スピーカーの補正フィルタを減らせないか検討していて、測定用マイク(Dayton audio EMM-6)の実測特性(製品にグラフが添付されていた)を見たら、意外に平坦でないことが分かった(グラフの縦軸のスケールが荒いために平坦に見える)。

更に説明書を見たら、測定データがダウンロードできることに(今頃)気付いたので、(買ったのは随分前だけど)試したらできた。ボケていたのか、最初は測定値の表記をリニア(基準を1とした時の比)と思い込んで、最大で2倍近い山("1.9")があると思い、それだと測ったスピーカーの特性も怪しいから補正フィルタの補正量が大き過ぎるのではと思って補正フィルタを再調整しようとした。

が、データをREWに取り込むためにdBに変換するコマンドを実行したら、エラーが出て(負の値があったため)、測定値がdB表記であることに気付いた。それであれば、最大1.9dB(1.2倍)と悪くない。実際、スピーカーの特性を補正しても大きな差は出なかった。 (→ グラフ: 緑(補正前)とベージュ(補正後), 灰はマイクの特性: 左のグラフと同じもの)

それでも、マイクの特性※が山になっている辺りの補正量を下げるとか なくせるかも知れないと試したが、意外にも無理だった。: 補正フィルタはHPF以外に160, 358, 790Hzがある。まず、160と358Hzの補正量をマイクの補正として2dBくらい減らした(出力は増加する)が、耳が拒否した(こもる感じ、耳が変な感じ)。更に、補正量を元に近づけても駄目だったし、358Hzだけ調整しても駄目だった。また、元々補正量が小さい790Hzを なしにするのも駄目だった。

※同時にスピーカーの特性も考慮しようとしたが、それは部屋で測定した値に含まれているので、考慮する必要がないことが分かった。

不思議なのは、そういうのを止めて元に戻すと変な感じが治るので、なぜかは分からないが、今の補正フィルタは少しでも変えては いけないようだ。＊ 他に、音の好みや慣れもあるのかも知れない。

＊その理由は分からないが、時間が経ってマイクの特性が変わった(平坦に近くなった?)とか、元々の補正量がギリギリで必要量より小さいのかと思う(確かに、なるべく小さくした覚えはある)。

スピーカーの超高域の共振について

本文に書いたように、使っているスピーカー(KEF Q300)は超高域に山がある(他者の測定結果がある)件について疑問が湧いた。

• 製品仕様での記述("Frequency response (±3dB): 42Hz-40kHz")と その測定結果(40kHzでは+8dBくらい)のどちらが正しいか。
• 超高域での増大が なぜ問題にならないか。

いろいろ調べてみたら、同じ製品ではないものの、同じメーカーのRシリーズの資料に、超高域(30kHz辺り)に山があるグラフが載っており(P. 15, Fig. 23)、ハードドームツイーターの共振をウェーブガイドで抑えている※という記述があるので、僕のスピーカーの測定結果も正しそうなことが分かった。つまり、仕様の記述が正しくなさそうだ。

実際、後継製品(例: Q350)の記述は"Frequency response (±3dB): 63Hz-28kHz"と、高域が低くなっている。上位機種(R3)では、"Frequency range (-6dB) 38Hz-50kHz"のように、(どんな音になるかは分からないが、)以前よりは正直に、増分(+XdB)を記載せずに共振する帯域を含めて書いてある。

※グラフを見ると、僕にすれば、抑えたって まだまだひどい。共振するなら100kHz以上にしたいところだ。(高価な素材でなく)アルミだから共振周波数が低いのかは分からないが＠、上位機種でも こうやって無理する理由が分からない。

＠スピーカーの超高域での共振について更に調べたら、分割振動＊によるものだと書いている資料があった。(参照: P.9 「5.2 Tweeter(ツイーター)」) そこに示されたグラフは 上と同様に、アルミ振動板の23kHz辺りに山がある。そして、ベリリウム％には それがない。また、柔らかいから良さそうだと思って居たソフトドームも比較的低い周波数で分割振動を生ずるということなので、一概に、金属でなければ良い訳ではなさそうで、難しい。

＊詳しくないが、分割振動すると歪みになるのであって、ある周波数の出力が増大するのとは違う気がする(分割振動したら、基本波は弱くなるのではないか?)。まあ、用語は どうでも良い。

％大昔、ベリリウム(ヤマハ NS-1000M)やボロンやダイアモンドを採用したスピーカーがあって、良く分からずに憧れていたが、こういう問題に対処していたのかと今になって分かった。

結局、僕のスピーカーはハイレゾでは使い物にならないというか、使ってはいけないことが分かった。「超音波発生機」になってしまう。これに、30kHz以上で雑音が増大するScarlettを組み合わせたら最悪だ。

まあ、僕はハイレゾを使う予定が ないから実害はないが、今になってメーカーの思想が全く受け入れられないことが分かった。

あと、確証はないが、本文にも書いた、サンプリング周波数を96kHzにした時の印象が悪い問題に関係しているのかも知れない。

ハイレゾ音源やサンプリング周波数を96kHz以上にした時の問題に対処する方法を少し 考えたが、どれも今一つな感じだ。いずれにしても、サンプリング周波数が高い意味を削ぐので馬鹿らしい。

• • △ DAC出力の前にソフトのLPF(カットオフ: 20kHz辺り、以下同)を入れる。: 悪くなさそう(以前やっていた)だし、手軽に出来るが、結構低い周波数から振幅や位相に影響があった覚えがある(キツいものは音質を劣化させる)。あと、良いフィルタを選ぶ必要がある。
  • △ DAC出力とアンプの間にLPFを入れる。: 悪くないが、結構低い周波数から特に位相に影響がありそうだ。
  • × アンプの出力とスピーカーの間にLPFを入れる。: スピーカーのインピーダンスは周波数で変わるので、安定に動作させるのは難しそうだし、アンプに容量性負荷(LPFのコンデンサ)を掛けるのは良くないという話もあるので、簡単ではなさそうだ。

世の中(欧米?)には、「聞こえなければ問題ない」と考えるメーカーが結構あるのに驚く。

その点、日本のメーカーは昔から律儀・健気に頑張っており※、例えば、ヤマハ NS-5000は強い共振を防ぐため、ZYLONというものを使っている。(昔からいろいろ繰り返されて来た)そういう工夫が本当に効くのかは不明だが、イメージ的には良さそうだ。以下、上のページからの引用(太字は筆者):

We have chosen textile made of 100% ZYLON® — a synthetic fiber of exceptionally high strength, having acoustic velocity as well as the ability to reproduce the finest details of audio equivalent to those of beryllium but without a sharp resonance peak inherent in a hard material

※そういう、実益があるのかないのか分からないところで頑張るのが、欧米に馬鹿にされたり「ガラパゴス化」したり没落する原因なのだろうが、思想や技術的には間違っていない。

もし次にスピーカーを買うとしたら、こういう共振のないものにしたい。良く調べていないが、ソフトドームや(金属でない)コーンなら大丈夫そうだが、どうだろうか(上記のように、一概に柔らかい素材が良い訳ではなさそうだ)。 例えば、Fostex辺りが出していて人気のある、シングルコーンのフルレンジがいいのかも知れないな。

こういうことが、そこらの、一見何の変哲もないものが人気がある理由のひとつなのかも知れない。昔は何も知らず、安易に金属コーン・ハードドームを選んだが、僕も進歩したものだ。

 

PS. だから、僕はきっとスーパーウーハー満載で超パワフルに「ドゥオンドゥオン」鳴ってる車には乗れないだろうし、クラブとかDJ(想像)にも行けないだろうｗ そう言えば、昔(耳の病気以前)、ロックのコンサートに行ったことがあるが、超低域以前に耳栓がないと耐えられなかった。

とは言え、低音が嫌いな訳じゃなく(ある程度 低音が豊かな ほうが生演奏に近付く)、持論(収録された音を そのまま出すのが「いい音」)に従って可能な限り平坦に出したいとは思っている。それで、本文に書いたように、勝てないと分かっているチキンレースをする訳だ。

 

(20:43 吸音材について追記; 21:08 原因(推定), 対処に加筆, 構成を修正; 21:28 その他に補足・修正; 22:19 症状(聞こえにくい)に参照先を追加; 4/27 8:33 アンプとサウンドカードの超低域の抑制に補足, 構成を修正, 34kHzの雑音に加筆; 4/28 6:36 Q300の振幅特性のグラフを追加(引用); 4/28 10:11 その後の話を追加, 15:56 わずかに補足, 16:22-18:38 スピーカーの超高域での共振について加筆, その他を少し修正・補足)

数週間前にSpotifyからメールが来た。題に書いたように、5/12から僕の使っている古いデスクトップアプリが使えなくなるとか書いてあったが、古い版やAPIを使う自作のプログラムも使っているので、具体的に いつ使ったどのバージョンが駄目か示してくれないと、何が使えなくなるのか分からず困った。

メールには問い合わせ先が書いてあったけど期待できないから検索したら、最初は何も出てこなかった。公式サイトにも何も書いてなかった。仕方なく、メールでの問い合わせも可能なようなので出してみたら、予想通りの回答が来た。: Linux版は非公式なのでサポート対象外(なので知らねえ!)と。※ そして、それ以外の質問(どのバージョンが「古い」のか、僕のLinux版は「古い」のか、見分ける方法は?)は無視だ。

※公式のページにインストール方法を書いたり、有料コンテンツへのアクセスを許可しているのに、こういう時に「非サポート」と逃げるのは無責任だ。

頭に来たし、できることもないので放置していたら、次の週に またメールが来て更にイライラした。

再度検索してみたら今度は出て来て(参照: 1, 2)、結構多くの方が困惑し、みんな怒っているようだ。その中に、チャットのようなもので問い合わせて「大丈夫」という回答を得た方が居たが、僕は信用・安心していない。

というのは、通知メール自体が曖昧な書き方(→ 英語版)※だし、問い合わせた時の回答も「分かってない人」からだったからだ。きっと、今のSpotifyはツイッターのように中が混乱していて、「古いアプリが使えなくなる」ことの実体・真相を把握している人は少なく、サポート担当は分かってないのではないか。

※メールには以下のように書いてあるが、客が使っている版が2021/4より前にリリースされたものかどうか書いてないから駄目な条件が不明で、2021/4以降にリリースされたものは使い続けられるのか不明だ。

• • 客が使っている版(バージョン不明)は古いので、2023/5/12から使えなくなる。
  • 2021/4より前にリリースされたものも使えなくなる。

どうして こういう書き方をするのか分からない。: 「バージョン＊以前のものは駄目」と書けば明確になるのに。もしかして、Linux版を「古い」という表現で排除しようとしているのだろうか?

大体、日本語での回答と英語での回答(上記)が違うのがおかしい! 僕は、英語で、使っているバージョン(上の「大丈夫」と同じ)を書いて聞いたのに、日本語で上述のように駄目という回答が来た。日本のサポートの連中が使えないなら、迷惑でしかないから きっぱり撤去して欲しい!

だから、できることは、5/12(メールは日本語だったが、UTCか日本時間かも不明!)の9時(UTCの0時)頃に、引き続きSpotifyアプリが使えるかどうかを試すしかない。使えなくなったら困るが※、今は何もできない。

※その時は、不便だけどweb版プレーヤーを使えば、とりあえず再生は可能だ。

駄目になったら移行先※を考えるか、他者のプレーヤーを試そう。

※探したけど ほとんどない・・・

 

(2023/5/12 9:15) 古いアプリが使えなくなるという期限(2023/5/12、ただしUTCかどうか不明)になったので、今使っている(現行版, version 1.2.8.923.g4f94bf0d: 警告が来た時から変更なし)Spotifyを再起動して使えるか試したが、問題なく再生できている。

ただ、キャッシュの関係でまだ大丈夫なのかも知れないし、そもそもSpotifyが信用できないので、しばらく様子を見る。

そういえば、この稿を書いて少しした頃から警告のメールが来なくなったので、Spotifyが誤りに気付いたのか、警告は以前使っていた旧版に対してだったのかも知れない。いずれにしても、原因(何が悪かったのか)教えてくれないのは迷惑だ。

(5/12 18:51) アプリは更新されていないけどUIが更新されたようで、少し変わった(けど、変わったのは どうだっていいところで、依然としてイマイチどころか、使いにくくなった)。ということは、このアプリは「古くない」し、使い続けられるってことだろう。Spotifyの(日本語の)サポートの奴は全くいい加減なことを書いていた。

自力で問題に対処したのはWordPressのAIOSプラグインだけでない。今日、先日書いたNextcloud(ファイル・PIMサーバ)の問題にも対処した(2回目)。

現象は、管理画面がスクロールできないという情けないものだ。ブラウザはVivaldiとFirefoxで起こった。(いずれもLinux版) Chromeも同様と思う。

(「あくしろ!」な手っ取り早く解決方法を知りたい方は、下の「解決方法」へ)

初めて気付いた時(去年の末)に調べたら、他の方も同様の現象が起こっており、CSSを修正(プラグインCustom CSSでCSSに追加)して暫定対処していた。僕もそれに倣ってみたが、直らなかった。その後試行錯誤して、どうにかうまく行くようになった。 (→ 後述のCSSの上半分)

しかし、近頃再発してしまった(もしかすると、以前からだったが気付かなかったのかも知れない)。: 今度は、アプリ管理画面がスクロールしなくなった。

再び検索したところ、同様の問題が起こっている方が居て、フォーラムに投稿しているものの、見付かった2件は解決していない。ひとつではユーザの環境の問題(いわゆる「おま環」)にされ(結構多くの人のところで起こっているのだが・・・)、もう片方では開発側の回答がないという、良くある ひどいありさまだ。

それでまた、開発者ツールでCSSを試行錯誤して、どうにか スクロールするようにできた。

(解決方法) 最終的には、以下をCustom CSSに追加した。

body, body #content { 
  overflow: scroll!important; 
  position: absolute!important;
}

.content[data-v-3cd3ed01]:not(.with-sidebar--full) {
  position: unset!important;
}

上半分はアプリ管理画面以外の全体的な対処、下半分がアプリ管理画面の対処である。後者は謎の数字や条件があって、いかにもNextcloudが更新されたら効かなくなりそうだが、良く分からないし(、こんな腐ったもののことなど)分かりたくないので、とりあえず使っている。駄目になったら またやれば良い。

その時は、AIに聞いたら教えてくれるだろうか??

 

どうも、"Nextcloud Hub"とか名乗ってから腐ってしまったようだ。例えば、このスクロールの問題以前に、画面のデザインが醜悪になってしまった。※ そもそもはownCloudのコピーだったが、"Hub"になってから自分たちでやろうと無駄に頑張って駄目にしてしまったのではなかろうか? (良くある話だ・・・)  大体、問い合わせにまともに対応しない時点で終わっている。

※そう言えば、上に挙げたフォーラムに書いてあったが、スクロールできない問題はテーマを変えると起こるのかも知れないようだ。確かに僕はテーマを変えている。が、デザインがひどくて見にくいので仕方なくしたのだし、設定くらいはまともに動くようにすべきだし、動かない設定は付けないで欲しい。全く腐ってる!

「いい加減にしろ!」って言いたいが、いい加減にされて困ってるｗ

それで乗り換え先を探しているけど、いいものはなく、ownCloudの最新版(OCIS)に戻るか、今まで知らなかったがSeafileかというところだ。

画面を見るたびにイライラするものの、安易に乗り換えられるものではないので、しばらくはNextcloudを使うしかない。まあ、画面は余り見ることがないのが幸いだ。

 

題に書いたように、近頃はオープンソースの質が随分落ちた気がしている。たまたま僕が使うものだけなのか、それらのユーザが少ないからかも知れないが、出すのならもっとしっかりして欲しい。自分たちのやりたいことだけやって、ユーザから報告される問題に碌に対応しないのなら、公開しなければいいではないか。

なお、「オープンソース」とは書いたものの、有料ソフト・サービスだって負けては居ないｗ※ それどころかハードだって同じだった。それらはユーザは手の出しようがない場合が多いから、余計ひどい。

※例えばSpotify(特にサポート)は ひどいものだ。またあとで書きたい。 → 書いた。

結局、なんでも駄目なものは駄目。しかも、駄目なものは増えているって結論か。