piu lentoの日々 (piu lento days)

「濁音に苦労した話」の続きである。元の稿に加筆したように、SpotifyのAPIで取れる曲情報でもcombining charactersが使われている(= 本体と(半)濁点が分離している)場合があることが分かった。

確かに、APIとそれ以外で別の情報を格納して別々に出すのは無駄だし、合理的でない。

表示は文字列が綺麗に出ればいいが、APIで取った曲情報は自作の音楽再生履歴記録システム MlhiのDBに格納しているので、今ひとつ良くない。というのは、今はまだ完全でない(イマイチな)ので余り使っていないが、将来は自分が聴いた曲をフレキシブルに(要するに、手軽に思ったとおりに)検索できるようにする予定で、その時に、combining charactersの濁音や半濁音を含む曲が出て来ない可能性があるからだ。

そういえば、以前、なぜか検索出来ない曲があったが、それだったのかも知れない。

(1/27 14:55) ちなみに、DBを調べたところ、曲情報(タイトル、アーティスト名、アルバム名、アルバムアーティスト)のいずれかにcombining characters(濁音、半濁音)が使われているものは、延べ27曲だった。DB全体は約1万曲なので、割合は約0.3%未満と少ない。ただ、僕は洋楽やクラシック音楽を聴くことが多く、曲情報が英語のものが多いから、日本の曲での割合は数%くらいではないか。

これを解決するには、以下の方法が考えられる。

1. DBに正規化した曲情報を格納する。
   • 今までにDBに格納した内容は正規化する。
2. 検索時に、検索文字列とDBの内容を正規化して比較する。
   • DBには、取得した情報をそのまま格納する。
3. × 検索時に、検索文字列として、正規化したものとそうでないものを両方指定する。
   • 正規化された文字を逆変換(分離)するのが面倒そうだが、uconvでできそうだ(本当?)。
   • 曲情報に正規化されている文字と そうでないものが混ざっているので、検索パターンが多くなり過ぎる。

Bが筋が良さそうだが、結構面倒そうだ(そもそも、DBに使っているSQLiteはUnicodeのこういう処理に対応しているのだろうか??※)。一方、前者は やればできそうなので、そうすることにした。

※ sqlean: All the missing SQLite functionsというソフトがあり、それは限定的なUnicode処理機能(upper/lower, like, unaccent)を持つので、SQLite自体は対応していないようだ。

ここで問題になったことがある。: 前の稿に書いたように、uconvで正規化すると、かな に正規化漏れが起こるのと、漢字の旧字体が新字体に変換されてしまう。前者は自作の処理(テーブル変換)で対応できているが、後者に対応するには、日本語の文字(漢字)を正規化しない必要がある。※

※幸い、日本語の漢字には濁点のような着脱可能な要素が なさそうなので、正規化対象から除外するだけで良い。ただ、例えば「辶」(しんにょう)のように、場合によって個数が違う点のような要素はある(→ 興味深い読み物があった)。が、それは純粋に文字の形の問題と思われ、意味や読みは変わらないので別件としたい。

他には、たまに、富と冨ののような着脱可能っぽい点はあるが、それらは同じ文字らしいし、相互に入れ替えて意味を変えることはないので(しんにょうと同様に)ヨシ、だ。

そもそも、今までに、(遊びをのぞいてｗ)漢字に かな のように点や丸を付けて意味などを変えたことはないし、そういうことを教わったこともないから、それで良さそうだ。

UnicodeやICUに不慣れなので、日本語を除外して正規化することができるのか分からなかったが、いろいろ調べたら できそうなことが分かった。

Unicodeにはscriptという概念があり、Latin文字(いわゆる英字)、カタカナ、ひらがな、漢字※のようなカテゴリ(Unicodeにはcategoryという概念があるが、それではない)を示すことができる。それを使って、uconvの正規化ルール(日本語除外フィルタのようなもの)を指定すればできそうだ。

※実際には、Unicodeの資料では漢字は"Han"と書かれており、おそらく中・日・韓の漢字を一緒にしたもの(≒ CJK Unified Ideographs)を差していると理解している。

具体的には、以下のコマンドで日本語(正確には、漢字、ひらがな、カタカナ)以外の文字を正規化できるはずだ。

uconv -f utf-8 -t utf-8 -x '::[ [:^Katakana:] & [:^Hiragana:] & [:^Han:] ]; ::nfc;'

処理内容は、-xの最初のルール(最初の ; まで)でカタカナ、ひらがな、漢字を除外し、残ったものに正規化(NFC)を実行する("::nfc")。

実は、上の処理には欠陥がある。おそらく韓国語(ハングル文字)はcombining charactersをバリバリ使っているはずだが、それも除外されるのではないか(ハングル文字がHanに含まれているとした場合: 実際には、scriptには"Hangul"というのがあるから、ハングル文字はHanには含まれていなさそうだ)。

が、僕の好みからして、曲名などが韓国語で書かれた曲は聴かないだろうから、とりあえずは良しとする。あと、中国語には簡体字も繁体字もあるし(それは関係ないのかも知れないが)、どうなのか想像も付かないｗ

上の処理は、以下のテストパターンで うまく行った。

• パ が 神: 正規化されずに出た。
• Ā (A + U+0304: Combining Macron): Ā (U+0100: Latin Capital Letter A with Macron)になった。※

※Āを使ったのは たまたま最初に できた(macronなるものが付いた単体のĀがあった)からである。この文字がどういう意味なのか全く分からないし、実際に使われるのかも知らない。

と、出来そうになって気分がいいところで、「残りはあとで」にしたｗ

参考にしたページは以下である。

• ICU Documentation: General Transforms
• ICU Documentation: Transform Rule Tutorial
• Programming with Unicode: 3. Definitions
• Regular-Expressions.info: Unicode Regular Expressions

uconvに指定するルールの書き方は最初と2番目(特に後者)が参考になった。最後に残った謎(どうやって日本語を除外するか? そうするパターンをどうやって書くか?)を解く鍵になったのは、最後のUnicode Regular Expressionsだった。

それについては最初の2つを丹念に読めば分かったのだろうが、余りにも知らない概念が多いうえに機能が多過ぎてチンプンカンプンだった(→ 読む気が起こらなかった)。一方で、-Regular Expressionsは馴染みの正規表現の話なので良く分かった。※ 更に、Hanが かな を含むという思い違いに気付かせてくれて、上のルールが出来た。

※実際、このページを見付けた切っ掛けは、ICU(uconv)のルールが全然思ったように動かないので諦めて、grepで正規表現で除外しようと思い、「『漢字全部』の うまい指定」があればと思って"Unicode regexp"で検索したことだ。

ちなみに、grepは-PオプションでUnicodeに対応した動作(PCRE)になる。

