このブログの公開期限切れの投稿を非表示にするのに、crontabのスクリプトでWordPressの機能を実行しているのだが、 なぜか、今月の頭辺りから以下のようなエラーが出るようになった。

AIOS_Helper::request_remote exception - cURL error 28: Operation timed out after 4001 milliseconds with 0 bytes received

どこから出るのかも原因も分からないので様子を見ていたら、エラーは次のものに変わった。※

AIOS_Helper::request_remote exception - cURL error 28: Failed to connect to api.ipify.org port 80: Connection timed out

※下に参照したフォーラムによれば、問い合わせを受けて修正したためにメッセージが変わったようだ。

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

検索すると、エラーメッセージの"AIOS"というのはWPのプラグイン"All In One WP Security"のことで、それがapi.ipify.orgというサイトにアクセスして(自分(=サーバ)の)IPアドレスを取得しているのだが、その接続に失敗しているようだ。 (参照: WPのフォーラムの同様の問題の問い合わせ: cron job error)

この時は、「(前科者の)"All In One"が またやっちゃったかあ・・・」と溜息をついて居た。ただ、証拠はないものの、エラーが出るようになったのがAIOSの更新後だったかも知れず、であれば「前科者」は正しい。 (← 調べたら、「更新後にエラーが出る」という問い合わせがあるので正しい。)

どうしてIPアドレスを取得するのかというと、webサーバでなく スクリプトからWPを実行する場合、PHPの変数$_SERVER[REMOTE_ADDR]にIPアドレスが設定されていないためだ。

それらの変数は、webサーバが$REMOTE_ADDRなどの環境変数に設定したものをPHPが$_SERVERに格納する。

この辺りはPHPのドキュメントのコメントにあるように、なかなかセキュリティ面が危うい気がするが、今はヨシとする(どうにも しようがない)。。。

どうしてIPアドレスが要るかというと、AIOSがアクセス元を調べるからのようだ。それでブラックリストの判定をしていると想像していたけど、この場合は無意味だ。というのは、サーバからapi.ipify.orgなどにアクセスして分かるのはサーバのIPアドレスで、アクセス元のではないからだ。

きっと、AIOSの更新の時に思い付いて追加したのだろうけど、全く無駄だ。JavaScriptなどでクライアント(ブラウザ)にやらせても詐称されるから無駄だ。環境変数にアクセス元のIPアドレスが設定されていないなら、全部エラーにするかサーバとみなすかのどちらかにすべきなのだ。

百歩譲ってサーバの本当のアドレス(グローバルアドレス)を取るとすれば、外部サイトに依存しない方法にすべきなのだ。

それは環境変数$REMOTE_ADDRで設定されるようなので(この時には上に書いたことは分かっておらず、直感や誤解で そう思った)、試しに、スクリプトを起動する前にlocalhostのアドレス(127.0.0.1)を設定したのだが※、効果は なかった(エラーが出ないこともあったが、出ることもあった)。

実は、上のフォーラムの回答には、アドレスが127.0.0.1の場合にも外部サイト(例: api.ipify.org)でIPアドレスを取得するとあるのだが、最初は読み飛ばしていたために無意味なことをした。

※なぜlocalhostにしたかというと、変わりようがないから安定かつ安全だと思ったためだ。それで却って失敗した・・・

それで、実行する時間帯をずらしたり、実行前にapi.ipify.orgにpingするなどの試行錯誤したあとで(うまく行ったりそうでなかったりした)、$REMOTE_ADDRにサーバの本当のアドレスを設定したら、うまく行っているようだった。

その理由を知るためにプラグインのプログラムを調べたら、上に書いたように、IPアドレスが空または127.0.0.1の場合には外部サイトからアドレスを取得することが分かった。

毎回エラーになる訳でないのも不思議だったが、いくつかのサイトをランダムな順で使っているようなので、api.ipify.orgが使われた時だけエラーになったのではないか。

ただ、そもそもapi.ipify.orgへのアクセスがエラーになった原因は分からないが、たまたまNWやサーバが重かったとかだろうか。

書いたあとで調べたら、他の方でも起こっているようなので、(このサーバでなく、)api.ipify.orgにアクセスが集中して接続できない場合があるのではないか。だとすれば、正しい修正は、IPアドレス取得に使うサーバを選択できるようにすることだ。

だから、

(解決方法) 環境変数$REMOTE_ADDRにサーバの本当のアドレス(例: hostname -ihostname -ihost -t A ホスト名 で取れる※)を設定すれば、エラーは起こらなくなることが分かった。

※今試して分かったが、hostname -iだと/etc/hostsの設定によっては127.0.0.1が返って来るので、host -t A ホスト名 などがいいかも知れない。

実際には以下のようにしている(the-WP-progがWPの処理を実行するスクリプト)。

export REMOTE_ADDR="`hostname -i`"; the-WP-prog

が、上述のようにhostname -iは今一つなので、(なんか冗長だけど)以下が良さそうだ(未確認)。

export REMOTE_ADDR="`host -t A \`hostname\`| cut -d " " -f 4`"; the-WP-prog

 

とりあえずエラーは出なくなったが、そもそも、スクリプトからWPを実行する場合はAIOSを無効にするほうが良さそうな気はする。が、それは結構大変(wp-load.phpなどの改造が必要で、逆に問題が起こる可能性が大きい)なので、これで良しとした。

まあ、問題は(サーバでない)スクリプトからWPを呼び出す場合だけで起こり、通常の使い方では起こらない。そのために手間を掛け・リスクを増やすこともないだろう。

 

PS. 本文で参照したフォーラムのやり取りを見ると、例によって「埒が明かない」感がある。: 質問の題"cron job error"が示すとおり、(webサーバからでない)スクリプトでIPアドレスが設定されないのが問題なのに、回答者が問題の原因を把握できず、適切な回答も修正もしていないので(2番目以降の質問者は)解決できていない。

