Archive for the ‘Linux’ Category

その後もSpotifyに飽きることはなく、Google Play Music (GPM)の支払いの継続を止めたので、移行済みとなった。前回も書いたが、あれからも手持ちの曲は掛けていない。連続2週間になる。ビートルズなんて手持ちで聴けるのに、わざわざSpotifyのプレイリストで聴いたりしたこともあった。GPMとは違って、なぜかは分からないが、随分居心地がいいようだ。個人用のリコメンド("Your Daily Mix")などの選曲がいいのが大きいのではないだろうか。

Spotify制御ツールの改良にも飽きることがない。もう、大きな改良はない(やりたいことはあるが、面倒なので保留している)が、細々とした改良や突然見つかるバグ修正を(慌てて)している。

昨日は、ちょっと思い付いた機能を追加した。先日、クラシック音楽の演奏者名が作曲者になっていたら、それを除外して2番目の演奏者名を表示するようにしたのだが、その機能を発展させて、曲名やアルバム名に作曲者名が入ってなかったら、曲名に追加するようにした。面倒な割には誤動作もあるから止めとこうとは思ったのだが、知らない曲で気になるものの作曲者を一目で知ることができれば便利だと思ったのだ。

まず、除外した時点で作曲者(の可能性の高い人)は分かっているから、それを保存しておく。ただし、フルネームを出すと長くなってしまうので、姓(モーツァルトなら"Mozart")だけを抽出するようにした。もちろん、AIのような最先端技術を使った訳ではなくw、泥臭い方法でやった。単に、名前の最後の単語が姓だとみなしている。なお、演奏者名を作曲者であるかを調べるための「作曲者リスト」には姓は大文字で記載されているので、それと組み合わせればもっと精度を上げられそうだが、今はやっていない(そもそも、姓が複数の単語ということはあるのか? "="で繋がっている人はそう?)

読み返していて、問題に気付いてしまった。作曲者が最初の演奏者になっていなかったら、この機能は起動しない。しかも、この場合は作曲者が分からないから、本当にAIが要りそうだ(実際にはDBでいいが)・・・ やっぱり止めとけば良かったなw まあ、Spotifyのアプリだと作曲者が見られるので、どうにかして、それを取り出せればいいとは思う。

次に、既に姓が曲名やアルバム名に入っていたら(例: "Mozart: Piano Concerto No.21")、改めて追加するのは無駄なので、それを検出するようにした。そして、どちらにも入っていなかったら、曲名の頭に"Mozart: "のように付ける。

苦労したのは、名前に言語特有の特殊な文字(例: ドヴォルザーク: "Dvořák"。そういう文字を一般的に何というのか不明)の記述の仕方がいろいろあって、検索がうまく行かなかったことだ。いろいろ試していたら、iconvというコマンドに、そういう文字をASCII(普通のアルファベット)に変換する機能があることが偶然分かって、使ってみたらすごくうまく行った。無事、ドヴォルザークは"Dvorak"になって、検索でマッチするようになった。

作曲者名をタイトルの前に追加

改めて書くが、このプログラムは、Pythonのような最新の言語なんて使っていない。古臭い、シェルスクリプト(bash)とTck/Tk(wish)だ。道具は(ある程度のものなら)何だっていいんですよw でも、OSがLinux(UNIX)だからできたのであって、Windowsでは決してできなかっただろうし、やる気も起こらなかっただろう。それだけ、Windows(Microsoft)は酷いものなのである。

別件だが、確か上の機能の確認中に、思わぬバグに悩まされた。ある曲の情報が表示できなかった。調べたら、曲名に"が含まれていたせいだった。その曲には'も入っていて、かなり極悪だった。ちなみに、その曲は初めて聞いた曲だったのだが、タルティーニという人の

Violin Sonata in G Minor "Devil's Trill"

だった。まさに悪魔の仕業だったw 特にシェルスクリプトでは、同じ文字列に"と'が同時に入っていると、小手先の対処では済まないので面倒なのだが、泥臭い手法でどうにか対処した。

「悪魔のトリル」に悩まされた。

それから、プログラムの名前を変えるなら"minispot"にしようと思ったが、調べたら既に2件あったので、"minisp"がいいかなと思っている。でも、変えるのは面倒なので、本当に変えるかは未定だ。そもそも公開するつもりがないので、何だっていい。単なる自己満足だ。

  •   0
  •   1

(題は英語ではない。「力技はいいよね(いや、本当は駄目なんだけどさw)」のような意。 たまたま"Power of love"が掛かっていたので思い付いた。)

先日のSpotify制御ツールV2はその後も止まらずに進化を続けて、今日、概ね、今までの不満が解消できた(内部的にはとんでもないことになっているのだが、それでもちゃんと動いて問題なく使えているので、暫定的に良しとしている)。とりあえず、外観を。

大幅改良後のSpotify制御ツール V2 (別名: 「Spotifyミニプレーヤー」?)

もう、「Spotifyミニプレーヤー」と言ったほうが適切かも知れない(が、名前を変えるのが面倒で、そのままにしている)。いったい、前回から何を変えたのかすっかり忘れているのだが、調べてみると、以下だった。

  • 細かい見栄え(例: 行間、文字サイズ、ウインドウサイズ)の調整
  • 起動時にSpotifyアプリが起動してなかったら、自動で起動する。
  • ジャケット画像をクリックすると、Spotifyアプリを前面に表示する。
  • (リモコン経由でなくても)アイコン(ウインドウ内のボタン)を押せば、「この曲の後に停止」を設定できるようにした。
  • 曲情報欄の高さが狭いことがある問題の修正。
  • ウインドウの表示位置を起動時に指定できるようにした。
  • 「正しい演奏者名」の表示
  • 再生位置(時間)の表示

今日までは、ずっと細かい調整が主だった。そして、今日、最後の2つをなんとか実装できた。

その前に、外観(UI)について少し書く。(画像中央右辺りを)ちょっと見ると、ESPカードを思い浮かべそうだが、かなりの試行錯誤の結果だ(もちろん、苦労したから結果がいいと言うつもりは毛頭ない。駄目なら駄目で仕方ない)。この辺りは、再生状態("♪")と、「この曲の後に停止」("∥")と、音量正規化("≂", 従来は"RG"だった)のインジケーターとボタンがある。

音量正規化のボタンは、ON/OFFの区別がしやすいように色を付けていた(→ )のだが、その色が問題だった。どんな色も気に入らない(しっくり来ない)のだ。その理由は分からないのだが、ウインドウ全体がモノトーンなのに、一箇所だけ色が付いているのと、アルバムのジャケットの色とかぶったりするからかと思う。さまざまな淡色を試したのだが、これという色がなかった。が、「この曲の後に停止」をボタンにする時に、ふと気付いた。色は不要だ(黒の濃さにすればいいのだ)と。

同様に、ボタンの外観は、最終的に、画像(アイコン)ではなく、文字にした。Linuxに入っているいろいろなアイコンを試したが、これというのがなかった。作ればいいのだが、それは面倒だったので、文字を探した。Unicodeの文字コード表でさんざん探して、押した時の動作、あるいは、現在の状態を予想できそうなものにした。

意図せず林檎系の意識高さを醸し出してしまっているのが悔しいが、我ながら、まずまずだと思っている。

ついでに、曲情報欄の高さが狭いことがある問題とその解決方法について書いておく。曲情報(題名、演奏者名、アルバム名、年)は、転載する時に全部を一度にコピーしたいので、一つの領域(textウィジェット)に書いている。そして、読みやすくするために、タイトルの文字の大きさを大きくしたり、行間を増やしたりしている。各テキストを書き込んだあと、曲情報欄の高さを丁度良くするために、実際に表示されている高さを求めて設定する。ところが、文字の修飾(特に行間)は高さの計算に含まれないようで、普通に高さを求めても低くなってしまう。それが狭くなった原因だった。それを解決しようと、ちょっと高目にしようとしても、textウィジェットの高さは行数でしか設定できないので、丁度良くはできない。1行多くするといい時もあるが、高くなり過ぎる場合もある。

そこで、苦肉の策を生み出した。textウィジェットのデフォルトのフォントサイズを1px(またはpt。どちらかは不明)にしたのだ。そうすると、1行の高さは1画素程度(とにかく小さい値)になるので、高さを細かく指定できるようになる。もちろん、そのままでは読めないが、書き込む都度、本来のサイズを指定すれば良いのだ。これも一種の力技だろう。表示に使っているTck/Tkの内部のことを考えると、極小フォントに対応させるために何か無駄な処理が起こっていそうだが、とりあえず、大きな問題は起こっていないので、良しとしている。

「正しい演奏者名」の表示は、Spotifyの数少ない問題点の一つへの対処だ。どういう訳か、Spotifyがクラシックの曲の作曲者をその演奏の演奏者にしてしまうのが、ずっと気に入らなかった。例えば、モーツァルトのピアノ協奏曲の演奏者を"Wolfgang Amadeus Mozart"にしていたりするのだ。涼しい顔して! これだけは全く許せない。

さっき思ったのだが、SpotifyのDBには「作曲者」の格納領域(フィールド)がないからこうなっているのかも知れない。今からでもいいから、直して欲しい!

それをどうにかしてみた。細かい話は飛ばすが、最後は力ずくでやった。まず、前回も書いた、"xesam:url"というプロパティから取得できる曲情報ページで、その曲の演奏者リストを取得してみた。当然、その最初も作曲者になっていることが多かったので、それを何とかするためにいろいろ考えたのだが、次のようにした。

演奏者が「(有名なクラシックの)作曲家」なら、無視する。

噴飯物ではあるが、まあ、他の方法(例: アルバムアーティストを使う)よりはましだと思う。そして、ある人が「(有名なクラシックの)作曲家」かどうかは、あるwebページに列挙されていた作曲家一覧からデータを作った。

道義的にどうかとは思うが、確か、データ自体には著作権はないので、法的な問題はないだろう。

正しい演奏者を調べる(推測する)手順は、以下である。

  1. その曲の曲情報ページから演奏者リストを取得する。
  2. 演奏者リストの最初の人から順に(有名なクラシックの)作曲家一覧内にあるかを調べ、あったら、その人は無視する。
  3. 最初に残った人が、その曲の「正しい演奏者」だとみなす。

この方法だと、作曲も演奏もする人(例: ラフマニノフやバーンシュタイン)が演奏した曲の結果がどうなるか恐ろしいものがある(「想定外」)のだが、それよりも、僕が普通に聴く曲(演奏)で演奏者が正しくなる確率の方が圧倒的に高いはずなので、この方式を使ってみることにした。やっぱり実装には苦労したが、以下のようにうまく動いている(赤枠内を比較すること)。

正しい演奏者名を表示するようにした。(左: 本ツールでの修正後("Richard Goode")、右: Spotifyアプリ("Ludwig van Beethoven"))

 

最後の、再生位置(時間)の表示は、一見、飾りのように思えるのだが、僕には意外に重要だ。「この曲の後に停止」を作ったのと関係があるが、例えば、曲を聴きながら何か(例: 出勤、家事)をする必要が起こった場合、残りの長さに応じて、最後まで聴くかすぐに止めるかを判断するのに必要なのである。

実装は面倒だった。しかも、大変醜くてものすごく気に入っていないのだが、曲がりなりにも動いているので、「今は良し」としている。が、いつか、問題が起こりそうなので、あとでちゃんとしたいと思っている。

何が良くないかというと、Spotifyのアプリは、Dbus(MPRIS)経由では、現在の再生位置(時間)を取得できない(いつも0が返って来る)ので、別の方法でそれを取る必要があって、その方法が汚いのである。

いろいろ調べて、Spotifyのアプリに含まれている、HTTP(web)での制御機能を使って、現在の状態(その中に、現在の再生位置(時間)も含まれている)を取得することができることが分かり、実際に取れた。が、制御ツールはシェルスクリプトなので、再生位置(時間)を更新するたびに、wgetという、webコンテンツを取得する外部コマンドを呼び出すのである。今は1秒に1回呼んでいる。それがとてもおぞましい。。。 (が、そもそも、シェルスクリプトなんて外部コマンドを呼びまくりなのだから、この程度で苦しくなったら即座に窒息してしまって生きて行けないだろうから、気にしなくていいのかも知れないw)。

その点では、本体をシェルスクリプトで書くのを止めて、PHPに移行したい気持ちもある。上の件以外にも、JSONなどの解析を全くテキトーにやっているし、大規模になったせいもあって、プログラム自体を書くのにも結構手間が掛かるので、僕としては心苦しいことだらけなのだ。PHPを使えば、HTTPでの通信は自分でできるし、外部コマンドの呼び出しはかなり減らせるし、文字列の解析・処理はお手のものだし、プログラムだってかなり書きやすくなるから、いいことずくめだ。が、今動いているものを作り直すには結構な勇気とパワーが要るので、なかなかできないだろうな・・・

てな訳で、最初や下の画像のように、プログレスバーで再生位置を表示することができた(数値(現在位置/全長)でも表示したいが、標準の機能ではできないし、今は疲れてしまったので、あとでやりたい)。めでたしめでたし。

再生位置はちゃんと合っているよ。

再生位置の数値も入れられた。ただし、文字の背景を透過にするのは面倒なのでやっていない。そこがちょっと不満ではあるが、まあいいことにする。

再生位置(時間)の数値も入った。

余談: 「ゴールデン・ハーフでーす」って題は今でも古く感じない(今の若い人も言いそう)のだが、彼女たちが先進的だったのか、まあ世の中なんてそんなものなのだろうか?w そもそも、当時、こんなふざけた題のレコードなんて出して、風当たりがすごくなかったのか、ちょっと心配になるw

いろいろ調べたら、丁度いいプログラム(リンク先の"Based on frame and label"の"a progress meter")が見つかり、ちょっと改造して使ってみたら、すごくいい感じになった。

再生位置(時間)の文字の背景を透過にできた!

それにしても、そのプログラムも「力技」でやっているのだが、ほんのちょっとしたものなのにすごく良く働くので、感心している。 (6/17 19:55)

 

(6/17 8:06 加筆・修正, 10:37 再生位置の数値を入れられた件を追記, 19:55 再生位置の文字の背景を透過にできた件を追記)

  •   0
  •   0

Spotify制御ツール(今は、「Spotifyのミニプレーヤー」の方が近いかも知れない)の見た目を改良して、元々の目標にかなり近づけられた。そのために、表示に使うプログラムを入れ替えた。それで"V2"とした。

目標としていたGMBのミニプレーヤー(これも自分でレイアウトを作った)に近くなり、幅が狭くなったのでコンパクトになった。

表示用プログラムを何にするか迷った。今まではyadというのを使っていたが、今ひとつ機能が低いし使いにくい。最初の版ではかなり無理をしたが、それでも、曲情報を1行に表示するしかなく、書式を工夫したのだが、どうしても見難くて気に入らなかった。今ならElectronを使うのが普通なのだろうが、JavaScript(Node.js)は使いにくくて大嫌い(GPMDPの改造でうんざりした)なので、避けたかった。次は軽いブラウザを考えた。ただ、今回必要な、(人の操作でなく)外部のコマンドなどで表示の更新ができるものはほとんどなく、uzblというのしかなかった。

uzblを試してみたのだが、開発中のせいか、どうも今ひとつだったので、更に検討したところ、大昔(1990年代)に最初に発表された頃に(確か、「UNIXマガジン」の紹介を読んで知ったのだと思う)ちょっと触った程度でどうも気に入らずにほとんど使わなかった、Tcl/Tkという言語が丁度良さそうなので、使ってみた。恐るべきことに、今でもLinuxでちゃんと動き、機能・仕様もそれなりに更新されているようで、まあまあ使えた。

(今回の開発においては、)Tcl/Tkの良い点は、すごく手軽に描画できるのはもちろんなのだが、標準入力からコマンドを読み込んで描画できることが一番大きい。というのは、Spotifyの挙動やリモコンからの要求に従って処理を行う本体プログラム(bashを使っている)から、文字列としてTcl/Tkのプログラム(コマンド)を出力することで描画できるので、本体を(訳の分からない)Tcl/Tkで(苦労して)書かなくても済むのだ。そのおかげで最初の版の主要な部分を流用することができた。もしElectronを使ったら、JavaScriptに書き直さなければならなかっただろうから、全部作り直しになるうえに、内部動作が非同期になってしまうから、大変な苦労になったはずだ。

とはいえ、Tcl/Tkは(昔感じたように)やっぱり言語仕様がおかしい(古代の言語のせいもあるのだろうか)ので、結構苦労してしまって、こんな時間だw でも、上のようにできたので、(まだいろいろ改良したいことはあるものの、)とりあえずは満足だ。

その後更に改良し、リリース年と大き目(250画素)のジャケット画像を出せるようにした。

