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

夏が来た!
夏が来た!

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

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、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の考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

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

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 見にくいので、訂正前の取り消し線の部分などを削除し、補足を追加した。)

先日書いたspicetify-cliのCSSを改造して できるようにした。結局、Spotifyアプリの実体はHTMLで、元々はコピーできるのだが、なぜか無効にしていたので、それを再度有効にすればいいだけの話だった。

こういうことは今までにも何度も見た(例: Webで右クリック禁止)が、全くクソ馬鹿野郎だと思う。考えが浅はかだ。そうやってユーザーの利便性を落として、どういう意味・価値があるのか。そんなに自分の財産を保護したいなら、公開せずに後生大事に金庫にでも保存していればいいのに! もし意識せずにそうなったのなら、もっと低レベルだ。

文学作品だったら少しは分かるが、単なる技術的とか豆知識とかの類でコピペ禁止にしたって、嫌がらせ以外に何の意味もないよ。

文学作品や歌詞だって、データをコピーするのはユーザーの自由で、それを合法的に使うのには何の問題もないのに、最初から疑ってできないようにするのは ちょっと違うと思う。

CSSは得意でないので結構苦労したが、基本的には、CSS中でコピーしたい要素の user-select プロパティを text などに変更すれば良い。

苦労したのは、以前の版(現行もそうかも)のSpotifyアプリのCSSがぐちゃくちゃで、同じような要素が別のクラスになっているので、「探しては設定する」を何度も繰り返した(そこまでする必要はなかったが、ついムキになったｗ)。

参考までに、以下に、以前の版(1:1.1.68.632.g2b11de83)のSpotifyアプリに対するspicetify-cli(1.2.1)のデフォルトのテーマ(SpicetifyDefault)の改造版のuser.cssへの追加分を載せる。ただし、他にもいろいろ変更しているので、これだけではうまく行かないかも知れないし、残った(コピーできない)部分があるかも知れない。でも、基本的なアイデアはこれだけ(コードは長く見えるが、主要部分は下から2行目のたった1行だけ)だ。

/* Make texts selectable.: Butty */
/* Not effective/useful in some part (eg. tracks in track list). 
  Because, possibly, the draggable attribute is set by JS.: TODO */
[draggable] {
  user-select: unset;
}

#document, /* Not enough: Reset later by JS. */
/* For playlist page. */
.glue-page-header__content-inner, 
.playlist-content,
/* For album page. */
.Header__content, 
.AlbumRoot__content .glue-page-wrapper,
/* Sidebar and player control (bottom). */
.LeftSidebar, .view-player, 
/* Others. */
.tracklist-album, .tracklist-chart, .tracklist-basic, .tracklist-playlist, 
  .tracklist-podcast, .tracklist-popular, .tracklist-station, .tracklist-queue, .tracklist-search,
.HomeRoot, .MadeForYouRoot, 
.RadioHubRoot, .RecentlyPlayedPage,
.App__description, .app-content, .App__content, .App,
/* For credits. */
.CreditsModalContent
{
  user-select: text;
}

これで、マウスのドラッグやCtrl-Aで以下のようにテキストが選択でき、当然ながらCtrl-Cでクリップボードにコピーできるようになった。

Spotifyアプリからテキストをコピーできるようにした。(全選択した状態)

なお、サイドバーと下部のプレイヤー制御部が選択されていないが、別の要素のためのようで、どちらかの部分でCtrl-Aを押すと選択できる。

なお、思い付き+勢いでやってみたため、ちょっと不便なことがある。ボタンなどの余計なテキストも選択され、また、曲一覧の部分では思った部分がなかなかマウスで選択できず、特定の曲の選択が難しいのだ。これはHTMLの作り(JSで設定されたdraggable属性はCSSでは解除できない)と僕の未熟さのせいで、基本的にはちゃんとできるはずだ。

あと、全然見ない(ので忘れて居た)のと、一応 日本での取り扱い状況を尊重して、歌詞をコピーできるようにはしていない。

実際に使うか使わないかは別として、「(クソみたいな制限なんてせず、)できるものはできるままにしておく」ってのが僕の主義なので やってみた。