当然ながら、$REMOTE_ADDRに本当のIPアドレスを設定してスクリプトを実行すれば良いことも書いてない。

不思議なのは、最初の質問者が「解決済み」にしているらしいことで、(しょうもない回答に呆れて)自力で解決できたのだろうか。あるいは 本当に解決していて、僕が曲解しているだけ??

本文に書いた内容や そういったことを投稿しようかと思ったが、ユーザー登録が必要なのと、この感じでは無駄になりそう(無視されそう)なので していない。

PS2. これを書き、そのあとで調べたりしたら、AIOSのアラが出て来て なんか信用ならない感じになって来た。が、以前調べたところでは これが一番良かったので、当面は頼るしかない。が、セキュリティのプラグインが そんなことでいいのか??

  •  1
  •  0
Keys: , ,

名前すら分からない人だ。

Care (1898) by Talbot Hughes, from Artvee

この目、顔が たまらない。何度見ても飽きない。一体どういう人で、どういう状況(背景)だったのだろうか? あと、どうして こんなコスプレみたいな格好をしているのか(いくら昔でも、これが普通の格好とは思えない)も知りたい。

有名な絵画なら「モナリザ」が 近い立ち位置の気がするが、僕は こっちのほうがずっといい。

書いたあとで思ったが、こういう絵はブロマイド(詳しくないが、今のトレカ?)に相当するものだったのかも知れない。当然 お金持ち用で、オーダーで描いたのではないか。そして、これは そういう客の中でも魔法使いとかコスプレのようなものが趣味の、奇人※の要望で描いたのかも知れない。もしそうであれば、昔も今みたいな趣味は あったようだ。と、想像は膨らむ。

※その人の屋敷の壁には こういうのが ずらっと並んで居て、客に自慢して(呆れられて)いた??

(4/17 15:42: 気になっていて書き忘れたこと) この人の顔が少し赤いのも謎だ。: 明らかに顔だけ赤く塗っているので、間違ってや下手でではなく、意図的にそうしたのは確かだ。これは当時の一般的な化粧なのか、このコスプレの形態なのか、(何かの理由で)顔を赤らめているのか(その状態を描いたのか)、それ以外か。是非知りたいなあ・・・

これはタルボット・ヒューズの"Care"で、120年くらい前の作品だが、それほど有名ではないらしく、調べても詳細や背景が分からなかった(だから日本語の題もないようだ)。もちろん、モデルの名前も分からない。

(ツイートしたのか、以前ここに書いたのか定かでないが、)これについて学芸員などの専門家に教えてもらいたくて、近くの美術館を調べたが、そういうサービスはなかった。都内の国立美術館も同様だったので、がっかりした。あと、国内の美術館の所蔵品を通して検索できるデータベースのようなもの※がないのにもがっかりした(国立美術館だけとか、限定的なものはある)。

※この作者の作品を置いているところなら、何か分かるかもと思った。

それで、ものは試しにAI(ChatGPTなど)に聞いてみた(例: 概要, 絵のリンクを示して「どういう絵?」, どこで見られるか)が、(当然なのだろうが、)インターネット(この場合はWikipediaがほとんどでは?)に公開されている情報しかベースにしていないようで、「分からない」とか、(良く書かれているように)間違った情報(この場合、同名の別人や全く別の作品)を平気で回答して来た。

「どこで見られるか」は、美術館を想定していたのに(確か、英語で"Where-"と聞いたので、物理的な場所の意図は伝わったはず)、画像のページのURLを示された。まあ間違っては いないが、結構がっかりした。

しかも、URLが おかしくて見られなかった。が、「見られない」と言ったら、修正を繰り返して最後には見られたのは ちょっとすごい(でも、その画像が正しかったかは不明(怪しい))。普通の人間のサポートだと、マニュアルどおりの回答しかできずに無理ではないか?w

だから、AIは便利だけど、知らないことを考えて導き出せるものでもなさそう(導き出したとしても、区別や確からしさを示さないので困る)だから、現状では過度に期待できないように感じた。

これを見付けたのは、あるツイート(↓)でだった。

ツイート: @Estetism_jp (2023/3/20)

その後、上の絵と同年代の1900年前後の服などにも気になるものが出て来た。

リンク: @wikivictorian

ただし、なぜか、肩や腕が膨らんでないことが条件で、上の2, 3番目は好みでない(2番目は全体的には いいが、肩から腕が惜しい)。つまり、タイトな服がいいっていうフェチ的なことなのだろうか?? ただ、スカートは膨らんで居ても問題ないのが謎だ。

そういえば、それに関係あるかは分からないが、アール・ヌーヴォー(この時代だった らしい)は綺麗だと思うけど余り好きじゃない。ミュシャ(近頃ツイートされることが多い)も同様に好きではない。

更に、以前にも見たことのある、ミレー(「ミレイ」と書くことが多いようだが、「ミレー」もある。ミレーは英仏に居たが英のほう)のオフィーリアも(少しコミカルなのに可哀想なところが)いい。あと、ミレーにはドレスの布の描写が すごい絵(The Black Brunswicker, 1860)もある。

Ophelia (1851-1852) by Sir John Everett Millais, from Wikipedia

調べると、この頃はヴィクトリア朝(1837-1901)とのことだ。偶然だろうが、大好きな映画BTTFの舞台となった年代(1985, 1955, 2015, 1885)にも入っている。

ただし、BTTFはUSだし、1885年の"3"は好きではない。

 

そもそもの切っ掛けになったのは、下の静物画だ。ヴィクトリア朝より更に前の17世紀の、ホーホストラーテンという人の作品である。

ツイート: @bijutsufan (2023/2/17)

