Archive for the ‘PC・技術’ Category

ニュースに「10%の食塩水1kg作るのに必要な塩と水は? 大学生が「%」を分からない絶望的な日本」というのがあって、どうももやもやした。僕も間違える気がするのだ。

というのは、これは昔からある引っ掛け問題で(小学校の頃に引っ掛かったか教わって、それ以来、苦手意識がある)、最後に1kgにしなくてはならないので、単純に1Lの水に食塩100gを入れるのでは間違いなのだ。でも、化学の実験はともかく、日常生活ではそれで充分な気がする。

誤差を計算すると、

  • 正しい場合: 10% (正答: 900gの水に100gの食塩)
  • 誤答の場合: 1Lの水に100gの食塩を入れた場合、9%
  • → 誤差率: -10%

なるほど。意外に誤差が大きいようだ。でも、大きな問題はない気がする(ちゃんとした料理だとそうでもないのかな)。

あと、正答を転記して思ったのだが、この%は重量率なのか容積率なのか不明ではないか。全部gだから重量率なのは自明なのか。そこで引っ掛かる人も居そうだ。細かくチェックするならちゃんと書けって言いたい。それに、「水900g」ってすごく違和感がある。器でなく秤で測るの? 濃度を室温に無関係にしたいのか。

それから、そもそも食塩が水に10%も溶けのるかという疑問もある。調べたら、常温で20%以上溶けるようなので問題なかったが、どうも、問題以前にこういうところでつまづいてしまいそうだw

PS. このニュースの題は今ひとつ適切でない。本文を読む限り、大学生が食塩水の問題を解いた訳でない(解いたのは中学生のようだ)のだ。近頃はこういうのが多くて、そこにももやもやする。あと、全角スペースは使うなとあれほど(略)w

  •   0
  •   0

先日、前回から一か月おいて歯科に行った。随分混んでいるようだ。前回は、左上の奥歯の詰物(金属)と歯の境目に穴が開いているので、セラミック(保険外)か金属(保険)のどちらにするか決めるように言われた。保険の金属はどうも良くない(今回のように、境目から虫歯になってしまう)感じなのでセラミックがいいのだが、ダメ元でレジン(保険)は可能か聞くことにして行った。

その日はなぜか寝不足だった。そのせいか、なぜかハイな感じになっていて、椅子に座るなり、衛生士さんにレジンが可能か聞いた。いつもは聞かれるまで待つのだが。すると、範囲が大きいから無理とのことなので、セラミックにした。

ここまでは想定範囲内だったのだが、ここからが予想外だった。なぜか、ディスプレイには(左でなく)右上の奥歯の写真が出されていて、歯科医師(前回の院長から変わり、息子のようだ)は、「右上奥歯の根本に亀裂があるので、そこを治す」と言った。

はい?

(確かに右は僕も気になっていたけど、)話が全然違うんですが。。。 結構驚いたし、(上述のように)寝不足でハイだったので、いつもと違って少しキツく反論した。前回の写真の確認などをしてもらって、左も要治療なことを分かってもらった。

ただ、謎なのは、前回はちゃんと左の奥歯の金属の写真で説明されたし、右も、写真を見ながら縦筋は割れではなさそうだから様子見という話を聞いたのに、どうして、今回は右の治療になっていたのだろうか。そういう記録があったのだろうが、それはいつ誰が書いたのか。前回の院長がトチ狂っていて言動が一致していないということ?? あとで記録を書いた時に、忘れたとか疲れとかでどっちか分からなくなって取り違えた? いずれにしても結構恐ろしい。こういう感じに医療ミスが起こるのかも知れない。何も言わずにいたら、別の歯を抜かれてしまったとかいうトラブルがあるのも分かる。

そして、セラミックと金属の選択でレジンは無理という話も右のことだったと思われたので、改めてレジンが可能か聞いたら、可能だということだった。もちろん耐久性は劣るとは言われたが、(僕の期待どおりになったので、)聞いてみて良かった。なお、右は削る範囲が大きいのでレジンは駄目だそうなので、セラミックにすることにした(今は昔より広くレジンが使えるようになっていることを読むが、それは都会とか最先端の話だし、常にそれが正しい・可能な訳でもないだろうから、ここで頑張ることはしなかった)。

結局、前回診てくれた院長がボケていた駄目だったようで、その時の鋭い衛生士さん※(と僕)だけが正しかった訳だ。

※今回と同じ人だったかは不明。雰囲気は同じような気がしたが、言動が違う気もした。寝不足のせいで、今ひとつ分からなかったw

というか、

あのジジイなんとかしろ!

すごく意外だが、こんなこともあるようだ。ただ、今回の歯科医師は若いせいか技術がありそうで、手際良く、丁寧に確認と説明をしながら治療してくれたので、最終的には安心した。次回も彼だといいのだが・・・

最後に、偉そうにも教訓めいたことを書けば、人は必ず間違えるので、それを前提に行動しないといけない。だから、患者も可能な限り考えて確認しないといけない。「言われたとおりにしていれば問題ない」なんてことは全くない。なんかのドラマで「私はミスしない」とかのたまう医師が居たようだが、アホかバカか、「出直して来い!」だ。そんなのに掛かったら却って怖いよ。

 

PS. 寝不足のせいでボケていて、隣の治療室(板で区切っているだけ)の衛生士さんの声が大きくて、その「型取りますねー」とかいうのが僕に言われているように勘違いして、数回「はい」と返事してしまった。こっちの衛生士さんは ちょっと驚いていた感じもしたが、無視していた。そこは微妙にいいような悪いような気がした。でも、若い頃と違って、このくらいでは全く恥ずかしく感じないw