昔に比べていろいろ改悪された、現行版Spotifyアプリ(Linux版)。かなり嫌なのは、再生中にアイコン(以下、再生中アイコン)が ちらちら動き続けて目障りなことだ(→ 画像: 1曲目の緑の棒グラフのようなアイコン)。たまたま今日 アプリが更新されたので試したが、やっぱり変わっていなかった。それで、以前どこかのページで知った情報を思い出して、無理矢理アイコンを換えられないものかと試したらできた。

試したアプリのバージョンは、 1:1.1.68.632.g2b11de83 である。※

※アプリでは出せないので、 aptitude show spotify-client コマンドで表示した。

概要(ポイント)は以下のとおり。

• SpotifyアプリのUIは /usr/share/spotify/Apps/xpui.spa (以下、UIファイル)の中に入っている。
• 再生中アイコンはUIファイルの中の images/equaliser-animated-green.gif で、24x24pxのアニメGIF
• UIファイル(xpui.spa)はZIPファイルなので、問題のアイコンのファイルを交換して作り直せば良い。

再生中アイコンを置換する手順の例は以下のとおり。

1. UIファイル(/usr/share/spotify/Apps/xpui.spa)を展開する。
   1. cd ~/tmp
   2. mkdir -p sp-xpui-work/xpui
   3. cd sp-xpui-work
   4. ln -s /usr/share/spotify/Apps/xpui.spa xpui.zip
   5. cd xpui
   6. unzip ../xpui.zip
2. 展開したディレクトリ中の再生中アイコン images/equaliser-animated-green.gif を適当なものに交換する。
   • 条件: ファイル名はequaliser-animated-green.gif, GIF形式, 24x24pxであること。
     • ファイル形式はPNGでもいいかも知れないが、SVGは駄目だった。
   • アプリに合わせて、背景は暗く(黒系)、描画色は白などが良い。
3. 新しいUIファイルを作る。
   1. zip -r ../xpui-new.zip *
4. 新しいUIファイルを/usr/share/spotify/Apps/に置く。
   1. cd /usr/share/spotify/Apps
   2. sudo mv -i xpui.spa{,.orig}
   3. sudo cp -i ~/tmp/sp-xpui-work/xpui-new.zip xpui.spa

アイコンは既存のものでも構わないが、GIFで背景が暗い、丁度良いものがすぐには見付からなかったので、gimpで文字"♪"(サイズ: 22pxくらい)でテキトーに作った。

面倒なのは、アプリが更新されるたびにアイコン置換作業をしなくてはならないことだが、自動化できそうだ。

この手順(以前のアプリでも同様)でUIをいろいろ改造できそうだが、まだ良く見ていない。 → ちょっと見たら、JSは判読困難なので改造は難しそうだが、CSSなら何とかできるかも知れない。: 例えば、緑で気に入らない再生中の曲の文字の色を変えるのはできるかも。 → 思い付いた。標準の色遣い(テーマ)が暗くて嫌いなので、つい、ライトテーマを作りたくなるが、まあ、それは やり過ぎってものだｗ (9/23 11:33)

「やり過ぎ」と書きつつも調べたら、(Linux版)SpotifyアプリのUIは(以前の予想どおり)基本的にブラウザ版と同じようで、ブラウザのWeb Developer Toolsを使えば、下のように(難読化を解除して)要素が調べられ、ちょっと変えて試すことができそうだ。 (9/23 11:52)

ブラウザ版で再生中アイコンの元(URL)を調べた。

→ (9/24 15:37) 「ちょっと」試したが、挫けた。UIファイル(xpui.spa)中のCSS(xpui.css, vendor-xpui.css)の色を変えて明るくしてみたら、(テキトーにやった割には)結構うまく行き、これなら(もっとちゃんとやれば)行けそうだと思ったのだが、表示内容(例: Daily Mix)によってはウインドウ(曲リスト)の半分だけ暗くなってしまった。

更に調べたら、JS(xpui.js, vendor-xpui.js)の中でも色を設定していた。しかも、(難読化のせいかも知れないが、)同じ色の値が何度何度も書いてあって、なんとも腐っているサイコーなこと・・・ 素人かな? まあ、ツールで作ったりすると良くありそうな感じだが、なかなか付き合い切れない。