何の変哲もない感じだけど(ただ、何を意味しているのかは分からない)、なぜか気に入った。色遣いや物や配置が いいのだろうか? 全然古さを感じなかったので、17世紀と知って驚いた。僕にしてみれば、20世紀と言われても おかしくない。

その他にもツイートされる絵などを見ていると、どうやら15-17世紀辺りも好みであることが分かった。が、昔過ぎて全くイメージが湧かない。その頃の絵を見ると、本当にそういう時代があったのかと不思議に思うくらいだ。

時代の呼び方を調べたら、14-15世紀は中世、14-16世紀はルネサンスとのことだが、17世紀には そういう呼び名はないようだ。

絵画ではないが、昔から好きだったシェークスピアは16-17世紀(1564-1616)で上の絵の頃に近く、どういう訳か その辺りは好きな(馴染みがある?)ようだ。

 

そして、中世の絵は素朴な感じがいい。: 例えば、下の左の猫と人の絵(本の挿絵?, 14世紀)は まるで鳥獣戯画のようだ。※

※調べると、鳥獣戯画(12-13世紀)のほうが先だったようだ。

リンク: @CathyRLowe, @WeirdMedieval

それから、上の右のドラゴンと蛇の絵(おそらく部分, 15世紀)は、個人的には、ドラゴン(鳥山明の漫画に出て来そう)は余り怖くないけど蛇が怖いという逆転現象がおかしい。実際に見たことのないものの怖さは想像できないからだろうか。

 

という具合に、中高生の頃は歴史は覚えるばかり(しかも、時代も場所も あっち行ったりこっち行ったりで脈絡がない)で詰まらなくて全く興味がなかったが、こうやって興味のあるものが見付かると俄然やる気が出るからおもしろい。

以前も音楽など芸術について書いたが、学校の授業も こういう風に進めると いい気がするものの、芸術と違って「勉強」の教科だと そうは いかない気はする。が、そもそも、歴史などを きっちり覚えることに意味があるかというと どうだろうなという気もする。まあ、文系に進む人には意味があるか。でも、細かいことを覚えることには意味がないと思う。

 

(4/19 13:01, 15:35) 今朝、すごく いい絵が見付かった。上にもある@wikivictorianがツイートしたもので、マーカス・ストーンの"An Interrupted Duel" (1868)である。シリアスで息を呑む瞬間の雰囲気が どっと伝わって来る。特に、お嬢さんの表情や仕草がすごい。描かれた人たちが今にも動きそうだし、声だって聞こえて来そうだ。何度も見入った。

An Interrupted Duel by Marcus Stone (1868), from Wikipedia

少し調べたものの日本語の題は見付からなかったし、この絵を載せているサイトも多くなかったので、最初のCure同様、それほど有名ではないのだろうけど、そこが不思議だ。まあ、世の中の評価と個人の評価は合わないのだろう。

あと、これは同時代を描いているのか、当時の「昔」を描いているのかは分からない(調べれば分かるだろう)。ツイート元の志向や服装からするとヴィクトリア朝で同時代に思えるが、まだ決闘が行われていたのだろうか。※ 不思議な感じだ。

※そう言えば、同じ頃の設定のBTTF3には西部劇的な決闘のシーンがあるので、やっぱりあったのだろう。それにしても、この場面と西部劇では随分違う(けど、根底は一緒の気がする)のも おもしろい。

 

注: 引用したツイートへのリンクを調べるのは大変なので、ツイート者のリンクにした。また、画像の参照が主意なので、ツイートのキャプチャ画像に含まれているキャプションは転載していない。

  •  1
  •  0
Keys: , , , , , , ,

全く「終わった詐欺」で、気付いたら前回から2か月も経って居た。が、今度は本当で、散らばっていた道具や電子部品を片付けて すっきりした。

前回書いた残件の、自作アンプBA3886やサウンドカード(ASUS Essence STX II)のDAC部の仕上げ作業をしていたら、例によって ちょっと気に入らないことや いくつかの謎・問題が出たので、追加作業をしたり手こずったりした。