PS2. レジンにできたおかげで、今回の治療費は2千円未満と、激安で済んだ(彼らにしてみれば、全然元が取れないのだろう)。

PS3. 気付いたら、保険の金属の詰物は2個だけになっていた。以前はかなり多かったが、長年掛けて(悪くなるたびに)セラミックやジルコニアやレジンに交換したおかげで、光るところが大分減って いい感じだ。

PS4. 一見関係ないが、秋のブロンフマンのコンサートは諦めた。冗談のようだが、セラミックの歯と同様の料金なので、歯を優先することにした。さすがに両方は使い過ぎだ。それに、前にも書いたが、今はルガンスキーくんが一番好きなのだ。そして、今はまだ、彼の方がコスパがいいw

  •   0
  •   0

先日HMVの広告で見た、Viviane Chassot(ヴィヴィアンヌ・シャッソ)という人の新作がSpotifyに入っていた。今回は丁度発売日だ。見付けてから結構日が経ったので、曲が何だったか忘れていた(「ゴルトベルク」と思い込んでいた)のだが、モーツァルトのピアノ協奏曲 第27番などだった。

それだけでは全く変哲がなく、広告を見たって待ってまで聴く気にならなかったのだが、なんと、楽器がアコーディオンなのだ。もう、それを見た時から、怖いもの見たさでw出るのを待っていたのだ。

今は先日書いた、再生履歴を自動記録するプログラムのプロトタイプを作っていて、そのテストがてら、今朝から聴いている。

掛ける前は、「どうせ、例によって『がっかり』のパターンだろうな・・・」(「ゴルトベルク」のピアノ以外の演奏に多い)と、全然期待していなかった。そもそも僕はアコーディオンが好きではない(嫌いでもないが、オルガン系なので余り積極的に聴かない)。

が、掛けた途端に、「これはいい!」と思った。最初の曲はピアノ協奏曲 第11番で馴染みがないし、頭はオケだけだが、アコーディオンが出る前からいい予感がした。オケ(Camerata Bern)の音がすごく綺麗なのは確かだ。相手がアコーディオンだからといって手加減している感じがしないのがいい。

で、アコーディオンが始まったら、これがなかなかおもしろくていい。アコーディオンの、暖かい、ヨーロッパの街角で演奏されてそうな(見たことはないw)、ちょっととぼけた音がいい。ちっと聞いただけだとヘタウマだと思いそうだが、音が絶妙だからそう聞こえるだけで、実際にはすごい腕だ。

気に入ったので聴き続けて、今は最後の曲、第27番(→ ライブでの演奏(一部): アルバム(→ プロモ)はこれよりずっといい)の終わりの辺りで、完全に気に入った。アコーディオンも悪くない。強いて言えば、最初の頃は音が少し弱い感じがしたが、聴き続けたら慣れた。アコーディオンがいいのはもちろんだが、上にも書いたように、オケがすごくいい。そして、HMVの広告にも書いてあったが、アコーディオンの音は木管楽器とすごく相性がいい。聴くまでは全然想像していなかったが、そこがすごく気に入った。

そして、選曲がうまい。収録されている曲は第11, 15, 27番で、どれも暖かい感じの曲だからアコーディオンの音が合ったのだろう。だから、第20番などは全く無理な気がする(それでも聴いてみたいし、彼女ならうまくやりそうだ)。選曲をちゃんとするのは当たり前のことなのだが、身の程知らずとか、自分の得意なところを分かってない人も多い気がする(挑戦するのは意味あるが・・・)。

いやぁ、アコーディオンだからといって馬鹿にしてはいけない。あと、こういう演奏とか雰囲気だったら、まさに音楽祭に持って来いではないだろうか。一方、系統が近いとはいえ、オルガンだったらイマイチな気がする。理由はすぐには出て来ないが、そういう気がする。好みの問題は大きいだろう。

 

PS. 再生履歴の自動記録は、Spotifyのミニプレーヤーがかなり複雑になっていて、改造するのが面倒だったので、別にプログラムを動かすことにした。プロトタイプなので、多少効率が悪くてもいいと考えたのだ。そして、たまたま、ミニプレーヤーがSpotifyから取得した、再生中の曲情報がファイルに格納されるようになっているので、それを参照すれば概ねうまくいくことが分かった。昨日から作り出してどうにか動き出し、Spotifyで再生した曲の情報が自動的にDBに記録されるようになった。DBなので、SQLというコマンドのようなものを入れれば、自由な条件で履歴を抽出できる。下に例を示す。

自動記録したSpotifyの再生履歴を抽出した例 (評価が良くて、コメントがあるもの)

もちろん、実際に使う時はSQLを打ち込むなんて面倒なことはせず、webなどから簡単に条件を指定できるようにするつもりだ。

ちなみに、記録し出してから1日も経っていないのに、エントリ(曲・トラック)数が150近くになった。今のDBのデータ量は約65KBで、1曲辺り0.5KB未満と小さい。それでも、10万曲だと50MBくらいになるので心配はあるが、画像管理ソフト(XnViewMP)のDBは180MBにもなっていて、それでも起動や処理が遅いことがないから、大丈夫そうだ。

次は、Spotifyの検索と上述の再生履歴を統合するプログラムのプロトタイプを作りたい。Spotifyの検索結果を再生履歴の条件(例: 「1度も再生したことがない」、「評価が悪くない」)でフィルタリングするイメージだ。その後は、ミニプレーヤーに、「初めて再生する」とか「今までの評価がいい」とかいうマークを出せるようにしたい。夢はふくらんでおもしろいが、作るのは楽しいけど楽ではないw