PS. Unicode(ICU)の処理には、カタカナ→ローマ字みたいなものがあって(→ Script Transliterationの表の「キャンパス: kyanpasu」)、「誰が使うの?」と思う。ちゃんと動くのならいいが、正規化みたいに中途半端だったら実装するだけ無駄だし、ほとんどの開発者は知らないので、使われない気が・・・ (いやいや、僕が無知なだけだよね)

PS2. こういう細かい話は嫌いだけど好きだ。: 実装や確認は面倒でやりたくないけど、豆知識的に調べるのは好きだ。発展したのがタモリかｗ

Chromeブラウザはメモリを大食いするのでメインには使っていないが、追跡されたくないとかプロファイルを完全に分離したい場合などに使っている。それが数日前から、妙な感じになって居た。普通は、タブを多く開くと使用メモリ量が多くなって警告メールが来る※はずなのが、来なくなったのだ。

※システム全体がメモリ不足になるのを防ぐために、定期的に「大食いアプリ」のメモリ量をチェックして出すようにしている。

うるさくなくていいけど却って気持ち悪いのでｗ、手で使用メモリ量を確認したら確かに少ないようだ。そういえば、近頃バージョンが上がったので改良されたのかと思った。

ただ、不思議なことに、調べてもそういう情報がない。Chromeのリリースノートのようなページには、「詳細は追ってブログに出る」のようなことが書いてあったので、これから分かるのかも知れない(→ 調べると、97での変更内容は山ほどあるので出なさそうだ)。あるいは、Linux版(の情報)は どうでもいいのかも知れないｗ

なお、一つだけ、外部のページ"Google Releases New Version of Chrome With Extra Security and Memory Safety Features"(2022/1)に近いことが書いてあった。以下に引用する。

... it is important to note that Chrome 97 also incorporates several upgrades to how it uses and manages memory. A common complaint that several users tend to have about Chrome is that it uses too much memory, and to fix this the new version of Chrome is no longer going to keep user profiles and settings saved after it is exited completely which will prevent these settings from using RAM in the background.

ただ、良く読むと終了後の話のようなので、違うのかも知れない。

「それじゃ、同じChromeベースのVivaldiも?!」と期待して調べたら、残念ながら大食いだった。大体、1タブで370MBくらい食う。Firefox(96.0.1)は約230MBなので、約1.6倍だ。そして、最新のChrome(97.0.4692.99)を調べたら約220MB/タブと、わずかながらFirefoxより少ない。

Vivaldi(5.0.2497.48)のUA文字列には"Chrome/96"とあるから、ベースは一つ前のようで、メモリ削減の改良がされていないのだろうと想像した。

ここで、省メモリだという評判のあるEdgeを思い出した(これもChromeベースなので、省メモリになっているかも知れないとも思った)。大嫌いなMS製だが、もし かなり省メモリなら(我慢して)使うのもありだと思って試したら、約370MB/タブ(Edge 98)とVivaldiと同様だったのでがっかりした。

どうやら、省メモリなのはWindowsでの話のようだ。想像だが、ChromeやVivaldiもWindows版とLinux版ではメモリ管理方法が異なっていて、Linux版は ずさんでメモリを浪費しているのではないか? あるいは、Windowsではアプリの使用量は少なく見えるが、実際には陰で大量に使っているのかも知れない。

まあ、いずれにしても、Edgeを使う意味は全くないことが分かった(そもそも使いたくないから、それでいいｗ)。

参考までに、以下に、各ブラウザのタブ1個当たりのメモリ使用量(増分)をまとめる。

• Firefox(96): 約230MB/タブ
• Chrome(75): 約220MB/タブ
• Vivaldi(5): 約370MB/タブ
• Edge(98): 約370MB/タブ

※すべてLinux版で、約6個のタブを開いて増加したメモリ使用量から求めた。メモリ使用量はpsコマンドの"RSS"(resident set size)を使った。

結局のところ、Chromeの使用メモリ量が減ったと言っても、ようやくFirefox並みになっただけなので、すぐに移る意味は ないことに気付いた。そもそも、Chromeには標準で縦のタブバーがないなど使いにくいので、移るとしてもVivaldiだ。それが更新されて省メモリになるのを待ち、それから使い勝手で判断することにした。

Vivaldi以外に ほのかに期待しているのは、同じく大食いのElectronやSpotifyも使用メモリ量が減らないかということだ。それらもChrome(chromium)を使っているはずなので、改良の効果があるのではないか。

以前にも書いたが、MozillaにはThunderbirdでも嫌気が差しているので、Firefoxから移れば離脱できそうだ。Mozillaは もう少し、ユーザーや開発者が喜ぶ(せめて、怒らない・使う気を なくさせない)ような進め方を考えればいいのにと思う。

夏が来た!
夏が来た!

上下の違いが分かる方は居るだろうか?: 同じに見えるけど違う。ブラウザ(かなり古いもの?)やフォントによっては、分かるかも知れない。

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、Unicodeのひらがな・カタカナは、濁音や半濁音を半角カナ的に 本体+(半)濁点 のように分離して記述し、なおかつ くっつけて一文字のように表示することができる。Combining charactersとかいって、日本語以外でも そういう処理ができるとのことだ。

上の例の「が」は、最初の行はcombining charactersで 「か」+「”」(← 見にくいのでダブルクォートにした) で、2番目は普通に書いてある。全く区別できない。※ 良く出来過ぎていることに、マウスでコピーする時は1文字として扱われるし、等幅フォントのエディタやターミナル(コンソール)でも くっついた状態で表示される。

※おそらく、フォントの字体としては、本体に濁点を加えたものが濁音の文字になっており、combining charactersの濁点は それを再現するような位置に表示されるようにできているのだろう。ただ、この方式ではすべての濁音で濁点が同じ位置に置かれるが、そこはフォントの 描き方でうまく合わせたのだろうか。

↑ ちょっと確かめたら、そう単純なことではないようだ。というのは、下の左図のように、「ヾ」と「ヷ」では濁点の大きさや形が明らかに違うからだ。ということは、フォントに濁点を付けるための情報があるのか、表示する時に、combining charactersの濁点が付く場合は自動で濁音の字に変換されるのか。見たところ、濁点の形が微妙に違う気がする(特に、線の太さ)ので前者なのかも知れないが、本当に そこまでやっているのかという気はする。どちらにしたって、「余計なところに力を入れ過ぎていないか?」と言いたくなる。 (1/22 5:18)

その後、文字に色を付けて濁点を重ねて比べたところ(下の右図)、同じ文字の濁点の形状は、combining charactersでもそうでなくても同様だが、異なる文字同士では異なっている(この例では、「ヾ」の濁点は「ヷ」のより大きい)ことが分かった。 (1/22 14:19)

僕が見付けた唯一の識別方法は、エディタ(ペーストする)で濁点側から1文字削除することだ。Combining charactersの場合は濁点だけが消えるが、そうでない場合は全部消える。