どうやったかというと、Dbus/MPRIS経由でSpotifyアプリから取得できる曲情報(Metadata)の中に"xesam:url"という、曲情報ページ(webプレーヤーのようなページ)のURLがあり、(大変ありがたいことに、)そのページのソースにSpotify.Entityというトラックの詳細情報が記述されているので、そこからリリース日(release_date)と大き目のジャケット画像(imagesの中のwidthまたはheightが300画素のもの)のURLを抽出するようにした。これはおそらく非公開情報なので、Spotifyの心変わりで動かなくなってしまうが、駄目なら従来の動作をするはずなので、(がっかりはするが)致命的な問題にはならない。

ちなみに、上の方法を思い付いたのは、上記の曲情報ページにリリース年が書いてあるので、その文字列を強引に抽出(スクレープ)して使おうかと思ってソースを見たらだ。情報は(東洋の経済紙の無知で不勉強この上ない訳者に「気味の悪い拡張子」と書かれてしまったw)JSON形式で構造化して書かれているので、ちゃんと処理すれば、綺麗にデータが取れる。

なんか、こうやって、それまで考えてできない・難しい・面倒と思ってたことを、試行錯誤や裏技や力技でできるようにするのは、とても血沸き肉踊るものがあって、プログラミングの醍醐味と言えよう。まあ、こういう裏技は趣味だから使えることだが、仕事にも形を変えてフィードバックできると思う。と言っても、意識低い僕は、仕事のために(「自己研鑽」だの「スキル向上」だのw)趣味のプログラミングをしている訳ではなく、お客さんや上司などの鼻を明かすとか、期待よりずっと早く仕事を終わらせて、遊びの時間が増えるのが楽しいからであるw (6/10 13:41)

(6/10 21:28 若干修正・加筆, 6/11 5:48 わずかに加筆)

 

PS. 改良したい点は、以下の通り。

  • プログラムを終了するとSpotifyも終わる問題の解決。 → 仮のターミナルからspotifyを起動したら直った。(6/10 11:19)
  • その他の問題の修正
  • アプリのタスクバーアイコンの設定 → できた。(6/10 11:19)
  • ステータス行のレイアウトの改良 (レイアウトするのに四苦八苦している)
  • 再生状態アイコンのサイズを小さくする。
  • ジャケット画像を大きく (大きな画像を取るには、SpotifyのWeb APIを使う必要があるので、面倒) → できた。(上述の通り。6/10 13:34)
  • 初出年の表示 (取るにはSpotifyのWeb APIを使う必要があるので、面倒) → できた。(上述の通り。6/10 13:34)
  • 再生時間の表示(プログレスバー): なぜか、Dbus/MPRISで取れる再生位置(時間)が0のままで更新されない。(Web helperでSpotifyアプリから取れるが、今一つ効率が悪そう)
  • プログラムの整理 (いろいろ汚いw)
  • CPU負荷・メモリ量に問題ないことの確認 → 大丈夫そう。(6/10 11:19)
    • メモリ: 全部で35MB程度
    • CPU負荷: 0% (通常時)

PS2. おや、新しいジャケット画像の取得方法だと、右下にSpotifyのマークが入っていない。全く予想も期待もしてなかったが、すっきりするので結構うれしいことだ。それから、Spotifyのリリース年はGPMよりずっと正確なので、ちゃんと参考にできるから、出すようにした甲斐がある。 (6/10 14:11)

  •   0
  •   1

5/22(US時刻)に、USなどでGoogle Play Music (GPM)がYouTube Musicに統合された。日本もそのうちそうなるらしい。4月下旬のニュースでは「Google Play Musicが年内に終了」などどいうセンセーショナルな見出しでびっくりしたのだが、中身を読むと、実際には上記のようなことで、全然「終了」ではない(それどころか、実質的には名前が変わった程度)のだが、記者が無知なのかアクセス数を稼ぎたいのか知らないが、大げさな見出しになっていた。(→ 先週、より正確なニュースがあった)

僕は、GPMが終了することはまずないと信じていたので(というのは、これくらいのサービスは、Googleのパワーやリソースをもってすれば、全然問題ない(Spotifyは結構辛そうな気がする)。逆に、投資に比べて利益(お金以外も)が多そうだ。)、それについては全然心配しなかったのだが(仮に終わりになっても、Spotifyなどの代わりがあるから、お気に入りの曲・アルバム一覧などを保存して、移るだけだ)、ちょっと気にあることがあった。それは、GPMをYouTubeに統合するために、システムの内部構造が多少変わる可能性があり、その変化の影響で、今僕がgmusicbrowser (GMB)でGPMを聴ために使っている、gmusicapiなどのプログラムがうまく動かなくなったら、GMBでGPMが聴けなくなって不便を強いられるのではないかという心配だった。その後、疲れのせいかちょっと調子が悪くて余裕がなくて、たまたま、移行した頃から家ではGPMを聴いておらず、移行の件もすっかり忘れていた。

そして今朝。たまたまGPMを掛けたら、なぜか再生できなかった。アプリを再起動したり何度試しても駄目で、無事死亡した。ログを見たら、HTTPエラー403(Forbidden)で曲取得用URLの取得に失敗していた。最初は、自分のPCのLinuxの更新でPython(gmusicapiを動かすプログラム)やgmusicapiを駄目にしたかとか、GPMの認証がおかしくなったのかと思ってその辺りを調整してみたが、駄目だった。それからGPMが移行したことを思い出して、それに関係しているのかも知れないと思った。そして、苦労して作ったシステムが、気付いたら音もなくバベルの塔のように瓦解してしまっていて、また一から作り直しになるのかと、結構重苦しい気分になった。

HTTPエラーが出ていることから、GPMの通信手順がちょっと変わったのかとか、曲のURLを取得するためのURLが変更になったのかと思った。それで、gmusicapiを最新版にしたり、AndroidのGPMアプリの中に新しいURLが書かれていないか調べたが、前者は効果がなく、後者は見当たらなかった(アプリでは使っていないのか、別のページからリダイレクトしているのか)。あとは、参照するDNSサーバを変えてみたり、locale(言語)を変えてみたりしたが、効果はなかった(思い付いて試してみたのだが、まあ、効果がなくて当たり前だ)。

そこで、試しにパスワードを異常なものにしてみたら、別のエラー(HTTP 401だったと思う)が出たので、認証自体は問題なく通っていることが分かった。また、gmusicapiを使ってGPMの曲の検索をしてみたら、正常にできた。要は、本当に、曲のURLを取得する要求(だけ)がハネられている(Forbidden)なのだ。

それで、いつから駄目になったのか(いつまでちゃんと使えていたのか)を調べたら、5/23の6時頃までは正常に再生できていた(それが最後だった)ことが分かった。切り替えがUS時刻の5/22 0時だったとしたら、それは日本時間の5/22 13時前後だから、切り替え後しばらくは使えていたようだ(ここは不思議だ。切り替えはUSの午後から夜だったのかも知れない)。

八方塞がりになったので、検索してみた(Googleだと「自サービスに関する望ましくない情報」としてブロックされている可能性があったので、Bingも使った)のだが、ほとんど出て来ないので、まだ誰も困っていないようだ。それから、gmusicapiが公開されているサーバ、Githubの問題掲示板(Issues)を見てみたら、何となく、それらしいのがあった。スレッド名は以下である:

get_stream_url gives 403 with 'DEVICE_NOT_AUTHORIZED' for Mobileclient.FROM_MAC_ADDRESS #590

去年からの問題ではあるのだが、近頃になって3人が投稿している。そして、(現時点で最後の)fizzybunkという人の投稿を読んで確信した。近頃(移行に関連して?)、曲のURL取得要求を出す時に指定するデバイスIDには(正しい)AndroidデバイスのIDを指定する必要があり、それ以外はエラー403になるようになったようだ。以下に主要な部分を載せる:

I even have tried using a valid android device_id that is registered with the account, seems the only way I am able to get Mobileclient.get_stream_url() to work is being logged into the account on the mobile app with the device of the device_id at the same time. Otherwise it is throwing a 403 error.

今までは、(デフォルトの、)PCのMACアドレスから生成した仮のデバイスIDが使われていたのだが、それでは駄目になったのだ。それで、今使っているスマフォ(AQUOS)のデバイスIDを指定すれば動きそうだとは思ったのだが、とんでもないヘマをしたらAQUOSでも聴けなくなってしまう可能性もあったので、まずは、iPhoneのIDで試したが、駄目だった。

それどころか、iPhoneのGPMのアプリを動かしたあとでGPMのデバイス一覧を調べたら、今日からiPhoneは「PC」扱いになっていた。以前はスマフォ("iOS")だったのに、それとは別に、(ちゃんとしたGPMのアプリを動かしたというのに)PC扱いのデバイスが増えてしまった。GPMに登録できるデバイス数は10個までで年間に4個しか解除できないので、これは結構ひどい。iPhoneの人から文句が出そうだが、まだ誰も騒いでいないようだ。

他に試したことも全然駄目だったので、意を決してAQUOSのデバイスIDで試したら、嘘のようにちゃんと動いた。fizzybunkさんの書き込みは正しかったのだ。

(ほぼ一日を潰して、)とりあえずは復旧した。が、AQUOSのデバイスIDを使うことで、AQUOS側に影響が出ないとも限らないし(ただし、分身の術を使わない限りw、PCのGMBとスマフォで同時に聴くことはないので、競合の問題はない)、今後、更に別の変更がなされて問題が起こりそうで心配だ。前者については、もし問題が起こるようなら、昔使っていたNexus 4にGPMのアプリを入れて、そのIDを使おうと思う。※ 後者はGoogleの腹一つなので、全くどうしようもない。ただ、世の中には多くのGPMアプリが出回っているから大きな変更はできないはずで、今回のようなちょっとしたことであることに期待する。

※AQUOSのデバイスIDを使って曲のURLを取得していると、AQUOSがすぐに(数時間以内)Googleからログアウトしてしまって不便なので、Nexus 4のIDを使うことにした。この問題はGithubの別のスレッドにもあったので予期してはいたが、いろいろな落とし穴が多そうだ・・・ (5/28 6:15)

ただ、本当に駄目になってしまったら、新しい曲の取り方を探すか、別のサービス(例: Spotify)に移ることを考えることにする。だが、仮にSpotifyに移ったって、通信手順などは非公開なので、曲にアクセスするためのプログラムはやっぱり第三者がリバースエンジニアリングで作ったものだから、いつ動かなくなっても不思議はない。だから、サービスを移るのはそれほど本質的でなさそうだ(ただ、SpotifyにはLinuxのアプリがあり、GPMのブラウザよりは使いやすそうなので、GMBで全然聴けなくなってしまった時に移る先としては、意味がある)。

まあ、結局のところ、Google様が心変わりしないように祈りながら音楽を聴く程度しか、できることはなさそうだw

 

PS. それにしても、今回の変更で、日本、いや、世界中で、ものすごい数の人が「あれー!? 再生できない?」って言いそうなものなのに全然そうでないってことは、LinuxでGPMを苦労工夫して聴いている人は、本当に少ないってことのようだ・・・

  •   0
  •   0

居るじゃないですか、気心の知れた少人数の仲間で遊んでいたのに、どこからか大勢引き連れて入って来て我が物顔して、いつの間にかリーダー面する奴。当然、それまで楽しかったのが苦痛になってしまうという(そして、いつの間にか、オリジナルメンバーは居なくなっている)・・・ 要は乗っ取りだ。近年のMicrosoftのLinuxへの接近は、これを予感させて大変「いやー」な感じである。

前の投稿では「全部Linuxでいいじゃん!」と書いたが、それは撤回する。個人的にはLinuxでいいのだが、だからこそ、Microsoftには永遠にWindowsの底なし沼に嵌って居て欲しい。そうでないと、Linuxが汚染されて台無しになると思うのだ。

彼らにはお金もパワー(人数)もあるから、その気になれば何でもできてしまう。最初は「コミュニティへの貢献」とかいう羊の顔をしているが、そのうちに本性を現すだろう。例えば以下が考えられる。

  • Windowsのように質の低い(バグが多い、効率が悪い、肥大化した、美しくない)プログラムの混入
    • 余談: 今のLinuxは充分肥大化して美しくないとは言えるが、バグが少なく効率もいい点で、Windowsよりはマシだ。
  • プロプライエタリな(非公開の、オープンソースでない)モジュールへの依存
    • 例: 最初はそれなしでも大丈夫なのだが、時間が経つと、MSのモジュールなしにはLinuxがまともに使えなくなってしまう事態になる。そうなった時に、奴らはお金をせびりだすのだ。

こうなると、Linuxのメリットの安定性や自由や柔軟性が損なわれ、まさにWindows化してしまう。だからMSはこっちに来なくていいよ。Linuxが少しくらい不便だっていいから、あっち行っててくれ!!

No "MS Linux", "Linux.NET",  or "Linux 365"!

 

PS. でも、乗っ取られて腐ってしまったら、今までの歴史から考えると、誰かが新しいOSを出してくれる気がする("A new hope"や"Return of Linus"?)。Linuxはもう古くて、いろいろぐちゃぐちゃになっているから、それもいいかも知れない。

(5/23 6:59追記) 今が"A new hope"の状態で、そろそろMSが"Strikes back"するとしたら、その次は"Return of Linus"かw

  •   0
  •   0

先日注文した三島の文庫本の残り一冊が来るのだが、ゆうパケットなので、届く時間が分からない。さっき見たら来ていなかったが、今配達状況を確認したら、来ていた。もし、(厚いなどの理由で)郵便受けに入らず、その時出られないと、不在になってしまうから、素早く再配達依頼を出す必要がある。また、配達されたら、なるべく早く回収したい(今回はそんな必要はないけど)。だから、タイムリーに配達状況をチェックしたい。ヤマトなら、会員サービスで不在持ち戻りなどを通知してくれるが、郵便にはまだない。

そこで思い付いた。配達状況検索ページを使えば簡単にできると。Windowsだったら、それ用のアプリが要るが(Windowsに詳しい人ならそうでもないだろうが)、Linuxならアプリなんて不要で、ちょっとしたコマンドを使えばできる。だから、アプリのダウンロードもインストールも更新などの煩雑さはない。

以下は、配達済み(郵便受けに入っている)かを確認する例である。配達されていたら、"done."と表示される。なお、改行は無視して全部続けること。