ただ、明るいテーマは なかなか爽やかで僕好みで捨て難い。が、苦労して色を変えても、アプリの更新で お釈迦になる可能性が高いので、あるアプリなりウインドウの色を実行時に変えるようなプログラムで色を変えたいが、そういうものはあるのだろうか?

↑ 色をグラデーションにしているので、単純な色の置換(LUT)では無理そうだ。 (9/24 17:33)

→ (9/24 19:17-9/25 12:30) 更に調べていたら、spicetify-cliというプログラムでテーマを変更できることが分かった。想像だが、これは上で僕がやったようにSpotifyのUIを展開して改造し、容易にカスタマイズできるようにているのだろう。デフォルトは(今は なき)GPMに似ていて懐かしい。

それで早速、僕のデスクトップのテーマ(Mint-X-Sand)に近付けてみた(spicetifyの古い版(1.2.1)は以前のSpotifyに対応しているので、そっちに適用した)。調整が不充分で見にくい箇所があるのと、ちょっと素っ気ないが(→ 調整し、テーマ(CSS)にも手を入れて随分改良した)、暗いよりずっといい。このプログラムは使い方のドキュメントが少ないが、いろいろ使えそうだ。

(9/26 7:09) 確かにspicetifyは使えるんだけど、Spotify同様なかなか余計なことをしてくれる。デフォルトはSpotifyのテーマを明るくするだけでいいのに、作者の好みで いろいろ変えてしまって(余程GPMに近くしたかったのか?: 個人的には、細かいところが「これは ないだろう」レベル)、それを戻すのに苦労した。まあ、苦手・嫌いなCSSの勉強(というか 付け焼き)には なったかなｗ

アイコンの交換は成功したものの、現行版には移らない。これはまあ、ちょっと思い付いたからやった、暇つぶしのお遊びだｗ

というのは、確かに以前は効かなかった、前・後ページのショートカットキー(Alt+←/→)が前の版で直ったが、依然として検索などで日本語が入力できないし(これは古い版でも同様)、左ペインでプレイリスト一覧がごちゃついているのが気に入らないからだ。それらが直ればいいが、まあ無理だろう。他に良くない点(例: 音が悪い)がなければ、百歩譲ってそれらを我慢して移行するのもありかも知れない。が、特にいいことはなさそうなので、古い版が動かなくなってからでも良さそうだからだ。

(9/23 5:12 画像を改良, わずかに加筆・修正, 9/23 9:48 わずかに加筆・修正, 9/23 11:33, 11:52 少し加筆, 9/23 16:07 PSに加筆して まとめとした。)

昨日、Linuxのメモリ消費が多くなって来たので※再起動したら、青天の霹靂。なぜかSpotifyアプリが激変してしまった。

※いろいろなアプリがメモリリークしていて、長期間動かすとそれが溜まるせいだと思う。

今考えると、おそらく少し前にアプリが更新されていた※のだが、アプリを再起動していなかったので更新が反映されなかったのではないかと思う。そういえば、3月末辺りに"Made for you"が変わったのは、これの関係だったのかも知れない。その変更の時は、「なかなか良くなった」と喜んでいたのだが・・・

※問題のバージョンは1:1.1.55.498.gf9a83c60

少しいじっただけで、以下のような違いに気付いた。

• なくなったショートカットキーがある。
  • 例: 前・後ページ(表示内容)への移動 (Alt+←, Alt+→)
• 設定のAboutがなくなったので、バージョンが表示できない。
  • 細かいことだけど、「どうよ」と思う。
  • 前の版に戻して(後述)気付いたのだが、実はAboutはあったけど気が動転して気付かなかったのかも知れない。
• ライブラリにMade for youのタブがなくなった。 → Homeから表示しろってことだろうか。
• 画面のデザインが煩雑になってしまった。
  • Web版に近い気がする。
• 起動時にdevilspieでの位置指定が効かない。
  • 起動後は効くので、起動時のアプリ名が変わったのだろうか?

ショートカットキーがなくなったのは とても不便だ。今までは、マウスジェスチャ(右クリック+左/右ドラッグにAlt+←/→を割り当てた)でページ切り替えしていたのができなくなってしまった。

すごく不便なので、何とか対処したいが できないだろうか? xdotoolで試したが、それらのショートカットキーの対応自体がなくなった感じだ。