そして、今回の切っ掛けに関係することは、どういう訳か、Spotifyで出る曲情報(タイトル、アーティスト名、アルバム名)※の中に、本体と濁点・半濁点が分離して記述されたものがあるのだ。全部ではなく、たまにあるのが不思議だ。特定のレーベルという訳でもない気がするが、老舗(例: ビクター、ソニー)や昔の曲に多い気がしている(と書きつつ、1990年代の(一番下の図)もあるので関係ないかも)。

想像だが、レーベルが曲情報を電子形態に登録する際、打ち込む人の癖などで分離してしまったか、それ以前の半角カナも使うシステム(そういうものがあったかは不明)から変換した時に、濁点・半濁点を統合しないままだったのではないか。

※詳しく確認していないのだが、同じSpotifyでも、アプリから取れる情報(Dbusのイベントで取れるもの)とAPIで取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。 ← どちらも同じように分離している場合があることが分かった。例: 飯島真理 「palette(パレット)」(2007)の「パ」。 (1/25 16:31)

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作のSpotifyのミニプレーヤーMinispが駄目だった(これが発端である)。次の左図のように、combining charactersである「が」のあとに空白が出来て、半角カナ的な見苦しさになってしまっている。今見ると、本体(か)と濁点の間隔も少し広い。本来は右側のようになるべきである。

どうやら、表示に使っているTcl/Tk(wish)がcombining charactersに対応していないようだ(調べた限りではTcl/Tkのページの"Unicode combining characters"の項にはコメントだか状況説明が書いてあるだけのようだし、 そういう設定や属性などがなかったので非対応なのではないか)。

これを何とかしようと調べたら、Rubyのソフト(unicode_utils)の紹介が出て来たものの、インストールするのが面倒なので試行錯誤したら、既存のプログラム iconvでは駄目だったものの、既に入っているパッケージ icu-devtoolsのuconvでできることが分かった。

Combining charactersを まとめる(くっついた文字にする)のは「正規化」という処理で、uconvのマニュアルに例(下記)が書いてあった。

uconv -f utf-8 -t utf-8 \
  -x '::nfkc; [:Cc:] >; ::katakana-hiragana;'

上は他の処理も混ざっているので、以下の例のように、曲のタイトル、アーティスト名、アルバム名をそれぞれ正規化してから表示するようにし、上の右図のように解決した。

echo "夏が来た!" | uconv -f utf-8 -t utf-8 -x '::nfc;'
→ 夏が来た!

※正規化処理は、マニュアルではNFKCだが、調べたらNFCのほうが良さそうなので そうした。この辺りは全く詳しくないので手探りだ。また、上のコマンドでnfc前後の :: と ; は なくていいようだが、例にならって付けている。

今 上の参照ページを読んだら、NFCでも今ひとつな場合(「例6: 神と神」)があって気に入らないが、仕方ない(レーベルも、旧字体は余り使わないだろう)。一番いいのは、正規化しなくてもwishで綺麗に表示できるようにすることか。

あるいは、(一番最初に考えた方式の、)uconvでなくプログラムで変換するのがいいか。ひらがな とカタカナだけの対応になるが、濁音・半濁音と そうでない音の文字の順序には概ね規則性(元の音のコード= 濁音-1, 半濁音-2)があるので、それでcombining charactersを くっついた文字に置換するのだ。これなら漢字の旧字体は問題ない。

というか、いちいち計算するのでなく、今の追加処理のテーブル方式で全部処理するほうが良さそうだ。濁音・半濁音は多くないから、テーブルを作るのは容易だ。 → 基本的に、uconvを使うのを止めて追加処理だけにすればできるので、早速そうした。

この方式なら、あとから追加変換が必要になことが分かっても、変換テーブルに追加するだけなので容易だ。 (1/21 17:05)

ところがどっこい!ｗ

下の左図の「グ」のように、なぜか、頑固に正規化できない文字がある(図で「ベ」は くっついているので、処理されていない訳ではないことが分かる)。

更に調べたら、どうやらuconv(使っているのは uconv v2.1 ICU 66.1)が正規化しない(素通しする)文字があるようだ。ひらがな・カタカナの濁音・半濁音について調べたところ、以下の文字が駄目だった(正規化されずにそのまま出て来た)。

ど ば べ ぼ ぱ ぺ ぽ ガ ギ グ ズ ゼ ゾ ダ ヷ ヾ

ところで、上の最後のほうにある見慣れない文字、Unicodeにある「ヷ」、「ヸ」、「ヹ」、「ヺ」って実際に使われたのだろうか? どういう読み?? 謎だ。 (→ 4/1に出た、参考になるページがあった。)

その後、PHPの国際化関数のTransliteratorのtransliterator_transliterate()でuconvと同様の正規化処理を試したら、なぜか上の文字も正規化できた。よって、下ではICUやUnicodeのライブラリの問題と書いているが、uconvの問題の可能性が高い。だが、どうしたらこういう抜けが起こるのか見当がつかない。 (1/27 16:08)

実際には、原因はuconvではなく、それが使っているICUやUnicodeのライブラリの問題だろう(日本語に詳しくない人が作った??)から、パッケージを(Linuxディストリビューションのものでない、)オリジナルの最新に入れ替えるか、設定とか調整すれば直せる気はするのだが、パッケージの交換は あとあと面倒になるのでせず、設定・調整はuconvなどのマニュアルを読んでも分からない用語が多くて どうすればいいか分からなかったので、以下のような力技で対応した。

1. 起動時(初期化)
   1. uconvで正規化できない濁音・半濁音を調べてリストを作る。
   2. それらの正規化後の文字のリストを作る。
2. 曲情報(タイトル、アーティスト名、アルバム名)を表示する前
   1. uconvで正規化する。
   2. uconvで正規化できなかった文字がある場合は、正規化した文字に置換する。

これなら、将来ICUやUnicodeのライブラリが更新されて、すべての濁音・半濁音が正規化できるようになれば(なんか、永遠にそうならない気が・・・ｗ)、自動的に追加処理が不要になる。

処理を実装し、上の右図のように、駄目だった文字が ちゃんと表示され、(今のところは)一件落着となった。ただ、いつものように、他にも何か問題がありそうなので、表示やログを注視しながら音楽を聴いている。

これ、日本語以外でも あったらお手上げだが、読めなくて気付かないだろうから良し?ｗｗｗ

PS. 中程("1/21 17:05"の辺り)に書いたように、これを書いたあとで、実は、uconvを使うのでなく一番最初に思い付いた単純なテーブル変換方式が一番良かったというオチだった(今のところは)。Unicodeの考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

元日に実家に行ったら、母が「スマホにしようと思う」とか言い出したので驚いた。そもそも、使えるあてもないのに、なぜそんな考えになったのか分からなかったが、下のまとめを読んで分かった。