(wget -q -O -
"https://trackings.post.japanpost.jp/services/srv/
search/direct?searchKind=XXXX&reqCodeNo1=YYYYYYYYYYYY&
locale=jp" | grep "お届け済み" > /dev/null 2>&1)
&& echo done.

上で、wgetコマンドに指定するURLは、発送元から通知されたURLそのままで良い。URLでなくて伝票番号だったら、下線のXXXXとY*Yを適宜設定すれば良い(XXXXは郵便の種類ごとに調べる必要がありそう)。また、"お届け済み"は、チェックしたい状態にすればいい。

※ここでは、コマンドや手順自体ではなく(実際、上に限らず、いくらでも別のやり方が可能)、「できそうもないことでも、やればできる」ことを示したかったので、各コマンドの機能や動作の説明は省略しましたが、必要なら説明します。

不在または配達済みをチェックしたい場合は、以下のようにすればいい(「持ち戻り」の文言は未確認)。実行すると、不在または配達済みなら、それと分かる文字列が表示される。

wget -q -O -
"https://trackings.post.japanpost.jp/services/srv/
search/direct?searchKind=XXXX&reqCodeNo1=YYYYYYYYYYYY&
locale=jp" | egrep "持ち戻り|お届け済み" 2>/dev/null

そんなコマンドを、定期的(例: 30分ごと)に実行して(これも簡単な手順でできる)、結果を見ていればいい。crontabコマンドなどを使えば、指定した条件でメールが来るようにもできるから、見る必要もない。

という訳で、(使いこなせる人にとっては)Linuxは普通に便利だよってことを自慢紹介したかった。近頃はWindows 10でも(Linuxのシェルが動くから)できるようだが、いいとこ取りだし、「だったら(ゴミは捨てて)全部Linuxでいいじゃん!」て言いたい。

 

PS. 僕は、小中高での一律なプログラミング教育には否定的だが、(方法や手順自体ではなく)「(上のようなことは、)ちょっと考えれば簡単にできる(いいシステムもある)んだよ」っていう、ITの基本(例: いいシステムを選ぶ。できなさそうなことだって、「できない」で終わりにせず、原理や方法を考えればできることがある。どうすれば一番簡単・単純にできるか考える)のようなことも教えるのであれば、意味があるかも知れないと、今思った。が、まあ、Windowsすら詳しくない人が教科書ベースで教えるんだったら、無理だろうなあ・・・

PS2. ひらめいてしまった。上の手順を応用して、あらかじめ、伝票番号を登録しておいて、不在だったら自動で再配達の依頼をするようなシステムを作ることもできそうだ。ただ、作るのは面倒だし、いつ受け取れるかはその日によって違うだろうから、余り実用性はない(せいぜい、ヤマトのデフォルトの受け取り時間設定のようなものだ)。現実的には、不在だったらメールで通知する程度で充分だろう。まあ、(理由はいろいろあるにしても)郵便の会社ができない・やってないことだって、技術的にはできるよってことの、おもしろさ(僕の大好きな、鼻を明かすこと)であるw

PS3. 「全部Linuxでいいじゃん!」とは書いたのだが、さっき、MSがゴミを捨ててLinuxに乗り換えたら("MS-Linux"なんてのを出したら)、それはそれで、こっちにも悪影響が出るようなおぞましいことになりそうなことに気付いてしまった。これはまさに"NIMBY"だ。杞憂ならいいが・・・ 詳しくはあとで書きたい。 (5/22 7:50)

  •   0
  •   0

僕は、OSは、自分で使うならLinuxがベストと思っているが、メジャーでないための面倒さが皆無とは言えない(だから、あえて人には勧めない)。Evernoteの純正クライアントがないのは、その最たるものだ。

昨夜、それも仕方ないと思える事実を見つけてしまった。たまたま、「EvernoteのLinux版を出すように働きかけよう」という投票サイトのようなのが見つかったのだが、去年の締め切りまでに集まっていたのは、たった50票程度だった。目を疑ったが、見間違いではなかった。脱力するしかなく、「そうか、Linuxはそこまでマイナーだったか」と、感慨を新たにしたw (11:25)

今まで散々探して来た(今も続けている)が、満足できるものはなかった。消去法でNixNote2を使ってきたが、これがかなりの代物で、以下のような問題があって、常に不安とイライラがあった。

  • ある時(ノートのサイズが大きくなったか構造が複雑になったか)、突然、編集できなくなる。エラーなどは出ないので原因が分からないし、どうすれば防げるのかも分からない。なお、サイズが大きいと言っても、1MB以下でも起こる。
  • 頻繁にフォーマットがおかしくなる。例えば、リストの数字が重なって表示されたり、箇条書きの段がおかしくなる。
  • 同期に失敗することがある。
  • 画像を貼っても消えることがある。

それが、昨日、いつものように検索していたら、全く新しい訳ではないが、以下のようなLinux用のクライアントが見つかった。

どれもweb版のEvernoteをアプリの形にしているものなので、web版に対する優位性はないと思って止めていたのだが、さすがにNixNote2には呆れ果てて来たので、試してみることにした。

すると、Whateverはweb版そのもので存在価値はないが(Electronを使う同様のアプリ(例: GPMDP)は多いのだが、こんなのを作って偉そうにする奴やありがたがる奴の気が知れない)、Tuskにはメニューが追加されていて、単なるweb版ではないことが分かった。

なお、ForeverNoteはなかなか動かなかった。JAVA(JDK, JRE)のバージョンが8や9ではだめ(真っ白なウインドウしか出ない)で、10に更新してやっと動いた(全然、"Write once, run anywhere."じゃない!!)。やっと動いても、説明ページのスクリーンショットにはメニューがあるように書かれているのに、実際にはなくてwebそのもの(= Whateverと同じ)だった。JAVAのバージョンや環境によるものなのか、説明が嘘なのかは分からないが、エラーすら出ないので、何が正しいのか分からない。

ちなみに、JAVAのバージョンを最新にすれば過去のすべてのアプリも問題なく動くのなら文句は言わないが、8を9にしただけでさまざまなアプリが動かなくなってしまった(なんでそうするかね。俺ら来るは本当に頭悪いねw・・・)。10なんて、Linuxのパッケージにすらなっていない。だから、自分用のJAVAを同梱しているアプリすらある。全く何やってんだよ! (11:19)

Tuskはベストとは言えないが、web版よりは使いやすそうだし、NixNote2よりは10倍マシだ。一番ありがたいのは、ノートの保存(Ctrl-S)や再表示(Ctrl-Shift-R)動作があることだ。これらを行えば、ノートがサーバーに同期されそうだ。Web版だとその動作があるのかないのか分からず、結構、スマフォとの間で競合していた(それがweb版を止めた理由だ)。Tuskではその問題がなくなることを期待している。

他には、ノートをPDFやMD(マークダウン)でエクスポートすることも可能だ。まあ、本来はEvernoteの形式(ENEX)でエクスポートしたいのだが、PDFでも何かに使えるかも知れない。

Tuskの欠点は、ノート内の検索ができない(Ctrl-Fが別の機能になっている)ことだ。これは結構痛い。ショートカットを割り当て直せばできるのか? (13:55)

→ いろいろ調べたが、Tuskでノート内検索する方法はなさそうだ。Web版ですらできるのに(ブラウザの機能ではあるが)。ありえない! 作者は自分では使っていないのか?? 仕方ないので、web版を使うことにした。競合の問題については、スマフォで更新した後が危ないので、そういう時(帰宅時など)は明示的にリロード(F5)しようと思う。 (16:32)

ノート内検索できないのはWhateverもForeverNoteも同じだった。こいつら、何も工夫してないじゃないか!! (16:55)

なお、今日は上記の他にQuentierというのも見つかった。これはちゃんとした独立のアプリのようで、かなり期待できるのだが、なぜか、サインインしても同期できない。開発中のせいなのかも知れないので、今後に期待している。

その後、Quentierで同期する方法が分かった。gnome-keyringというモジュールが必要なようだ。だが、まだまだ開発中のようで、ノートを更新しても反映されない(同期すると変更部分が消えてしまう)とか、一部のショートカット(例: Ctrl-C)が効かないなどの欠点が多いので、まだ駄目だ。(13:52)

そして最後に、例のセリフが出て来る(約一名の方だけに分かって頂きたいw)。

あえて言おう、NixNote2なんてカスであると!

そして、WhateverもForeverNoteもJAVAも!

更にTuskも!

 

PS. その後、web版Evernoteもやっぱり駄目なので(例: 頻繁に保存(同期)エラーになる。入力していると突然エラーになって、そこまでの分がなくなる)、以前試したNimbus noteを再度試すことにした。 (22:42)

Nimbus noteを試し始めてから2日も経ってないのに、もう無料プランの100MBのデータ量制限になって、怒り心頭だ。普通に日記とか書いていただけなのに、それはないだろう。Webアプリが腐っているのだろう。こいつもカスだった! もう二度と試さない。 (5/4 19:47)

  •   0
  •   0

この連休にはオーディオ(スピーカー・部屋)の音響特性の測定と調整をしようと思っていた。が、今日は下の家族が居るようで、子どもが走り回ったりして雑音が出るので延期した。それで、ちょっと前に思い付いた機能を作ってみた。

僕は、gmusicbrowser(GMB)の出力は標準のPulseAudioでなくJACKに出すようにしている。それに深い意味や大きなメリットがある訳ではないのだが、イコライザや出力はJACKなので、PulseAudioを介さずに直接JACKに入れることで、わずかに音の劣化が減ることを期待しているのだ。

が、それにはちょっとした問題がある。GMBのJACK出力は、曲を再生中以外ではなくなってしまうので、そのままでは再生するたびに接続しなければならず、全く実用的でない。それで、jack-plumbingという自動接続プログラムで接続するようにした。

それで問題なく使えていたのだが、先日、一つだけ問題が見つかった。音源がモノラル(正確にはチャネル数が1)の場合、左のスピーカーからしか音が出ないのだ(JACKでなく、PulseAudioの時は出ていた)。

どういうことかというと、GMBやJACKにはモノラルをステレオに変換(正確には、単一チャネルの音を両チャネルに出す)する機能がないため、モノラルの場合にはGMBからは最初の出力ポート(左チャネル)しか生成されず、jack-plumbingにもチャネル数が1の時は重複接続するような機能はないため、結局、左チャネルの入力ポートにしか接続されないので、左からしか音が出ないのだ。

モノラル(1チャネル)の音源なんてほとんどないから、我慢・無視すればいいだけなのだが、好奇心とか興味でなんとかしたくなった。それで、それにはGMBの改造が要るので、どうせやるなら、ついでにJACKへの自動接続機能も付けて、jack-plumbingを廃止したくなった。やり方は大体分かっていたので、今日は実装と修正をした。

それから、別件だが、少し前に、特定のアプリの音を特定の出力(例: ヘッドフォン)だけに出したくなって、それも実現していた。

以下に、それぞれの実現方法や実装の概要やちょっと苦労した点を書く。

(4/29 13:25追記) さっき、昨日思い付いたこと(下記の「Gstreamerの機能でも接続できるのかも知れない。」)を試したら、意外に苦労はしたものの、概ねうまく行った。おかげで、処理を大幅に簡素化できた。Gstreamerには分からないことが多過ぎて、まだ気に入らないこと(モノラルの処理)があるのだが、とりあえずは良しとする。以下に、その内容を"[4/29]"として追記する。

(4/30 9:42追記) 昨夜(4/29)、上に書いた「気に入らないこと(モノラルの処理)」もできた。Gstreamerの動作が調べたことと違うので、やっぱり苦労した。他に、特定アプリの音に関する接続漏れが見つかったので、修正した。以下に、それらの内容を"[4/30]"として追記する。

GMBからJACKへの自動接続機能

  • GMBで再生時、Gstreamer(再生用ライブラリ)の再生準備をした後(playbinというものの初期化後)、指定したJACKの接続先(入力ポート)に接続する。
    • JACKへの接続にはjack_connectコマンドを使った。もしかしたら、Gstreamerの機能でも接続できるのかも知れない。
    • [4/29] GstreamerのJACKモジュール、jackaudiosinkの自動接続機能でJACKに接続できるようになった。今までできなかったのは、仕様(使い方)を理解していなかったのと、JACKサーバに知らない機能があったためだった。
      • jackaudiosinkのプロパティconnectを"auto"にし、port-patternに接続先を設定(正規表現。例: "jack_mixer:In .+")すれば自動的に接続される。
      • JACKサーバのバージョンによっては、self connect(アプリが自分で接続する機能)が無効化されているために接続できない場合がある。その場合は、jack_controlコマンドでself connectモードを" "(self connect有効)に設定し、サーバを再起動する。
        • 例:  jack_control eps self-connect-mode " "
      • self connectを有効にした時、PulseAudioサーバのバージョンによっては、pacmdでmodule-jack-sinkをロードした時に、自動的にデフォルト出力に接続される場合がある。その場合は、ロード時に自動接続を無効化すればいい。
        • 例: pacmd load-module module-jack-sink connect=false
      • ただし、私はJACKサーバをjackdbusで起動しており、その場合にはmodule-jack-sinkが自動でロードされるようで、上記の指定は無効なので、JACKサーバの起動後に自分で切断している。設定ファイルに書けばいいのだろうが、JACKの開始スクリプトに書いた方が確実と考えた。
  • 曲をスキップさせたり再生ゲインのモードを変更した時などにはplaybinが初期化されるので、再度接続する。
    • [4/29] jackaudiosinkの機能で接続する場合には不要になった。
  • 理由は分からないのだが、playbinの初期化直後は接続に失敗するので、その場合は一定時間後にリトライするようにした。
    • たまたま、GMBには500msの周期処理(UpdateTime)があることに気付いたので、その中にリトライを追加した。
    • [4/29] jackaudiosinkの機能で接続する場合には、自分で接続しないので失敗することもなく、リトライは不要になった。
  • 接続済みの場合に再度接続しようとすると、無駄な処理の繰り返しになって負荷が増えるので、接続しようとする前に接続済みかどうかを調べるようにした。
    • JACKの接続確認にはjack_lspコマンドを使う自作のコマンドを使った。
    • [4/29] jackaudiosinkの機能で接続する場合には、自分で接続しないので不要になった。
  • 接続先ポートはGUIで設定できるようにすべきだが、頻繁に変える訳ではないので、今はプログラムの中に記述している。

GMBでのモノ→ステレオ変換

  • 上記のJACKへの自動接続時に、再生しようとしている曲がモノラル(チャネル数=1)だった場合、最初のチャネル(左)をJACKの右チャネル入力にも重複接続する。
  • [4/29] Gstreamerの信号処理機能を使えば、1チャネルを2チャネルにすることも可能そうだが、方法が分からなかったので、ミキサーにモノラル入力を追加し、モノラルの場合には、出力先をそこにすることにした。
    • 試しにモノラル入力に音を入れてみたら左右両方に出力されることが分かったので、こうした。
  • [4/30] Gstreamerの信号処理機能を使い、1チャネルを2チャネルにするようにした。
    • GMBのイコライザの処理を参考にして、Gstreamerの「パイプライン」というものを追加した。
    • 調べたところでは、"audioconvert ! audio/x-raw,channels=2"(チャネルを2つに増やす)というパイプラインでできるはずなのだが、どうしてもエラーになってしまう。また、"audioconvert mix-matrix='<<(float)1.0, (float)0.0>, <(float)1.0, (float)0.0>>'"(左チャネルの音を右チャネルにも出す)も駄目だった。試行錯誤の結果、"audiochannelmix left-to-right=1 right-to-right=0  ! audioconvert"(左チャネルの音を右チャネルにも出す)は成功したので、これを使うことにした。
  • 曲がステレオ(チャネル数>1)に戻った場合は、右チャネルへの重複接続※を切断し、通常の接続を行う。
    • JACK接続の切断にはjack_disconnectコマンドを使った。
    • [4/29] ※「右チャネルへの重複接続」は「モノラル入力への接続」と読み替える。
    • [4/29] jackaudiosinkの機能で接続する場合には明示的な切断手順がないため、一旦、playbinの状態を初期化してから設定すことにし直した。以下に手順を示す。
      1. playbinをset_state("null")で初期状態にする。
      2. 同様に、Ready状態にする。
      3. 出力先を変更する(port-patternを設定)。
      4. 1と同様に、Paused状態、Playing状態にする。→ 再生が再開する。
    • [4/30] GMBからは常に2チャネルが出力されるようになったので、重複接続やモノラル入力への接続切り替えは不要になった。
  • この時、通常の接続を接続する前に重複接続を切断すると、一瞬音が切れるように聞こえるので、通常の、右から右への接続を行ってから、重複接続(左から右)を切断するようにした。
    • こうすると、一瞬音が混じるはずだが、音が切れるよりはマシなので、こうした。実際には混じって聞こえる感じはしないので、一種の錯覚なのだろう。
    • [4/29] jackaudiosinkの機能で接続する場合には音が途切れないので、不要になった。

特定のアプリの音を特定の出力だけに出す。

  • PulseAudioに、新しい出力先を作る。
    • 新しい出力先を作るには、pacmdコマンドでmodule-jack-sinkをロードした(pactlでもできるはず)。
    • 例: pacmd load-module module-jack-sink channels=2 client_name=PA_alt_jack_sink  sink_name=PA_alt_jack_sink
  • 対象のアプリの音をその新しい出力に出すようにする。
    • アプリの音の出力先は、音量調節アプリ(pavucontrol)で設定すれば、それが記憶されて、以降は自動で出力されるようになるが、プログラムで明示的に接続した方が、後日、設定したことを忘れて困ることがないと思うので、次のようにした。
      • pactl subscribeコマンドでPulseAudioのイベントを監視し、対象のクライアントが接続されたら、pactl move-sink-inputコマンドで、対象のクライアントの出力を新しい出力に接続する。
      • subscribeではクライアントIDしか出力されないので、pactl list sink-inputsコマンドでクライアント名を取得して対象のクライアントかどうかを判定し、同時に得られるクライアントの出力(sink-input)IDをmove-sink-inputに指定する。
    • なお、pactlコマンドもクライアントとして認識されるので、上記処理でpactlを実行するたびに新規クライアントのイベントが生成されて無限ループになってしまうので、pactlコマンドの実行後は新規クライアントのイベントを1個読み捨てるようにした。そのため、タイミングによっては本当の新規クライアントイベントが破棄される可能性があるが、起こる確率が低いので、対処はしていない。

以下にJACKの接続例とミキサーの図を示す。

左図で、左中央の"gmusicbrowser"がGMBの出力で、上記の自動接続機能によって中央のミキサーの入力(jack_mixerのIN L,R)に自動接続される。モノラル時には、上記の変換機能によって、中央図のように、GMBの1つの出力が重複してL,Rチャネルに自動接続されて、両方のスピーカーから音が出るようになる。

[4/29] 改良後のJACKの接続例とミキサーの図を示す。

[4/29] モノラル時には、上段右図のように、GMBの出力がミキサーのモノラル入力(jack_mixerのMono_In)に入り、ミキサーによってL,Rチャネルに出力されるので、両方のスピーカーから音が出るようになる。

[4/30] モノラル時も左右チャネルから音が出るようになったので、ミキサーのモノラル入力への接続は行わなくなった。そのため、モノラル時の接続状態は上の「通常(ステレオ)再生時」と同じである。

特定アプリの音は、PulseAudioから左下のPA_alt_jack_sinkに出力され、ミキサーの入力(jack_mixerのAlt_In L,R)に接続されている(この接続は勝手に切れないので、静的な設定にしている)。ミキサーでは、この音(の中央列: Alt_In)をミュートしている(図のMボタンがミュート)ので、通常の出力(MAIN L,R)からは出ないのでスピーカーからは出ず、特定の出力(Realtek_aout)だけに出力される。ミュートを解除すれば、通常の出力にも流れて、イコライザ(jack_rack)を経由してJACKの標準の出力(system)に出て、スピーカーからも出すこともできる。

[4/30] 特定アプリ以外の音(通常の音)をヘッドフォンに出すことを忘れていたので、接続を追加した(jack_mixer: In Out L/R → Realtek_aout: playback_1/2)。

まあ、オーディオシステムは、あくまでも音楽を聴くのが目的であって、こういう作業はまったく本質ではない、自己満足とか慰みの領域ではあるのだが、自分で構築したシステム(暇さえあれば、自分のアイデアで改良できる)で音楽を聴けるのは、なかなか楽しい。そして、こんなことはWindowsやMacではまず無理(可能ではあるだろうが、手軽にはできない)だろうから、Linux+JACKにして良かったと思う。とはいえ、実は、こここに書いたことだけなら、WindowsやMacではやる必要のない作業なのかも知れないw

が、それにしても、こういう作業をすると、今まで知らなかった・やったことのないことを見つけたり気付いたりすることがあって、技術者としてはおもしろいし、いつか仕事でも使えるかも知れないから、一石三鳥だw まじめな話、Windowsだと、基本機能になければ(その基本機能もコロコロ変わる)、他人が作ったアプリを探して使うしかない(ものすごく時間を掛けて、自分で作れば別)から、おもしろくないしつぶしが効かない。あ、Mac?、あんなものは林檎社がUNIXを腐らせしまっているので、全く論外ですw

 

PS. 今の録音エンジニアなどの方には当たり前なのだろうが、今回のように、「接続を忘れてたから追加する」とかいうのがマウス1個wでできるのは、JACKの大きなメリットのように思う。昔(僕が中高大の頃)は、本物のケーブルで接続しなければならなかったから、端子やケーブルや機器が足りなければ接続できなかったし、端子の形状が違っても駄目だったし、信号レベルやインピーダンスも考慮すべきだったし、並列・直列接続し過ぎると音質が劣化するし、ミキサーを介さずに複数の出力を同じ入力に繋げるのは電気・音質的に良くないことだった。

今はそんなことを全く意識する必要がなく、自由に接続できるので、すごく便利だ。機器にしたって、「ミキサー(あるいはミキサーのチャネル)がない・足りないからから増やそう」と思っても、お金を工面して買いに行くw必要などなく、即座に無料で増やせる。もちろん、PulseAudioやALSAでもそういう変更は可能だが、GUIではできず、設定ファイルを書き換える必要があるから、「ちょっとやってみよう」という気にはならない。

そういうことがあるから、いろいろな手間や欠点があったにも関わらず、JACKに乗り換えようと思ったのかも知れない。 (4/29 10:34)

 

(4/29 5:02 加筆・修正; 13:58 改良した内容を追記; 4/30 10:16 4/29夜の改良・修正点を追記、その他、若干修正; 4/30 10:37 題を変更; 4/30 17:59 若干修正)

  •   0
  •   0

映画「アマデウス」(1984)のDVDを買おうか迷ったのだが、結局、Amazonで安い中古(1997年盤)を注文したら、予定より1日早く、今日届いた。本体は約50円、送料と合わせて約400円だった。

開封してみると、何か違和感があったので、良く見たらUS盤だった。まず、パッケージに日本語が全く書いてないので、おかしいと思った(嫌な予感がした)。リージョンは1(日本は2)で、字幕だって英語とフランス語しかない。更に、初めて見る両面1層ディスクだった(要裏返し)。そのため、ディスクには印刷がない。それも違和感を感じた一因だろう。

ちなみに、両面1層ディスクは"SIDE A"を上にセットするとA面が再生される。当たり前のことだろうが、僕は、"SIDE A"にA面の内容が記録されていると思って、そちらを下にセットしたら、B面が再生された。これは余計に詳しい者だけが迷うところかw

Advanced余談: ありえないが、もし、3面以上のディスク(実際には多面体メディア)の場合、面表示("SIDE A"など)はどうなるのだろうか? ある面の「反対側」の面は一意には決まらないから、その面に記録してあるデータの内容を書くしかあるまい。ただ、「反対側」の面が決まる多面体(平行面からなるもの)もあるから、そういう形状を採用するのかも知れない。それに、上からメディアを読むことにすれば、(今まで同様)再生したい面表示が見えるようにセットするだけで何も問題ない。そもそも、将来はホログラフィーが使われるだろうから、メディアをセットする方向は1つしかないだろう。いやいや、それ以前に、物理メディアなんてなくなるから、考える必要すらない。なんて、考えて遊んでいる以外の何物でもない、まったく無駄な心配だw

調べたら、DVD-Videoは1996年から発売開始されたそうなので、これは最初期のもののようだ。だから両面1層なのかも知れない。更に、Wikipediaの"DVD-Video"の項には、この作品は数少ない両面1層の例として載っているから、今も構成し直さずにそのまま売られているのかも知れない。ディレクターズカット盤を出したから、それで良しとしたのか。

てっきり騙されたかと思って商品ページを見たら、全く正しかった。ちゃんと字幕は英語とフランス語と書いてある。ただ、リージョンは書いてなかった。販売元は"Warner Home Video"で、日本の会社(ワーナー・ホーム・ビデオ)と同じだと思ったら、そうではなくて、USの会社だった。タイトルは「アマデウス」でなく"Amadeus"なので、これと販売元の名前、あとはパッケージの表記(ただし、ディレクターズカット盤には英語しか書いてないので、紛らわしい)で見分けるしかないようだ。

安いのを探す余り英語で検索したうえに、ちゃんと確認しなかった僕が馬鹿だった。

それで、買い直すのももったいないので、とりあえず観てみた。英語字幕も表示したら結構内容が分かったので、安心した。最初に観た時のことを覚えているのと(何十年も前なのに、よほど印象が強かったのか)、音楽が多いせいもあるのだろう(感想は別に書く)。

楽しんで観ていたら、約1時間経過した辺りで再生が終わった。てっきりA面が終わったと思ってB面にしたら、曲が後期のもの(短調のピアノ協奏曲, 20番か)で、(その曲は好きなのだが、)繋がりが違う。良く調べたら、A面の再生時間は1:50程度なので、1時間で終わるのはおかしい(最初は、再生時間は両面の合計が出ていると思い込んでいた)。汚れかと思ってディスクを掃除してみたが、駄目だった。

再生プログラムはVLCを使ったのだが、設定を見直してもA面の1時間(チャプター14)以降が再生できないので、他のプレーヤー(SMPlayer, Media Player, mpv, kaffeine, xine, Totem, 仮想マシン上のWindowsのMPCHC)も試したが、駄目だった。

それで、(あくまでも、原因を調べるために)試しにPCに取り込んでみた。Handbrakeで取り込んでも途中までしか再生できない。ddやdvdbackupでコピーしても同様だった。

検索して、DVD関連パッケージのlibdvd-pkgをインストールしても駄目で、更に、ubuntu-restricted-extrasをインストールしていろいろ試すうちに、なぜか、ちゃんと再生できるようになった感じだ(VLCとTotemで大丈夫そうだった)。この状態でdvdbackupで取り込み直したら(くどいけど、あくまでも試し)、ファイルからの再生も大丈夫そうだった。ただ、ubuntu-restricted-extrasをインストールした直後は駄目だった気がするので、何が本当の問題だったのかは分からないが、チャプター14以降の読み込みあるいはデコードに失敗していたようだ。

ここまでで中断してから2時間くらい経ってしまい、疲れたので続きを観るのは止めた。明日にしよう。また駄目とかいうオチがないことを祈る・・・

 

PS. すごいことに、ネットにはオープンな(無料の)字幕があって、それを再生時に表示できるようだが、この作品の日本語版はないようだった。まあいいか。

PS2. それにしても、本作が配信サービスで観られたなら、こんなのは全然起こることがない問題だった。配給元は手をこまねいておらずに、早くなんとかすればいいのに・・・ まあ、もう古い作品で、モーツァルトブームも終わっているから(次は23年後(没後250年)?)、それほど売れる見込みがない(要望も少ない)ので放置しているというのが現状なのかな。あるいは、権利者に頑固者が居るのか? ビートルズの映画にそんなのがあったなw

PS3. 観終わって、メディアをケースから分離する時に感心した。紙(ジャケット)とトレイがすごく簡単に分離できるのだ。トレイと紙は、トレイの縁の幅5mm程度のつばだけで固定されている(接着されていない)ので、ちょっと力を入れて引き抜けば、カパっと綺麗に外れる。

特定メーカー・時期・タイトルだけなのか、USのDVD類は全部そうなのかは分からないが、さすがリサイクル先進国だけあると思った。(4/22 13:22)

  •   1
  •   0

以前にも書いたことがある気がするが、近頃、以前にも増して音の違いが分かるようになった気がする。その原因は、音の出力系をグライコ(DEQ2496)からJACKとPC内蔵DACに切り替えたからとは思えないが、気付いた時期とは一致している。

例えば、以下のようなことがある。

  • ビートルズの2009年ステレオリマスターと"Millennium remasters"(海賊盤。"Dr. Ebbetts"と呼ばれているものの更なるコピー)の音の違いが一瞬で分かる(「音が悪いなあ」と思ってプレーヤーを見ると、後者。ちなみに、リマスターを買った当時は、後者の方がいい音だと思っていた。なお、1988年に出たCDは分からない)。
  • 小泉今日子 「ヤマトナデシコ七変化」の「クシャーン」という、何かが潰れるような音がリアル(正確には、実際にはリアルでないことも分かるのだが、リアルっぽく聞こえる: 「カニかま」がちゃんとそれと分かり、銘柄が判別できるような感じw)。
  • 同 "The Stardust Memory"のサ行の音の悪さ(「潰れ気味」と書けばいいのか。DeEsserの設定不良?)。

まあ、機材や再生環境に関しては、DEQ2496を導入した時から必要充分な状態になったと思っているので、短期的には体調の変化(音に敏感になっている?)、長期的には経験値が上がったということなのかと思う。あ、環境については、JACKに切り替えた時に部屋の特性に対する補正を再調整したのが効いている可能性はあるか。

いずれにしても、昔は劣悪(と言っても、当時はそれなりにいいものを揃えていたつもりだった)な機材や再生環境で、原音(レコードやCDに記録された音)に忠実な再生なんて夢のまた夢だったし、経験が少ないために脳がついて来られなかったのだろうか、聴いても音や歌詞が判別できないことが多かった。

だが今は、(とりあえず)忠実な再生が出来る機材や環境が手に入って、手軽にいい音で再生でき、脳も(老化するばかりでなくw)継続的にバージョンアップできているようなので、うれしい限りだw

 

PS. 驚くべきことに、今、ビートルズの2009年モノラルリマスター("Please Please Me")を聴いてみたら、全然音が悪くない。買った当時は、音(振幅)が変に圧縮されて聞こえて嫌だったのだ。これは、機材・環境の改善の効果かも知れない。だとしたら、随分長い時間を無駄にしていたことになる。もう少し確認してみたい。

確かに音は悪くないのだが、やっぱりステレオ盤の方が好みだ。ステレオ盤の方が抜け感(今はやりの用法ではないw)があって、心地良い気がする。

PS2. 上で1988年のビートルズのCDの音は分からないと書いて気付いたのだが、Dr. Ebbettsはレコードから音をダビングしているから音が悪くなっている一方、本物のCDはオリジナルのマスターテープからデータを作っているから音の劣化がないということではないだろうか。

ということは、今、(どういう訳か)みんながありがたがっているアナログ盤(レコード)もそんなものではないだろうか? まあ、今のレコードは制作者がそれ用にマスタリングしているのだろうから(全くご苦労なことだ)、それなりの意味はあるのだろうけど。

まあ、好みの問題だ。ストレートな音を好むか、アナログ媒体のフィルタを通した音を好むかの違いだろう。後者が好きなのなら、聴けばいい。僕はレコードやテープといったアナログ媒体自体には全く価値を感じないし、音がいいなどとも思わないし、好きでもない。

「コーヒーを純水(H2O)で淹れるか湧き水で淹れるかの違い」と書くと、なんか違う気もするしw、「MT車とAT車の違い」、あるいは、「電気自動車とエンジン車の違い」と書いてもやっぱり違う感じだ。

さらに話が逸れるが、将来、モーターの車が普通になったら、「エンジン車のまろやかな加速がいいんだよなあ」とか言って乗る人が出て来そうだw

  • Dr Ebbetts

    Dr Ebbetts

    Please do not use Dr Ebbetts as a label unless it …

  •   0
  •   0

暇があると、特にやりたくはないのだが、つい、JACKのイコライザ(の種類)による耳痛の原因を調べ出してしまう。今日は、以下のことをした。

  1. DEQ2496("DEQ")とJACKのイコライザのDIN dual tone特性の比較
  2. 耳の痛くなるイコライザの一部を無効にした場合の確認
  3. JACKのイコライザの作り(実現方式)の調査
  4. JACKのイコライザ同士やDEQとの波形の差の測定

1では、DEQとFIL-pluginsの4バンドPEQ("PEQ4")とCalf Jack Hostの8バンドPEQ("Calf")で有意な差はなかった。だから、混変調歪みが原因ではなさそうだ。

2では、Calfの低域(120, 200Hz)の広く深い減衰設定を無効にし、代わりにPEQ4のその部分を使ったら、耳痛が出なかった。そのため、Calfでの広く深い減衰設定が問題らしいことが分かった。

3でPEQ4とCalfのプログラム(ソースコード)を確認したら、重要なことが分かった。耳の痛まないもの(PEQ4)と痛むもの(今回はCalfを調べた)では、フィルタの実現方式が異なっていたのだ。

  • PEQ4: 格子(lattice)型IIRフィルタ ("2nd order resonant filter implemented with Mitra-Regalia style lattice filter" → 典拠)
  • Calf: 双2次(biquad) IIRフィルタ(直接I型) ('"traditional" Direct I form' → 典拠)

IIRフィルタの実現方式の特徴を調べたところ、方式によって演算誤差の影響が異なり、直接型は誤差の影響を受けやすく、余り使われていないとのことだった。

余談: 大学で勉強したので、上のような話は調べるまでもなくスラっと出て来ないといけないのだが、当時(今もw)、フーリエ変換やFFTまでは問題なかったが、「z変換? はぁ?」となり、難しい式を見ただけでお腹いっぱいになって「パス」していたw だから、今回も、「ソースを読んだ」と言っても、コメントから判別した程度だ。

これと2の結果より、直接型を使っているイコライザ(Calfなどほとんどのもの)は、広く深い減衰設定を行うと誤差の影響(誤差が蓄積するのだろうか)で音質の劣化(歪み)が生じて耳が痛むのではないかと推測する。ただ、試験信号のような単音(純音)では歪みは生じず、音楽(特定のポップ音楽)で生じるのが不思議だ。 ← 試験信号でも劣化は生じているのだろうが、(下のグラフで分かるように)振幅が小さいので、周波数特性のグラフを見たり比較しただけでは識別できないのだと思う。

それで、4でPEQ4とCalfの波形の差やDEQとPEQ4およびCalfの波形の差がどうなっているか見てみた。結果は以下である。

  • PEQ4とCalfの波形に違いはあるが、PEQ4とCalfのどちらが「正しい」のかは分からないし、それらの差の振幅はかなり小さく(最大で-50dB程度(=最大音量の約0.31%))、それが聴こえて音質に影響を及ぼすのか疑問だ。ただ、曲全体を測定した訳ではないので、測定していない箇所で差(波形の違い)がもっと大きくなっている可能性はある。 → Rush "Big money"の曲全体で確認したところ、特に大きくなっている箇所はなかった。
  • 差信号の帯域は200Hz-2kHz程度(概ね、イコライザで補正している範囲)で、これが歪みになって耳を痛くしているのだろうか? ただ、耳痛の原因になると言われている帯域(例: 4kHz以上)より低いので、本当に耳痛の原因なのかは疑問だ。ただ、上と同様に、測定していない箇所で高域に歪み成分が出ている可能性はある。 → Rush "Big money"の曲全体で確認したところ、超低域(60Hz付近)の差が大きくなっていた(この付近は曲自体の振幅も大きかった)。
  • DEQとPEQ4またはCalfの波形にも違いはあるが、DEQとの差分の求め方に問題がある可能性がある(DEQと内蔵DACの出力はアナログであるうえに、振幅差や時間差があるので、差を正確に求めるのが難しい)ので、有意な差かどうかは疑問だ。

曲全体で確認した結果から、どうやら、(PEQ4の出力が「正しい」と仮定すれば、)Calfの演算誤差(あるいは音質劣化)の影響は超低音に出ているようなので、CalfにHPFを追加して超低域をカットして聴いてみたところ、わずかに耳閉感はあったものの、概ね問題なかった。

超低域の差の原因としてもう一つ考えられるのは、フィルタの遅延時間(位相)の差だ。どちらかのイコライザが低域になるほど遅延時間が長くなるか短くなるのであれば、その帯域で差を求めたら片方が筒抜けになるだろうから、グラフのような山ができるのは自然だ。これは誤差の影響でも音質劣化でもないので、耳痛の原因ではなくなる。そうであれば、最初に書いた帯域(200Hz-2kHz)が効いているのであろう。ただ、上記のように、この帯域をカットしたら耳痛が改善したので、やはり、誤差の影響はあるのではないかと思う。

イコライザの演算誤差による音質劣化が直接耳痛を起こすのか、スピーカーで混変調を起こして高域の歪みになって耳痛になるのかは分からない。なお、曲によって耳痛が起こったり起こらなかったりするのは、曲ごとに誤差が問題となる帯域の成分の量が違うからではないか。いずれにしても、Calfのような作りのイコライザは僕には使えないことが分かった。

(4/3 5:18, 7:49追記) 上記のPEQ4とCalfの差分は、演算誤差でなく、それらの設定パラメタ(フィルタの幅・鋭さ)の違いによるものが大きそうだ。というのは、PEQ4は、それをQ値でなく独自の値で設定するので、目分量で決めた。それをCalfに移植する時には、グラフの形が合うように目分量でQ値を決めたので、パラメタは厳密には同一にならず、曲線の形は一致しないから、比較的大きな差分が出ているのだ。あとで、PEQ4のフィルタの幅・鋭さとQ値の関係を調べ、より正確なQ値をCalfに設定して差分を測定してみたい。

(4/5 6:48, 7:35追記) PEQ4のバンド幅の設定値(→ BW)とQ値の関係を推定したところ、以下の式が良さそうだった。

Q= 0.45/BW

そのQ値(元の値から最大2%程度変わった)をCalfに設定したところ、特性のグラフは良く一致した。PEQ4との差分も20dB程度小さくなったが、スペクトラムの形状は余り変わらず、超低域(20-75Hz)の成分が大きい。なお、グラフで見る限り、位相特性の差はなかった。

やはり、特に超低域でイコライザ(フィルタ)の誤差が出るようだ。両方に誤差があって、どちらかが大きいはずだが、数値計算でフィルタを実現する以上、「真のフィルタ」の出力を得ることはできないから、どちらがより正しいのかを測定することはできない(それぞれの式から、誤差の理論値を求めることは可能だろう)。ただ、聴感(耳痛のなさ)ではPEQ4はDEQに近いので、PEQ4の方が誤差(別の言い方をすれば、音質の劣化度合い)が少ないと考えられる。

ただ、差分の最大振幅は約-60dBで、0.1%に相当するのだが、それが耳痛を起こす程音質を劣化させるのだろうか? スピーカーでの混変調歪みや、耳や脳内での妨害が大きいのだろうか?

いずれにしても、(特定の使い方をした時に)「音質の悪い」イコライザ(フィルタ)はあると言え、後述の結論に変更はない。

そして、すべてのものを確認した訳ではないが、多くのJACK(正確にはLADSPAやLV2)のイコライザは、安直な実装を行っている可能性がある。Calfなんて、"Studio"なんて単語が名前に入っているうえに見た目もかっこいいけれど、中身はお粗末(双2次IIRフィルタの直接I型)でがっかりした。演算誤差の影響がどの程度かは分からないが、リソース(処理速度、メモリ量)の豊富なPCで実行するのだから、多少演算量が多くなっても、誤差に強い(=ロバスト性が高い、音質劣化が少ない)方式を選ぶべきだ。おそらく、実装する時に最初に目した(あるいはどこかからのコピペ?)、処理が簡単な方式(直接型)を禄に検討・評価せずに使ったのではないか。

一方、DEQはプロ(スタジオ)用機器だからか、(PEQ4と同様に)演算誤差の影響を受けにくい方式を使っていて、それで耳痛が出ないのではないか。そして、PEQ4を見つけたのは全くの僥倖なのだが(これがなかったらJACKは使えなかったから、DEQから脱却できなかった・・・)、ページを見ると、ちゃんとした方のようなので、定石通りに作ったのだろう。

ただ、多くの人がCalfなどのイコライザを使って問題になっていないということは、演算誤差の影響は実際にはなく、あっても耳痛には関係ないか、僕の使い方(設定)が常識外れで音質が劣化しているのか、僕が特に敏感なのかも知れない。あるいは、現実にはJACKのイコライザ(、あるいはJACK自体)を使っている人がほとんど居ないから発覚していないだけなのかも知れない。それはそれで、他にも問題がありそうだから、結構良くない話だ・・・

という訳で、ひとまずの結論は以下になる(したい)。

耳の痛みはイコライザ(PEQ)のフィルタの作り(実現方式)に起因する可能性が高い。

  • 具体的には、定説通り、双2次IIRフィルタの直接型は良くなさそうだ。
  • イコライザの使い方にも依存し、低域に広く深い減衰(例: 120Hz, -9dB, 1.5oct)を設定するのは良くなさそうだ。

 

PS. DACなどで、フィルタを切り換えて音が変わる・変えられるというのは、こういうことがあるのだろう。ただ、前にも書いたが、それは売りにするものではなく、(すべての場合に最適なものがないから)仕方なしにやるとか、おまけでしかないと思う。元々いいものを使っていれば、切り替える必要なんてない。車のタイヤで言えば、オールシーズンタイヤで充分なら交換は不要で、無理ならノーマルとスタッドレスで切り替えざるを得ないのと同様だ。

それから、ハイレゾ化(アップサンプル)すると音が変わると言われるのも同様だ。その時に使うフィルタの作りがイマイチなために、音が(劣化とまでは言わないが)変質することもあるのではないか。ニセレゾなんて、元々ない音を追加して本当に変質させているしねw

PS2. JACKの自由に配線できる機能のおかげで、耳痛の原因を調べるためのいろいろな実験(確認)が手軽にできた。が、それは実は本末転倒で、耳さえ痛くならなければ、実験など不要だったのだ。でも、やっぱり、いろいろ遊べるのは好きだw

  •   0
  •   0

スマフォでGPMを聴くが、音量は「最大」にしたら何とか足りたものの、(グライコで調整しても)音が悪くて不満。そこで、ふと思い付いて、仕事用に持参したノートPCでテザリングして聴こうとするが、インストールしていたVivaldiやFirefoxではFlashプラグインがどうのこうので、結局、Chromeをインストールした。いろいろ手こずったが、今はいい音でK.488が聴けているので、満足。やっぱり、こうじゃなきゃダメだ。

それにしても疲れたw

PS. もちろんポリーニで、寝る前の締めだ。

(3/29 20:22追記) 昨夜、PCをスリープにしておいて今朝復帰させたら、電池残が半分以下に減っていた。それで小一時間聴いたら、もう電池がなくなって停まってしまった(こうなるとは思ってなかったので、ACアダプタは部屋に持って来なかった)。まったく、重くて大きいだけのダメPCだ(某林檎社製)。仕方ないので、続きはスマフォで聴いた。スマフォにしても、テザリングすると電池消費率が大きかった(約10%/h)。

まあ、それは仕方ないのだが、思い付いたことがある。大抵のホテルには外部入力端子付きのTVがあるから、ケーブル(ミニ-ピンまたはミニ)を持って行けば、TVに繋いで音楽が聴けそうだ。これなら音質は問題ないし、テザリングは不要なので電池に優しいし、クソ重いPCを持って行かなくても大丈夫だ。次回は是非試そう。

 

(3/31 7:11 少し加筆)

PS2. 実は、少し前までは、音量不足と音質を改善するため、ポータブルスピーカーを買おうと思っていた。が、スマフォにケースを付けたら音量が大きくなったように感じられ、音質も少し良くなったように感じられたし、イコライザアプリを見つけたし、スピーカーは結構大きくて重いので、持ち歩きたくなかったので、「次回」(=今回)試してから決めようと保留した。

そうしたら、軽くてかさばらず、0円で済むケーブルのアイデアが出たのは、大変ありがたい。野宿などしないので、大抵は問題ないw あ、実家はケーブルを伸ばさないと駄目だし、寝る部屋にはTVがないな・・・ (3/31 7:19)

  •   0
  •   0

JACKが落ち着いてちょっと余裕が出来たので、例のイコライザ(の種類)による耳の痛みの問題をまた少し調べた。

まず、今までに、FIL-pluginsの4バンドPEQ ("PEQ4")なら問題ないことが分かっていて(、今もそれを使っているのだが)、その設定を他のイコライザに適用(移植)したらどうなるか試してみた。結果は、残念ながら駄目だった。以下の4種類を試したのだが、どれも、耳の痛みに通じる耳閉感があった。

次に、問題の原因を探るため、以前から疑っていた、混変調歪み(IMD)(につながる特性)を測定しようとしてみた。以前はうまく行かなかったのだが、Room EQ Wizard (REW)の信号発生器のdual tone機能で2つの周波数の音を同時にイコライザに入れ、その出力をREWのリアルタイムアナライザ(RTA)で測定した。

REWはいろいろな種類のdual toneが出せるのだが、とりあえず、一般的そうなDIN(250Hz:8Khz= 4:1)とSMPTE(60Hz:7kHz= 4:1)で試した。直感的には、DINの方が音楽再生に近い気がする。

すると、興味深い結果が出た。以下の各グラフで、黒はイコライザなし(原音)、赤はPEQ4、青はCalf、ベージュはDSP、上の群は左チャネル、下の群は右チャネルである。また、低音の山の辺りは差が出ないため、上部をカットしている。なお、TAPはかなり特性が悪かったので(高音の山が出なかった)表示しておらず、TBPWS+SBPの測定は省略した。

僕の考えでは、イコライザなしに近いもの、あるいは、山が鋭いものや2つの周波数の間が低いものが特性がいい(=耳痛が少ない)はずなのだが、実際には、特性の悪そうなPEQ4(赤)が(耳に)良く、特性の良く見えるCalf(青)やDSP(ベージュ)は駄目だ。

何種類かの測定方法で試したのだが、どうも不思議なことが多かった。窓関数(連続した信号の切り出し方)や表示方法を変えるだけで、特性(グラフの形)がかなり変わってしまった。そもそも、イコライザなしの特性が予想外に悪いのが腑に落ちない。それは、僕がこういう測定の基本を知らないためだと思う。

だから、上のグラフ自体はイコライザの特性の良し悪しを直接表している訳ではなく、各イコライザには混変調歪み(あるいは、耳痛の原因となる音質劣化)の出方の違いがあり、グラフはその違いがあることだけを示していると解釈した。そして、(グラフからは信じがたいが)PEQ4は一番劣化が起こりにくい(少なくとも、僕には一番音質がいい)作りなのだろう。

その後調べたら、パラメトリックイコライザ(PEQ)はIIR(無限インパルス応答)フィルタで作るらしいが、IIR型は演算誤差が蓄積するという情報があった。その誤差が蓄積して音質が劣化し、耳の痛みが生じているのではないかと考えている。ただ、JACKのモジュールの内部処理は浮動小数点演算のはずなのに、それでも誤差が溜まるのか、ちょっと分からない(確かに、普通の数値計算でも、いい加減な処理をしたら誤差が増大してまともな結果が出ないから、それと同様なのだろう)。処理方式で誤差蓄積量が違うという記述もあったので、最終的にはイコライザのプログラムを読むしかないが、かなりハードルが高い。それに、読んで、「確かに駄目だ」と分かったところで、僕には改良することはできないから、読んでも無駄だとも言える。

あと、PEQは「Qが鋭いと演算精度が下がる」という記述もあった。「Qが鋭い」というのは、Qの値が大きいことなのか小さいことなのか、山が鋭いことなのか分からないが(某有名オーディオ機器メーカーの広告なので、表現がいい加減なのだろうw)、いずれにしても、設定によっては音質が劣化するのだろう。そして、僕の設定(多分、低域の幅広く深い減衰)が良くないような気がして来た・・・

その、PEQの設定(使い方)の問題は、PEQやIIRフィルタの作りや式に詳しい人なら当たり前のことなのだろうが、僕は全然ピンと来ない。ただ、ロバスト性が高いイコライザがあることは確かで、PEQ4はそうだろうし、製品ならDEQ2496がそうだ。プロ用機器は、そういうところがちゃんと考えられているのかも知れない。

という訳で、現段階では以下のようなことが分かっている。

イコライザの種類(作り)と使い方によって音質は変わり(音質が劣化し)、耳が痛くなることもある。ただし、その音質劣化は普通の周波数特性では判定できず、複数の周波数の音を同時に入れるような測定(例: DIN dual tone)をしないと分からない。

これは、「物理特性では本当の音質は分からない」という説を裏付けそうだ。

なお、混変調歪みは「本当の音質」に関係している可能性があるが、今は表示している機器が少ないし、2つの周波数だけでは不十分で、無限の組み合わせでの測定が必要そうだ。

だから、オーディオ機器メーカーは、良く、「『マイスター』が何百時間も聴いてチューニングした」とか言っているのだろうか。僕の考えでは、その音の良し悪しの本質は主観的なものでなく、上記のような複数周波数からなる信号(=音楽信号)に対する特性に帰着するのだろうが、それに気付いている人が少ないのか、気付いていても、(うまく表現できる値がないので、)あえて主観的なものと表現しているのか(その方がありがたそうだから?)、分からない(僕にはどちらでも構わないが、音質は(主観的なものだから)数値とは無関係だと言われたり、それを発展させて、物理法則とは無関係な、非論理的な「トンデモ理論」を出されると、どうしても信用できない)。

もし、音の良し悪しの本質が主観的なものでしかなかったら、オーディオ機器なんて作った人の耳(あるいは運?)に依存し、その「耳」は買う人みんな違うはずだから、一般的に「音のいい製品」なんてあり得ないことになる。それだったら、本当に「何だっていい」ことにならないか? そして、誰かが「いい」と言ったものを、みんな盲信して買うのか(昔からそんな気がするがw)。

それにしても、オーディオ機器の音質を測る・示す・改良するのは、なかなか奥が深いものだ。

  • bmc0/dsp

    bmc0/dsp

    dsp - An audio processing program with an interact…

  •   0
  •   0

JACK(Linuxのサウンドシステムの一つ)への移行が軌道に乗ってから約2週間経ったが、大きな問題はなく、満足している。また、耳が痛くなる問題は再発していないので、解決したようだ(結局、PEQの使い方が悪かったようだ → PSも参照)。以下に、利点と欠点とその他を書く。

利点

  • 使用しているサウンドカード(ASUS Essence STX II)とアンプ(SAYA SP192AB)の機能・仕様により、システムの電源を切る前にアンプの電源を切ったり音量を絞ったりしなくても雑音が出なくなった(グライコ(Behringer DEQ2496)は電源on/off時に雑音を出す)。
    • ただし、ボリュームを全く動かさないと(摺動面の状態が悪くなって)雑音が出やすくなると聞いたことがあるので、寝る前は絞り、朝は何回か動かすようにしている(が、それでもこのアンプは雑音が出ることがある)。
  • 他のシステム(PulseAudioやALSA)と違い、(仮想的な)音の配線を(設定ファイルなどでなく)マウスでできるので、とても便利。
  • 音の処理や配線を自由に変更できるので、思い付いたことを簡単に試せるようになった(PluseAudioやALSAでやろうとすると、設定ファイルに書く必要があるので、かなり面倒)。が、ここは研究室ではなく、音楽を聴くのが目的なので、そんなに頻繁に音の実験をする訳ではない。
  • プログラム(スクリプト)との親和性が高いので、ちょっとした処理は自分で作れる。
  • イコライザの調整が楽になった(グライコの小さいディスプレイを見ながらつまみを回すのでなく、キーボードで数値を入力でき、設定をファイルに保存できる)。ただし、最終的には実特性を測定して調整する必要があり、そのためにはマイクを立てる必要があり、それはやっぱり面倒なので、ものすごく楽になった訳ではない。
  • 外部のグライコ(DEQ2496)が不要になったので、システムをコンパクトにできた(そのうちDEQ2496は片付けたい)。また、DEQ2496が壊れた時のことを心配する必要がなくなった。ただし、サウンドカードやPCが壊れた時の心配は要る。
  • PCから外部に(光や同軸やUSBで)音の信号を出さなくてもいいので、その分、(ジッターが減るなどして)音質の劣化が減るはずだ。が、実際にはそういう経路の寄与は微々たるものだろうから、分からないと思う。
    • 逆に、サウンドカードはPCの雑音や電源変動の影響を受けやすいが、聴いた感じでは全く分からない。

欠点

  • JACKの扱えるサンプリングレートは固定で、単一の値である(それ以外は変換される)。僕はCD系(44.1kHz)がほとんどなので問題ないが、DVDなど(48kHz)の音も良く聴く人やいろいろなハイレゾ(JACKが対応しているかは不明)を聴く人には余り良くないだろう。
  • 音の処理(信号処理)をソフトで行うので、その分、CPU負荷が高くなる。ただし、普通に再生している場合は、OSのload average(平均待ちプロセス数)は0.5以下、JACK関連プロセスのCPU使用率は4%程度なので、全く実害はない。
  • 間違ってウィンドウを閉じるなどして、JACKの各プログラムを終了させると、音の経路が切れて音が出なくなってしまうので、注意が要る。同様に、イコライザの設定を間違って変えてしまうと音がおかしくなる。また、JACK関連のプログラムが多くなると、アイコンが増えて表示領域がいっぱいになってしまう。
    • → 滅多に設定を変えないプログラムは、アイコンを非表示にするといいのかも知れない。
  • ごくたまに、重い処理(例: 外部HDDの取り外し)をすると音が飛ぶことがある。ただし、原因となった操作をするといつも起こる訳ではないので、JACKには関係ない可能性が高い。
    • → 音飛びを防ぐため、JACKとgmusicbrowser(以下、GMB。実際にはGstreamer)のバッファサイズを大き目にした。
  • JACK関連の詳しい情報が余りなくて(あっても誤りだったり古かったりして)、自分なりに理解して使えるようにするのに結構苦労した。更に、「これだけでいい」というソフトがなく、取捨選択や自分で作る必要があった。また、JACK自体が古く、更新がされていないようなので、将来性に不安がある。
    • が、JACKは信号処理の枠組み程度のものなので、もっといいものができれば、それで既存の(LADSPAやLV2の)イコライザは使えるだろうから、大丈夫ではないか。
  • 当たり前ではあるが、間違った配線をすると、音がおかしくなったり、出なかったり、ハウリングなどが起こったりするので、注意する必要がある。

その他

  • (グライコのAUX出力が壊れたため、代わりにオンボードのサウンド出力を使うようにしたために)ヘッドフォンの音量が不足することがある件は、jack_mixerというソフトで音量を大きくすることで解決できた。複数の出力が出せるので、スピーカーで聴く時にも(アンプの音量を変える代わりに一時的に)調整できるし、音量メーターもあるのでちょっと便利だ。
  • GMBをJACKで使うと音量が不安定になる問題があったが、Gstreamerのplaybin(これが何かは分かってない)を作る時に"soft-volume"というフラグを指定しないようにしたら直った。この意味や、これで本当にいいのかは、良く分からない。ただ、基本的に、GMBの音量は変更しない(常に100%にしている)ので、問題はなさそうだ。
  • GMBはJACKへの接続を自動では行えないようで、それで手で接続しても再生を停止すると切れてしまうので、jack-plumbingというソフトで自動接続するようにした。
  • GMBの音を(PulseAudio経由でなく)直接JACKに出すメリット(音質がいい?)があるのかは全く不明だが、余計なものを通さないので(何かしら)良いと考えて、そうしている(はっきり言って、気分の問題であるw)。
  • 以前も書いたかも知れないが、JACKの接続状態を自動的に保存するプログラムを作った。ログイン時には、JACKの各プログラムの起動後、その保存された配線を復帰させるようにしている(qjackctlは僕には使いにくいため)。
    • なお、上記のjack-plumbingと接続保存プログラムは競合するので、jack-plumbingで自動接続した接続は保存しないようにした。
  • JACKにしたのではあるが、下位(ドライバ)にはALSAが使われているので、alsamixerというプログラムでサウンドカードの設定をする必要がある(そうしないと、音が出なかったり録音できなかったりする)。分かりにくいし、煩雑な点だ。
  • JACKにしたことで音質が良くなったということはないと思う。何となく、音がいい(低音や高音が良く出ている)ように感じることがあるが、気のせいか、音量が大きくなったせいか、イコライザを調整し直したためだと思う。
  • 昔、スリープからの復帰後にJACKの音が出ないことがあったのは、使っていたプログラム(qjackctl?)が悪かったのか余計なことをしたためなのか、分からない。今は、特に何もしなくても、スリープからの復帰後にJACKの音は出る。
  • JACKはWindowsでのASIOのような位置付け(仕組みは全然違うだろう)のように感じる。

画面

 

PS. 耳の痛みは、PEQの使い方(設定)以外に、PEQの仕様(中の作り?)にもよるようだ。というのは、さっき、いくつかの別なイコライザ(Calf EQ8, LADSPA DSP, TAP Eq/BW, Triple/Single band para. with shelves)を同じ特性にして試したところ、短時間しか聴いていないのだが、どれも耳閉感があったのだ。依然として謎は解けていない。 (3/25 15:05)

  •   0
  •   0

苦節3年じゃなく、教師生活25年じゃなく、41歳の春でもなくw、1か月に満たない期間ではあったが、謎が解けずに試行錯誤の連続だったJACKのイコライザの調整は、おそらく今日で終わりだ。見事、耳を痛くせずにRushの"Power windows"と"Hold your fire"を完奏できるイコライザ(PEQ)の設定ができたのだ。もちろん、前回書いたように、グライコタイプのイコライザmbeqを使えば問題なかったのだが、どうしても気に入らないので、PEQ(パラメトリックイコライザ)で実現した。

ただ、残念なことに、耳が痛くなった原因は分からず仕舞いだから、どうして解決できたのかも判然としない。今回、mbeqを実測値に基づいて調整しつつ簡素化・最適化した後で、試しにPEQ(前回使って印象が良かった、FIL-pluginsの4バンドPEQ(以下、PEQ4))を同様の特性にしてみたら、信じられないことに、耳が痛くならなかったのだ。

問題が解決できた理由を推測してみると、前にも書いたように、イコライザの使い方(設定)が悪かったのと、イコライザの特性(作り方)が関係しているのではないかと思う。今までは、右チャネルの80Hz付近の山を抑えるために、幅の狭いフィルタをそれ以外の低域の音量を下げるための広いフィルタに重ねていた(→ 参考: 図中のグラフの左の方の"P I"が"P II"に重なっている)のだが、今回はそれを止めて、フィルタが重ならないようにした(帯域の端では重なるだろうが、それは問題ないようだ)。

元々のグライコ(DEQ2496)のPEQはフィルタが重なる使い方をしても大丈夫だが(ただし、PEQの数が多いと駄目だった)、JACK(正確にはLADSPAやLV2)の多くのイコライザは駄目(混変調歪みが生じる?)なようで、そこが特性の違いなのかと思う。DEQ2496はプロ(「演奏者」という方が適切か)用なので、そういう問題が起こりにくい作りになっているのかもしれない。

一言で書けば、今回はPEQをグライコのような使い方にしたのだ。だったらmbeqを使えば良いのだが、フィルタの数(=補正処理の量)を減らして(mbeqでは6個だったのが3個に減らせた)、補正曲線をシンプルで美しくしたかったのだ。その方が音質の劣化が少ない気がする(実際、高調波歪みは少ない)し、趣味としての満足感があるw

大変マニアックだが、何をもって「綺麗」かそうでないかという話を書くと、グラフの左チャネル(上)だと、mbeq(紺)は1.2kHz辺りでの水平線との接続部が角ばっていて滑らかでなく、そこから200Hzまでの凸凹が急だし、200Hz辺りでの低域の曲線との繋がりに無理があって、滑らかでない。繋がりについては右チャネル(下)でも同様だ。そういう雑さは、mbeqがグライコだからであり、PEQ4(青)では全く問題ない。ただし、曲線の綺麗さが音質の違いに現れるかというと、まずないだろうと思うw が、一つ、急な凸凹は余り良くないとは思う。PEQはそういう点を細かく調整できるのがいい。

なお、耳が痛くなった原因が分からないので、他のイコライザでも同じ設定をすれば同じ結果になるかは分からない(設定は容易だが、試聴するのが面倒だし耳が痛くなるのは嫌なので、少なくとも今は試す気はしない)。

以下に、PEQ4の設定(識別記号="PEQ4-5")や補正後の特性を示す。僕の部屋用なので、設定自体には余り意味がない。特性はmbeq(識別記号="mbeq-2-4")や元のグライコ(DEQ2496)と比較した。

去年DEQ2496を設定してから部屋の特性が変わったようで(本棚をスカスカにしたせい?)、山の位置が変わったり(右: 80 → 144Hz)、新たな山(900Hz付近)ができていたので、それを解消するために設定を調整した。その新たな山が耳が痛くなった原因の可能性もあるが、同じ条件のDEQ2496では問題なかったので、違うだろう。

PEQは4個使った。ただし、2つ(中のSection 1と2)はそれぞれ片チャネルだけで使っているので、実際には3個である。当初は430Hzのフィルタ(Section 4)は入れずに3(2)個だけだったのだが、そこの山が気になったので追加した。

設定した特性の比較グラフは、イコライザで処理した音を(実際にDAC・スピーカーで出力してマイク・ADCで収集するのでなく、)PC内で直接分析した値(理論値)を比較している。

実測値の比較グラフを見ると分かるように、PEQ4-5ではDEQ2496と同等以上の特性が得られた。mbeqと異なり、PEQ4にはLowShelfフィルタが入っていないので、mbeqで気に入らなかった超低域(50Hz以下)の音量低下が回避できた(が、部屋の特性に起因する深い谷が55Hz付近にあるので、余りメリットがない)。また、サウンドカード(ASUS Essence STX II)のLPFは限界ギリギリ(約22kHz)まで通すため、DEQ2496での超高域(16kHz以上)の音量低下も緩和できている(ただし、僕には聴こえない)。なお、左右同時出力(グラフ: 上)での超高域の低下は、左右のスピーカとマイク間の距離差による干渉が原因である。右(グラフ: 下)の超高域の低下は原因不明で、測定に何らかの問題があったのかも知れない。

それから、今回、スピーカーの音を測定するために新しくマイクスタンドを買った。今までのカメラ用三脚を改造したものが駄目になりかかって(ポールを固定する結束バンドが緩んで来た)、マイクの固定が不安定になったためである。

新しいマイクスタンドを使って特性を測定

キクタニのMS-150Bにした。ヨドバシで約3700円だが、サウンドカードを買った時に貯まったポイントを使って約半額になった(他社では売価がもっと安いものがあったが、これが最安に近くなった)。高いだけあってしっかりしているし、つや消し塗装もちゃんとしていて、いい物だ。ただし、説明書は何もなく、組み立て方法が今ひとつ不明だったし、用途不明の金具があったりした。プロ用だからか?

なお、ブーム型のマイクスタンド(アコースティックギターで使うような物)は安かったのだが、脚(3本の棒)の設置場所を食うし、組み立てと分解(大き過ぎて、分解しないと恐らく収納できない)が面倒なことに気付いたので、ストレート型にした。

 

PS. こうやって特性が簡単(?)に測定・調整できるのはいいのだが、作業中はマイクの位置を動かしてはいけないので、椅子に座ってPCを操作することができず、マイクスタンドの脇に膝立ちせざるを得ないのが辛い。測定・調整用のサブPCでもあるといいのか? ああ、スマフォで(操作)できるといいな・・・

  •   0
  •   0

あれから更にいろいろ試したが、結論(どういう訳か、「Steve HarrisのMultiband Eq. (以下、mbeq)が最適」)は余り変わっていない。「余り」というのは、一つだけ、新たにいいものが見つかったのだ。それは、FIL-plugins(またはfil-plugins)の4バンドPEQ(以下、PEQ4)だ。

PEQ4はwebでの情報が少なく、バンド幅の設定もおかしい(オクターブでもQでもない)ので期待していなかったのだが、比べてみると、mbeqと同じくらいいい(耳に痛くない)。mbeqは超低域をカットしてしまい、たとえそれが聴感上問題ないとしても(趣味的に)好ましくないので、PEQ4で問題なければ使いたいと思って、しつこく試している。

PEQ4はバンド幅の設定の仕方がおかしいので、パラメタの調整には苦労したが、元の特性とそっくりにできた(グラフの形状が同じなので、今回は載せない)。試してみると、いつも使っているRushの"Power windows"はキツかったものの、その他ではほとんど問題ない。ただ、mbeqが最高なのはどうしても否定できなかった。

現在までに試したイコライザと評価は以下のとおりである。○△×などは評価で、基本的に上が良い。その次は僕が設定に使っている識別記号で、()内がイコライザの名前や説明である。

  1. ○ jr-mbeq-2 (Steve HarrisのMultiband Eq, "mbeq")
  2. △+? jr-PEQ4-1 (FIL-pluginsの4バンドPEQ, "PEQ4")
  3. △ jr-DSP-EQ-4 (bmc0のdspのDouble-pole peaking filterのeq, "DSP")
  4. △- calf-butty-PEQ+HPF-1 (Calf Jack Host(以下Calf)の5バンドPEQと高域通過フィルタ)
  5. △- calf-butty-PEQ+LS-2 (Calfの5バンドPEQとLowshelfフィルタ)
  6. ? jr-mbeq-3 (mbeq-2で6kHz付近を落としたもの)
  7. ? jr-PEQ4-2 (PEQ4-1で6kHz付近を落としたもの)
  8. ? jr-DSP-EQ-3 (DSP-EQ-4で6kHz付近を落としたもの)
  9. × butty-hpf-2 (calf-butty-PEQ+HPF-1を若干変更したもの)
  10. × calf-butty-PEQ+HS-12 (Calfの5バンドPEQとHighshelfフィルタ)
  11. × jr-tap-eq-bw-1 (TAP-pluginsの8バンドPEQ, バンド幅指定付き)
  12. × Calf EQ30 (Calfの30バンドEQ)
  13. × jr-TBWS-1 (Steve Harrisの3バンドPEQ)
  14. × jr-tap-eq-2-1 (TAP-pluginsの8バンドPEQ, バンド幅指定なし)
  15. × Calf EQ5 (Calfの5バンドPEQ)
  16. × EQ4Q (EQ10Qの4バンドPEQ)
  17. × jr-DSP-EQ-1 (dspで200Hzだけ幅広く落としたもの)
  18. × jr-DSP-EQ-2 (DSP-EQ-3で最初に全体を-3dB下げたもの)
  19. × carla-x42-1 (x42の4バンドPEQ)
  20. × jr-ls-1 (dspでLowshelfフィルタだけにしたもの): 耳は痛くないが、低域が不足して駄目だった。

DSPが意外に良く(dspのパッケージはいろいろな処理ができて便利なので、機会があれば活用したい)、Calf Jack Hostは手軽なのだが駄目だった。EQ10QもTAP-pluginsも駄目だった。

いろいろなイコライザを試すのと同時に、なぜそれらで音(耳の痛み)に違いが出るのかを考えた。結論は出ていないが、以下の点を疑っている。

  • イコライザ(PEQ)の使い方が良くない。
  • 混変調(正しくは「相互変調」とのこと)歪み(IMD)が生じている。
    • 6kHz付近に出る?
    • 超低域によるもの?
    • イコライザの作りによって生じる?
  • イコライザの作り(計算式またはプログラムの実装)が悪い。

PEQの使い方については、設定図を見ると分かるように、低域(右チャネルの80Hz付近)で2つのフィルタが重複している。このように使うと、(イコライザの作りによるだろうが)歪むのかも知れない。あるいは、図の低域(200Hzが中心)のように幅広く使うのが良くないのかも知れない。そして、それらに起因する歪みが6kHz付近に出る(だから、そこを下げると痛みが減る)のではないか。

その証拠に、mbeqはグライコタイプでフィルタが重複しない(実際には隣り合うフィルタは重なっているはずだが)ので、音が悪くないのではないかと思っている。

が、どちらも、検索した限りでは、「悪い使い方」として出て来なかった。もしかしたら、イコライザの常識なのかも知れない。

混変調歪みについては、超低域をそのまま出すと、イコライザかスピーカーで歪みが生じるのではないかと考えた。ただ、グライコ(DEQ2496)のPEQでも同じ条件なのに問題なかったので、スピーカーは関係なさそうで、イコライザの作りによりそうだ。

その証拠に、mbeqはたまたまにせよ超低域をカットしているので、音が悪くないのではないかと思っている。

そのイコライザの作りによる音の違いについては、あるとしかいいようがない。使っている計算式(この辺りは難しくて苦手で、全然知識がない)が適切でないのか、それをプログラムにする仕方が適切でないことが考えられる。後者の気がする(ほとんどのイコライザはオープンソースなので、プログラムを見られるが、面倒そうなので止めておく)。

ただ、誰も文句を言っていないので、すごく微妙なことなのか、僕がしているような特定の使い方で発現するのではないか。なお、イコライザの処理中のオーバーフローを疑って入力レベルを下げてみたが、効果がなかった。内部では浮動小数点で処理しているから、計算自体に問題はないのだろう。

という訳で、DACやフィルタやデジタルアンプを変えたら音が変わる現象は「ありまーす」になるw ただ、それは全然褒められることではなく、単なる処理の違い、しかも、処理が良くないために起こるのであって、何を使っても音が変わらないのが当たり前のことだと思うのは、変わりない。

だから、DACなどでフィルタを選べるのを売りにする会社なんて、単なる優柔不断な腰抜けだと思う。男なら(女でも)、最高の一個で勝負して欲しい。

追って、スピーカーの音を実測して各イコライザの「音(特性)の違い」を調べ(果たして測定できるのだろうか?)、最適なもの(mbeqかPEQ4)を決め、実測値に基づいて微調整をしたい。

  •   0
  •   0

珍しく1週間空いた。年度末で仕事が超忙しかった訳ではなくw、ひたすらJACKの調整(耳が痛くなる原因の究明と、そうならない設定・方法を探す)をしていた。毎晩夜更しで寝不足だ。それで疲れ果てて、昨日は、「もう飽きたし、(内蔵サウンドカードやJACKを使うことに意味はなく、普通の女の子に戻りたいに音楽を聴きたいから)止めようかという気になっていた。

ただ、それでも諦めないのが僕のしつこいところだ。折角買ったサウンドカードが無駄になるのが癪だというセコさもある。それで、昨日、もしJACKが音を悪くする(僕の耳に痛い)なら、PulseAudio(JACKでない、Linuxの普通のサウンド・システム)で使ってみようかと思った(正確には、「もしPulseAudioで耳が痛くならないなら、JACKが原因であることが分かる」ということ)。

ただ、PulseAudioだと使えるイコライザがほとんどなくて不便なのだが、調べたら、JACKで使っているもの(LADSPAプラグイン)を使う手があることが分かった。ただ、それをちゃんとやるのは面倒なので、まずは、手軽に使えるイコライザ(pulseaudio-equalizer)を今までのグライコの設定に近くして聴いてみることにした。

意外なことに、勘で目分量で設定したのにも関わらず、数回でかなり近くできた。ただ、左右別の設定ができないようなので、右だけ下げる箇所(80Hz付近)は一旦諦めた。

聴いてみると、JACKの時と同様に、耳が塞がるようになってそのうち痛くなそうな感じがすることがあったが、(JACKの場合は1分以内に痛くなることが多いのに、)2時間近く経っても決定的に痛く(聴くのが「嫌」としか言いようがなくなる)はならなかった。それで、PulseAudioでは問題が起こらなそうなことが分かり、更に、JACKと共通に使っているサウンドカードやDACにも問題がなさそうなことが分かった。

pulseaudio-equalizerについて少し調べたら、内部では、Steve HarrisのMultiband Eq (mbeq)というLADSPAプラグインを使っており、それはJACKでも使えるので、実際にJACKに入れて同じ特性にして、耳がどうなるか試すことにした。もし問題なければ、耳痛の原因は、ほぼ、JACKで使っていたイコライザ(Calf Jack Hostの5バンドイコライザなど)ということになる。

約2時間経過したが、PulseAudioの時と全く同様に、そのうち痛くなりそうな感じなのだが、決定的に痛くはなっていない。もう少し様子を見る必要はあるが、JACKは問題ではない可能性が高い。まあ、それはそうで、そんな基本的なモジュールが原因で音がおかしくなったら、みんな文句を言うし、使われないだろう。

だったらイコライザが悪いということになるのだが、それにしたって、みんな使っているのに耳が痛くなるほどいい加減なものばかり(1個だけじゃなく、複数が駄目だった)というのは信じがたい。個人(体質)的なものなのだろうか?

一方、元のグライコ(DEQ2496)では問題なかったから、やっぱりソフトがどこかいい加減なのかも知れない。まあ、DEQ2496でもPEQで補正し過ぎると痛くなったので、イコライザの性質や特性ということなのだろうか。

とはいえ、今やっているのは「補正し過ぎ」とは言えない程度の軽い補正だから、性質や特性としたら、ほとんどのイコライザは「使えない」ものなのだろうか? もしそうだとしたら、そんないい加減ものに大切な音を任せていいのか?!という話になる・・・

(22:11) 仕事じゃないので、上記の重要(で難しい)な問題は一旦置いておいてw、mbeqとJACKは概ね問題なさそうだった。ただ、元々の補正からずれているという欠点がある。下図のように概ねいい感じなのだが、超低域や右チャネルの80Hzが駄目だ。超低域は、mbeqの仕様で最低の帯域(50Hz)がLowshelfフィルタになってしまっているためだ。これが普通のに切り替えられれば良かったのに・・・ あと、どうしてか、歪みが多いという問題もある。低域で多く、多いところでは約0.6%(-45dB)もある。

まあ、特性は大体合っているし(そもそも、ズレの大きい50Hz以下なんて、僕のスピーカーではほとんど出ない帯域だ)、歪みだって聴いて分からないから大きな問題はないのだが、欲深い僕は、もうちょっと良くしたくなった。

既に書いたように、耳に優しいイコライザはほとんどないのだが、Calf Jack Hostの30バンドイコライザ(EQ30)は、mbeqと同様に(PEQでなく)グライコなので、もしかしたら耳が痛くならないかも知れないと思って試してみた。PEQに慣れるとグライコの設定は逆に面倒だ。特にこれはバンド数が多く、しかも、左右別でコピー機能なんでないので、それらを一個ずつ設定するのはなかなかの苦痛だった。見た目は壮観で格好いいけど、僕はもう中二じゃないのでw

余談: 「中二」と書いて思い出した。僕はその頃、本当にグライコ(PEQではダメだった)が欲しくてたまらなかった。画像のような、ずらっと並ぶのが欲しかったが、ものすごく高くて、全く無理だった。それで、数バンドのを作ろうかとか思ったが、それすらも高かったし、意味がなさそうだったので止めた気がする。あと、同様にスペアナも欲しかったが、やっぱり手に入らなかった。それが、今では、PCでタダで実現できるんだから、是非当時の僕に教えてあげたい。でも、教えても、逆に悔しがるだけかw

特性を見ると、ガタガタでいかにも音が悪そうだったのだが、聴いてみると、意外に悪くなかった。そして、耳の痛みに関してはmbeqと同等だったので、これを試すことにした。また、見た目に反して歪みも問題なかった。こっちは高域で大きくなるのだが、最高でも0.006%(-85dB)程度で、100倍良くなった。

周波数特性がガタガタな理由については良くは分からないが、平滑化をしていないためだと思う。その音が問題ないのは、このグラフは周波数領域で、それを聴く訳ではなく、人間が聴く時間領域に変換すれば滑らかになるのだと思う。実際、時間領域で大変滑らかな正弦波は、周波数領域では鋭い縦線になり、見た目では鋭い音になりそうだが、そんなことはない。

なお、EQ30のフィルタはバタワース型にした。チェビシェフ型は周波数特性が更にガタガタ(櫛型になっている)なので、さすがに問題ありそうだからやめた。

EQ30の欠点は、CPU負荷が常時約20%と高いことだ。こんなに帯域(30バンド×2= 60バンド)が多ければ、処理量も増えるだろう。ただ、それでも、PC全体では90%程度がアイドル時間になっているので、大きな問題はなさそうだ。

音に関しては、約4時間聴いているが、試聴に使っているRushのアルバムではキツい点もあったものの、それでもmbeqと同等だし、普通のビートルズのアルバムでは、耳痛については全く問題ない。これで決着すればありがたいのだが・・・ ← 今ココ

もしこれがOKなら、あとで、(とても面倒なのだが、)スピーカーの音を測定して微調整したい。ビートルズの曲でベースが不自然に強い箇所があったので、グライコの調整が要るようだ。元の特性で、超低域を持ち上げている(実際には、その手前で下げたのを戻しているだけ)のが余り良くなくて、もう少し控える方がいいのかも知れない。あるいは、単に部屋の共振周波数に合っているために、どうしても下げられない音だったのかも知れない。

そして、頑張ってEQ30を設定したものの、mbeqが最適(しかも、何十個でなく、たった数個の設定でほとんどの条件を満たすうえに、見た目も美しいwのは、すごくスマートじゃないか)な気がして来たが、実測値を見て考えよう。

(つづく)

 

PS. 以下、前回から今までに試したことを列挙する(特に記載のない限り、耳痛に対して効果はなかった)。

  • 別のイコライザにしてみる。 → 以下を試したが、どれも耳痛が起こった。
    • EQ4Q Stereo, Triple band parametric with shelves
  • (単音でなく、)ピンクノイズでイコライザの周波数特性を測って、問題の有無を調べる。 → 特に問題はなかった。
  • DeEsserというフィルタで、高音が強い時だけ下げることを試した。
  • JACKの設定をデフォルトにしてみた。
  • 音楽再生アプリ(gmusicbrowser, GMB)からPulseAudioを経由せずに、直接ALSAからJACKに入れてみた。
  • サウンドカードのデバイス名の指定を変えてみた。
  • GMBの出力をGstreamer(音楽再生・処理モジュール)でなくmplayerにしてみた。 → 有意の差はなかった。
  • 構成図を描いて状況を整理し、耳痛の原因となるすべての可能性を再検討した。
    • PCのオーディオ関係の構成図 (上: JACK, 下: 従来)

  • 消去法により、以下が耳痛の原因である可能性が高そうだった。
    • JACKで使っているイコライザ: 何らかの原因により、6kHz辺りの音が異常(混変調ひずみ?)になっている。
    • サウンドカードのドライバ: (今考えると、別のドライバを使っているであろう、元のグライコでも耳が痛くなったので、無関係だろう)
  • RMAAというソフトで混変調ひずみ率を測ろうとしたが、Windowsアプリのためか、うまく動かなかった。その後、一般的な「混変調ひずみ率」は特定の周波数2個しか使わないので、今回は意味がない可能性が高いことに気付いた。
  • 超高域(>=10kHzなど)を更に下げてみたが、元のグライコ(DEQ2496)では下げていないにも関わらず問題はなかったので、無関係なことに気付いた。
  • 再度、6kHz辺りを下げてみた。 → やっぱり、効果がある感じだった。
  • JACKのバッファサイズを減らしてみた。
  • ピンクノイズで元のグライコの周波数特性を測った。 → 補正している帯域以外は概ね平坦で、特に変わった点(例: 6kHz付近の定常的な上昇)はなかった。
  • DACの入力オーバーでのひずみを検討したが、理論上、起こらないことが分かった。そもそも、通常時のレベルメーターの目視で最大レベルが-3dBを超えることがないのにも関わらず耳が痛くなるので、無関係なことが分かった。
  • ディザーを入れていないための量子化ひずみを疑い、JACKに設定してみたが、特に改善はなかった。そもそも、ディザーは量子化ビット数を減らす時に、微小音で起こるものなので、今は関係ないことが分かった。
  • クラシック音楽では耳の痛みは全く起こらないので、違いを調べたが、(予想どおり)ポップ音楽は高音成分がかなり多いことが分かったので、再度DeEsserを試したが、イコライザとの違いは感じられなかった。
  • 元のグライコに戻したら、やっぱり、耳痛は起こらなくなった。
  • DACのロールオフ特性を"Slow"にしてみた。ただ、元のグライコでは、同じDACで音を出しているにも関わらず、PC側をJACKにした場合だけ耳が痛くなったので、これも関係ないことが分かった。
  • 再度、ピンクノイズやホワイトノイズで、元のグライコとJACKのイコライザの特性を比較した。 → 大きな違いはなかった。
  • PulseAudioを使うことや、新しいサウンドカードを諦めて元のグライコに戻ることも選択肢に入れることにした。
  • PulseAudioを調べたら、意外にいろいろな機能があるので、JACKでなくても必要条件(特に、2つの出力(スピーカーとヘッドフォン)に対してイコライザの有無を独立に設定できる)が満たせるかも知れないことが分かった。
  • (JACKでなく)PulseAudioを使った時に耳痛がどうなるかを試したところ、大丈夫そうだった。

PS2. 耳痛に関する進捗は今ひとつなのだが、それ以外はかなり進歩した。JACKを使うにはqjackctlというアプリを使うのが定番なのだが、僕にはすごく使いにくいので、自分で代わりのプログラムを作って、qjackctlを使わずに済むようにした。

その結果、JACKのモジュール間の接続(仮想的な配線)をCarla(このシリーズには似たような名前の同様な機能のソフトがいくつかあるが、Carlaはイコライザなどのモジュールの追加もできるのが良い)で行うことができるようになり、とても便利になった。また、接続が変わったら自動的に保存し、あとで復帰できるようにするプログラムも作ったが、Carlaの機能を使えば不要なのかも知れない。

Carlaのパッチベイ (配線状態)

更に、今までは、スリープとスリープからの復帰時にいろいろな処理をしていたが、qjackctlを止めたおかげか、何もしなくて済む(復帰後に何もしなくても、ちゃんと音が出る)ようになった。

PS3. イコライザを確認する時に聴いたのは、Rushの"Power Windows" (1985)や"Hold Your Fire" (1987)が多かった。高域が強いようで、駄目な時はすぐに「来る」のだ。どちらも大好きなアルバムだが、何度も聴いたうえに痛い目にも遭っているのでちょっと良くない・・・ こんなオーディオマニアのような聴き方から早く脱却したいものだw

  •   0
  •   0

グライコ(DEQ2496)を使わず、PCのJACKの(ソフトの)イコライザで音質を補正した時に起こる耳の痛みが解決したかも知れない。

今のところの原因は、特定の周波数(6.2kHz付近)の音が僕の耳を攻撃していたことのようだ。

前回の対処の、超高域(>=16kHz)を下げるのは、やっぱり駄目な感じだった。その辺りの特性を微調整しても駄目だったので、耳の痛くなる周波数を探して、下げてみることにした。

最初は、良く言われている、4kHz辺りを試したが、どうも効果がないようだった。それで、耳が痛くなりやすかった曲(例: 戸川純 "Joe le Taxi")を掛けたり、周波数を変えながら正弦波を出して、耳の感じを探った。なかなか分からなかったのだが、半ば勘で6.2kHz辺りとして、そこを3dB下げてみた(Q=5)。

耳が痛くなる辺り(6.2kHz)を下げてみた(赤, DACは通さずに測定)。 (黒はオリジナル(グライコ= DEQ2496))

なお、前回原因と考えた、超高域(>=16kHz)は無関係のようなので、カットしないことにした。もちろん聴こえないからどっちでもいいのだが、例え意味がなくても「(とりあえずスピーカーからは)原音再生」が理想なのでw、そのまま出すことにした。それに、フィルタ(信号処理)は少ないに越したことはないから、そのままでいいならその方がいい。

悪くない感じで、まだ2時間くらいしか聴いていないが、(若干兆候はあるものの)まだ耳は痛くなっていない。これが解かどうかは分からないが、もしそうだとしたら、この辺りの音は、僕の苦手な音(例: 黒板を引っ掻いた音、発泡スチロールをこすった音)なのかも知れない。当然、そういう音には個人差があるので、これは僕だけの設定になる。

不思議なのは、グライコ(DEQ2496)から音を出した時には耳が痛まないことだ。もう、「相性」と言うしかないのか。その正体として考えられることはもう余りないのだが、混変調ひずみ特性あるいはマスキングのようなものが関係あるのかも知れない。

サウンドカードは特定の帯域に混変調ひずみが出やすく、グライコはそうでない、あるいはその逆(例:グライコ固有の特性のために、複数の音が出た時に問題の周波数が出にくくなる)なのだろうか。そして、これは、測定用の信号(単音)では起こらないから、グラフを見ても分からず、音楽を再生した時だけ出てくるのかも知れない。

だから、良く言われる、「数値に出ない音」ってのはこういうことがあるのかも知れない。とはいえ、それは、即座に「ケーブルの構造や材質で音が変わる」のようなことが正しいことは全く意味しない(良くこじつける人が居るが、大きな問題だ)。ここで言っているのは、測定困難なだけで、物理量としては定義可能な特性に音が影響されているということで、測定できない(あるいは、理論上、無関係とか存在しない)「何か」(例: 声掛け、「波動」)に音が影響されるということではない。

もちろん、まだ解決したとは決まっていないので、あくまでも現時点での推測だ(そういうのを考えるのが楽しいので、未確定にも関わらず書いている)。

そして、超高域を出しているにも関わらず(現時点で)大丈夫ということは、少なくともそこは原因でなかったということだ。だから、「聴こえない音」は、やっぱり、耳から脳には伝わらず、脳には何も影響を及ぼさないことになる。つまり、ハイレゾは僕には無意味ということになり、多くの中高年にも意味がない(益も害もないし、違いを知ることもできない)だろう。もちろん、趣味なので買うのは自由ですがw

 

現在のCalf JACK Hostのイコライザ

 

PS. JACKだと、今回のように、DACを通す必要のない特性の測定は、(本物のケーブルを接続しなくても)パッチベイで出力と入力を接続するだけで測れるようになるので、すごく便利だ。そういう点では、JACKにした価値は大いにあった。

パッチベイ (仮想的な接続状態)

PS2. 6kHzの謎を調べたくて検索していたら、アマチュア無線用の短波帯トランシーバの音がいいとかいう記述があって、「はぁ?!」と思ってちょっと読んだら驚いた。今のは光デジタル音声入力(オーディオ用と同じ!)があるそうで、更に調べたら、光デジタル出力、USB、LAN、シリアルポート、更にはディスプレイ端子まで付いており、しかもDSP内蔵だそうで、パソコン以上だ。そんな最新兵器に昔ながらの大きなM型アンテナ端子が付いているのは、何ともおもしろい。でも、僕だったら、PCのスロットに挿す、トランシーバーカードがいいな。ソフトでいくらでも機能を追加・変更できるような。既にあるかも知れないが。 (21:21)

PS3. 耳管の共振周波数は9-10kHzというのを読んで、6.2kHzの代わりに9.5kHzを落としてみたが、どうも駄目だった。イヤフォンなどで耳を塞いだ場合は6-7kHzになるようだが、今回は開放しているので関係なさそうだ。いずれにしても、耳管の共振周波数と不快な音の周波数が同じ必然性はない。謎は深い。(23:16)

  •   0
  •   0

先日から気になっていた、グライコ(DEQ2496)の代わりにJACKの(ソフトの)イコライザで音質を補正した時に耳が痛くなる問題。いろいろ試したのだが、なかなか原因が分からず、対処できずにいた。それで、いろいろ検索したところ、耳が痛くなるのは、高域(4kHz以上)が強いことが原因という話が多かった。それで、イコライザでその辺りを下げてみたのだが、やっぱり効果がなかった。

さらに、90Hz付近のPEQのQ(山や谷の急峻さ)の設定がいい加減なためかと、帯域幅からQを求める方法を見つけて調整したのだが駄目だった。そんなこんなで第8案までやったのだが駄目で、残ったのは、今まで耳が痛くならなかったグライコの特性を測定して、それにJACKの特性を合わせることだった。ただ、そもそも今のグライコの特性はJACKのに近似させて作ったので、それに合わせる意味はないと思った。(2/22 17:56追記: 調べたら、JACKに近似させたあと、グライコ側で微調整していた。)

ただ、それまでの手がことごとく駄目だったので、もしかしたら、グライコとJACKの特性が微妙に違っていて、それが耳に痛い周波数帯の可能性がありそうだったので、改めて測定してみた。すると、以前は見落としていたことに気付いた。超高域である。グライコ(グラフの赤線)は約16kHz以上が落ちているのだ。一方、JACK(ベージュ色)は「そこまで律儀にやらなくても、誰も文句言わないよ」と言いたいほど、限界(約20kHz)まで綺麗に伸び、ストンと落ちている("JACK"とは書いたが、実際にはサウンドカードの仕事だ)。

右チャネルの特性比較 (DEQ=DEQ2496, JACK=Calf Jack Host。見やすいようにレベルをずらした)

何年も使っていたのだが、グライコ(のDAC)が意外にも超高域をカットしていることに初めて気付いた。間違ってそういう設定にしたのか、そういう仕様なのか、回路がしょぼいのか、経年劣化したのか分からないが、とにかく出ていない。(2/22 11:07追記: これはグライコDEQ2496の仕様の可能性がある。PS2を参照のこと。)

僕はそんな高い音は聴こえないから、出ていても関係ないとは思ったのだが、周波数特性の違いはその程度なので(その他に位相特性もあるのだが、未知数である)、試しにイコライザで落としてみた。まだ余り聴いてないが、前よりはましな感じがする(が、まだ耳が痛い気もするので、下げる量が足りないのかも知れない)。

もしこれで効果があったら(= 耳の痛みの原因は超高音)、僕はそういう超高音を音としては認識できないが、感じてはいるということだ。ということは、良く言われる、「ハイレゾの音は、聴こえなくても(可聴帯域外でも)身体で感じる」という説が正しいことになる。ただ、僕のような者にとってはハイレゾなんて苦痛でしかなさそうだがw

素人考え: 「身体で感じる」と言っても、実際には耳で感じていると思うのだが、脳ではそれが音とは認識されないということなのではないか。ただ、何らかの「感じ」がする(結局は脳の神経の電流になるのか)ので、聴こえないはずのハイレゾの違いが分かったり、(僕とは逆に)ハイレゾが心地よく感じる人が居るのだろう。

それから、サウンドカードやスピーカーの性能がすごいのに驚いた。無駄にいいと言ってもいいくらいだw いずれにしても、音(再生の忠実度)が良過ぎて駄目なことがあるなんて、全く信じられない。

という訳で、今日はいろいろと認めたくないことがあった。

 

(2/22 13:39追記) 「謎が解けた!」と思ったのだが、ちょっと腑に落ちないことがあるのに気付いた。前回JACKを試した時も、音を出すのにグライコをのDACを使っていたなら、やはり超高域がカットされていたはずだから、耳は痛くならなかったはずだ。オンボードのDACを使えばあり得るが、ちょっと考えにくい。あれから何か構成を変えたのだろうか? あるいは、グライコで処理した音をDACで出す時だけカットされる(=グライコがバイパスモードで、DACだけ使っている時はカットされない)のか? (← 実際に測ったら、バイパスモードでもカットされていた) この問題はなかなか奥が深そうだ。

(2/22 16:38追記) もう意地になって、耳が痛くないグライコの特性をJACKに移して(自分のをコピーw)みた。

右チャネルの特性比較 (黒=DEQ2496, 赤=Calf Jack Host)

これなら「何も文句はない!」はずなのだが、それでも何となく耳が痛くなりそうな気配がするのだから不思議だし、気に入らない。「DACで音が変わる」ってやつだろうか・・・ やっぱり認めたくないものだ。むーん。

もしかして、イコライザ・フィルタの位相特性の問題なのだろうか? 確かに、グライコの時も、グライコやPEQを多用したら耳が痛くなった。だとすれば厄介だ。けど、いろいろなフィルタを探して試せば、中にはいいのがあるかも知れない。純然たるデジタルのシステムだけど、アナログ的な音作りは要るようだ・・・

(2/22 16:58追記) JACKにコピーした特性の位相を調べてみたのたが、基本的には問題ない。

右チャネルの位相特性の比較 (黒=DEQ2496, 赤=Calf Jack Host)

JACK(赤)で超高域(16kHz以上)の位相がおかしいのは、フィルタ(LPF)を掛けているためで、仕方ない。この辺りは振幅が小さくなっているので、影響は少ないはずだ。それにしても、DEQ2496のLPFはすばらしく素直で感心する。やはり、本物だけのことはあるのだろうか? これはDACチップ(AKM製)内蔵フィルタの特性なのだろうか? 正直言って見くびっていたのだが、すごいと思う。

と書いたものの、実はAKMも最後の方は位相が乱れており、JACKの線の下に隠れているだけだ。本当にすごいのは、今のサウンドカード(TIあるいはASUSのフィルタ)だ。グラフは載せないが、超高域カットをしない場合、最後まで全く破綻せず、-60°までしかずれてない。「素性がいいDAC」というのは、こういうことなのかも知れない。

ただ、それで耳が痛くなったらしょうがないのだがw

(2/22 18:20追記) まだ余り時間は経ってないが、今度は大丈夫な気がする。確かにちょっとキツい感じはするが、疲れとか風邪で調子が悪いせいかも知れない。しばらく様子を見よう。やっぱり、超高域はカットするしかないのだろうか? もちろん聴こえないし痛いからそれでいいんだけど、なんか損した気分だw

(2/24 10:08追記) 位相と振幅が最適なフィルタを探したところ、意外にも、中低域の調整に使っているCalf Jack HostのPEQ(5バンドイコライザ)のHighshelfフィルタが良かった。なるべくグライコ(DEQ2496)に近い特性になるように設定を調整した(→ 目標値: -25dB@19.25k, Q: 0.85になった)。以下に位相と振幅特性の比較を示す。Highshelf(緑)では今までのCalfのLPF(赤)の20kHz辺りからの位相の乱れがなくなった。振幅も、グライコよりわずかに傾きが小さい程度である。こちらの方が19kHz辺りまでが小さ目なので、僕には好ましい気がする。また、処理モジュールが1個で済むのも好都合だ。

高域の位相特性の比較 (黒: DEQ2496, 赤: Calf LPF, 緑: Calf Highshelf)

高域の振幅特性の比較 (黒: DEQ2496, 赤: Calf LPF, 緑: Calf Highshelf)

聴いた感じは、今までに比べて「耳触り」が良く、くつろげる気がするが、今はクラシックを掛けているせいかも知れないし、昨日より体調がいいせいかも知れないし、気のせいかも知れない。 → 残念ながら耳が痛くなった。傾きが小さいせいだろうか?

いずれにしても、デジタルでもアナログのように音を変える要素はあって、音作り(または調整)の作業が必要なことを痛感した。僕の目指していた原音再生とは異なるが、聴き疲れするのでは元も子もないので、仕方ないのだろう。

 

PS. 帯域幅からQを求める方法(式)は、「音響とか / Sound and Acoustics」が参考になった。今度はいつ使うか分からないが、ちょっと知識が増えた。参考のために、肝となる式を書いておく。

オクターブバンドの帯域通過・除去フィルタの中心周波数: fc,
下限周波数: fl, 上限周波数: fh (それぞれ、-3(または+3)dBとなる周波数),
Q値: Q
の時、以下の式が成り立つ。

fc= sqrt(fl * fh)
Q= fc/(fh - fl)

これにより、グライコのPEQのfcと帯域幅(「xオクターブ」)が分かれば、fcと帯域幅からfhとflを求めることで、Qが求められる。

PS2. グライコ(DEQ2496)の仕様を見てみたら、超高域の低下の原因が分かったかも知れない。仕様では、

周波数帯域: 10Hzから35kHz(-1dB)@ 96kHz Sampling Rate

となっている。充分広いように見えるので、「ふーん」と通り過ぎそうだが、良く見ると、上限の35kHzが曲者の気がする。これが、サンプリング周波数が44KHzの場合には比例して下がるとしたら、

35/(96/2)*44/2= 16kHz

になり、上の測定結果のとおりではないだろうか? 口コミで読んだ記憶がないので、今まで誰もこれに気付かなかったのか、みんな知っていてそんなもんだと思っていたのか、内蔵DACを使う人は少ないのか。まあ、何でもいい。僕にはありがたい仕様ではあったw

なお、同じ仕様書でGEQやPEQなどの帯域は"20Hz - 20kHz"となっているので、デジタル出力を使う場合には超高域の低下は問題なさそうだ。が、ハイレゾ指向の人には向かなそうだ。

いずれにしても、ずっと気付かなかった仕様の不備(というか、気付かなかったことが不備)ではあるが、僕には怪現象の原因が分かったことの方がうれしいw (2/22 11:05)

  •   0
  •   0

昨夜、サウンドカード(ASUS Essence STX II、以下、"Essence")が届き、早速PCに取り付けて動作確認を行ったところ、アナログ入出力とデジタル(光)出力のすべてで問題なかった。ただ、OSの設定をしてから時間が経っていたために、いくつか思わぬトラブルがあった。

  • LANインタフェースの名前が変わり、一時、ネットに接続できなくなった。
    • サウンドカードを付けたために、LANインタフェースの番号が変わったため。
  • OS(Linux)がスリープしなくなった。
    • 上記と同じく、LANインタフェースの番号が変わったため、スリープ中にLANなどから不意に復帰されないように設定するプログラム(自作)が、LANのデバイスがないためにエラーになって、スリープ処理が中断していた。
    • 暫定対応したが、デバイス番号を決め打ちにするのでなく、もっと柔軟にしたい。

一番気になっていた電源on/off時の雑音は見事に出なかった。少しは出るだろうと思っていたが、全然出ない。出力にリレーが入っているせいだろう。期待以上だ。これで、アンプをonにしたままPCを停める(スリープにする)というずぼらができるから、ちゃんと使えればすごく楽になりそうだ。

周波数特性も雑音レベルも素晴らしく、日常で使うのに何も問題ない。

周波数特性は約10Hz-22kHzで平坦(-0.5dB程度)、雑音レベルは-120dB程度だった(サンプリング周波数は44.1kHz)。なお、雑音特性のグラフの上部の赤線はフルスケール参照用のホワイトノイズ(-3dB)である。

その他、動作確認の時に気付いたことは以下の通りである。

  • 前もって知っていたが、出力をラインとヘッドフォンで切り替える時に雑音が出る。ただ、このカードにはヘッドフォンは繋がないので、問題ない。
  • このカードはオペアンプが交換でき、交換用工具(ラジオペンチのようなもの)が付いているのは知っていたが、交換用オペアンプ一式(1個はMUSES 8820、他の2個の型番は見えない)まで付いているのは意外だった。もちろん、僕は意味(価値)を感じないので、交換しない。
  • デジタル出力は同軸・光だが、光は棒状のアダプタを同軸ジャックに挿入して使う。そのアダプタの突き出し量が結構大きいため、ぶつけてアダプタが折れるリスクが高いので、光接続で使うのは実用的でない。ただ、このカードはアナログ出力を目的に買ったので、大きな問題ではない。
  • ASUSのサイトの記述だと、光アダプタはそのように書いてない(「S/PDIFアダプタ」のようにしか書いてない)ので、買うまで、期待する物が添付されているか不明だった。

という訳で、Essenceは期待以上の良い製品だった。そして、電源on/offの雑音が出ないのに気を良くして、予定を早めて外部グライコ(DEQ2496)から乗り換えたくなり、今朝の早朝から、Jack(Linuxのサウンド出力方式の一種)で使えるようにし始めた。デフォルトのPulseAudioではまともなイコライザを通せないためである。

Jackを使えるようにしたのは随分前のことで、その時も試行錯誤していたうえにずっと使っていなかったので、どうすれば使えるようになるのか思い出せず、当時書いたメモ・ブログやプログラムを調べて、ようやく分かった。

なんとかJackで音が出るようになったのだが、何となく耳が痛い(前回もそうだった)ので、今、それを何とかしている。原因は良く分からないのだが、どうも、Jackを良く理解していないために、同じ信号を異なる経路で重複して同じ出力端子に接続していたからのように思う。その間違いを修正してからは、痛くなくなったように思う(もう少し様子を見る)。

Jackの画面 (下左: パッチベイ、下右: イコライザ)

PulseAudioと違って、Jackは各(仮想)機器間を自由に(仮想的に)配線できるので、例えば、今回買ったEssenceのライン出力にはイコライザを通した音を出し、オンボードのライン出力には(ヘッドフォン用に)そのままの音を出すということが容易にできる。ただ、デバイスやイコライザがいくつもあるので、上図のパッチベイのように、配線がごちゃごちゃになるし、各デバイスを配線できるようにするための手順も結構ある。また、スリープ(サスペンド)に対応させるのも、面倒だ。

また、Jackはどうもこなれてない感じで、ちょっと設定や操作を失敗すると音が出なくなったり、最悪の場合OSがハングするので、慣れるまでは神経を遣う。あと、Jackは出力デバイスのサンプリングレートを指定するのだが、指定以外のサンプリングレートの音がどうなるのか気になるところだ(面倒だし怖いので、まだ試していないw)。 → 44.1kHzの設定に対して、16, 32kHzが問題なく再生できた。指定した値に自動でリサンプルするようだ。リサンプルせずにそのまま通せばいいと思うが、とりあえずはいい。

最後に、これだけすごい特性のサウンドカードではあるのだが、(今は耳の痛みはなくなったので、)搭載しているDACチップPCM1792Aのおかげで音が良くなったとか、悪くなったとか変わったとは思わない(何となく音に迫力が出た気がするのは、再生音量が大きいためかプラシボ効果だろう)。それはもちろん予想通りのことだ。DACは、単に、デジタル信号をアナログ信号に変換する「ケーブル」のようなものであるべきなのだから、それで音が変わってはいけないので、ごく当たり前のことである。例えば、水や空気に味や匂いがあったら耐えられないようなものだ。が、それが分かってないメーカーやマニアは多い。

PS. まだ少し耳が痛む。ただ、これは今のサウンドカードを入れる前からJackでは起こっていたので、サウンドカードによる音の変化(劣化)ではなく、Jackのイコライザの設定がグライコと違うためだと思う。実際、PEQではパラメタが違うもの(グライコでは幅(oct.)だがJackではQ)があり、換算方法が分からないので適当に設定しているのだが、それが関係していそうだ。もう少し調整が要る。 (2/21 6:40)

  •   0
  •   0