PS2. 丁度、「いかにもアコーディオン」でがっかりするいい例があった。これも今日HMVで見付けたのだが、Nikola Djoricという人の「展覧会の絵」(2019)だ。これは、いかにも「アコーディオンだったら、まあ、こんなものだよね」的だ。。。 まさに、Chassotを聴く前に予想していて、外れたことだ。彼女がすご過ぎたようだ。そもそも、こちらは選曲が悪い。音が甘く・丸くて、曲に全然合ってない(僕の好みが大きいとは思うが)。 (19:20)

(19:31 加筆)

  •   0
  •   1

Spotifyで主にクラシックの演奏を選ぶ時に、以前聴いたかどうかと、聴いていた時はその時の感想や評価(例: 好き/嫌い)が出れば、二度手間にならなくていい※と思っているのだが、そういう機能はない(再生履歴は出るが、検索が楽ではない)。曲にコメントが記入できるといいのだが、無理だ。それで、少し前から、そういう仕組みを作りたくなって検討している。

※感想は聴くたびに変わる可能性があるが、少なくとも、「フォルテピアノ・古楽器だから駄目(「僕は嫌い」の意)」などという情報があれば「普通の演奏」だと思って掛けることがないから、二度手間にならないことは確実だし、それでフィルタリングできれば、選ぶ手間がかなり減る。こういう機能がマジで欲しいのだ。

主要な機能は以下だ。

  1. Spotifyで新しい(= 過去に再生したことがない)曲を再生したら、その曲の情報と再生日時を記録する。 → 「再生履歴」
  2. 曲の再生中または後に、その曲の再生履歴にコメント(感想)を記録できる。「嫌い」という情報(マーク)も記録できる。
  3. Spotifyで曲を検索し、結果に出た曲に再生履歴があれば、過去の再生日や評価やコメントなどを一緒に表示する。再生ボタンやリンクをクリックすると、Spotifyアプリで再生できる。

実現方法を考えたところ、1は自作のミニプレーヤー(minisp)を改造すればできそうだ。2は再生履歴の管理プログラムを作ることになる。3は、Spotifyの検索プログラムを作る必要がある。基本的には、web版Spotifyのようなイメージだ。そこに再生履歴の情報も合わせて表示する。SpotifyのAPIは公開されているので、面倒ではあるが、作るのは不可能ではない。

更に検討したところ、再生履歴の管理プログラムの再生履歴のデータをどのように格納・管理するかが問題になった。かなり多くの曲を再生し、それらが全部登録されるから、CSVのような普通のファイルでは処理が遅くなったり壊れたりして破綻しそうだ。

最初は、曲ごとに別々のファイルに再生履歴を格納することを考えたのだが、考えているうちに問題(この方式では一つのキー(= ファイル名)でしか高速な検索ができない)に気付いたり、(仕事でもないのに)いちから全部(例: ファイルフォーマット、作成・処理・管理)自分で作るのは馬鹿らしい気がして来た。それで、まずは近い用途の既存のプログラム(音楽などの管理プログラム)を使って手を抜くことを考えた。重要なことは、外部から(GUIでなくコマンドラインで)データの追加・変更ができることと、カスタムフィールドが追加できることだ。

以下に検討した候補の概要と結果を示す。

  • 音楽管理ソフト
    • × gmusicbrowser: 音楽プレーヤー
      • 現在、音楽ファイルの管理と再生に使っており、カスタマイズ(改造)もしている。
      • 曲情報を格納するファイルが一つ(CSVのようなもの)なので、曲数が多くなると破綻する。
      • 将来性が疑問(開発・サポートが終わっている)。
      • Perlで書かれているので改造や保守が大変。
    • Beets: 音楽管理ソフト
      • 試用の結果、使用可能なことが分かった。ただし、若干の細工(ダミーファイルをインポートするなど)が要る。
      • GUIはなく、コマンドラインのみ(webは貧弱)。
      • 拡張性が高い。
      • まだ完成していない感じ。
      • Pythonで書かれているので(以下略)。
  • 汎用コレクション・ライブラリ管理ソフト
    • × GCstar: 汎用コレクション管理ソフト
      • Perlのバージョンの問題か、うまく動作しなかったので却下した。
    • × Data Crow: 汎用メディア管理ソフト
      • コマンドラインでの実行はできなさそうなので却下した。
      • Javaで書かれている。。。
    • × BiblioteQ: 汎用ライブラリ管理ソフト
      • Linux用パッケージが壊れているので却下した。
      • ドキュメントが貧弱。
      • コマンドラインはなさそう。
    • × Tellico: 汎用コレクション管理ソフト
      • コマンドラインでは書籍しか登録できないので却下した。
  • その他
    • × tinyMediaManager: 映画の管理ソフト
      • 既に動画ファイル・DVDなどの管理に使っている。
      • ほぼ動画専用(映画の管理に特化した機能が多い)
      • この用途には若干の細工(ダミーファイルをインポートするなど)が要る。
      • コマンドラインは不明。
      • エントリ追加後の再スキャンが面倒。
    • calibre: 電子書籍管理ソフト
      • 既に電子書籍の管理に使っている。
      • コマンドラインでの操作が可能。
      • 試用の結果、使用可能なことが分かった。
        • ただし、音楽を書籍として扱うのは無理があるのと、ちょっとした問題(GUIが起動していないと、コマンドラインでの登録時に無駄な待ちが生じて遅い)がある。

試行錯誤して、Beetsとcalibreで再生履歴の管理ができそうなことが確認できたのだが、結局、実質的にはそれらの主たる機能でなく、DBの機能を(うまく誤魔化しながら)使っていることに気付いた。DB以外にGUIが使いやすければ便利だが、calibreは音楽は目的外なので最適化できず、BeetsにはGUIはない。