【悲報】ガラケー歴20年目のワイ。ドコモから最後通告が届く

ドコモが、ガラケーを持っている人に脅迫的な案内を出しているからではないか。古い端末が修理できなくなるのは当たり前のことで仕方ないが、それとスマフォへの移行は関係ない。ドコモが従来型の端末を出して(あるいは、他社の製品を)、それを紹介するだけでいいのに、余りにも恣意的にスマフォに移行させて、金を巻き上げる魂胆が透けて見える。

この件については、意図しているのか単に頭が悪いのか、以下の異なるものをごちゃまぜにしているように思う。

• ガラケー終了 (メーカーのやる気の問題)
• 3G終了 (電波・キャリアの問題)
• i-mode終了 (ドコモの都合)
• スマフォブーム(に乗じて収益を増やしたいキャリアの魂胆)

最初の2つについては、4Gなどで使える、ガラケーでもスマフォでもない従来型の端末、フィーチャーフォンを出せばいいのだ(今は1機種だけあるようだ)。高齢者はアプリとかの高機能なものは要らなくて、電話機能に加えてメールと写真程度で充分ではないか。

でも、それらすらガラケーの範疇になるのかも知れない。であれば、これまでガラケー・i-mode※で たっぷり稼いで来た責任があるのだから、ガラケーを使いたい人が居なくなるまでスマフォを押し付けようとすべきではない。それと電波(3G→4G)は全然別なのに、分かっていない人には もっともらしい説明になるのが嫌らしい。

これは、良くある詐欺の、「これからは＊が使えなくなるので、これを買って下さい」みたいだ。

※i-modeについては、勝手な(まさにガラパゴスそのもの)規格・仕様(そのために、世の中の標準的仕様と合わないことが多くて移行が難しいだろう)をでっち上げた責任は大きい。ユーザーが不利益を被らずに終了させる責任は大いにある。

その点、Apple・ジョブズ(iPhone)は(いくら大嫌いでもｗ)すごい。まあ、少なくとも3Gがなければできなかっただろうし最初は無理があったけど、標準規格ベースで あれだけのもの(サービスと言える)を成立・普及させたのだ。

例えば、3Gが終わって使えなくなるiPhone(Androidも)の機種はあるが、それらで使えていたサービスが使えなくなることは まずない。対応する機種に換えれば それで済む。ごく当たり前のこと・考え方ではあるが、できない会社は多い。

それにしても、これからしばらくは、ガラケーしか使えないのにスマフォを押し付けられて文鎮化させてしまう、あるいは、詐欺(フィッシング、ガラケー・3G詐欺なんてのも出そうだ)などに引っかかる高齢者、ガラケー難民(?)が増えそうだ。全く無責任だ。

そもそも、高齢者に限らず、今もこれからも「普通の携帯電話」が必要な人・場合は多い※のに、それを切り捨てるのは正しい進み方ではないと思う(まあ、会社自体が正しい進み方をしていたかという疑問はあるが)。

※例えば、「(それしかないので)いつでもどこでもデカくて重いタッチパネル端末を使え」ってのは、無理もいいところだ。

(てな、全然おめでたくない話を年頭から書くのは さすがに気が引けたので保留していたが、日が経った(それでもイライラは減らない)のと、丁度 最初に挙げたまとめが出て状況が分かった気がしたので、出した。)

PS. 母については、以前聞かれて、(本文にも書いた、)従来型の端末があることを教えて居たのに、再びスマフォなどと言い出したので、そこでブチ切れた。たまたま とか高齢だからという訳ではなく、あの人は、昔から人の話を聞き流す(賛成でなくても分からなくても、賛成のような分かったような返事をする)癖があり、それを目の当たりにして、昔からのトラウマが出たような(フラッシュバック?)嫌な気分が続いている。

スマフォに移るにしても、そういう考えになった理由や経緯を説明してくれれば まだいいのだが、あの人は僕が子どもの頃からそれをせず唐突に言い出すので、いつも混乱させられ、嫌な目に遭って来た(説明不足のために、こっちが被害・誤解を受けた)。

あと、ガラケーですらまともに使えない癖に、ある時、「こんなのテキトーに使えば使える」とか口走ったのにも大変ムカついた。テキトーに使える機械なんてない! だったら、スマフォもそうすればいいのに その気はなく、以前僕の余ったものを試すか聞いても乗り気でなかった。「(その癖に、)なぜ今スマフォなんだ!」と、正月から何重ものイライラが爆発した。

(18:25 わずかに変更・修正)

僕は洗濯用洗剤は無香料のものに決めていて、昔、ふぇーどるさん(お元気ですか?＾＾)が教えて下さったファーファを愛用していたのだが、去年辺りに販売終了(の分類)になってしまった。そのうち再開するかと思って静観していたのだが、やっぱり駄目だった。どうも、高いもの(濃縮タイプ)に切り替えたようだ。確かに、1個(900g)200円くらいでは売るのが馬鹿らしくなるとは思うが、がっかりした。

ファーファ(無香料)が販売終了に なっていた。。。

ファーファが残り少なくなって来たので少し焦りつつ探したのだが、濃縮タイプは まああるものの、そうでないもの(、かつ、高くないもの)はほとんどなかった。(以前書いたが)僕の考えによれば、濃縮洗剤は計量誤差(無駄)が大きくなって高く付くだけでメリットがないので選びたくない。一方、(合成でない、)液体のせっけんは結構あり、無香料だし身体に良さそうなのは分かっているが、昔使っていたら洗濯機に黒いカス(ぬる、あるいは、薄い わかめ みたいなもの)が溜まり、洗った服に付いて汚ないので止めた。

それで、ヨドバシにファブラッシュというのがあったので、試しに買ってみた。これはファーファ(中性)と成分が若干違って弱アルカリ性だ。まあ、(余計・変・嫌な)臭いがなければ、「大体」洗えればいい。デリケートな衣服とかないしｗ

さて、どうだか。

PS. それにしても、みんな、良く 変な(というと好きな人には悪いけど、)臭いの付いた洗剤だの柔軟剤を使うものだ。四六時中そういう臭いに接して気分が悪くならないのだろうか?※ まあ、すぐに抜けるのかも知れないが(でも、満員電車などで柔軟剤の臭いに困っている人は多いようだ)、要らないものは要らない。余計な ものは嫌いだ。

※この辺りのスーパーやドラッグストアには合成洗剤は臭い付きしか置いてないので、気にする人はほとんど居ないのだろう。そういえば、ファブリーズのような消臭剤も臭い付きしか置いてなかった気がする。

加湿しないと暖房しても寒く感じるようなので、先日 加湿器を買った。そして、いつものように苦労したｗので、そこら辺の話を書きたい。(良くやる手抜きだが、ちゃんとした文章にするのが面倒なので、箇条書きで済ませる。)