デザインはまさに劣化と感じる。その劣化度は、以前のがどうだったか思い出せないくらい強烈だ。。。 一番嫌なのは、再生中の曲の左のアイコンがちょろちょろ動くことだ(画像の黄色い円の中)。ひょっとしてアニメGIF? 90年代じゃねーんだよ!! そもそも、ページに画像や色が無駄に多くて全く鬱陶しい!!! 鬱陶しいので余り表示させたくない。

以前のが簡素過ぎたのかも知れないが、目障りでない点ではずっと良かった。

それで、試しに(、デザインがどうだかは分からないが、)Winodws版アプリをWineで動かそうとしたら、「管理者アカウントではインストールできない」というエラーとなって、諦めた。。。

不思議なのは、この劣化を検索しても出て来ないことで、誰も気付いていないのか、多くの人は新しいデザインが好きなのか、Linux版を使っている人がすごく少ないのか、僕の環境がおかしいかのどれかだ。

想像だが、Linux版のメンテが面倒になって、UIに関しては基本的にweb版を表示するようにして手を抜こうと思ったか、逆に、下手に頑張っちゃってLinux版をWindows版に寄せたか共通化してしまったのかも知れない。

今はまだ耐えられるけど、更にLinux版の手抜きが進んで、消滅(Evernoteのように「Web版を使ってね!」)という憂き目になったら すごく困るな・・・ その時はまた「移動」かも知れないな。もちろん、行く先があればだが・・・

↓

とりあえず、(クソな状態で使いたくないが、そんなのに対応するのは時間の無駄だし そんなパワーもないので、)アプリを前の版に戻したら(コマンド例は下記)、当然ながら元の表示・動作になった。ただ、いつか使えなくなりそうだ。

sudo aptitude install \
spotify-client=1:1.1.42.622.gbd112320-37

Spotifyアプリを前の版に戻して、平和が戻った。

即座に更新マネージャが更新の案内を出したが 「無視」にして、しばらくは これで お茶を濁そう＾＾

年末の風物詩?、Spotifyから今年のまとめ、「音楽で1年を振り返ろう。」が届いた。残念ながら去年より簡素になってしまって、去年は自分用のwebページに華々しく記録が書かれていたのだが、今年はちょっと賑やかなメールだけになり、送られて来る記録的な内容は聴いた(掛けた)時間(62,262分 → 約2.8時間/日)だけで曲数(延べもユニークも)は分からない。他には各自のプレイリスト"Your Top Songs 2020"で順位を参照できるだけになった。その順位が何に基づくのか(例: 再生回数)も分からない。: (Amazonだけでなく、)Spotifyも作っている人が変わったのか、経営状態が良くないのか。

まあ、そういうこともあろうと(でもないが)、僕にはMlhiという自作の再生履歴記録システムがあるので、履歴は ばっちり記録されている。その活用については下に書く。

Spotifyによれば、今年最も再生した曲は、意外にもポールとスティーヴィー・ワンダーの"Ebony and Ivory" (1982)だった。確かに良く掛かっていた気はするし、嫌いな歌ではない。ちなみに、マイケルとの"Say say say" (1983)も好きだが(当時は嫌いだったｗ)、なぜか10位以内には入っていなかった。参考までに5位までを載せる。それぞれに、Mlhiで調べた再生回数(後述)も示した。

1. Ebony and Ivory (Paul McCartney & Stevie Wonder, 1982)
   • 全96回 (2020年: 79回)
2. My love (Wings, 1973)
   • 全85回 (2020年: 74回)
3. Band on the run (Wings, 1973)
   • 全78回 (2020年: 72回)
4. Jet (Wings, 1974)
   • 全73回 (2020年: 70回)
5. Maybe I’m amazed (Paul McCartney, 1970)
   • 全72回 (2020年: 69回)

と、まあ、見事なほど「ポール一色」だ。いや、嫌いじゃないけど大好きって訳でもないんだが・・・ なお、10位までには、他にELOとBad fingerしか入っていない。ビートルズはどうしたんだろうか??

それから、去年はどうだったかというと(去年のブログの画像より)、