calibreを用いた音楽再生履歴の管理(プロトタイプ)

そこで、だましだまし他用途のアプリを使うのでなく、直接、DBと管理ソフトを使うことを考えた。ただ、(特にコマンドラインで)DBを直接操作するのは面倒な(そんなことが目的じゃないので、やってられない)ので、「ぱぱっ」と使えるものを探した。それほど詳しく調べていないのだが、多くは基本的にはSQLを自分で打ち込んで操作するもの(詳しい人用?)のようだったが、DB Browser for SQLite(以下、DB Browser)だけは簡単に使えそうな感じだったので、試してみた。

すると、確かにすごく簡単にDBを作成・操作できて、すぐに試用・評価が始められた。これはすごく推奨できる(対象者はとても限られるがw)。DBはSQLiteなので、当然、(GUIでなく)コマンドラインでの操作も可能だ。SQLiteはDBのファイルが単一なのが気になるが、DB用に処理を最適化しているはずだから、曲数が多くなっても破綻しないことが期待できる(実際に使用例は多い)。

DB Browser for SQLiteを用いた音楽再生履歴の管理(プロトタイプ)

ただ、calibreのGUIの手軽さは捨て難かった。しかし、この用途では、できればアルバム中の曲をまとめて扱いたい。例えば、感想を曲ごとだけでなく、アルバム全体にも付けられるようにしたい※。それはcalibreではどうしても無理だった(複数の本に共通するコメントが付けられないため)。逆に、DBを使えばできそうな気がした。

※これは、クラシック音楽の楽章(= 各トラック= 上記の「曲」)ごとでなく、曲(全部の楽章)全体に対して感想を書きたいからなのだが、良く考えると、アルバムには複数の曲が入っていることが多いから、アルバム全体に感想を付けるのも最適ではなく、任意の曲をまとめて扱える方がいいようだ。管理や操作が煩雑になりそうだが、DBを使うのであれば、アルバム全体の感想と同様に実現できる。ただ、そこまで凝らなくてもいい気もする。

実際に試してみたら、ちょっと苦労したもののできた。DBの「テーブル」というものを2つ作り、片方には曲(トラック)の、もう片方にはアルバムの情報を格納し、双方を結びつける情報(例: 「アルバムID」)を両方のテーブルに格納しておき、SQLでそれらを統合すればいい。図示するのが難しいが、統合の例として、トラック情報のテーブルアルバム情報のテーブルの中で同じアルバムIDを持つものを同じアルバムとし、同じアルバム中の各曲にアルバムのコメントを追加し、主要な情報だけを出力した場合を以下に示す。

両方のテーブルにアルバムID(図中の"album_id")を格納し、それを用いて同じアルバム中の曲を抽出できる※。アルバムID以外に双方で重複する情報は格納されていない。

※書いていて気付いたのだが、このデータ構造は、ある曲(トラック)が複数のアルバムに含まれることを想定していないので、もう少し検討が要りそうだ。やっぱり、アルバム単位での処理をしないほうが現実的なのかも知れない。

この処理のためのSQLは以下のようになった。

select t.title, a.album_artist, a.album_title, t.disc, t.track,
t.rating, a.album_comment, t.comment
from album a, trk_info_hist t
where t.album_id = a.album_id
order by t.album_id, a.album_title, disc, track;

DB BrowserのGUIは、機能は充分だが見た目や使い勝手は「まあまあ」で、calibreには劣る。が、この画面を使うのは管理とか保守の場合だけ(Spotifyの曲の検索画面は別途作る必要がある)と思われるから、これでいいのかも知れない。ただ、上に書いたように、実際にはアルバム全体のコメントは最適でないとか不要な気もして来たので、もう少し考えてみたい。

→ 考えたところ、以下のようにすれば良さそうだ。

  • 「演奏」ごとに「演奏ID」を割り当てる。
    • 演奏IDは同じ演奏なら同じ値にする。
      • 「同じ演奏」とは、例えばクラシック音楽なら一曲(全部の楽章)である。ポップ音楽の場合は曲ごとに別々にしたり、アルバム全体で一つにすることが考えられる。
  • 演奏IDの値は演奏ごとにユニーク(異なる)であれば何でも良い。
    • 例えば、一組の演奏を構成する曲(トラック)の最初の曲IDとする。
      • 今は、曲IDにはISRCを使おうとしている。
  • トラック情報テーブルで、曲ごとに演奏IDを格納する。
  • 演奏全体に対する感想などは、例えば、以下のいずれかのように格納する。
    • その演奏の最初のトラックに格納することにし、データ抽出時あるいは使用時に、それを演奏全体に対するものとして扱うようにする。: この場合、最初のトラックへの感想と全体への感想の区別ができない。
    • 「演奏テーブル」を作り、そこに演奏全体に対する感想などを格納するようにする。

上記の「演奏テーブル」を作らない場合のようにすればアルバム(または演奏)ごとの管理が不要にできるので、トラック情報テーブルだけで良くなる(「演奏テーブル」を作れば、より「正しく」かつデータ量の点で効率的になるが、管理が煩雑になる)。

なお、効率の点ではDB Browser(とsqlite3コマンド)を使うのが一番良かった。速度もデータサイズも最短・最小だった。ちなみに、calibreもBeetsも、内部ではSQLiteを使用している。calibreはデータサイズが大きく、速度も遅い。