前回以降の追加作業・苦労・謎

  • アンプ本体
    • 前回から回路の変更はなく、確定したのだが、特性をチェックしたら以下の謎・問題が出た。
      • 50Hzの雑音(特に右が大きい):
        • アンプ単体では出ないので、ボリュームやカップリング回路に関係しているようだが、解決できず。 (参照: グラフ: ベージュ: アンプ単体時の右, オレンジ: ボリュームとカップリング回路を接続時の右: 50Hz辺りに山がある)
          • ボリュームなどで雑音が入りやすいのは分かるが、右だけに出ることがあるのが不思議だ。
          • ベース(放熱板兼固定台)をGNDに接続したら雑音が減るかも知れないと試したが、予想通り、効果はなかった。 (→ 写真: 左下のネジと黒いコード)
            • 単純にGNDに繋げた金属板があるだけで雑音が防げる訳ではなく、少なくとも周囲を囲う必要はあるだろうし、そうしても、アンテナになって雑音を拾ったり、変動するGNDが雑音を撒き散らすことがあるとのことだ。
        • 気に入らないものの、かなりレベルが小さく聞こえないので、保留にしている。
      • クロストークが大きい(作った時より悪化した)。: 対処できた。
        • 入力のコードと出力部(コイル, コンデンサ)が近かったこと。+残る謎の原因?
          • → コードを基板に密着させていたのを、なるべく基板から離すようにしたら、悪化は解消し、作った時より少し良くなった。
            • 更に検討したところ、推測ではあるが、基板でなくコンデンサに近いのが悪かったようだ。 (詳細は後述)
            • コイルについては、作った時も同じコードの通し方だったので違うだろう。
      • なぜか歪みが大きいことがある。: 対処できた。
        • 入出力のコードの通し方が悪かった。: なぜか、電源フィルタ付近(特にアンプの下)を通すのが駄目なようだ。
          • 作業が終わってコードを綺麗にしようとしてアンプの下に挟むと なぜか歪みが増大して、上のクロストークの改善作業で随分遠回りした。
          • → コードをアンプから少し離すようにした
      • 超高域での左右の歪みの差・左の歪みの増大 (参照: グラフ: 超高域での青系(左)と赤系(右)の差):
        • 電源の弱さ・経路の非対称性、基板の非対称性、LM3886(アンプIC)の個体差によるのではないか。
        • 出力に応じて歪みが増大し続ける訳ではなく、実用上の問題はないので保留とした。
      • 両チャネルで大出力時の高域での歪みの増大 (参照: グラフ: 実線: 片チャネル, 点線: 両チャネル):
        • 電源の弱さかも知れないが、高域なので違う気がする。
          • 上の問題(左右の歪みの差)の対処の試行でも分かったが、電源ではないのかも知れない。
        • 増大した状態でもひどい値ではなく、LM3886のデータシートの値に近いため、大きな問題ではないと考えている。
      • 左右のカットオフ周波数(高域)の差: なぜか右が30kHzくらい低くなった。: 対処できた。
        • 右の測定用出力を取リ出す位置を間違えていた。。。 → 修正したら直った。
          • 本来の出力の手前にあるZobelフィルタの抵抗とコンデンサの間から取っていた。 (参照: 回路図: 右端の"Out A/B"から取るべきところを、その少し左の"AltZobel"の右辺りから取っていた。)
          • 超高域(約30kHz以上)ではZobelフィルタが効き出して流れる電流が増え、そのために信号を取り出している点の電圧が下がるために、カットオフ周波数が下がったように見えたと考えている。
    • その他の作業
      • 交換後のコンデンサが結構大きく、また、並列接続などで数が多くて取り付け強度に不安があったので、ハリ玉と ひっつき虫の混合物(またはブルタック)で止めて補強した。 (→ 写真: 白いもの)
        • それらは熱で柔らかくなるが、作った時に温度センサをLM3886に固定するのに付けたブルタックが問題なさそうなので、大丈夫そうだ。
          • ただ、夏に状態を確認する予定だ。
        • また、余り期待しては居ないが、フィルムコンデンサが振動するのが良くないようなので、多少は防振できそうだ。
      • 同様に、クロストークの改善(上記)のために入力のコードを浮かせたため、基板に半田付けしている部分が力に弱いので、ハリ玉などを付けて動きを制限して補強した。 (→ 写真: 白いもの)
      • LM3886をベース(放熱板兼固定台)に固定する押え板をDVDケースを切ったもので作り直した
        • それまではPCケースのベイのトレイのレールを加工したものを使っていたが、厚くて基板の配置が不便なので作り直すことにした。
        • LM3886はネジ止めする部分が薄いので、そこにも板を密着させて押さえる力を高めるため、2枚重ねた。
        • 思い付きで始めたため、実寸を全く測らず、データシートのサイズと大体の想像で作ってしまったが、結束バンドを通す切り欠き部を調整したのと上記の重ねた部分以外は問題なかった。
        • DVDのケースの素材(PP)の耐熱性が気になったが、調べたら大丈夫そうだった。
      • 最終的な特性の測定時に、なるべく「綺麗」な特性を手軽に測りたかったので、アンプ基板に測定用出力コネクタを追加した。 (→ 写真: 下部に出ているコードとコネクタ)
        • その接続先(右チャネル)が誤っていて、上記の左右のカットオフ周波数(高域)の差の問題が起こった。。。
        • コネクタに測定用ピンコードを付けることで、簡単に測定できるようになった。
      • 同様に、最終的な特性の測定時に、なるべく「綺麗」な残留雑音を手軽に測りたかったので、アンプの入力をショートするピンプラグを作った。 (→ 写真: 上・中)
        • 同様に、ASUSのADCの入力をショートするミニプラグも作った。 (→ 写真: 下)
        • どちらも、手持ちの「使えない」部品でテキトーに作った。
    • 改良後の回路図 (入力部(下記のカップリング回路とボリューム)を含む)

改良後のBA3886の回路図 (入力部を含む)

  • カップリング回路 (ASUSとアンプを接続する部分)
    • カットオフ周波数が少し低いためか、わずかに耳に問題が起こりやすい感じだったので、少し高くした。
      • カットオフ周波数(後段の抵抗が90kΩの場合の理論値): 約4Hz → 約5.4Hz
      • アンプと組み合わせた場合(実測値): 約7.0Hz → 約9.4Hz
      • コンデンサの容量: 0.44μF → 0.33μF
        • 0.22μFと0.22μFx2個直列を並列接続した。
          • 合成容量= 0.22 + 1/(1/0.22 + 1/0.22)= 0.33
      • 高くなったとは言え わずかな差(約2.4Hz)なので、実は耳の調子の問題だったのかも知れず、本当に効果があったのかは分からない。
    • 正式版を作ったあとに、アンプ同様にクロストークが大きい落とし穴が見付かった。
      • ケースに入れたため、左右チャネルのコンデンサが平行に密着して干渉するようなので、約90°に配置し、GNDに繋いだ網線(VGAケーブルのもの)を間に入れて隔離(シールド)したら改善できて、最終版となった。
      • ※変遷を おまけに載せた。
    • なお、本アダプタのコンデンサをASUSのカップリングコンデンサにする(置き換える)ことも考えたが、ASUSもアンプも接続先や構成が変わる可能性があり、その時にはコンデンサの容量を調整する必要がある可能性があるため、それが容易な外付けにした。
  • ASUS (サウンドカード, DAC)
    • 新たな問題はなく、正式なDC出力化とそれに伴う電源off時のポップ音の防止のための改造をした。
    • 改造の目的・期待する効果・概要
      • 出力のカップリングコンデンサ(220uF, 電解)の音質への影響の排除
        • コンデンサの排除 → 出力のDC化
      • LPF出力から出力端子までの間の部品の音質への影響の排除
        • 出力抵抗(100Ω), コンデンサ(容量不明), その他(抵抗?)の排除
      • リレーの接点(3個/チャネル)の音質への影響の排除
        • 出力切り換え用, ミュート用の接点の直結化
      • 出力のDC化に伴う電源on/off時のポップ音の防止
        • 改造後もミュート機能が働くようにした。
    • 改造前後の回路図