1. The power of love (Huey Lewis & the News, 1985)
2. 初恋 (村下孝蔵, 1983)
3. More than a feeling (Boston, 1976)
4. 夏をあきらめて (研ナオコ, 1982)
5. Mr. サマータイム (サーカス, 1978)

全然違う。。。 気付いていなかったが、今年は去年から10年くらい過去にさかのぼって70年代がメインだったようだ。あと、去年はなぜか、熱・暑(苦し)そうｗとか夏っぽい歌を良く聴いていたようだ。

もちろん、ここまででは終わらないｗ 今年のプレイリスト(順位)を見ていて、再生回数の順位なのか順不同なのか分からなかった(プレイリストに再生回数が出ていない)ので、Mlhiで調べてみた。Mlhiのwebで検索したりDBにアクセスすれば再生回数は簡単に出るが、「最初」からの回数なので、今年の分は手で計算した。すると、概ねSpotifyの順位に合っていたので、Spotifyは再生回数でソートしたようだ。

ところで、調べていて、妙なことがいくつかあった。

"Ebony and Ivory"はMlhiには2つの曲(演奏)が入っていて、Spotifyのリストに載っていた演奏は全44回だが、もう一つ(SpotifyのIDが異なる)は全52回だった。※ なので、Spotifyはどうにかして「実質的に同じ演奏」を統合してカウントしているようだ。

※なお、それらは異なるアルバム(オリジナルとベスト盤)に入っており、リマスタリングしたせいか、ISRCも異なっている。また、Spotifyのリストはベスト盤のを載せていた。

"Maybe I’m amazed"は、最初はMlhi(webもDBも)では検索できなかった。いろいろ試すと、 ' の文字が違うためだった。分かるかどうか分からないが、 ' には開き、閉じ、垂直なものの3つがあり、この曲の表記(閉じ?)とキーボードから入る文字(垂直)が異なるために検索に出てこなかったのだ(曲名をSpotifyからコピー・ペーストしたら出て来た)。他には " も同様だし、Unicode全体だともっと多そうで、結構深そうな問題だ。

そう言えば、論外な話だが、日本語の曲名の濁点を " にしてしまって、「眼(まなこ)はタ"イアモント"」(あくまでも仮の例)のように出る、残念な曲もあった(それだけでなく、カタカナを半角にしていた気もする・・・ ← 別の曲だったかも知れない)。日本のレーベルが配信に出す時にテキトーに打ち込んでしまったのか(さすがにないか)、そのレーベルが元々そういう残念な管理なのか、そして、(書いたあとで気付いたのだが、)半角カタカナを全角に直した名残りなのか。いずれにしても、これでは全然検索できない・・・

余談だが、こういうのは日本だけかというと実はそうでもなさそうで、海外ではdiacritical mark(ウムラウトなど)の表記方法(特に、別の文字で代替する場合)もいろいろあるようで、そこで問題になりそうだ。

更に謎なのは、10位だった"Listen to what the man said" (Wings, 1975)はMlhiのwebでは検索できなかった。確かにDBには入っているのだが。いろいろ調べると、どうやら、近頃Spotifyの演奏が新しい版に入れ替わったためのようで、Spotifyの検索をしないようにしたら出て来た。

DBに入っているものと2020年のリストに入っているのは"Listen To What The Man Said - 1993 Digital Remaster" (ISRC:GBCCS0700283)だが、今Spotifyで検索して出て来るのは"Listen To What The Man Said - Remastered 2014" (ISRC:GBCCS1400011)である。

音楽配信はダイナミックに中身が変わることの典型だろうが、これも意外に深そうだ。再生すると確かに同じ曲が演奏されるが、以前聴いたものとは違う版だということが起こる。この曲は以前の版も残っているが、完全に置換されてなくなっているものもあるだろう。そこにこだわるマニアは、CDなどを買って それぞれの版を手元に残す必要が出て来る(が、僕はもういい)。

ついでに、Mlhi全体、つまり、Spotifyとgmusicbrowser(以下GMB)を合わせた順位を調べてみた。これもDBで簡単に出せる。ただし、記録フォーマットの関係で今年だけの分を抽出するのは面倒なので、「最初」から(Spotifyは2019年から、GMBは2016年から)にした。また、テストで何度も少し掛けた曲があるので、再生回数でなく、完奏率×再生回数(→ 「好き度」みたいなもの? または、何度掛けても途中で止めなかった → 気に障らなさ → 当たり障りのなさ?= 「ポップ度」??)で順位を付けた。それぞれの曲名の下の数字は完奏率×再生回数である。