DB BrowserでcalibreのDBを見てみたら、やたらにテーブルが多くて無駄に複雑な気がした。それでデータサイズが大きくなっているようだ。その点ではDB Browserを使うのがいい感じだ。ただ、calibreにもいい点はある(例: 機能が豊富: とはいえ、それが今回の用途には余り有効でない)ので、判断が難しい。

さらっと書いて来たが、題で触れたように、僕はDB(RDB= リレーショナルDB)やSQLが大嫌い・大の苦手で、ずっと避けて来た。というのは、RDBはセンスが悪い(≒ クソ)※と思うことと、SQLの構文がクソ(昔は全部大文字だったし、いつも、「"select"とか"where"とか何なんだ!」って思う)だからだ。仕事で必要な場合は仕方なく使ったが、自分から使おうと思ったことはない。しかし、さすがにDBが必要な・適する用途が出て来たので、使う羽目になりそうだ。

※大昔、RDBは表形式(Excelみたいな感じ)でデータを格納(正確には関連付ける?)することを最初に知った時、どうもおかしい(「は? そんなんでいいの? それが"DB"??」、「古臭い!」)し、分かりにくいと思った。一方、(近頃流行りらしいNoSQL DBの一つの)Key-Value型(あるいは連想配列)のデータ格納方式は分かりやすいから大好きで、昔から愛用していた(自分でも、何度も簡単な仕組みを作った)。だから、今だったらNoSQLなら馴染み易いのかも知れない(でも、実際に調べると訳の分からないことが多そうだ)w

更に全くの余談を書くと、その「大昔」に、いくつかの選択肢があった(確か、他はWordとExcelだったか・・・)中でRDB(製品名は全く分からない: dBase3?)を選ばなかったら、上記のような ほんの基礎的な知識すらなかったので、その時に「今までやったことがないから」選んだのは正解だったと言える。

それから、そもそも、これからSpotifyで新規の曲(演奏)をどのくらい再生するのかも気になっている。もうそれほど多くの新規の曲(演奏)がSpotifyに入らない・再生しないのであれば、手間を掛けて作る価値は少ない。ただ、Spotify用以外にも、自分の感想の記録にはなるから、その点では価値はありそうだ(その時には過去の記録を引っ張り出して転記する作業が必要で、それはそれで大変だし、自動化などできないw)。

  •   0
  •   0

キーボード(FILCO Majestouch BLACK Tenkeyless, FKBN91M/NFB2)の底にある滑り止めのゴムかそれを貼っている両面テープが劣化したようで、ベトついてきた。気付いたきっかけは、時々、机にベトベトした汚れが付いているのを見たことだった。最初(去年の今頃)は、机に塗り直したオイルが良く乾かずにムラになったのかと思ったが、そうではなかった。先日、ふとキーボードの底面を見たら、ゴムが埃だらけでベトベトになっていたので、劣化していることが分かった。

見ると、4つの脚全部が劣化しているのだが、どういう訳か手前がひどい。どうやら、ゴムでなくゴムを貼り付けている両面テープが劣化してベタベタな「何か」になり、手前側は面積が大きいので机に垂れたのだろうか。それで、このゴムを「何とか」することにした。ついでに、埃などでかなり汚れていたので清掃もすることにした。

劣化したゴムをどうするかだが、手前のものは、以前流しの樋を固定するために買った滑り止めに交換し、奥は、ゴムの上から剥がせるシールを貼った。清掃も含めて特に問題なく終わった。一番の問題は、両面テープのベトベトのタチが悪かったことだ。指にくっついたらなかなか取れず、気持ちが悪かった。

清掃してとても綺麗になった。しかし、滑り止めについては早くも問題が生じた。日記に書くため、手前に貼った滑り止めの材質を調べたら、ポリウレタン製だったのだ。これは、以前手直しした、経年劣化したバッグのコーティングの材質である。だから、いつか劣化する。ゴムでは両面テープが劣化したが、今度は滑り止め自体が劣化するので、更に好ましくない気がした。更に、奥のシールは貼ってすぐに剥がれてしまった。そもそも「剥がせる」シールだから当然ではある。

それで、手前と奥両方を、昔買って残っていた、机や椅子の脚の底部に貼って騒音や傷を防止するフェルトに交換した

この作業も簡単に終わった。ただ、奥は貼る場所(脚)のカーブがキツいため、フェルトがすぐに剥がれてしまったので、(ケーブルを束ねるのに良く使われている)ビニル被覆の針金で固定した。本当は細い結束バンドの方が強力で良さそうだが、手軽なので針金にした。そもそも、キーボードを持ち上げることは滅多にないから固定しなくてもいいとは思ったが、剥がれた粘着材に埃が付着したり、いつか外れて嫌な気分になるのが嫌なので、一応固定した。

作業後は、フェルトのせいでキーボードが軽く(スルッと)動くようになった。これは想定外だったのだが(滑るフェルトを貼ったので当然ではある)、僕は、とりたててキーボードの固定が必要な使い方をしていないし、食事とか作業の時などに頻繁に前後に動かすので、その時に滑れば机に傷を付けないから却って好都合なので、「結果オーライ」となった。

今回は良く考えずにテキトーに作業を始めたのでいろいろ想定外のことが起こったが、手軽に(その割には写真が多いが)うまく行ったので良しとするw

 

PS. キーボードの清掃後、キートップも劣化していることに気付いた。良く使うキー(A, S, D, Eなど)がひどい。まるで、お寺の凹んだ石段だ。汚れなのかも知れないが、擦っても全然取れないので、コーティング(しているのだろうか?)とかキートップ自体が削れたのかも知れない。まだ4年も使っていないのだが・・・ この辺りは、指の腹でなく爪の先で押すことが多いからなのかも知れない。