ASUSのDAC出力の改造内容の回路図(関連部分のみ, オリジナルは推定): 上: 改造前(オリジナル), 下: 改造後

    • 改造箇所の写真

作った時(2021/6)・前回(2023/2)からの変化

特性は作った時と ほとんど変わりない(悪化したものはある)が、音は確かに良くなっている(主観的印象)。それに加え、以前から書いている、耳の問題(耳閉感)が起こりにくくなった。

  • 特性の違い
    • 良くなったもの: 歪み率(特に大出力時の超低域(参照: 改良前: 30Hz以下で増大 → 改良後))とクロストーク(少しだけ)(参照: 改良前改良後)
      • 比較
        • 歪み率 (20Hz, 約8W, 片チャネル出力): 約1/7になった。
        • クロストーク (L→RとR→Lの平均): 1-2dB程度減った。
      • 歪み率はDCサーボ(の作りの悪さ)による。クロストークは上述の入力のコードの引き回しが大きかったようだ。
    • 悪くなったもの: 振幅(低域の下限が少し高くなった)と位相(低域(100Hz以下)のズレが大きくなった)
      • 比較
        • 振幅特性: 下限が約6倍になった。
          • 作った時 (入力: DC): 3Hz-20kHz※: +0, -1.1dB
            • ※サンプリング周波数44.1kHzで測定したため、上限が正しく測れなかった。
          • 改良後 (カップリング回路接続時(入力: AC)): 17Hz-42kHz +0, -1dB
        • 位相 (30Hz): ズレが約8倍になった。
      • 悪化したのはDCサーボを止めてコンデンサ(カップリング, フィードバック)にしたためで、予期したもので異常・問題ではない。
      • なお、グラフでカップリング回路+ボリューム(水色, ピンク)の高域の特性が悪いのは、ボリューム※に起因する。ボリュームの寄生容量が関係しているのかと推測している。
        • ※カップリング回路単体の特性を測りたかったが、後続に約90k-100kΩの抵抗がないとカットオフ周波数(低域)が変わってしまうので使った。
  • 音が良くなったと感じる原因: 定かでない。
    • ASUSの出力のカップリングコンデンサ(電解コンデンサ)とアンプのDCサーボを撤去したのが一番大きく、次は上記のクロストークの改善※だと推測している。
      • ※クロストーク悪化の原因の、コードを基板に密着させて固定したのが いつからかは、調べないと定かでないが、その時に音が悪くなったが気付かず、今回直して良くなったと推測する。
        • ↑過去の写真を調べたら、作った時(2021年)には既にコードが基板に近い状態だった※ことが分かった。
          • ※当時はアンプ基板の隣にサーボ基板があったため、スペースが狭くてコードを浮かせられなかった。
        • だから、作った時からクロストークは悪かったようだ。確かに、作った時に書いた資料での結果は悪かったが、2022年の更新版の資料での結果(上を参照)は それほど悪くない。 → まだ他に謎があるのかも知れない。
          • 更新版でクロストークが良くなった経緯を調べたら、実は最初から悪くなかった。
            • 今回、特性を比較する時に参照した資料(PDF版)が古かったため、良くないクロストークが載っていて最初は悪かったと思って居たが、(このブログにも載せているように、)正式版の資料(Zim)では正しいクロストークになっている。
          • 結局、クロストークは元々悪くなかったのに、今回の改良時に一時悪化したようで、それが謎である。
            • フィードバックコンデンサ(左チャネル)や高域ゲイン抑制用コンデンサ(右チャネル)の直近に入力のコードを通したのが、良くなかったのかも知れない。 (→ 参照: 入力のコード(黒)がフィードバックコンデンサ(茶)や高域ゲイン抑制用コンデンサ(赤)に接して通っている。)
    • また、(以前の稿に書いたように、)カップリング, フィードバック, 超高域のゲイン抑制回路に使うコンデンサの品種を、可能な限り聴感が良いものに選別・交換したのも効いたと思う。
      • Zobelフィルタでも選別したものに交換したが、効いているかは不明。
  • 耳の問題が起こりにくくなった原因: 超低域(概ね10(-30)Hz以下の帯域と推測している)の変動(ゆらぎ)が減ったためと推測している。
    • 超低域が「出過ぎる」 ASUSの出力のカップリングコンデンサやDCサーボを撤去し、カップリング回路やフィードバック回路を調整することで超低域を抑制した。

実際に聞いてもらって説明しないと音の違い(客観的には「良くなった」とは言えない)を示すのは難しいが*、なるべく有名で幅広い手段で聴けそうな演奏で、以前との違いが顕著※と感じた例を示す。全般的には、高い小さい音や余韻の響きに違いが出やすい印象だ。

*しかも、改良前の音は出せないから説得力がない。

※「顕著」とは言っても かなり些細な違いでしかないので、全く差が分からない可能性はある。 (「分かるかなぁ、分かんねえだろうなぁ」の域?w)