事前検討・試行、製品の選択

• 本物の加湿器は結構高いので電気ポットを検討したが、難しそうなので本物を買うことにした。
  • まず、電気ポットでの加湿を試行しようと、沸騰させた水を入れた やかんを置いて試したが、効果がほとんどなかった。
    • 常に(間欠的に)加熱しなければ、水が冷えてしまって湯気(蒸気)が出ず、加湿が続かないのだろう。
  • → 電気ポットを加湿に使う場合、常に(間欠的に)加熱する必要があることが分かった。
    • 保温の温度が選べる機種はあるが、希望のパワー(加湿力)になるか不明だし、電気代も予測できない。
    • 蓋を開けたままにしておけば加熱頻度は少なくていいかも知れないが、危険過ぎる。
  • → 電気ポットは諦めた。
• 製品を選ぶのに苦労した。
  • 衛生の面から水は沸騰させたい。また、無精で手間を掛けたくないので、フィルタ不使用が必須。更に、掃除を容易にするため、内部構造が簡単なものが良い。
    • → 超音波式や気化式は駄目。スチーム式でも複雑なものは不可。
      • いくら抗菌処理とかしても、腐るものは腐り、カビるものはカビるだろう。
      • ハイブリッドは両方の欠点が出るのでは?
      • 溝などにこびりついたカルキの塊は、絶対に取れない。
    • → 電気ポット型(スチーム式)にした。
  • さらに、窓などの結露を ひどくしたくないので、弱め(30%台前半)に加湿できるものが良い。
    • → ほとんど選択肢がなかった(確か3機種だけだった)が、性能・機能や信頼性やサポート体制を重視し、(ちょっと高いけど)象印の2.2lのもの(EE-RR35)にした。
      • 3lのは水の追加が少なくなりそうで良さそうだったが、消費電力が少し大きいので電気代がかさむのと、加湿能力が僕の希望より高そうなので止めた。
      • 少しでも安くしたかったので型番で検索したら、奇跡的に安い店(ココデカウ)が見つかった。: 価格comの最安より千円くらい安く、1.2万円以下だった。
        • なぜか価格comやBestgateに載ってなく、初めて見た名前だしURLも怪しい感じだったので詐欺かと思ったが、調べたら ちゃんとした店(EDION加盟)だった。
        • 確認したが、サイト名やURLの偽装でもなかった。
        • → もちろん、ちゃんと届いた＾＾
          • 注文した翌日に届いた(そこまでは期待していなかったので、感心した)。

使ってみて

• 効果はあるが、(例によって)音の問題が出た。
  • 効果: 湿度が40%以上だと、室温が低くても暖かく感じる。
    • (僕の目標の、20℃付近で)35%くらいだと微妙。
      • 加湿していない時のように腰などがスースーすることはないが、手などが冷たい(室温が低いせいか)。
      • ちなみに、加湿しない場合、昼は30%以下(概ね25-30%)だったので、加湿器によって5-10%増やせた。
      • この機種では、自動の「ひかえめ」モードだと40%程度になり、本来の加湿には充分である。また、自動なので調整が不要なのは便利だ(しかし、次に書いたように使っていない)。
    • ただ、窓などの結露が激しくなるのと電気代が掛かる(うちだと、ほとんど いつも加熱している)ので、低目に抑えることにした。 → 加湿モードを連続の「弱」にしている。
      • 「連続」とは言うものの、実際には約1分加熱、約2分休みのパターンだった。
        • ヒーターに加えるパワー(電力)を効率良く(しかも安く)、細かく制御できないためだろうか。
          • PWMは高くはないが、on/off制御(僕の機種はリレーを使っているようだ。: on/off時に音がする)よりは高いし面倒だ。
          • それに、高周波音が出て僕には向かない可能性が高いｗ
      • ※以下で出て来る測定値などは このモードでのものである。
  • 音の問題
    • 騒音: 運転音(炊飯器みたいな音)が結構耳につく。 → 遮音板で直接音を減らして試している。
      • → 天井などに反射するのか回折するのか、音量(測定した)は ほとんど減らず、効果は小さそうだ。
        • ただ、少しは効果があるのか慣れたのか、近頃は気にならなくなった。
        • 運転音や外の騒音の音量が変動するので正確な測定が難しく、効果を測るのは難しい。
        • 写真の状態になる前は、板にスポンジやゴムを付けたり段ボールで もっと広く囲ってみたりしたのだが、効果がないようなので、板(これすら気休めかも知れないｗ)だけにした。
      • 音量はエアコンより少し大きいことがある程度だが、音の質(成分)が違う。
      • あと、一度だけなので気にしていないが、最初に沸騰させる時の音は なかなか豪快だ。
        • それを減らすモードもあるが、毎回設定するのが面倒だし、沸騰するまでに時間が掛かるので、使っていない。
    • 加湿するようになってから、耳閉感が出た。
      • モーターの回転音や回路から出る音が悪いのかと思って運転音の周波数分布を調べたが、特に変な成分はなかった。
      • 風邪や疲れによるものの気がする。
• 唯一の欠点
  • コードが短いこと。1mちょっとしかないので、非推奨の延長コードを使うしかない。
    • 無理して延長しないでコンセントに繋ぐと、足を引っ掛ける。
      • それでも、磁石のコネクタなので、抜けるだけで倒れる心配はない。
    • 「そもそも壁際が非推奨なのに、この短さは何なのよ?」と言いたいｗ
  • 今のところ、これしか問題はない。(上述の運転音もあるけど、それ自体は ひどくはない。個人的な問題である。)
  • (書く場所がないので ここに) それから、一番最初に動かした時は少し臭い(こういうものに良くある系統)がしたが、数回で消えたので問題ではない。
• 加湿能力
  • 実測から求めた値(約70ml/h)は仕様(80ml/h)に近かった。
    • 1日使うと、水は半分くらい(1l)減る。
  • 湿度は概ね35%前後になっており、希望が実現できた。
• 消費電力、電気代
  • 実測から求めた値は約150Wだった。加湿パターンからの予測(約100W)より大きいが、最初に沸騰させる加熱(最大約1kW)や、毎回の立ち上がり時に消費電力が大きくなるのではないか。
  • 上の値より、1日12時間使用するとすると、約1.8kWh/日, 約55.8kWh/月 → 電気代は約1200円/月 (20円/kWhとした)となる。
    • 計算に間違いがなければ、それほど高くなさそうだ。
• 置き場所選びに苦労した(している)。
  • 結露する可能性があるので、壁や電気製品の近くは不可とのこと。 → 置けるところは ほとんどないｗ
    • 特に、タイル(台所)は すぐに結露して駄目だった。材質が冷えやすいせいか。
  • 席(いつも居る場所)に近いと うるさい。
  • 遠いと加湿効果が弱くなりそう。
  • 部屋の真ん中や通り道に置くと邪魔。
  • → ひとまず、席の斜め後ろ、エアコンの手前にした。
    • 暖房していれば風で結露しにくくなるし、湿気も部屋に拡散するはず。
    • 席から約1.4m離れている。
    • 今までのところ、仮の台の椅子の背もたれは結露していない。

