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

まとめ的なもの

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

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

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

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

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

数週間前に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の(日本語の)サポートの奴は全くいい加減なことを書いていた。

先日、Spotifyアプリを現行版に切り換えた。アンプなどの改良の効果か、以前試した時に起こった耳の問題が起こらず安心していたのだが、別の問題が発覚した。それは、音量正規化をonにしているのに、他より小さく聞こえる曲(演奏)があることだ。

実は少し前から気付いていて、その時に調べたのだが、正規化しても演奏ごとの音量に ある程度の幅ができることや、主観的な差(音の作りで聞こえ方が違うのと耳の調子)ではないかと思って居た。しかし、今日、TOTOの"Africa"が明らかに小さく聞こえたので、ebumeterというプログラムで音量(ラウドネス)を測ってみた。比較のため、普通の音量に聞こえるELOの"Don't bring me down"も測った。以下にIntegrated loudness("I")を示す。なお、アプリの音量正規化のモードは"Normal"である。

• Spotifyの音量正規化Normalでの音量(ラウドネス, LUFS)
  • Africa: -22.8
  • Don't bring me down: -17.0

両者の差は5.8 LUFS(dB)と2倍近く、Africaが小さく聞こえるのも無理はない。

参考までに、"Africa"の正規化offの場合と旧版Spotifyと別の再生アプリ(gmusicbrowser, GMB)での正規化なしでの音量(ラウドネス, LUFS)を示す。

• • Spotify(新版, 音量正規化: off): -22.8
  • Spotify(旧版, 音量正規化: Normal): -17.6
  • GMB(音量正規化: off): -15.2

不思議なことに、正規化をoffにしても同じ音量となった。これは、正規化をonにしているのにonになっていないように感じたことに合っている。

旧版での"Don't bring-"の音量は測定していないが、新版と同じとすれば 音量が揃っているので、聴感に合う。それから、メディアやバージョンが異なるせいか(手持ちはBlu-spec CD, Spotifyは無印)、GMBでの音量はSpotifyより大きい。

アプリの設定を いろいろ変えて試したが、効果はなかった。それで、アプリにバグがあって、"Normal"モードでは正規化されないのかと思った。

それで、(別の理由で以前やっていたように、)全体的に音量が小さいQuietモードの出力をJACKのアンプで増幅して音量を上げるようにしてみた。すると、どういう訳か、耳に問題(軽い耳閉感)が起こった。原因は、ピークの大きい演奏を増幅すると、ピークがオーバーフローしてクリップして音が歪むからではないかと推測している。だから、Quietモードでも増幅しなければ良さそうなことが分かった。

それで更に、そもそも どういうことか検討したら、音量が小さい演奏があるのはアプリのバグではなさそうなことが分かった。: Spotifyの音量正規化に関する資料を良く読み、試しにゲインなどを計算したら分かった。以下に重要な箇所を引用する(太字は筆者)。

Positive or negative gain compensation gets applied to a track while it’s playing.

• • Negative gain is applied to louder masters so the loudness level is -14 dB LUFS. This lowers the volume in comparison to the master - no additional distortion occurs.
  • Positive gain is applied to softer masters so the loudness level is -14 dB LUFS. We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality.

Example: If a track loudness level is -20 dB LUFS, and its True Peak maximum is -5 dB FS, we only lift the track up to -16 dB LUFS.

上の例(Example)の計算を細かくすると、以下になるだろう。

本来のゲインG= 基準音量 Ref(-14) - Loudness(-20)= 6 dB
Gで増幅した場合のヘッドルーム H= TruePeak(-5) + G(6)= 1dB (オーバーフロー → クリップ)
確保したいヘッドルーム H'= -1dB なので、修正ゲイン G'= H'(-1) - TruePeak(-5) = 4dB
修正後の基準音量 Ref'= L(-20) + G'(4)= -16 LUFS:上に合う

それで、問題の"Africa"(True peakは推定-0.6dBFS)では どうなるかと言うと、