1. My love (Wings, 1973)
   • Spofity, 86.0
2. Come together (The Beatles, 1969)
   • GMB, 85.8
3. Band on the run (Wings, 1973)
   • Spofity, 75.15
4. Here comes the sun (The Beatles, 1969)
   • GMB, 74.7
5. Piano concerto No.2 in C minor Op.18 : III Allegro scherzando (Lugansky, 2005)
   • GMB, 74.45

やっぱり、意外なほどポールが強いｗ そして、ビートルズはGMBで聴くことが多かったようだ。また、大好きなルガンスキーのラフマニノフのピアノ協奏曲もGMBで聴いている。

参考までに、上の順位は以下のようなSQLで出した。

select track_id, title, artist, album, 
  played_full_tot, played_full_tot/played_cnt, played_cnt 
from trk_info_hist
where played_full_tot is not null
  and played_full_tot <= played_cnt
order by played_full_tot DESC limit 0,20;

再生履歴をDBに記録しておくと、(趣味的に)おもしろく便利だ。一方で、「年ごとの順位を手軽に出したい」といったようないろいろな要望や思わぬバグも出て来て、なかなか先は長い。 (でも、記録していることに安心して、なかなか手を付けないｗ)

PS. MlhiのDBに登録された曲は8千曲近くなった(去年の中頃から記録し始めたため、去年の今頃は4500曲だった)。DBのサイズも大きくなって、約5MBになった。それでも、まだまだ小さいうちだから問題なさそうだ。

夕方にSpotifyが時々音切れして直らないので、アプリを再起動したら、なぜか、SpotifyのDaily mixが様変わりして、今までは1-6までプレイリストがあったのに、アーティスト名のものだけになっていた(参考: 昔の状態)。そういえば、今朝辺りから やたらにビートルズが掛かっていたのは、それだったのか。

まあ、それに気づかず「Spotifyも僕の好みが分かってきたじゃん」と思って居たから結果的にはいいけどｗ、なくなってしまうと寂しいし、アーティストのプレイリストは今までの数字のものとは全然違うものだから困る。

Androidアプリでも同様だったので、システムのトラブルか仕様変更か。ただ、検索しても誰もそれに触れていないようなので、僕だけの問題なのかも知れない。

もう少し様子を見よう・・・

なぜか、SpotifyのDaily mixが様変わりして、アーティスト名のプレイリスト(mix)だけになってしまった。

↓

(12/3 8:42) 実は、Daily mixの名前の付け方が変わっただけなのかも知れない。つまり、今までは"Daily Mix 1"という番号の名前だったのを、"Queen Mix"のように、そのmix(プレイリスト)のメインとなるアーティスト(大抵は最初の曲のアーティスト)を名前にすることにしたのか。※ それなら、僕の選び方(最初の数曲で「グッ」と来るか)に合っているから歓迎だが、本当にそうなのか(何となく、名前の付いたアーティストに偏っている気がする)。プレイリストとは別に、各アーティストや曲などでのラジオ(例: "Queen Radio")もあるので ややこしい・・・

※Spotifyの説明には、今も、「最大6個できる」とあり、確かにアーティスト名のプレイリストは6個ある。

なお、元々の音切れも原因が分からないが、通信速度を測ったら変動が大きいことがあったのと、今は直っているので、たまたまネットが混んでいたのかも知れない。

気付いたら、Spotifyのクラシック音楽のDaily mixのひとつが、ほとんど「春の祭典」、「展覧会の絵」、「パガニーニの主題による狂詩曲」の中の曲ばかりになっていた。

Spotifyのクラシック音楽のDaily mixの選曲が偏っている・・・

たしかにどれも好きだが、ここまで続けられると飽きるし、それぞれの曲は繋がっているからバラバラにされては困るし、ジュースじゃないのでミックスされるのも困る。