その他

• 相対湿度と絶対湿度
  • 加湿量・能力は絶対湿度(= 空気中の水分量)で測れる(と考えた)。
    • → 絶対湿度を求めるのに使ったページ: なかなか便利で、愛用している。
  • 相対湿度は温度に依存するので、統一的な比較には向かない。
  • 人体は絶対湿度でなく相対湿度に反応するのが不思議。
    • 簡単のために「湿度」と言っているが、実は絶対湿度なのかも知れない。
• 連続して加湿しているのに(何もしなくても)絶対湿度が下がる、あるいは変わらないのが謎。
  • 弱い常時換気が効いているのか?
  • 上がることもあるから、単に湿度計の誤差や変動?
• 寝る時も加湿する人が居るようだが、暖房をしない場合、室温が下がって(相対)湿度が上がるので、(換気し過ぎなければ)不要なのでは?
  • 換気し過ぎず、余り結露しなければ、室内の空気中の水分量は余り減らないので、絶対湿度も下がらないはず。
  • だから 僕は、寝る前に(暖房と一緒に)停め、朝は暖房が効いて湿度が下がる頃に入れることにした。
    • 夜に湿度が高くて下がらなそうな場合は、早目に停める。
  • 寝室が別の人は仕方ないか。
• しょうもない製品・会社、的外れのレビュー(文句)、変な店など、いろいろあった。
  • しょうもない製品の例
    • すぐ壊れる。
    • 水漏れ
    • 補水時に蓋に付いた露で周りが水浸し。
    • 蓋を開ける時に火傷。
    • 倒すと、熱湯が どばっと こぼれる。
    • 重いけど持つところがない。
    • マニュアルが誤っている。
      • クエン酸洗浄できると書いてあるのに、実際にはできない。
    • スマフォアプリ対応をうたっているけど、アプリが まともに動かない。
    • メーカーも型番も製造国も書いてない。
  • サポートする気0の会社 (例: ジェネリック家電のY社)
    • メールなどは不可、フリーダイヤルは なく、有料電話(ナビダイヤル)のみ。。。
    • メーカー: 「修理は買った店に」 ⇔ 通販店: 「メーカーに」 → 実質修理不可
      • 保証期間内に壊れたら困る。
      • 修理受付している店でも、「まずメーカーに確認しろ」なので、ナビダイヤルでお金が むしり取られる。
    • メーカーページに製品が載っていない。。。 (検索しても出て来ない)
    • 上に比べれば、象印は とんでもなく親切で感心・安心した＾＾
      • もちろんフリーダイヤルだし、製品もちゃんとしている。蓋(ちゃんとロックが掛かる)を開けても水浸しなんてことはない。
    • 上とは関係ないが、パナがスチーム型を出さないのは、熱湯の安全性の確保が難しいからか、ナノイーとか重箱の隅に こだわる技術馬鹿だからか?
  • 的外れのレビュー
    • 「湿度が上がらない。」: 加熱して水が減っていれば湿度は上がるはずだから、何かがおかしい。: 文句を言うだけでなく、考えればいいのに。
    • 「ガラスや壁が結露で びしゃびしゃ」: そもそもそういう器具だｗ 物理法則なので仕方ないよ。自分で調整しなくちゃ・・・
      • やっぱり考えてない感じ。
    • 「家電や家具などに白い粉。取れない」(超音波式): 大昔から既知の現象だが・・・
      • 何も調べずに買ったのだろうか?
  • 変な店
    • 嫌いなA→Z社
      • なぜか、旧機種が高く売られていた。
      • しかも、メーカー+「加湿器」の検索では最新機種は出てこなかった。
        • 型番では出た。
• 残件
  • 正式な台をどうするか。
    • 今は予備の椅子に載せているが、なんか もったいないし、使いたい時に使えなくて不便。
    • 冬だけなので、それで いいかも。
    • あるいは、床置きでもいいのかも知れない。
      • つまづくと危ない?
    • → ちょっと思い付いて こしらえたものを試している。良さそうなら追記したい。 (1/15 8:04)
      • (1/15 16:27) 下のように、元々の遮音板に(元々の)脚を付けて台にして加湿器を載せ、(加湿器の箱を梱包していた)段ボールで囲って遮音してみた。
      • 遮音性を高めるため、板を2重にし、なるべく大きく(高く)した。
      • 内部で音が反射して共鳴するのの防止と操作性を向上させるために前面を開け、同じく共鳴防止と強度を高めるため、中に斜めの板を付けた。
      • まだ試作段階で、マスキングテープで仮止めしている。今日は洗濯物を部屋干したために加湿は必要ないので、明日試す。大丈夫そうなら ちゃんと作りたい。
      • 「防火管理者」が見たら烈火のごとく怒りそうだがｗ、さすがに発火は しないことを祈っている。
      • あと、湿気で板がフニャフニャにならないか気になるが、開口は大きいし、プロトは大丈夫そうだったので、試作版も大丈夫だろう。
        • もし駄目なら、内側に(窓に張った残りが かなり余っている)養生シートやPEのシートを張る手もあるが、更に可燃性が高まるという欠点はある。

↓

試作版の遮音板は大丈夫そうなので、ボンドで接着して正式版にした。使わない時に小さくできるように、中の斜めの板の片方を固定せずにたためるようにした。多少のズレはあるものの、僕としては なかなか うまく行った。

ただ、何枚もの板で貼る面積が大きかったため、途中でボンドが なくなってしまい、最後の一枚は足りないボンドで付け、斜めの板は両面テープで貼った。前者は大丈夫そうだが、後者は力が掛かって剥がれそうだったので、布用接着剤で貼り直した。

それから、ガムテープやマスキングテープを剥がすのが(自分としては気を遣ったつもりだが、)無造作だったため、段ボールの表面の紙の剥がれがひどい。内側はともかく、側面が見苦しいので、あとで綺麗にしたい。

肝心の運転音に関しては、試作・正式版の防音板にしてから聞こえる時間が短くなったように感じ、そのおかげで以前より気にならなくなった。実際には加湿器の加熱時間は変わらないので、小さい音や高い音が聞こえにくくなったためと推測するが、防音板を大きくして席側を囲っているせいか、あるいは、単に慣れたせいか、両方かも知れないが、確かに良くなった。 (1/17 7:59)

(1/16 4:14 湿度の目標の基準の室温を記載、その他細かい修正)

オーディオ馬鹿の とっても些細な話: 以前も検討した気がするが、その詳細を忘れて再度試したので書く。