キートップも劣化していた。

このキーボードは文字がキートップでなく側面に印刷されているので、使い込んでも文字が削れてみにくくなったりしないから選んだのだが、こういう落とし穴があるとは思いも寄らなかった。まあ、それでも、いくら使い込んでも穴が開くとは思えないのでw、キーのスイッチが壊れるまでは問題なく使えそうだ。

そういえば、キートップとは関係ないが、このキーボードは、長期間(1か月くらい?)使い続けると誤動作するのか(Linux側の問題の可能性もある)、文字が勝手にリピートするようになる(ケーブルを抜いて挿し直すと直る)。定期的(あるいは、スリープからの復帰時など)にキーボードをリセットする処理ができないかと、今思った。

LinuxのUSBの機能を使い、スリープからの復帰時にキーボードをリセット(正確には、USBデバイスのdeauthorizeのあとにauthorizeして、キーボードを再登録する)するようにしてみた。数か月後に結果が分かるはずだ。ただし、この処理はUSBコネクタを抜くのと異なり、キーボードの電源が切れるかは不明なので、もし、キーボード側が異常動作しているのなら、効果がないかも知れない。 (13:03, 14:52)

  •   0
  •   0

Spotifyで何の気なしに(他のに飽きて)、プレイリスト「昭和歌謡」でも掛けようと思って、「まあ、どうせいつもの曲だろう」と思いつつも曲のリストを見たら、なんと、キャンディーズが入っていた。ちょっと驚いてアーティストのページを見たら、オリジナルアルバムがフルに入っている感じだ。

プレイリストへの登録日が"7 days ago"とあるので、1週間前くらいに入ったようだ。だが、4/30に聴いた時にダメ元で探しても出て来なかったのが不思議だった。ただ、ちょっと試したら、どうも探し方が悪かったようで、英語の綴り"Candies"では出ないようだ。なぜかキャンディーズを聴きたくなったことや、何かのニュースを読んだついでに「田中好子」を検索したのは、虫の知らせだったのか?w

考えてみると、田中の命日(4/21)が近かったからか、ニュースに出ていたのを読んで検索し※、命日に関連して(何かの区切りが付いた?)Spotifyにも追加されたような気がする。

※詳しい経緯を思い出した。「カフェテリアの甘い罠w」を書く時に「甘い罠」で検索したら、「春一番」について、「後奏のギターが間違って聞こえる」という内容が書かれたブログのページが見付かり、それを確認したくて聴きたくなったのだ。まったくの偶然に「誘惑の甘い罠」という節が浮かんだ(最初は誰の歌かも分からなかったので検索した → 実際には山口百恵だった)はずなのだが、本当に虫の知らせだったのかも?

そして、あの自民のちょっと苦境の大物政治家I氏も喜んでいるだろうか?w まあ、そもそもレコードを全部以上持っているだろうし、外で聴く時だってSpotifyなんて使ってないだろうから、関係ないな。

Spotifyも地道にレパートリーを増やしているようだ。これからも頑張って欲しい。ただ、もしやと思って吉幾三※や山口百恵や小泉今日子を探したが、やっぱり入っておらず、まだまだ頭が硬いか遅れている人(レーベル)は多いようだ。

※吉に関しては、なぜか、あるプレイリストに本人の曲が登録されているし、そこからアルバムにも行けるのだが、曲は再生不可の状態になっている。近いうちに入るのか、海外では再生できるのか、昔は入っていたけど配信を止めてしまったのだろうか。

 

PS. 懐かしいグループ 青い三角定規は、Spotifyの英語モードだと"Bluetriangle"と出て、(単なる直訳なのに、)かっこ良いうえに自然で、USのグループと言っても分からないくらいだ(実際、何かの曲一覧で見た時、「こんなグループあったっけ?」と思った)。便宜上付けられただけなのか、当時からそうだったのか、ちょっと気になる。 → 調べたら、当時のシングルのジャケットに"BLUE TRIANGLE"と書いてあるので、概ね元々そういう綴りだったようだ。ちょっと感心した(ただ、近年のベストCDにはローマ字で"A・O・I Sankakujohgi"と書いてあるのは、本人とは関係ないだろうが、頂けない)。

PS2. リンクを挙げた曲の入っているベスト盤(「GOLDEN☆ベスト キャンディーズ コンプリート・シングルコレクション」(2011))のジャケットは当時から嫌いだった。まず、"Candies"と書かれた文字がそうは読めない。次に、色柄が全然「らしくない」からである(こういうののほうがらしい)。が、まあ、僕は熱心なファンでないから、大した問題ではないw

  •   0
  •   0

伝統が大好きな日本の人たちは、なぜ、当たり前の顔をして太陽暦(グレゴリオ暦)を使っているのだろうか? 西暦の年号はキリスト教由来のものだ(から、それだけにするのはけしからん)と言うが、グレゴリオ暦だって日本のものではない。時間の基本的な単位だって、秒でいいのかどうか甚だ疑問だ。僕は歴史には詳しくないが、今の暦になったのは明治のようなので、まさかそれが日本古来の伝統だということはあるまい。ダブルスタンダードだ。

伝統を守るのであれば、年号同様、日付や時刻も世界標準と伝統的な暦(何にするかは勝手に決めて欲しい)を併記すればいいし、お役所は伝統的な暦で運用すればいいではないか。明六つ・暮六つとかやればいいのだ。今はデジタルだからいくらでもできる(かも知れない)し、伝統を守るんだから、不便に耐えるのは当たり前だよねw