なお、YouTubeでは聞こえ方が違って分からないものばかりなので、Spotifyか他のサービスかCDなどを参照されたい。

  • A Walk In Taormina (Eric Serra, 1988): 低音のパーカッションやオルガンの響きが それまでと全然違って聞こえる。
    • 一番違いが大きく感じるものだが、この表現では客観的には違いが分からない・・・
  • 夢先案内人 (山口百恵, 1977): 右でほぼ通して鳴って居る、すごく小さいシンバルとかハイハットみたいな「シャッ」という音が聞こえた。 (4/13 11:16)
  • Day Tripper - Remastered 2015 (The Beatles, 1965): イントロのギター(左側)の、弦が少し かすれるような音(ピックで弦が擦れる音?)が聞こえるようになった。
  • Drive My Car - Remastered 2009 (The Beatles, 1965): 上と同様に、イントロの小さいギター(左側)の かすれるような音が聞こえるようになった。
    • これもYouTube版では聞こえ方が違う。
  • 風立ちぬ(SEIKO STORY〜80's HITS COLLECTION〜) (松田聖子, 1981): 時々左で小さく「シャンシャン」と連打されるパーカッションが はっきり聞こえるようになった。
  • Urgent (Foreigner, 1981): 時々(例: 42秒から)左で鳴る、変わった音(パイプを叩いてるような音)のパーカッションが聞こえるようになった。
    • YouTube版では聞こえ方が違い、上の音は はっきり聞こえる。なお、公式版は音が悪くて駄目。

まとめ

いろいろ謎は あるものの、とりあえず片付いた。改良の効果なのか、耳の問題の緩和のためにPCからの出力に入れているHPFのカットオフ周波数を少し低く(80Hz → 65Hz)して、超低域を増やしても※大丈夫なようだ(確認中 → OKだった。ただ、実際には超低域は減っていた。詳細は下を参照)。

※実際には、そうしても低音が増すと感じることは なく(部屋の特性のため、低域に出にくい帯域がある)、気分の問題である。チキンレース的な「どこまで行けるか!?」のようなものだw

これで前回書いた残件の2/3が終わり、最後に残った、(そもそも やっていた、)(再生)音による耳の問題の原因調査の続きが ようやく(?)再開できる(けど面倒だ・・・)。

 

その後

(4/18 15:45) HPFのカットオフ周波数を以前より少し低くした65Hzで しばらく聴いてみて大丈夫だったので、スピーカーでの特性を測ってみたら、予想以上に「いい感じ」だった。

というのは、なぜか、前回に比べて低域(60Hz以下)が少し(30-50Hzで約2dB)下がったのだ。※ (→ グラフ: 灰: 前回, 緑: 今回) しかも、カットオフ周波数を少し上下させると30Hz辺り*が前回と同じくらいに大きくなるので、期せずして この部屋の特性に最適になったようだ。

※理論的には、HPFのカットオフ周波数を下げると低域が大きくなるはずだが、部屋の特性やフィルタ間・スピーカー間の相互作用(位相?)が関係しているのだろうか。

*この辺り以下の超低音が耳に問題を起こすと考えて、下げようとしている。

偶然だとは思うが、聴感(耳の問題の起こりにくさ)も考慮して65Hzにしたのが合っていた。また、まとめに書いたように、これで低音が増すと感じなかったのは実際にそうだったので、それなりに耳が正しいのかも知れない。

スピーカー(+部屋)の音の特性を測定した。: 灰, 青, 赤: 前回(2022/12/15, カットオフ周波数: 80Hz); 緑, 薄青, ピンク: 今回(同65Hz) (それぞれの線はL+R, L, Rの順)

 

(4/24 9:04) 昨日、HPFのカットオフ周波数でも「チキンレース」をしたw 別件(再開した耳の問題の原因調査)の途中で、ちょっと思い付いた。カットオフを下げると低域が増すかも知れない(→ 比較グラフ)以外に、補正フィルタによる低域の位相の変化(→ 位相のグラフの最高と最低の差)を減らすことができることが分かったからだ。位相の変化を減らすと音が良くなる根拠はないが、そういう気がするではないか。

カットオフ周波数を20-80Hzで変えて50Hz以上での位相の変化量を比較したところ、60Hz辺りで最小になるようで、この点でも、元々の設定の(、耳で決めた)65Hzは正しかったようだ。

が、「少しくらい下げて(低域を増して)も大丈夫なんじゃね?」という悪魔の囁きが聞こえて、カットオフを50, 55, 57.5Hzで聴いて試した。: 確かに低域が増して聞こえたが、50Hzにした場合はブーミーに聞こえることがあった。だから、部屋の特性(共鳴)で、超低域を多く出すと増強されてしまうのかも知れない。

更に、超低域が増強されるためか、いずれでも耳が駄目だった(例: 軽い唾飲み時の違和感、少し耳が聞こえにくくなった)ので却下して、元の65Hzに戻した。

なかなか敏感・過敏だ。でも、耳に再現性があることが確認できた。そして、今回も思い付きは失敗した。。。

 

付録: 代替カップリング回路(AltCC)評価用アダプタについて

この作業の初期に、ASUSのカップリング回路の代わりを試行錯誤する(主にコンデンサを取り替えて試す)ために、2種類のアダプタを作った。1つは普通の大きいコンデンサ用(#1)、もう1つはチップコンデンサ用(#2)である。以下に簡単に説明する。

#1: このアンプを作る時に買ったものの使わなかったスピーカー保護回路の基板と部品(ターミナル)を流用した。: カップリング回路を構成するコンデンサや抵抗をコード用のターミナルにネジ止めするようにした。

なお、基板のパターンや穴の都合でコンデンサ用のターミナルを付けられる場所に制約があり、入出力の左右が逆になった。

#2: チップコンデンサは小さい(1-2mm角)ため容易に取り替えられない※ので、試すコンデンサを基板に半田付けし*、それぞれに入力を繋ぐためのピン(ポスト)を立てておき、入力用コードに付けたジャックを試したいコンデンサに対応するピンに挿すことでコンデンサを選択できるようにした。 (→ 写真: 上側)

※チップにリード線を半田付けして脚を付けることで、普通のコンデンサ同様に交換することも考えたが、脚からチップに力が掛かって破損する可能性があったので止めた。

*1種類(PMLCAP)は あとから付けたのだが、なぜか間違って裏面に付けてしまった。 (→ 写真: 左寄り上下の4つの紫・銀色の四角)

それぞれのコンデンサは2個ずつ実装されているので、入力用コードを2本のピンに繋ぐことで2倍の容量で試すことができる。また、少し工夫して2個のコンデンサを直列接続にすれば、1/2の容量で試すことができる。

なお、基板に半田付けした場合、いずれかのコンデンサを正式に使う時に再利用できない※が、基板ごと使うつもりで居た。

※半田付けしたものを基板から剥がすと熱で破損する可能性が高いので、無理だ。

以下に写真や回路図を示す。

使ってみて分かったのは、これらは確かに便利でミノムシクリップなどよりはずっと安定だが、(半田付けに比べると)ターミナルやポスト・ジャックの接触が今一つなせいか、雑音が入りやすかった。また、#1は何度もコンデンサをターミナルに(キツく)付け外しして力が掛かったせいか、最後には右チャネルが断線してしまった。

だから、本来は毎回コンデンサを半田付けして試すのが一番良いが、何度も繰り返すとコンデンサも基板も駄目になってしまうから、難しいところだ。

他に、良くあることだが、入出力のコードも切れやすかった。コードが動きにくいようにベースに固定して居たが、それでも半田付けした部分が折れてしまう。試行用なので そこら辺にあったテキトーなコードを使ったのだが、硬かったのが良くなかった。硬いコードは大嫌いだ。

 

おまけ

作業で思ったこと

  • 今まで ない方が・なくても良いと思って居た、パワーアンプの前のプリアンプとかバッファアンプの必要性が分かった気がする。
    • パワーアンプの入力にボリュームやカップリングコンデンサ(CC)がある場合、音源(DACなど)の出力の構成(例: カップリングコンデンサ)によっては周波数特性(特に低域)が変わることがあるため。
    • → バッファ(プリ)アンプのあとにボリュームやCCを付ければ影響がなくなりそう。
      • ただ、バッファの入力を どうするかが問題かも。: DC? 入力抵抗は なしじゃないと無意味?

 

今回の改良関係の費用

  • 約8500円 (通販4回)
    • 送料抜き: 約7200円
      • 実際に使った分: 約2000円※
      • ※コンデンサを「取っ替え引っ替え」、買っても使わなかったりしたため、効率は30%未満と悪い。

 

正式版カップリング回路アダプタの変遷

本文に書いたように、一旦出来てからクロストークの問題が発覚したため、配置などを試行錯誤した。その過程の写真を載せる。

いつものように、作業中と終了後の作業机の比較

ボツ(未使用)写真集

 

(4/11 6:10 ASUSの改造内容の回路図のPCM1792Aの出力-I/Vを修正, 少し修正・加筆; 7:58 おまけのレイアウトを修正, 若干加筆; 11:40 アンプ(入力部を含む)の回路図を追加, 回路図をPNG形式に変更, その他の作業などを追加・加筆, 写真を追加, レイアウトを改良; 12:25 少し補足; 13:44 ボツ写真を追加; 15:12 入力のコードの通し方やクロストークの変化の経緯を調べた結果、その他を追記; 4/12 8:20 ボツ写真を追加, 作った時との特性の比較を追加; 4/12 12:26 代替カップリング回路(AltCC)評価用アダプタについてを追加, 13:24 正式版カップリング回路アダプタの変遷を追加。とりあえず、この稿も完成。; 4/12 18:12-21:07 少し加筆・修正他; 4/13 11:16 聞こえ方が違う例に「夢先案内人」を追加; 4/15 13:24 ボツ写真を追加; 4/18 15:45 スピーカーの特性の測定結果を追加)

  •  0
  •  2
Keys: , , , , , , , , , , , , , ,

先日、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未満)ことも確認した。

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

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

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ビットで配信をすれば まるっと解決しそうだ。

  •  0
  •  0
Keys:

数日前に、ツイッターが切っ掛けで※題に書いた演奏があるのを知った。アムラン(Marc-André Hamelin)は以前にもアンスネスとの「春の祭典」(2台ピアノ版)を買ったりして、結構気になって居る人だ。

彼は有名人には珍しくフレンドリーというのか、彼に楽譜の一部をツイートすると、どんな難曲でも(?)(即座に?)それが何かを当てるという「掛かって来い!」的なことをやっていて、その点でも いい感じだ。

※元は何だったか思い出せない。調べれば分かるが、本題ではなく面倒なので、今は止める。本人のツイートの関連だったか。そう言えば、ラフマニノフの命日(3/28)に関連して、誰かがこの演奏を褒めていた気がする。

ただ、ポリシーなのだろう、Spotifyなどには ほとんど配信されていないので、作品(演奏)があることを知ったり試す機会が ほとんどない。特に、過去の作品はレコード販売店の広告にも出ることが少ないで、気付かない。ポリシーは人それぞれなので仕方ないが、作品に触れる機会が減るのは どうなんだろうと思う。

でも、以前見た、自分で配信を許可した癖に「金にならない」とか文句を言ってた奴(日本人)に比べれば、全く真っ当だ。

この演奏に関しては、試聴した感じが なかなか良さそうだった。上述のとおり配信されていないので、昨日、ものすごく久し振りに(約5年振り)に買った(Hyperionでダウンロード購入)。

なお、本来のアルバムとしては もう一曲(Medtnerのピアノ協奏曲第2番)あり、試聴の断片では まあまあだったのだが、Tozerの演奏(2005)を聴いてみたら、プロコフィエフ的、あるいはラフマニノフの好きでないピアノ協奏曲的な「変さ」があって苦手な感じだったので買わなかった。そういうのは大昔は好きだったが・・・

ただ、途中で止めるほどでないのが微妙だった。それでも、買っても一回だけしか聴かないと思う。

聴いてみると、試聴の時と同様にテンポの遅さが目立つ。そのため、好きなルガンスキーの(2003)とは随分違うが、落ち着いた感じでいい。僕は遅過ぎる演奏は嫌なのだが、そこまで遅くないのが絶妙な感じだ。しかも、近頃好きになっているアンスネスの多くの演奏(この曲では2010)とは違って、僕の好みとの違いは感じるものの違和感はない。そこでも「絶妙」だ。

アンスネスについては、モーツァルトのピアノ協奏曲(2021, 2022)について書きたいと思って居たけど手を付けていない。概略は、全般的に、彼の演奏は最初はすごく違和感があって拒否反応が出るが、我慢して(?)何度か聴くと馴染めることが多いのが全く不思議だということだ。ただ、出てすぐ評論家などに絶賛されているので、客観的には何も問題はなく、僕の好みとの相性なのだと思う。

ルガンスキーは いいのだが、アムランに比べると直線的とか直情径行的というのか、(それはそれで気持ち良くて好きなのだが、)深みが足りないように思えてしまう。だから、これからアムランを繰り返し聴くうちに、僕の中でルガンスキーを超えるかも知れない。

直情径行的と言えば、断片(今のコンサートまたはツアーのリハ)しか聴いていない、かつ曲が違うが、ワン(Yuja Wang)のラフマニノフのピアノ協奏曲 第2番は パワフルかつスピード感があって、是非聴きたいと思った。それとアムランは対極的・正反対な気がする。でも、どちらも好きだ。

 

(以下は技術的、あるいは、僕の耳に関係する話)

買う時に、フォーマットがいくつかあって迷った。もちろんMP3でなくFLACなのは決まりだが、CD品質(44.1kHz, 16bit)と「ハイレゾ」(96kHz, 24bit)で迷った。最初は、持論のとおりCD品質で充分だと思って決めていたのだが、注文する直前に迷いが出て「試しに・折角なので」ハイレゾ版にしてみた。値段はGBP 9.15(約1500円)で、CD品質より約500円高かった。

96kHzは再生時にサンプリングレート変換が必要になるため※、耳の問題が起こらないか心配があったのだが、買ったものを聴いたら当たってしまった。どういう訳か、第3楽章だけで問題(唾飲み時の違和感)が起こった。近頃は起こって居なかったので、いつもの耳の調子やオーディオの問題では なさそうだった。

※再生ソフトもサウンドカードも96kHzに対応しているが、JACKの設定が44.1kHzなので、そこに入れる時に変換が要る。

そこで、試しにsoxコマンドでサンプリングレートを44.1kHzに変換したものを再生したら、大丈夫そうだった。それから、再生時に(再生ソフト(gmusicbrowser)でなく)PulseAudioでサンプリングレート変換して試したら、わずかに唾飲み時の違和感が起こった。ただ、最初(再生ソフトで変換)よりは軽かった。

推測だが、再生時のサンプリングレート変換は品質が今ひとつ(例: 歪みが多い、超低域の変動が多い)だとか、PCの負荷状態でタイミングがズレて(= ジッター)耳に問題が起こるのかも知れない。

なお、第1楽章のスペクトラムを比較した限りでは、96kHzとsoxで44.1kHzに変換したものに大きな差は見られなかった。※ ただ、平均的には差がなくても、ダイナミックな特性が異なる可能性はある。

アムランのラフマニノフ PC 第3番 第1楽章 (左チャネル)のスペクトラム: 赤: 96kHz, 青: soxで44.1kHzにダウンサンプル

※もちろん、グラフの右端を見ると分かるように、96kHzのものには(44.1kHzの上限の)22.1kHz以上にも微量ながら成分がある点は異なる(が、そこらは まあ、雑音と思われる)。

という訳で、今回も余計な思い付きは失敗した。まあ、後付けだが、96kHzは駄目だったものの、24bitはCD品質(16bit)よりダイナミックレンジが広いという点でハイレゾ版にした価値はあった。※ 今後は、まずないだろうけど、44.kHz, 24bit版があれば それにしたい。

※とは言え、ちゃんとした音源であれば聴いて違いが分かるものではなく、フィルタなどの処理をした時に効く程度だと思う。

あと、書いたあとで思い出したが、上のグラフのように、96kHz版には どのくらい超高域成分があるかを調べたかったw

 

PS. なぜか ページ右側のフォントサイズが小さくなってしまった。何もしてないはずなのに・・・ またTODOが増えた。 ← 開発者ツールで調べたら、リンクしていたHyperionのOpen graph protocolでのページアイコンと説明がページ全体に影響を及ぼしていた。なぜか、この稿の下と右側をsmallにしてしまう。: あっちも こっちも いかんなあ・・・ → とりあえず、URLを昔みたいに書いた。

HyperionのページのOGPが その下と右側をsmallにしてしまう。

更に調べたら、HyperionのページのOGPのプロパティ(og:description)にHTMLタグが含まれているうえに 正しくないことが分かった。: あっちの作成ミスなんだろうけど、こっちも対処しないとXSSみたいなことに使われそうだ。

とりあえず対応(変なプロパティがあるOGPは破棄する)した。それで、リンクを普通に戻した。 (21:17)

  •  0
  •  0
Keys: ,