Spotifyの音量正規化には、大(loud)、中(normal)、小(quiet)の3種類の音量がある。僕は、ポップ音楽とクラシック音楽両方の音量を手軽に揃え、かつ、他のアプリとも音量を合わせたいので、小にしてPC内部で増幅(7倍)※しているが、増幅するのが馬鹿らしいし音に悪い気がしたので、(他アプリとの音量合わせを諦め、)増幅を止めてボリュームで音量を調整してアンプで増幅するようにしてみた。

※「増幅」とは書いたが、数値演算(乗算)だけで、仮想的なものだ。

何も問題は なかったのだが、昨日くらいから、それは実は音に悪い気がして来た。というのは、PC内部(デジタル)とアンプ(アナログ)での増幅の音に対する影響を比べたら、前者のほうが得策なように思えたのだ。ただ、どのくらい音が劣化するか(データが落ちるか)を検討しないと分からないので した。

まず、PC内部での増幅(7倍)のデータ精度への影響は約1ビット(高々2ビット)で、内部表現(演奏の録音のフォーマットではなく、PC内部の音の処理の話)が20ビット以上なら(おそらく24や32ビットだろう)、DAC(有効精度は20ビット未満)が出す音質には影響がなさそうだ。

次に、更に詳しく検討した。元の演奏の音量(いろいろなものの平均)を1とし、アンプから出す音量をAとした場合のアンプの増幅量を比較した。

元々の(PC内部で増幅する)場合

• 元の演奏の音量: 1
• Spotifyの正規化(quiet): x0.45 (-7dB → 約1ビット減少※)
  • 元の演奏の音量を-16 dB LUFS(仮の想定＊)、quietで正規化後の平均音量を-23 dB LUFSとして＊＊、-7dB= x0.446とした。
• PC内部での増幅: x2.24 (7dB)
  • 表現上は約1ビット(1.17ビット)増える※が、実際にはデータの有効数字は増えない。
• DAC出力の音量: 1.0＊
  
• アンプの増幅量 G1: A＊

※除算してから乗算するので、内部処理方法によってはデータのビット数が減少しない可能性がある。そうでない場合でも、DACの有効ビット数(20ビット未満)は内部表現のビット数(24または32ビット)より少ないので、実質的には減少分は無視しうる。

＊実際には音量は演奏(曲)によって変化するので、これらの値も音量に従って変化する(下の、PC内部で増幅しない場合も同様)。

＊＊Spotifyの情報によれば、quietは-23, normalは-14, loudは-11 dB LUFS。

PC内部では増幅しない(アンプで増幅する)場合

• 元の演奏の音量: 1
• Spotifyの正規化(quiet): x0.45 (約1ビット減少)
• PC内部での増幅: x1 (なし)
• DAC出力の音量: 0.45＊
• アンプの増幅量 G2: A/0.45＊

A > 0なので、G1 (A) < G2 (A/0.45)となり(比は内部増幅の倍率の約2.2倍, 7dB)、増幅なしの場合はDAC出力が小さく、その分アンプ(ボリュームを含む)での増幅量が大きい。そのため、DACで小さい音量を出すことでの精度劣化(約1ビット分)、アンプまで(コード、ボリューム・アッテネータ)の雑音混入や音質劣化、アンプでの雑音・音質劣化といった負の要因が増える可能性があり、得策ではなさそうだ。

結局、元のまま、PC内部で増幅してDACから出すのが最適そうだということになって、戻した。

いずれにしても、本当にわずかな違い(しかも理論上)の話なので、実用上はどちらでも問題はない。気分の問題である。

と書いたのだが、上記のようにDAC出力の音量が(数値上は)7dB違う(約2.2倍)ので、結構音質に影響がありそうだ。聴いても違いは分からなかった(ただ、何となく音が悪い気がすることがあった。どのようにかは はっきり覚えていないが、音の鮮度が落ちたような気がしたように思う)が、実際にはどうなのだろうか(まあ、「病は気から」的なものだと思うｗ)。

(1/13 8:39) 訂正後に検討したら、Spotifyの音量正規化にquietでなくnormalを使ってPC内での増幅量を減らす(約2.5倍, 8dBに)ほうが得策なようだ。ただ、normalの場合には音量正規化処理で増幅される場合があり、それを増幅するとオーバーフローすることもあり得るので、音質が劣化する可能性がある。が、それは頻繁でなさそうなので、試す余地はある。 → あとで詳しく検討・試行したい。

↓

(1/13 18:01) どうもこの稿は誤りが多い。上記の減らした増幅量は2.5倍でなく約0.79倍(-2dB)である。

• 元の演奏の音量: 1
• Spotifyの正規化(normal): x1.3 (+2dB)
  • 元の演奏の音量を-16 dB LUFS(仮の想定)、normalで正規化後の平均音量を-14 dB LUFSとして、+2dB= x1.26とした。
• PC内部での増幅: x0.79 (-2dB)
  • 当初想定していた音量に合わせるため、Spotifyの正規化で-14dB LUFSになった音量を-16dB LUFSに戻す。
• DAC出力の音量: 1.0
  
• アンプの増幅量 G1: A

これなら、Spotifyの正規化でオーバーフローが起こらない限り、PC内で情報が失われることがないので、音質的には最良だ。

正確には、PC内部での増幅(実際には減衰)をしないのが一番だが、他アプリと音量を合わせたいので、あえてそうする。

さっき この処理を実装して動くようになった。気のせいだとは思うが、音が よりシャキッと(鮮度が上がった)した気がする。もちろん気のせいだ＾＾

(1/13 8:39 Spotifyの音量正規化の音量を訂正し、それに関連する修正・加筆した。; 1/13 12:52 PC内部での増幅ゲインも間違っていたので訂正した。; 1/14 10:55 見にくいので、訂正前の取り消し線の部分などを削除し、補足を追加した。)

(環境に優しい?ボツ稿のリサイクルシリーズｗ)

6年近く前に以下を書いたものの、投稿せずに残って居た。

この曲では、ショパン(Chopin)を「チョピン」と歌っているのだが、なぜなのだろうか。録音の時に誰も気付かなかったのか? その時はどうでも良かったのかも知れない。。。

それで、セルフカバーではどうしてるのかと思って調べたら、セルフカバーされていて、それも「チョピン」だった!

ということは、詞に何か意図があるなのかも知れない。あるいは、恥ずかしいけどオリジナルに忠実に歌ったのかな。

今日、再利用しようと思い、見直して調べたら、スペイン語ではショパンは「チョピン」と読むらしいし、そういう靴もあるらしいので、本当に間違いかは不明だ。あと、以前調べて「チョピン」という人が居た気がすると思い、やはりボツだと思った。