本来のゲインG= 基準音量 Ref(-14) - Loudness(-22.8)= 8.8 dB
Gで増幅した場合のヘッドルーム H= TruePeak(-0.6) + G(8.8)= 8.2dB (オーバーフロー)
確保したいヘッドルーム H'= -1dB なので、修正ゲイン G'= H'(-1) - TruePeak(-0.6) = -0.4dB
修正後の基準音量 Ref'= L(-22.8) + G'(-0.4)= -23.3 LUFS: 元の音量-22.8 LUFSとほとんど変わらない。

と、音量正規化後の音量は聴感や実測した音量(LUFS)に合う。更に、想像だが、修正後のゲイン(G')が負の場合には正規化しないとすると音量が変わらないので、実測値と一致する。

なお、Quietの場合も、修正ゲインG'と修正後の基準音量Ref'はNormalと同じ-23.3LUFSとなり、基準音量(-19LUFS)より小さいが、Normal(基準音量は-14LUFS)より差が小さくなる(9.3 dB (2.9倍) → 4.3 dB (1.6倍))ために目立たないのではないか。

実際にQuietで聴き・音量を実測したら、聴感も数値も見事に揃った。実測の音量は以下である。

• Spotifyの音量正規化Quietでの音量(ラウドネス, LUFS)
  • Africa: -22.8
  • Don't bring me down: -22.0

また、別のレベルメータで調べたところ、クリップしていない(最大値が0dBFS未満)ことも確認した。

そのためか、今のところ耳の問題も起こっていないので、これで一件落着か。

とは言え、いつものように、以下のような余計な考え・こだわりはあるｗ

Quietにして全体の音量が小さくなったため、(本物の)アンプのボリュームを少し(5dB, 約1.8倍)大きくする必要があるが、まあ仕方ない。1.8倍は大きく見えるが、ボリュームの特性上、今までより少し(時計の5分分未満, 10°くらい?)回転が増える程度だ。

ただ、(上に書いた、以前のJACKのアンプでの増幅の理由に関係するが、)DACからの出力の精度やダイナミックレンジ(有効数字的なもの)が約1ビット減る(1/2になる)ので、その分音質は悪くなるはずだ。増幅してクリップするのと、ビット数が減るのとどちらが良いかの話になった。

丁度良いゲインと良いコンプレッサーで「うまく」増幅するといいのだろうが、JACKには良いコンプレッサーがなさそう、かつ、設定が難しいので、とりあえずは これで行こう。

あと、期待混じりであるが、ほとんどの音源は16ビット精度で、PCの内部では浮動小数点数で処理され、DACは24ビットなので、DACに出す時の変換で1ビット分が消えずに残る可能性がある。それなら音は悪くならない。せいぜい、DACから出る信号が弱いために雑音が入りやすくなる程度だ。そうであれば、コンプレッサーを入れて常に音を変質させるより ずっと良い。

ただ、そうは言っても、アナログ信号が弱いと雑音が入りやすいのは確かだ。そこで、音量正規化の時だけ(JACKで)クリップしない程度に増幅して、ちょっと大き目に出せれば(気分が)良さそうだ。

が、Spotifyが音量正規化しているかどうかは設定だけでは分からないという問題がある。: 音量正規化の設定がonでもアルバムを再生する時はoffになる、賢く便利だけど ある意味余計な お世話的機能があるためだ。

実際に音量正規化しているかの状態は外部から取得できないので、例えば再生キュー内の曲のアルバムが同じかどうかで判断(推測)することが考えられるが、面倒なうえに時間が掛かる。仮に再生開始時に判断して増幅するかどうかを変更するとすれば、演奏の先頭の音量がおかしくなる可能性がある。

と、ちょっとした思い付きでも実現は面倒だ。どうにかできないかAIに聞けば、教えてもらえるのだろうか??

例によって だらだらしたので まとめると、(現行版の)Spotifyアプリで音量正規化をNormalにしていて、やたらに音量が小さい曲(演奏)がある場合は、Quietにしてボリュームを上げれば良いことが分かった。これはLinux版だけなのか、他のプラットフォームでも有効なのかは分からない。

参考・補記

検索して この問題(現象)を調べたけど同じものは見付からず、Spotifyのフォーラムに類似のもの(2022)があったものの、例によって未解決だった。もしかしたら同じなのかも知れないが、分からない。

それから、これはLinux版固有なのかも不明だ。想像だが、Linux版が新しくなった時に音量正規化の方法が変わり、他のアプリ(例: スマフォ用)と共通になったのかも知れない。そうであれば、Linux版以外でも起こるかも知れない。

最初に書いた、以前新版を試した時に起こった耳の問題は、これとは関係なさそうだ。というのは、上に書いたように、Normalではクリップするほど無理に増幅しないため、音量が小さい代わりに歪みが発生しないからである。

それでは旧版(音量が揃っていた)では どうなのかは気になるところだが、(結果的にピークがオーバーフローすることになっても)増幅しているものの、うまく圧縮してひどい歪みが起こらないようにしていたのではないだろうか。これは他の再生アプリや配布される音源(例: 「海苔弁」)と同じことで、多少音を悪くする代わりに ひどいことにならないようにしているのだろう。

この問題に関して検索した時に、「(音が悪くなるから)音量正規化はoffにすべきだ」みたいな意見があったが、僕は全くそうは思わない。音量正規化をするのは音質よりも便利さを求めるからで、耳に問題が起こるほど音が悪くならない(「それなりに聴ける」)なら問題ない。

逆に、現行版のSpotifyアプリのNormalの動作は音質の点では正しいとは思うが、一貫性がなくて不便で、無意味だとすら思う。せめて、デフォルトをQuietにすべきなのではないだろうか?

てことは、つまり、Spotifyが-14 LUFSに合わせているのが おかしいってことでは? -22や-23辺りで良かったんじゃないの?? と思うが、YouTubeなどの他のサービスは-14辺りのようなので、仕方なさそうだ。

あと、平均音量を下げるとダイナミックレンジが小さくなって音質が劣化する演奏が増えそうだ。その点では、24ビットで配信をすれば まるっと解決しそうだ。

しなくちゃならないけど面倒で、なかなか進まないことが溜まった。ただ、いくつかは事前の予想と違って すんなりできた。

• PHPとLinux Mintの更新。。。
  • 久し振りに両方がメジャー更新なので、互換性の事前確認をする必要があったり、更新中・後に必ず問題が起こるので、全く気軽にできない。
    • ただ、Linux Mint(実際にはUbuntu)を更新すれば それに含まれるPHPも更新されるので、手間は少ない?
  • デスクトップだけでなくサーバもなので、面倒さは2倍だ・・・
  • まあ、Winのように鬱陶しい通知や強制更新がないから、自分のペースでできるから助かる。
• [済] digiKamの更新: 比較的容易に更新できた。結構改良されていた。
  • メジャー更新直後は まともに使えなかったので2年近く放置していたが、今回は ちゃんと動いて良かった。
  • ただ、どういう訳か、OSの再起動後に一度カタログ(画像のディレクトリ)全体を更新しないと、新しい画像が自動認識されなかった。
• [済] Spotifyのアプリ: 旧版から現行版に乗り換えた。
  • 現行版だと耳に問題(例: 耳閉感)が起こるので旧版を使っていたが、逆に以下のような問題が起こるようになったので、乗り換えた。
    • Autoplayをoffにしているのに、ミックスやアルバムが終わると勝手に曲が追加されてしまう。
    • レイアウトがおかしくなった。: 例えば、Made for youのアイコンが巨大になってしまう。
  • 耳の問題は、オーディオシステムの改良(あとで「その後」(完結編?)を書きたい)の効果か、あるいは、季節が変わって耳の調子が良くなったのか、起こらなくなった。
    • 想像では両方だと思う。: 現行版のアプリは旧版より耳に良くない音(超低域(例: 10Hz以下)と推測している)が出やすいのではないかと思う。
      • オーディオを改良して それらの音が出にくくなり、また、春になって耳の血行が良くなったために問題が起こりにくくなったのではないか。
        • → 改良が片付いてから原因を調べる予定だが、おそらく再現せず分からない気がする。その場合は次の冬に確かめられる。
• [保留] スマフォの買い替え? → 壊れるまで保留にした。
  • OSが古くなってセキュリティの問題はあるが、「今まで大丈夫だったのでヨシ!」ということにしたｗ
  • 今のスマフォに格別欲しいものがない。
    • いろいろ退化しているのが許せない。
      • 例: 巨大で重いものばかり、画面にカメラの穴・・・、背面に不格好なレンズの出っ張り、通知ランプがない、イヤフォンジャックもない。
    • 買うならAQUOS sense 7だろうけど消去法で、特別欲しくない。

結局、溜まっていたけど残りは1個になった。

が、その前に、オーディオの改良の片付け(最終チェック・まとめ)をしなくてはいけない。1個謎は残って居るものの問題なく聴けているので、なかなか面倒になってしまったｗ

(3/28 6:53) が、その後、厄介なものが2つも増えた。。。

• Joplin (ノートをPCとスマフォで同期するために使っている)の代替探し?
  • 少し前から、スマフォのJoplinアプリの同期が開始するまでに すごく時間が掛かるようになったので、アプリのストレージを消して再設定して同期(ダウンロード)しようとしたら、何時間掛かっても終わらない。
    • 仕方ないので、サーバ側のノートなどを全部削除してPCから再アップロードし、そのあとでスマフォに同期(ダウンロード)しようとして居るが、これで直るか分からない。
    • → PCからサーバにアップロードし直し(これも遅く、約5時間掛かった)、スマフォにダウンロードしているが、約0.6ファイル/sと余りにも遅い。 (3/28 13:35)
  • 以前からJoplin(開発の仕方と出来)は怪しいと思って居たが、そもそもクソな(設計がひどい※)ことが確定したので、他を探し始めた。
    • ノートをスマフォに同期できて表示できるだけで良い。
      • 今のところ、Zettel Notesが良さそうだ。
    • ※サーバでノートやリソース(添付画像)が それぞれ全部単一ディレクトリに格納されるため、ディレクトリが肥大化してしまう。論外な作りだ。
      • 何らかの上限はあるだろうから いつか破綻するし、それ以前にも同期の効率が悪くなるだろう。
        • これが問題の原因かと思っている。
      • クライアントでもリソースは単一ディレクトリに入る。
  • ※他にも、Androidアプリの同期がクソ遅い問題を抱えている方が結構居るようだ。: 例: Sync issues finally drove me away from the Joplin note-taking app (2022)
    • 上の方は、僕同様にJoplinから他に移ることにしたとのこと。 (その後は不明)
      • ノート数が増えると遅くなるとのことなので、上に書いたように、ノートなどのファイルを全部単一ディレクトリに格納しているのも悪いのではないか(それだけではないと思う)。
    • フォーラムにも何件か問い合わせがあるが、やっぱり暖簾に腕押し状態で、結局、(以前も書いたが、)ユーザのことは どうでも良くて、自分のやりたいことしかしない人たちのようだ。
      • 結局、そういうお遊びが おもしろい人が使えば良くて、僕らのように(Joplinの志向を誤解して)真面目に使おうとする者には全く使いものにならない。時間と手間の無駄だ。
• NextCloud(PIMやファイル共有)の代替探し?
  • ちょっと前にバージョンアップしてから、管理画面のUIが醜くなり、スクロールバーでのスクロールが効かなくなってしまった。
  • フォーラムを見ると、何件か問い合わせがあるにも関わらず、「再現しない」や無視していて、Joplin同様にクソな体制と出来になってしまった。
  • OwnCloud(OCISという新しい版が出た)に戻るか、他(例: Seafile)にするか考えている。

オーディオと格闘していたって、他のトラブルは手加減などしてくれない。

少し前からSpotifyアプリ(以前のLinux版(1.1.42.622.gbd112320)のレイアウトをspicetifyで修正しているもの)のレイアウトがおかしくなり出した。: "Made for you"のタブ(?)で表示されるアイコンが全ウインドウくらいに大きくなってしまった。※

※曲が勝手に追加されるのに業を煮やしてspicetifyを無効にして試してみたが、レイアウトも曲が勝手に追加される(後述)のも直らなかったので、アプリ自体とSpotifyの整合性が悪くなったのだろう。 (2/3 19:56)

spicetifyがそれほど使いやすくなくてレイアウトを直すのが面倒なので(オーディオで忙しいせいもある)、安直な対処が ないか探したら、"Home"なら問題なく、その中にMade for youもあるので、それで使っていた。

が、レイアウト以外にも問題が起こった。設定でAutoplayを解除しているのに、アルバムやプレイリストやミックスが終わったあとに、勝手に選ばれた新しい曲が再生されるのだ。ミックスならいいけど、アルバムで そうされると嫌だ。

それで、仕方なく最新版に移ることにして試したのだが、こっちにも問題はある。Minispという自作のミニプレーヤーとの相性が悪く、曲の再生開始や一時停止イベントが来ない。。。＠ 苦労して それにも対応して使っていたら、どうも音が悪い感じがする。※ 耳の問題が起こるのだ。＊ 他にもいくつか問題があった気がする。

＠ その後、イベントが来ないのは現行Spotifyの問題ではなく、僕のプログラムの問題だったことが分かった。詳細は新しい稿を参照のこと。 (2023/6/4 17:23)

※例によって、少し特性を比べても違いは見られなかった。

特性は、Spotify中のオーディオテスト用のアルバム("Bunker Analog – Stereo Test: Speaker Setup, Calibration Tones, Soundcheck")の中のスイープ信号をREWのRTAに入れて、簡易に振幅特性を測定した。そのために今一つ差が出なかった気がする。ローカルなテスト信号(REWの信号)のファイルを使おうにもMP3しか認識せず、劣化が気になるので止めた。

＊再度試してみたら、やっぱり、旧版から切り替えて すぐに高域が良くない感じ(こもっているような感じ)がし、少し経って耳閉感が起こった。それで旧版に戻したら、ほとんどすぐに治った。何が悪いのかは分からないが、音関係のライブラリ(コーデック?)が違うとか、内部処理が悪いのだろうか? (2/3 19:50)

更に試してみたら、音量正規化をoffにすると問題が起こらない感じなので、アプリ内の音量正規化処理が違うのだろうか? ただ、音量正規化をoffにして使うのは不便だから充分に試してなく、確かではない。 (2/5 0:25)

その後、更に調べたら、やはり、音量正規化をoffにすると問題が起こらないようだ()。が、当然ながら、曲ごとの音量変化があって不便だ。また、on(normal)にして数曲(再生した曲は異なる)の新旧のピークレベルを調べたら、新版は-0.3dBFS, 旧版は-1.0dBFSと、新版は少しクリップしてそうな感じで、それが音が悪く感じることに関係しているのかも知れない。

ただ、平均音量の小さいon(quiet)でも駄目だったので、クリップでなく正規化の処理が違うのかも知れない。

なお、今回も、新版を聞き続けると耳に問題(軽い耳閉感)が起こり、旧版に戻すと治ったので、新版は何かが悪いことは確かだ。 (2/9 19:06)

仕方ないので、元の以前の版を「騙し騙し」使っている。全く面倒だ。どうするかねえ・・・

以前の版の「勝手に曲が追加される問題」は、同じアルバムの曲が続いたら(ミックスやプレイリストでなく)アルバムを再生していると みなして、アルバムが変わったところで停めるようにすることを考えたが、面倒だし やり過ぎの感があるので、保留している。

(2/1 22:27, 2/2 16:46 若干補足)