でもまあ、考えてみると、大量の西洋文明が流入した明治起源のものを「伝統」と称している場合が多いから、彼ら的にはこれで筋が通っているのかも知れない。僕はとても不思議な気がするが。「伝統」と言うなら、やっぱり平安、せめて江戸ではないか?

もちろん、僕は世界標準の体系だけで充分だ。

 

PS. と書きつつ、この文章を日本語で書くのはダブルスタンダードかも知れないねw まあ、今はUnicodeのおかげで日本語の文字は世界標準に取り込まれているから、完全なガラパゴスとも言えないかな。本当にいいのは、全部の投稿を日英併記することだろう。仕事サイトではやっていたが、趣味だとなかなか・・・ 機械翻訳の精度がもっと上がれば楽になるけど、言葉遊びの類は難しいだろうな。

  •   0
  •   0

コンビニで金曜のコンサートの券3枚を受け取った帰りに、電気店に寄った。もちろん買いたいものなんてなくて、休憩と情報収集と人間観察wのためである。連休のせいなのかいつもなのか、閑散とした店内で、ふと電子ピアノが数台並んでいるのを見たら、

英雄ポロネーズ」を盛大に弾きたくなった!

完璧に弾き切って、何事もなかったように立ち去った

ら、きっと、カ・イ・カ・ンなんだろうなと思ったが、残念ながら、弾く腕も何も全くないことに気付いてしまったので通り過ぎたw

 

PS. 例として1番目にリンクを載せた浅野真弓という人の演奏(2016)が、僕の好きなルービンシュタインの演奏に通じるものがあって、かなり気に入った。スケルツォ(2016)は、力強い部分(ポロネーズもそうだが、力の入れ方と抜き方)がすごく気持ちいい。僕は、ここら辺の曲にはそれほど興味がないのだが、この演奏はいいと思った(強いて言えば、途中の「シュワーッ」となる箇所の発泡感が少し物足りない気はした: って、分かるかなぁ、分かんないだろうなぁ)。いい人を見付けた。僕にしては珍しく、どちら3回くらい聴いた。(繰り返し聴いたら多少のあらが見えたものの、)それほど良かった。まさに棚ボタだ。

PS2. 本来の収穫もあったw ホイールの回転にノッチがあるというのか、一定の角度で停まるマウスが増えて来たのだ。逆に、無段階のものが少なくなった気もする。これなら、今度マウスが壊れても、(直さなくても)買い換えれば良さそうだ。あと、メカニカルなのか、それなりに打鍵感のいいキーボードもあった。マウス同様、「ゲーミング」と書いてあったが、コンパクトなので、いざというときはいいかも知れない。ただ、どちらも安くはなかった(キーボードは1万円くらい)ので、買うなら通販かな。

  •   0
  •   1

郵便というと、あの西室とかいう、会社の甘い汁を吸いまくっては駄目にして渡り歩いていた上級国民ジジイの顔しか浮かばないのだが、今でもその文化が抜けていないようだ。

ゆうパックなどの配達を、宅急便のようにメールなどで事前通知するサービス(名前は調べたくもない)が発表された時は、「郵便も頑張ってるじゃん」とうれしくなり、サービス開始と同時に登録したのだが、その後、まったく使えないことが分かった。形だけは宅急便を真似しているが、それだけだった。最初に感じた(後述)、「無駄が多いサービス」以前に、このサービス自体が無駄だった。

(登録した時に無駄と思った話を書いた気がするのだが、ツイートだったようなので再度書く)

サービスに登録する時、webでの申し込み以外に、本人確認のために郵便が発送され、わざわざそれを自分で受け取らなくてはならなかった。気持ちは分かるが、ものすごい無駄だと思った。配達員の手間が増えるばかりだ(少しは彼らの気持ちを考えて欲しい)。もっと簡便な方法があるだろうに。例えば、ゆうびんIDはマイナンバーでの認証もできるのだから、少なくともそれが使えるではないか。

次に、そのサービスへの登録後最初にゆうパックが届く時、すっかり忘れていたのだが、通知がないことに気付いた。発送直後には来ないのかと思って翌日まで待ったが、全然なかった。登録漏れがあったかと思って調べたら、どうも通知先メールアドレスを登録する必要があるようだった(実際には、これは追加の通知先なのかも知れない)ので、登録した。ただ、そもそもゆうびんIDを作る時にメールアドレスを登録しているのだから、無指定ならそこに出すのが当然だし、サービス登録時に「通知先アドレスが未登録です」のような警告がなく、本人確認郵便で届いた紙には「これで使えます!」みたいなことが書いてあったのだから、全く納得できない。

それでも、「まあ、次は大丈夫だろう」と思っていたが、昨日、やっぱりゆうパックの通知が来なかった。全くおかしい。しかも、このサービスでできるはずの受け取り時間変更もできないと出たので、何かがおかしい(条件から外れている)ようだ。調べてみると、手書き伝票やこの通知に同意していない相手の場合などは通知が来ないらしいので、それのようだ(それ以上の情報がないので、実際のところは全く分からない)。ただ、発送者は2回ともヨドバシだったのだが、伝票はもちろん手書きではないし、ヨドバシが通知に同意しないとも思えないので、システム的な不備なのだろう。そのうち対応されるのかも知れない。でも、

もういい! 今後はあてにしないから。

もちろん、サポートの問い合わせなんてしない。徒労なだけなことが分かり切っているので。そもそも、手書き伝票に対応してなかったら、個人間のゆうパックなんてほとんど対象外ではないか? 宛先が読み取れなくて処理できないのだろうが、郵便(葉書や封書)はちゃんとやっているではないか。「システムが違うので統合(流用)できない」とか言われそうだが、それをやらなかなったら単なる手抜きだよ。すぐにできなくてもいいから、とりあえず予定を示さないと、使う側にはがっかり感やイライラしか残らない。