が、歌詞を調べたら、「ショパン」でなく"Jobim"(アントニオ・カルロス・ジョビン?)だった。それで思い出した。: 確かに以前も調べて そのことが分かったので、この稿をボツにしたんだった。でも、なぜ、ピアノでわざわざ「ジョビン」? ジョビンのメインはボサノヴァらしいのに。

推測だが、最初は"Chopin"と書いてあったのを間違えて歌ってしまい、あとから気付いたけど遅かったので、「どうにかならんか?!」と調べたら運良く似た音の作曲家が居たので、(作詞家に頭を下げて)詞を直してもらった??

詞を読むと、ボサノヴァのピアノを教えるとかいう雰囲気ではなく、ショパンのほうが合ってそうだが、果たして・・・

↑改めて聴いたら曲調がボサノヴァっぽかったので、Jobimで正しいようだ。残念?

昨日、部屋のスピーカーの特性を定期チェックしたら、なぜか左チャネルの特性が少し変わっていた。主に700-800Hz付近の山の形や頂点の周波数が変わっていた。具体的には、前回までは690Hzが高かったのが780Hzが高くなった。昨日はその辺りのイコライザのフィルタを調整して しのいだが、やっぱり原因が気になった。

約半年の間に700-800Hz辺りの特性が変わった。: L: 青: 前回(2021/6), 紫: 今回(2022/1)

なお、変化は悪いことばかりではなく、上のグラフを見ると分かるが、160-200, 370-400, 500Hz, 1k, 2.6kHz辺りの多くの山が なぜか低くなっているのは いいことだ。

新たに頂点になった周波数(780Hz)の波長を計算してみると、大体44cmだった。それで、そのくらい、あるいはその整数倍の隙間や音の経路差で音が強まっているのではないかと推測した。それで、前回のチェック(去年の6月)からスピーカー周辺で位置を変えたり追加したものはあるか考えたが、特になかった。何も変えていないのに特性が変わるのは不思議だが、可能性を考えた。

まず、メインディスプレイと壁の間隔が44cmくらいで、そこで共鳴しているかと考えたが、元からそうだし、右チャンネルには影響がないし、変えようがないので却下した。

ただ、何か変えようがあるかも知れないので、あとで試したい。

次に気になったのは、初冬に窓に張ったシートである。シートはガラスより手前にあるから、それで反射するなら、その分経路が短くなって周波数が高くなるだろう。ただ、計算してみたら合わなかった。そもそも、シートよりガラスのほうが反射が強そうだ。

それから、気温が下がった影響かと考えたが、温度が下がると音速が下がって、同じ波長(経路差や隙間の間隔に関係する)の周波数は低くなるから今回とは逆である。

更に、床での反射を考えた。前述のとおり、置いてある物や位置は変わっていないから反射の仕方も変わっていないはずだが、調べてみると、スピーカーとマイクの距離と、スピーカー-床-マイクの距離差は90-94cmで、780Hz辺りの波長44-49cmの約2倍となるから強まりそうである。

それで、床への入射を抑制しようと試行錯誤したが、なかなかうまく行かなかった。一番抑えられたのは、机の脇(スピーカー側)に平らにした段ボール箱(= 段ボール板)を立てた場合だった。ただし、机から20cm近く上まで伸ばさないと効果がなかった。これより、どうやら、机の天板での反射も効いていそうなことが分かった。

ただ、そのように遮蔽板を設置すると高音が遮られてしまうので、実施はできない。諦めようと思っていた時に、思い出した。今年のカレンダーのために、それまでスピーカーの直近に置いていたペン立てや猫の置物を反対側に移動していたことを。そんな小さい物は関係ないとは思ったが、ダメ元で元の場所に置いたら、なぜか効果があった。

実際には、前回測定後に作った光・温度センサが元の位置にあって少し位置が違うせいか、完全に同じ特性にはならなかったが、結構良くなった(グラフ1(L, イコライザなし): 調整(ペン立てなどの移動)により、紫だったのが水色となり、前回の青に近付いた。また、イコライザでの補正もれが少なくなった。 → グラフ2(L), グラフ3(LR, 全域))。

なんでそうなるのかは新たな謎だが※、ペン立て(マグカップ)の表面で音が乱反射や屈折し、あるいはカップの凹みで共鳴して、うまい具合にその辺りの音が弱まるのだろうか。

だとしたら、逆に音に悪そうだが、ひとまず山が下がったので、今のところは良しとする。

※あと、これに気付くまでペン立てなどを移していた右側の特性が変わらない理由も謎だ。

(1/8 14:52) その後、更に原因を調べたが分からず、しかも、ペン立て(マグカップ)を置いても改善できなくなってしまったので、迷宮入りだ。大きな問題はないので保留としたが、今までのところ、以下(単独でなく、組み合わせ)が原因の可能性があると考えている。

• 机の天板での反射: 天板(スピーカー側)にマットを敷いたら改善できた。
• 床での反射: 上述のとおり。
• メインディスプレイのケースの共振: 叩くと800Hzに近い音が出るが、ゴムテープを貼っても改善できなかった。ゴムテープは軽くて無意味なのか、中の空間が鳴って居るのかも知れない。
• メインディスプレイの背面と壁の間での共振: 斜めにしても変わらなかったので、関係ない?
• 工事の騒音: 関係ない可能性が高い。

(1/8 20:45) 原因を知りたかったので、主にメインディスプレイでの共振関連を試したが、関係なかった。更に他の可能性を調べたところ、なんと、左スピーカーの脇に置いたカレンダーが悪かったことが分かった。あんなに小さくても結構な影響があることに驚いた。板なので800Hz付近の音を反射して強めるのだろうか?

そして、(妙だとは思っていたが)マグカップ(ペン立て)には音を改善する効果は ないことが分かった。マグカップを置いて特性が改善されたのでなく、カレンダーを置かないことで変な特性でなくなったのである。それで、今は再びカレンダーを本棚に置いて、元の特性に近くなった。

完全に分かった訳ではないが、ひとまずは片付いたので「ヨシ」。

PS. カレンダーのいい置き場所がないのだが、とりあえずは本棚に置いている。ちょっと遠いけど、普段は使わないので良しとするｗ

(電気羊じゃなくてｗ)

先日見た記事で、また少し期待が高まった。

“Snapdragon PC”でMSや主要メーカーと連携を加速 クアルコム

ただ、Snapdragonて、ARMでも熱い・電力効率が悪そうな気がするので、やっぱり今のところはM1チップがいいが、こういうのが増えると、そのうち「いい感じ」のチップやセットが出て来そうだ。もちろんM1でもいいが、Linuxが大前提だ。

とにかく、クソ効率の悪いx86は止めにしよう!!

PS. これを切っ掛けに ちょっと調べたら、ロシアのBaikal-MというチップのPCが発表されて居て、ハードの機能としては結構使えそうな感じだしTDPも30W以下で悪くないが(とは言え、10Wくらいになって欲しい)、海外には出ないようだ。