今気付いたが、その原因は、それらの曲はどれも短い曲・楽章・変奏が集まって一つになっており、当然ながら、僕はそれぞれの曲をいつも通して聴き、いろいろな演奏者のを取っ替え引っ替え聴き、しかも、好きな演奏の各小曲に♥(Like)を付けているので、僕がそこら辺を「すごく好き」とみなされて、このように推奨されている気がして来た。うむ。

そして、SpotifyはGoogleとかじゃないので、ここら辺のAI的な処理があまり賢くないのだろう。まあ許せる。

ルーティンワークｗでCeronの新着ニュースを見ていたら、「小泉今日子、全104タイトルのべ726曲が一斉サブスク解禁（コメントあり） - 音楽ナタリー」というのが目に入り、早速Spotifyをチェックしたら確かに入っていた。

ようやく小泉今日子の曲がSpotifyに入った。

でも、まあ、特に急いで聴きたい曲はないから、入っているのを見て「ふーん」と思っただけだが、少しして、折角だから とりあえず聴いてみようと思い、最新のベスト「コイズミクロニクル ~コンプリートシングルベスト1982-2017~」(2017)を試している。

演奏や音じゃないからいいけど、これのジャケットは「なんだかなあ・・・」である。この、昔の(ビットマップを改造して作った)ようなフォントは一体??※ どういう味を出したかったのか? あと、配信の画像では細かい文字が見えない。。。

※全くの余談だが、昔(1990年代前半)、LaTeXという文書整形システムを使っていたのだが、それに使えるフリーの日本語フォントがほとんどなく、X Window Systemの日本語ビットマップフォントを加工して使っていたことがある。今みたいに拡大・縮小自由自在のベクターフォントじゃないので、その字形は線が細かったり太かったり、線の横にドットがギザギザと出ていたりで、なかなかひどいものだった。偶然だとは思うが、ジャケットの「小泉今日子」の文字は、そのフォントにそっくりなのだ。

最初のほうの曲目は手持ちのベスト(「ザ・ベスト」(1986))と同じなので目新しくはないものの、やっぱり懐かしい。僕は、「まっ赤な女の子」(1983)辺りからリアルタイムに聞いていた気がする。と言っても、その頃はまだTVなどでちょっと聞く程度だった。なぜか力を入れ出したのは、何度か書いている"Today's girl"(1985)からだった。

このベストには、シングル(B面?)だけとか別名義で出した曲(例: あんみつ姫 「クライマックス御一緒に」(1984))も入っているから、手持ちになかった曲も聴けていい。

(ここまでの時点では)「渚のはいから人魚」(1984)、「渚のはいから人魚」(1984)、「迷宮のアンドローラ」(1984)、「ヤマトナデシコ七変化」(1984)、"The Stardust Memory"(1985)なんて、つい乗ってしまった・・・ (ほとんど全部だｗｗｗ)

余談: 「ヤマトナデシコ−」だと思ったが、たまたま観たTVの歌番組で、あんみつ姫の格好で歌ったのだが、お笑いの人(東八郎?)が一緒におかしく(茶化しっぽく)踊っていたので、最後に彼女がちょっと切れて「バカヤロー」って言ってたのを思い出す。その動画、あるかなあ・・・

そして、以前書いた山口百恵と違って、数百曲のうち聴きたいのは数曲ってことはなく、数十曲はありそうだ＾＾ うむ、そうだったか。

少し音質の話を書くと、聴き出した時から、なんとなく音質が違う(良い)気がして、リマスタリングしたのかと思い、調べたら本当にそうだった。手持ちに比べて細かい音もちゃんと聞こえるが、(特に海外に)良くあるリマスター版のように、低音や高音を出し過ぎて「いかにもいい音」にしていないのが好感が持てる。こういう真っ当なリマスターなら許せる。いったい、どうすれば こうできるのか、ちょっと不思議ではある。ビクターの(この盤を担当した)エンジニアは腕がいいのかも知れない。

例えば、「半分少女」(1983)は、高域はもちろん低域もいい感じになっている。"The Stardust Memory"は右の電子(電気)ピアノと思われる音が違う(より忠実な感じ)。「ハートブレイカー」(1985)は低域が豊かになり、全体的な迫力も増えている。「なんてったってアイドル」(1985)は高音(シンバルなど)が ちゃんと聞こえる(切れ味が鋭いが、うるさくない)。