そこの技術系社員(もし居るのなら)は、上から言われたものを、大金掛けて丸投げして何かでっちあげればいい(しかも、細かい手間は全部現場に押し付ければOK!)、簡単なお仕事のようだw

 

PS. 結局、今も、以前作った問い合わせ番号から配達状況を表示するプログラムを改良したものを使っている。こっちの方がずっと便利だ。そのプログラムを使うと、以下のような感じで最新の状況が出るので、受け取り準備が多少できる。

$ ./bin/check-post3.sh 1234567890XX
05:52:59: 2019/04/27 02:58 到着; 配達予定日:4月27日
08:43:04: 2019/04/27 持ち出し中;

PS2. こんなにひどい状況なのに、ニュースや掲示板などで文句を見ないというのは、誰も知らなくて使われていないのか、僕とかヨドバシだけ何かおかしいのか? 謎だ。

 

(19:02 題とその他を少し変更・追加)

  •   3
  •   1

(前にも書いた気もするが、広告を見て気付いたから暇つぶしに)

デジタル音楽プレーヤーやDACユニットで、DACチップの複数の出力チャネルをまとめることで音質向上をうたう製品が多いが(↓例)、

L/Rにそれぞれ1基ずつを割り当て、8chをフルに使ったD/A変換により正確なサウンドを出力できる。

本当にそうかな?

そもそも、上の例文の「正確なサウンド」って何だ? DACの出力の正確性は、DACチップの精度とLPFと出力部の性能で決まるはずだ。この場合、DACチップの出力をまとめているので、LPF以降は関係なく、DACチップの出力の精度を向上させると言っているのだろう。

だけど、DACチップの出力の精度を向上させるとしたら、高精度なチップを使うのが適切だし、そもそも、今のチップなら大抵のものは家庭用には充分過ぎる精度だろう。重要なのはLPF以降のアナログ回路だ。正確なサウンドを出力したいなら、高精度なDACの出力をそのまま外に出すことに注力すべきで、チップの出力をまとめてどうこうするのは苦肉の策みたいなもので、売りにするのはナンセンスだと思う。

上の例だと8本もの出力を1つにまとめている(= 加算している)ようだ※。確かに、複数の信号を加算(平均)すれば雑音は減るが、DACチップの出力チャネル間の時間差は無視していいのだろうか。こういうのにこだわる人は、nsとかpsオーダーでクロック精度を追求していると思うが、果たしてDACチップの各出力はそこまで合っているだろうか? 厳密に合っていなければ、折角のクロック精度(に意味があるかは知らないがw)が台無しになるし、微妙な時間差のために波形が鈍るだろうから、例えば、高域が劣化したり位相特性が悪化したりするだろう。オーディオ的表現では、音の「鮮度」や「立ち上がりの鋭さ」が減るはずだ*。

※そもそも、複数チャネルをまとめる理由は何だろうか。変換誤差を減らすため? とは言っても、もともと、オーディオ用DACは例え32ビット品でも20ビット前後(高々24ビット)程度の精度しかない(しかも、出力段ではもっと雑音が増える)から、いくらまとめたって有意に変換誤差は減らないだろう。

2つのチャネルを合わせた時にどの程度雑音が減るかは忘れたが、仮に、雑音が1/2になって精度が1ビット相当増えると仮定したら、8本合わせても3ビットしか向上しない。24ビットを32ビット相当にするには全く足りない。

そもそも、音源(曲)がそこまで低雑音だとも思えないし、20ビットの最下位ですら、一般家庭では(普通の音量で)再生しても聞こえないだろう。意図が分からない。

*実際には、DACとLPF・出力アンプの間にはホールド回路があるはずなので(LPFで兼ねているのかも知れないし、(DACの特性を信じて)ないかも知れないが、詳しくは分からない)、チャネル間の時間差は吸収される可能性があるから、最初に問題にした時間差による音質の劣化はなくなる。この場合、複数出力を合わせる意味は、もともと精度がおかしいチャネルを多数決で隠すことと雑音の低減になる。前者は検査で落とすべきものだから、結局は雑音だけだろう。その場合でも下記の逆流の問題はあるだろう。

それから、仮に出力チャネル間の時間差が全くないとしても、各出力チャネルの電圧(または電流)に微妙な差があるだろうから、その影響が出そうだ。例えば、高いチャネルから低い方に電流が逆流して歪が増えるかも知れない(ここは良く分からない)。

整理すると、複数チャネルをまとめた時のメリット・デメリット(いずれも量は無視している)は、以下のように推測できる。

  • メリット
    • 雑音がわずかに減る可能性がある。
    • (精度が悪いチャネルの影響を多数決で減らせる。)
  • デメリット
    • チャネル間に電位差が生じ、歪みが生じる可能性がある。
    • DACとLPF・出力アンプの間にホールド回路がない時、チャネル間に時間ズレが生じ、
      • 高精度なクロックを使っている場合は無駄になる。
      • 周波数・位相特性が悪化する可能性がある。

まあ、いずれにしても、聴感上は何も変わらない気はする。単に無駄なだけだろうから、どうでもいいw いや、もしかしたら、上記の時間差のために音がわずかに良く聴こえるかも知れない(例: オーケストラの多数のバイオリンの音が厚くなること)。だから、「音の厚み・深みが増した」とかいうレビューが出るかも知れない。でも、それは自分が高いお金を掛けて求めていた方向とは真逆で、言ってみれば棚ボタ的な結果のはずだ。

  •   0
  •   0