Archive for the ‘PC・技術’ Category

昨日だったか今朝だったか、ニュースで「バ美肉」なる言葉を見た。初めての言葉で意味が全く分からなかったし、その字面に面食らったのだが、記事は「チェンバロからバ美肉装置まで 「2018楽器フェア」でさまざまな楽器を体験してきた」という題だったので、ーベキューのに音楽を聴かせて、おいしく(味に)する装置だろうかと思った。が、中身を読むと全く違っており、単なる(Vtuber用の、)声を変える装置だったのでがっかりした。それにしても、僕の想像した装置の方がずっとおもしろいし、パナ辺りが出しそうではないかw ただ、それを「楽器」というかは不明だが。

他に、以前「微レ存」というのを見たが意味を調べずに放置していたので、さっき調べたら、余りおもしろくなかった。もっと学術的な言葉に関係しているのかと思った。

 

PS. それにしても、「楽器フェア」にチェンバロを出すとは、随分場違いというか、(いや、何も間違ってないんだけど、)思い切ったなあと思った。実際、記事には、うるさくて弾いても音がよく聞こえなかったみたいに書いてあったし。でも、そういうところで、さらっと「フランス組曲」(の頭)などをちゃんと弾けたら、さぞかし(スタバでのMac以上に)ドヤれるのだろうかwと、今思った。まあ、あこがれるし羨ましい限りである。そして、そういううるさいところだったら、是非、スタインウェイかなんかのグランドピアノを力一杯にうならせたいと思ったが、脱線しすぎだろう。

  •   0
  •   0

昨夜、どうもThunderbirdが重いので再起動したら、スケジュールが出なくなってしまって慌てた。それで、アドオンをみてみたら、ほとんど全滅していた。どうも、Thunderbirdのバージョンが大きく上がった(自動更新されたようだ)せいらしい。Firefoxみたいなことをしたのだろうか。何でもいいけど、連絡とかアナウンスはして欲しいし(勝手に更新するのだから、その前にメッセージを出すくらいできるだろう)、それまでのアドオンを使えなくするのは、全くセンスが悪い。

このまま当分駄目だったら、スケジュールはスマフォで見るしかないかと思い掛けたのだが、いろいろ調べて、基本的には駄目になったアドオンを一旦削除してからインストールすれば回復できることが分かった。が、それでもインストールできないものがいくつかあった。スケジュール(Lightning)もそうで、どうしてか、Linuxからパッケージをインストールするか、新しいThunderbirdに対応した開発版を入れるしかなかった。あと、アドレス帳のための追加モジュール(Inverse SOGO connector)も駄目になっていたが、アドオン自体がなくなったようだ。まあ、元からうまく動いていなかったので、仕方ない。こちらは、別のアドオン(CardBook)で何とかはなっている(が、不便だ)。

更に困ったのは、アドオンを再インストールするにしても、駄目になったものも単に「無効」(使っていないと同じ)の状態になっているので、それまで何を使っていたか分からなくなってしまったことだ。それまで使っていなかったアドオンなら入れないけど、使っていたなら入れる必要がある。一つどっちか分からないものがあり、しかもインストールできないので、困った。

無料で使っているから何をされても仕方ないけど、突然こんなことをするのはクズ(無責任)だ。それで、以前も書いたように、過度のThunderbird依存(メール・スケジュール・アドレス)を解消したいという思いを強くした。が、Evernoteと同じで、いいのがないんだよなあ・・・

それにしても、ただでさえユーザーが少ないのに、こんなMSや林檎みたいに勝手なばかりことしていたら、更に減るだろうに。Mozillaは大丈夫なのかねえ・・・

 

PS. 昨日入れたものの使い方(設定方法)が分からなかった、TbSyncという、スケジュールとアドレス帳の同期を行うアドオンの設定の仕方が分かり(ステータスバー右下の"TbSync"を押すと設定が出る: これはちょっと嫌だ)、Lightning(の同期部)とInverse SOGO connectorの代用になりそうなので試してみることにした。こっちはMozillaのように変なことはしなさそうだ(本当に?w)。

  •   0
  •   0

消費税を上げたら、キャッシュレスで支払うと還元するとかいう案がある話を読んだが、馬鹿馬鹿しいにも程がある。期間限定にしたって、返すんだった最初から上げなきゃいいのに。そもそも、増税とまったく関係ないキャッシュレスを結びつけるところに、日本らしいセンスのなさ・頭の悪さ・合理性の欠如が見える。結局、目先の餌で騙そうって魂胆なんだろうな。新聞の1か月無料とか携帯料金の1年間割り引きと同じようなものか。

そして、さっきスーパーでイライラしたことから、悪夢のような光景を想像してしまった。もし、プリペイドカードで還元されるようになったら、多くの人が

毎回千円ずつチャージして払う

のでは?

まったく浅はかとしか言いようがない。何の意味があるのだろうか? 店員だって手間が増えてしょうがない。誰得って感じだ。でも、やる人は多いんだろうな。もう、始まる前からストレスが溜まるよw

 

PS. さっき、小額でチャージする意図を考えたのだが、

  • カードを失くした時・盗まれた時の損失を抑えたい。
  • チャージしてから使うまでの利子を店に得させたくない。

程度だ。

失くした時の話は現金だって一緒じゃないか。(カードを裸で持つ人は論外として、)失くす時は財布ごとだろうから、そっちの方が被害が大きくないか?

利子の話は正しいけど、仮に今、1万円を1年間放置して、いくら利子が付くかねぇ??

はい論破w

  •   0
  •   0

Spotifyの純正アプリがメモリーリークする件だが、どうしても直らず、自動で再起動する処理を追加したものの、ほぼ毎日再起動する感じで、いつ再起動したらいいか気を遣わされるという腐れ具合がどうにも嫌になくなってしまった。

それで、ダメ元でLinux用Spotifyアプリを検索してみたら、Nuvola(正確には、Nuvola Apps Runtime + Spotify script。以下、Nuvola Spotify)というプレーヤが出て来た。以前も試したことがあるのだが、GPMのプレーヤ同様、webページをアプリにしているだけなので、意味がないから止めた。ただ、今となっては、そういうしょうもないものでも、メモリーリークさえしなければ使う価値はあると思った。実際、検索する前は、(一見それなりに使えそうな)web版Spotifyを自作のミニプレーヤ(minisp)に繋げられないかと考えていたほどなので、もし、Nuvola SpotifyにDbusの機能があれば、純正アプリと同様に繋げられる可能性が高いので、再度試すことにした。

結論としては、機能は期待以上のものだった。Dbus(MPRIS2)に対応しているし、純正アプリが実装していなかった音量取得・設定機能すらある。あと、ウインドウを閉じても終わらないようにできるのがうれしい。更に、少し動かしてみてもメモリーリークする気配はなかった。

それで今日、Nuvola Spotifyをミニプレーヤとリモコンにくっつけてみた。が、いつものように予想外のことがいろいろあって、結構な作業になり、丸一日掛かった。それでも何とか動くようになった。

そして、いくつか問題点や気に入らないことがある。多くは元々のweb版Spotifyの欠点であるのだが・・・

  • Web版Spotifyの問題
    • ジャケットが表示されていると、ウインドウの背景の色が勝手にジャケットの系統の色に設定されて、趣味が悪いだけでなく、ものすごく見難い。しかも、変更できない。
    • プレイリストの曲操作が使いにくい(例: 複数曲の選択ができない)。 → とても不便。
    • 曲のジャンプができないことが多い(曲名をクリックしてジャンプできず、前か次にしか行けないことが多い)。 → とても不便。
    • クレジット(演奏者など)の表示機能がない・・・ → とても不便。ミニプレーヤに追加しようか?
    • プレイリスト(Daily mix)の再生が進んでも、表示が更新されない(現在再生中の曲が見えなくなる)。 → キューを表示すれば、再生中の曲が見える。
    • 純正アプリと同様、頑固に、検索などに日本語が入らない。NuvolaやNuvolaが使っているブラウザの問題なのかも知れない。
  • Nuvola Spotifyの問題
    • 表示をズームできるのはいいのだが、倍率を変えた時の品質が汚くて実用にならない。 → 結局、等倍で使っている。
    • Dbusで来るイベントの内容・タイミングが純正アプリと違う。 → なんとか対応した。
    • 動作が遅い・重い? → 要改善
      • 曲の切り替わり通知タイミングが純正アプリより遅い。そのため、音量正規化の音量設定タイミングが遅れて、一瞬大きな音が出ることがある。: GPMと似たようなもので、ブラウザを使っているから仕方ないのかも。
      • 子プロセス(ValacefSubprocess)が若干重い。
    • 音量の設定が謎
      • 以前も書いた、0..1あるいは%だけど、実態は対数のような感じ。 → 暫定対応したが、要調整(較正)。

こうして書くとさまざまな問題があって、作っている最中にも、何度か「あ”ー面倒臭い、止める!」と放り出して純正に戻したい気にもなったのだが、使用メモリ量に関しては、約6時間で10MB程度しか増えていないので(最初は全然増えていないと思っていたのだが、良く見たら増えていたので、ちょっとがっかりした。僕としては、この程度だって増えて欲しくなかった。時間が経てば解放処理が動いて減ることに期待している)、その点では充分に価値がある。しばらく使ってみて、どっちがいいか決めたい。ただ、今までの経過を見ると、純正アプリは今後も修正・改良される可能性はないので、Nuvola Spotifyに期待(、あるいは自分で改造)する方が良さそうな気はする。

まあ、「根はいい人なんだけど、雑なのよねえ」と言われる人と「美人だけど、素直じゃないし、何もしないのよねえ」と言われる人の選択だろうかw

(10/15 21:54追記) 今日もほとんど一日掛かりっきりで修正・改良し、タイミングずれを改善した。Dbusのイベントの仕様が違うために曲の切り替わりを落としていたのが大きかった。あと、音量の設定もdBから設定値(0..1)への式(結局、10のべき乗のようだ)を導けたと思ったのだが、なぜか期待する音量にならないことがある。どうも、Nuvola Spotifyの音量の式や曲線が違うのか、音量設定処理が不安定なのではないかと思う。仕方なく、純正アプリと同様にPulseAudio側の音量を変えるようにした。

が、そこまでしたにも関わらず、web版Spotifyのひどさに全く我慢できなくなり(あれはゴミとしか言いようがない。本当に使うことを考えていないし、メンテされてない)、純正アプリに戻ろうかと思っている。純正アプリの更新はないと思っていたが、以前出たsnap版とかいうののバージョン番号が更新されていたので、そっちを試している。が、若干の変更・修正はあるものの、やっぱりメモリ・リークは直ってなさそうだ。

賢くて性格は悪くないけど大食いでデブな人と、化粧が濃くて高い服を着ていて目をひくけど、実際にはセンスが悪く、スリムだけど頭も顔も性格も悪い人の、究極の選択かw

(10/16 7:24 若干追加・修正)

 

PS. 測定して比較した訳ではないから証拠はないのだが、どうも、Nuvola Spotifyは音質が悪いように思う。今、純正アプリで聴いていると、普通に「すっ」と聴けて、音は全然悪くないのだが、Nuvolaの時は何となく嫌な感じがしていた(明らかに変ということはない)。Nuvolaのベースはweb(ブラウザ)なので、音を出す仕組みも「それなり」のもの(Widevineというアドオンが関係している?)だろうから、音質(特に時間軸の精度(=ジッター)か?)が劣化しているのかも知れない。 (10/16 16:17)

  •   0
  •   0

先日、ニュースで、某国のグループが音楽配信サービスに不正にアクセスしてチャートの順位を上げている疑惑を読んだ。

それで思い付いた。SNSの友人とかいいねの数を水増しするように、音楽配信サービスの再生数を水増ししてお金を稼ぐことを。

  1. とりあえず、プロダクションとレーベルを作る。
  2. 架空のグループを作り、売れない作曲家や作詞家と売れないアーティストに依頼して曲を揃える。信ぴょう性を上げるため、ビデオをYouTubeにも入れ、SNSのアカウントも作り(ただし、メンバーの詳細は伏せ、顔も出さない)、曲をダウンロード販売するサイトも作る。
  3. 作った曲・アルバムを音楽配信サービスに配信する。
  4. 音楽配信サービスで指定した曲を連続して再生するプログラムを作り、複数のPCやスマフォにインストールする(マイニングマルウェアのように世界中にばらまくと、効率が良い)。
  5. そのプログラムに、でっち上げたグループの曲やアルバムを指定して実行する。

ウマー?w

ある日突然、無名のグループがチャートの上位になったという話題で持ち切りになって、本当に売れるかも知れないな。でも、結局、これは仮想アイドルとかYouTuberの水増しと同じことで、うまく行かないのか?

問題点は、曲を再生するにはサービスの会員になる必要があるから、自分たちだけで入会して水増しするのではコストがペイしないってことだろう。あと、曲は途中で停めずに全部再生しないとお金が減りそうだから、時間も掛かりそうだ(その点は、曲の使用料と月額会費との比が絡むが、きっと、高額をせしめるには時間が全く足らないだろう)。更に、電気代も掛かるな。。。そういう点ではマルウェアで大規模にやるしかない? あとは、無料会員でも聴けるサービスでアカウントを乱造?

(21:51追記) 別件で検索していたら、配信サービスの使用料が分かった。 : "What is the best alternative to Spotify?"のDeeser musicのCONSより:

Doesn't pay artists enough
Deezer pays artists significantly less than other similar services. As of March 2018 it was paying $0.0064 / play, less than Apple Music and Google Play, half as much as Tidal ($0.0125). Not as bad as Spotify or Pandora, but could certainly do better.

上の情報が正しくて、仮にSpotifyの使用料がDeezerと同じとすれば、156回再生してようやく1ドルのようだから、なかなか割に合わない。仮想通貨のマイニングとどっちが儲かるのだろうか・・・

一方、AIが高性能になったら、作曲家も作詞家もアーティストも不要になり、どんどん曲が作れそうだから、コストは節約できそうだ。

もちろん、あくまでも空想です。実行してはいけません。

 

まあ、上の1から3までなら本当の音楽制作で、お金にならなくたって、まじめにやれば、それで充分楽しそうではないか。僕はそっちでいいやw

  •   1
  •   0

昨日、Spotifyの音量正規化がようやく何とかなったと一息ついていたのだが、ふと気付いたら、なぜか空きメモリがほとんどなくなっていた。道理で近頃Spotifyが重いような気がした訳だ。実際、何がメモリを食っているか調べたら、そのSpotifyが10GB以上食っていた(こういうのを「メモリー・リーク」という)。それは重くなるわなあ。。。

まずは、アプリの最大使用メモリ量を数GBに制限したのだが、抜本的な解決方法を考えるために、原因を調べた。ミニプレーヤの関係(Dbusで繋げているため)かと思ったが、結局、アプリ自体が悪いようで、既知の問題("Massive memory leak under Ubuntu 16.04 LTS" (2018/6/14))だった。そして、その投稿へのSpotifyからの回答はなし・・・

仕方ないので、どうにかして解決あるいは緩和できないか調べている。再生したりプレイリストを開くと増えるし、そもそも、何もしなくても増える。今は、アプリの内部情報を消さずにいて溜まっているせいではないかと考えて、起動時のオプションに"--trace-file=/dev/null"を指定して試しているが、半日も経たないうちに使用メモリ量は200MB近く増えて1.3倍になっており、期待できない。

"--trace-file=/dev/null"を指定しないと、起動直後の使用メモリ量が2倍近くになるようなので、指定した方がいいようだ。 (15:10)

(10/13 6時、6:43追記) Spotifyアプリのキャッシュ(~/.cache/spotify)と設定(~/.config/spotify)を削除すると(設定の削除は不要かも知れない)、使用メモリ量の増加速度が小さくなるようだ。1/3くらい(12MB/時)に遅くなった。それでも、メモリー・リークが直った訳ではない。キャッシュのデータ量は10GBにもなっていたので、定期的な削除が要りそうだ。というか、して欲しい・・・ ← 削除しなかったらもっと大きくなるはずだし、自分でも自動削除するようにしていて忘れていた。予想よりデータ量が多かったので、もっと頻繁に削除が要るのかも知れない。

どうしても駄目なら、アプリの使用メモリ量がとても多くなった場合には、長時間アイドル時にアプリを再起動しようかと思っている。以前はミニプレーヤで音量正規化の切替時に再起動していたから(今まで気付かなかったのは、これで頻繁に再起動していたからだろう)、実現するのは簡単だ。が、どうにも気分が悪い。(それに、ミニプレーヤのプログラムがどんどん肥大化するのも嫌だw)

→ つまらない機能を作るのが面倒なので、定期的にSpotifyアプリの使用メモリ量をチェックして、大きくなり過ぎていたらメールで通知するようにした。メールが来たら、自分で再起動すればいい。急激に大きくなる訳ではないから、それで充分だ。何でも作ればいいってもんじゃないw

→ 使用メモリ量の変化を見ていたら、毎日再起動したくなりそうな速さ(数MB/分 → 1GB/日以上)で、そんなに毎日手で再起動するのは面倒なので、自動再起動機能を作った。 まったく手が掛かる奴だw なお、使用メモリ量が多くなってアイドル時に自動再起動する時は、メニューボタンの背景色を変えて分かるようにした。あと、メモリ量のチェックを2段階にして、2番目のしきい値を超えたら即座に再起動するようにした。つい、遊んでしまう。こういうのを「芸は身を滅ぼす」というのだろうかw (19:15)

気になるのは、その問題自体よりSpotifyの対応なり動向だ。他にも問題や変なところが放置されているから、そのうち手に負えなくなって、「Linuxアプリは止めまーす!」とか言い出しそうな気がしている。それはとてもまずい。。。 まあ、その時でもWeb APIは継続するだろうから、それを使って自分でプレーヤーを作るか、他の対応プレーヤーを使うかだろうか。あとは、ミニプレーヤを純正のwebプレーヤーに繋げることができれば、それが一番いい。

でも、それよりも、Spotify自体が終わりになることが一番怖い。その時はどこへ移ろうか? 消去法でAmazonしかない気はするw あとはDeezer(ここは高いからないけど)などの新手のものかな。

  •   0
  •   1

ニュースを読んでいたら、「Googleの追跡から逃れよう」みたいな良くある記事(大抵は徒労なのだがw)があり、そこに、No More Googleという、Googleのサービスの代替手段を人気順に示すサイトが紹介されていて、なかなか参考になった。

特に良かったのは、Authyという2段階認証用のトークン(数字)生成アプリ・サービスだ。Googleの認証アプリの代わりに使えるのはもちろん、PCでも動く(Chromeのアプリ・アドインやWin用アプリがある)から、PCのブラウザでログインする時も、いちいちスマフォ(のアプリ)を開かずに済み、トークンも(目で見て)手入力でなくコピー・ペーストできるようになった。だから、トークンを打ち込んでいる最中に時間切れで変わって慌てることがなくなるw

更に便利なのは、各デバイス間でログイン情報が共有されることだ。Authyのアカウントを作っておけば、PCでもスマフォでも同じようにトークンが生成できる。あと、ログイン情報のバックアップもできるので、スマフォが壊れたり紛失しても大丈夫そうだ(その時は、それ自体が痛いのだがw)。

なお、ログインするサイトの登録は、QRコードを読ませる関係で(PCで文字列をペーストするのも可能だろうが)、スマフォの方が便利だが、上記の共有機能のおかげで、スマフォで登録してPCで使えるから便利だ。

リスクは、Authyからの情報流出(サーバにどの程度のログイン情報が保存されるのだろうか? その情報で偽のログインができるのだろうか?)やサービス終了だが、前者については信じるしかない。後者はいかようにもなるから大丈夫だ。

(20:23追記) 偽ログインの可能性を考えてみる。: Authyのサーバには、少なくともパスワードは入っていないから、すぐはできない。ただ、サイト登録時の情報にはサイト名(例: Evernote)は入っているだろうし、アカウント名(例: メールアドレス)が入っている場合もあるので、安心はできない。サーバに入っているトークン生成用情報から正しいトークンが作れるので、もし、トークン生成用情報とアカウント名が漏れ、その上でパスワードが推測されたら、偽ログインは可能そうだ。そういう意味では、便利さを捨てて、サーバに情報を保存しない方がいいのは確実だ。

サイト登録時のトークン生成用情報(QRコード)にサイト名やアカウント名などを追加しているのはサイト側であり、それは2段階認証の効力を自分で薄めているので、いかがなものかと思う。全く余計なお世話だ!

 

PS. ちなみに、検索は少し前にDuckDuckGoにした。ただ、どうしても期待する情報が出て来ない時はGoogleに切り替えている。他にも、ブラウザ、パスワード管理、メール、DNS、ドライブ、フォト、天気、カレンダー、アドレス帳などは使っていない(または依存していない)。もちろん、Google+は使ってないw 要は、Googleの右上のメニューに出るものは、地図を除いてほとんど使っていない。Chromeも常用していないが、通常のブラウザとは別のアクセスをしたい時に、Firefoxと併せて使っている。まあ、Androidスマフォを使っている時点で「負け」なのは認めるがw

僕は、Googleの個人情報収集や追跡などから逃れるよりも(まず無理だし、彼らのサービス利用料のようなものだから、仕方ない)、彼らへの依存を避けることで、いつ彼らの気が変わっても困らないようにしたいから代替サービスを使っている。他のサービスも同様で、予期せぬサービス終了などのリスクを避けるために、自由に他社に移行可能なサービス(= オープンシステム)を選び、高くなければ有料サービスも使う。OSについても同様で、MSやAppleがどんなにアホなことをしても、「へぇ、なんか大変だね」と、高みの見物をしていたい。

(10/12 7:36 使っていないGoogleのサービスを追加、わずかに加筆)

  •   0
  •   1

近頃はプログラミングばかりしていたので、ドライブしたくてうずうずしていた。訳ではないのだが、余り車に乗らないで調子が悪くなってしまうのが嫌なので、ちょっと出掛けた。今回は手軽にしたかったので、久し振りに上三依水生植物園(日光市)に行くことにした。

8時頃出発した。いつものように気持ち良く走れた。途中の塩原は混みそうだと心配していたのだが、どうしてか空いていた。時間が早かったせいだろうか。

10:15頃着いた。シーズンでないせいか、駐車場はガラガラだった。園内も同様だった。でも、その方が静かでくつろげるからいい。紅葉はまだだった。

11:45頃、周り終えた。そもそも、あそこは意外に広いのだが、のんびりしていたせいか、意外に時間が掛かった。事務所に、生まれた日ごとの花名のポスターが貼ってあるのだが、それを見ていたオジさんが一緒のオバさんに、「(彼の)生まれた日は役所のが間違っていて、実際とは違う」とか言っていた。「そんなのどうだっていいから、本当の日で見ればいいだけじゃん!」と思ったが、まあ、そういう話で盛り上がろうとしたかったんだよねw

終わり近くにデジカメの電池が切れてしまい、その後はスマフォで撮影した。この電池は2個目なのだが、最初から切れやすかったので、どうも偽物臭い。ただ、Amazonなら良くあるようだが、ヨドバシでも偽物のことがあるのだろうか?

それはともかくとして、以前あんなに(naokiさんに頂いた)リコーGX100を褒めておきながら、今日は「IXYも手に馴染んで、さっと使えてなかなかいいなぁ」と思った(もう10年近く使っているから当たり前だが)。ただ、肝心の撮影には難しいところがある(滅多に「綺麗」に撮れない・・・)のだが、今日は結構良く撮れた(数枚、我ながらすごいと思うのがあった)。どうも、晴れて日射しが強いよりも、曇って暗目な方がいいようだ。光学系や撮像素子の性質なのだろうか。だとすれば、あれにはNDフィルタ(暗くするもの)が内蔵されているので、それを自分で使えればいいかも知れない。

この頃から晴れて、まぶしく・暑くなった。お腹が空いたので、久し振りにコークを飲んだ。キャンピングカーで来た家族の子どもたちが、閉店になった蕎麦屋の横にある、ブランコが沢山ぶら下がっているような遊具で遊んでいたのが、のどかだった(以前行った時は、この遊具は朽ちていて使えないと思っていたが、大丈夫だったようだ)。それから、実家近くのデニーズで昼食にすることにした。

途中、アホトラックが居た。最初は小型車の後ろにピッタリ着いてあおっていたのだが、その車が居なくなって先頭になったら、センターライン超えを連発して、対向車の迷惑になっていた(数台停めていた)。それができない時は遅くて、まったく、プロドライバーの風上にも置けない奴だった。そのアフォだけでなく、他の車も、そんなに速くもないのに(いや、いくら速くたって、センターラインを超えなくてはならないなら、それは「遅い」のだが)平気でセンターライン超えをしていたので、呆れた。そういうの同士がぶつかればいいのにと思う。それに引き換え、僕の後ろにいたクラウンは終始紳士的だったので、感心した。高齢者が多いせいか、平均するとちゃんとした人が乗っているのだろうか。

14:20頃、ようやくデニーズに着いた。いつものように、空腹・眠気・トイレに悩まされた。旧例幣使街道で、前にずっとマイペースな車が居り、眠気が増して辛かった。あの車が居なければ、もう少し気持ちよく走れたのだが、あそこは狭いから無茶しない方が良かったのは確かだ。

食事は白身魚の西京漬け焼きにした。サラダやノンアルコールビールなどを頼んだら、2千円くらいになった。途中で羊羹を食べたせいか、おかずが多かったせいか、珍しくご飯を残した。前回も思ったのだが、やっぱり、味が落ちた気がする。店によるのだろうか。あと、店長らしき人はあいかわらず挨拶ができない(前回も今回も、支払いにレジに行っても無言)ので、すこぶる印象が悪い。もちろん、小泉さん(仮)は居なかったから、もう、あそこは止めようかと思う。帰路の途中から疲れがすごかったのだが、食べたら結構回復した。

壁に貼られた絵を見たら、手を繋いだ子ども7人うち、2人は猫とキリン(?)だったので、なごんだ。不思議なことに、猫もキリンもズボンをはいていたのは、ドレスコードがあるのだろうか? (上下逆だが、)プーさんと同じ論理か?w

16時頃、帰宅した。「疲労困憊」だった。どうしてこんなに疲れたのか考えたのだが、運動不足はあるだろうが、撮影に気合を入れたせいもあるかと思った。無理な姿勢で構図を選び、息を停めて腕を動かさないようにしてシャッターを押し、老眼なので眼鏡を外して画面を確認する(しかも、駄目なら再度・・・)のは、結構キツい。。。

毎回書くようだが、運転しながら、僕の車は、軽いせいか、スピードとかパワーの乗りがいいと感じた。余計な慣性が少なく、アクセルを踏んだだけスコっと動く感じだ。そのうえか・そのせいか、滑るように走れて、すごく心地良い。それでスピードを出さなくても気持ちいいのだ。収入がないせいもあるけど、滅多なことでは乗り換えたくない。大体、新車なんて、気を遣うことが多くて面倒だ。

約7.5時間、160km。「手軽に」と思いつつも、いつもと同様になった。
IXY Digital 3000ISとAQUOS sense liteで撮影。珍しく写りが良かったので、100枚以上撮った。

(10/9 7:02 若干、加筆・修正。以前撮った遊具の写真へのリンクを追加)

  •   0
  •   0

Spotifyの音量正規化機能は大抵はうまく動いているのだが、曲によっては音量や音自体がおかしくなることがある。特に、Pink Floydの"Speak to me"(1973)の先頭のように音量がとても小さい時に破綻する。それでも、Google Play Musicのように、ないよりはずっといいのは確かだ。

が、近頃、SpotifyのWeb APIが使えるようになり、その中に曲の(音的な)特徴を取得する機能があるのに気付き、それを使って音量正規化ができないかと思っていた。具体的には、"Get Audio Analysis for a Track"(以下、Analysis)や"Get Audio Features for a Track"(以下、Features)が使えそうなので、調べてみた。

すると、どちらでも音量正規化に必要となる特徴量(曲の音量)が取れそうなことが分かった。具体的には、それらで取得できる"loudness"や"energy"である。なお、Analysisは取得できる情報は多いものの、上記の値程度しか使わないし、毎回分析するのか処理が遅いので、Featuresを使うことにした。

新しい音量正規化の処理として、以下のような手順を考えた。

  1. 新しい曲の再生開始時に、Features APIを実行し、音量の特徴量を取得する。(→ L)
  2. Lから、音量を正規化するための音量調整量を求める。(→ G)
  3. GをSpotifyの音量値に変換し(→ V)、設定する。

いくつかの曲で試したところ、音量の特徴量Lとしては、loudnessが良さそうだった。定義(概要)は以下のようなので、理論上はそのまま使えそうだ。

The overall loudness of a track in decibels (dB). Loudness values are averaged across the entire track and are useful for comparing relative loudness of tracks.

なお、energyの定義(概要)は以下のようなので、うまくLに変換できれば、(数値でなく)聴感的な音量の正規化ができそうなのだが、いい方法が思い付かなかったので、今回は見送った。

Energy is a measure from 0.0 to 1.0 and represents a perceptual measure of intensity and activity.

GMB(gmusicbrowser)での音量正規化の結果と比較して検討し、loudnessをそのままLとして使う場合、LからGへの変換式は以下とした。

G= X - L

Xは目標とする(一定にしたあとの)再生音量(dB)で、試行錯誤の結果、-13(dB)が最もGMBの音量に近くなったので採用した。

(10/12 6:26追記) 後から気付いたのだが、上のXは正確には2つの要素からなる。一つは、目標とする音量Yであり、これが仮想的な0dBとなる。もう一つは、正規化した音のシステムの最大音量(0dB)からの余裕Zであり、Yの音量は実際のシステムでは-Zとなる。音量をYに正規化したあと、音量(振幅)はZまで大きくなることが可能である。XはYとZの和であり、通常はY= Z= X/2と設定するので、上のように書いても大きな問題ではないが、動作の調整・確認をしている時に「何かおかしい」と思ったので書いた。

ただ、これは考え過ぎとか誤解だと思う。今、書いたあとに気付いたのだが、Yは実際には「平均」音量であり、もしYを「最大」音量(0dB)とすれば、Z= 0となる(それで充分)だから、Y= Xとなり、上の変換式はそのままで正しい。最初は最大音量と考えてその式を書いたのに、実際の動作を見ているうちに誤解したのだろう。 (だから、この節は書かなくても全く問題ないのだが、忘れるために書いておくw)

が、更に気付いたのは、Lはloudnessであって最大音量ではないので、やはりYは平均音量と考えるべきで、やっぱり上の節は要る。別の考えをすれば、Lに係数が要るのかも知れないということだ。その係数は、その曲の振幅の変化量(= ダイナミックレンジ)を示す値だろう(が、それはSpotifyでは分からない)。

Spotifyの音量を調整するには、アプリの音量そのものを変更する以外に、Spotifyアプリのあとにアンプやミキサーを入れてそれで調整する手がある。しかし、外部プログラムから手軽にゲインを変更可能なものが見つからなかった(MIDIを使えば制御できそうではあった)のと、できるとしても結構大げさになるので、今回は見送った。

Spotifyアプリの音量を変更するには、(現在のSpotifyアプリはDbusでは音量が調整できないため、)Spotifyアプリにウインドウシステム(X11)経由でイベント(キーやマウスホイール)を送ってボリュームを操作する方法と、PulseAudioのSpotifyアプリのボリュームを設定する方法がある。後者は音量値にdBや相対値が指定でき、pactlコマンドで簡単に実行できるので採用した。

上記のように、音量値にdBが指定できるので、基本的に、GがそのままSpotifyの音量値として使える。ただし、Gが大き過ぎる(例: 0よりかなり大きい)と音質が劣化するので、上限(Vmax)を設けることにした。今回はLは6(dB)とした。結局、Spotifyの音量設定値V(dB)は以下のようになる。

V= G (G < Vmaxの時),
     Vmax (G >= Vmaxの時)

ただし、pactlコマンドの仕様により、符号付きの値は現在値からの相対値になってしまい、負のdBは相対値とみなされるために(、結局全然)使えないので(どういうつもりなのか、作者に聞きたい)、pactlに指定する時に0..1の数値(R)に変換している。これはdBから数(比率)への変換で、以下のとおりである。

R= 10(V/20)

ここで不思議だったのは、Rをpactlに指定すると期待どおりの結果にはなったのだが、設定後に取得した音量の%の値が想定と異なるのである。例えば、"0.5"を指定すると、結果は"50%"でなく"79%"となる。dBの値は"-6.02dB"と正しいが、%はどうもおかしい気がする。本来は50%になるべきと思うのだが、%の値も対数なのだろうか。謎ではあるが、実際の音量や聴感的には期待どおりなので、深くは考えないことにした。ただ、将来的に、バージョンアップなどでこの動作が変わってしまうリスクはある。

pactlコマンドでSpotifyアプリの音量を設定するには、以下の手順で行う。

  1. Spotifyアプリのsink-inputのIDを得る。→ siid
    • pactl list sink-inputsの出力を解析する。
  2. Spotifyアプリの音量をRに設定する。
    • pactl set-sink-input-volume siid Rを実行する。

上記の処理を実装して聴いてみたところ、概ね期待通り動いている(→ 曲が変わるとボリューム(画面中央下部)が動くデモ)。ただし、以下のような問題がある。

  • 曲の切り替わりの検出に時間ズレが生じることがあるので、音量設定タイミングがずれることがある。
    • 音量の小さい曲の後に大きい曲が掛かる場合、音量を下げるのが遅れる場合があって、その時には、次の曲の先頭が(一瞬)大音量で再生されてしまう。
    • 逆に、音量の大きい曲の後に小さい曲が掛かる場合、音量を上げるのが早過ぎる場合があって、その時にも、次の曲の先頭が(一瞬)大音量で再生されてしまう。
  • 曲によっては少し大きく感じることがある。
    • 例: Commodores "Easy", CHIC "Le Freak"

曲の切り替わりの検出精度は、Spotify API自体にズレがあるので、容易には向上できず、本質的な解決は難しいのだが、音量を一気に変えずに、1回の変更量に上限を持たせて少しずつ変えるようにして(ただし、音量を下げる時は2倍の速さにする)緩和を試みた。また、変更前の音量が0dBを超えている場合は、超過分を一度に下げるようにした。この修正の都合で、pactlへの音量設定値を、比率(R)でなく現在の音量とVの差分にした(結局、符号付きのdB指定(相対値)だけでも良くなった)。

(10/3 12:23追記) 曲の頭が一瞬大音量になることがある問題は、JACKのエフェクタを使えば緩和できるかも知れない。Spotifyの出力を、瞬間的な大音量を抑えるようなエフェクタ(リミッター?)につなぎ、音量正規化がonの時だけそのエフェクタをonにすれば良さそうだ。エフェクタの制御は本アプリ(Spotifyミニプレーヤー)からMIDIで行う。おもしろそうだが、パラメタの設定は難しそうだ。余りにも気になるようなら、やってみたい。

この場合は、音量正規化もJACKでできる。Spotifyの出力をミキサーのSpotify用入力につなぎ、その音量を本アプリから行えばいい。上記エフェクタの入力レベルが変えられるなら、それでも可能だ。ただ、これ自体の価値はそれほどない。あくまでも、大音量を抑えるついでにできるということだ。

大きく聴こえる曲は、今のところどうしようもない。数値で正規化する限界なのかと思い、採用を見送ったenergyがうまく使えないものかと思っている。ただ、GMBの正規化でも同様なことはあるし、自分や周囲の状態によっても音量は違って聴こえる(要は「気のせい」)から、あまり深追いしても仕方ないのかも知れない。

(10/6 21:22追記) 音量で気になっていることの一つは、静かな曲の音量が大きくなり過ぎることなので、それを解消するのに上記のenergy(以下、E)を使って音量設定値Vを調整してみた。

静かな曲はloudness(L)が小さいためにVが大きくなるので、音量が大きくなりやすい。一方、そういう曲はEも小さいので、Eの大きさ(小ささ)でVを調整することを考えた。Eが小さい時は、その分Vを減らすのである。

Eがどういう単位・仕様の値なのか不明(0..1ということだけ明らか)なのだが、試行錯誤して、Eの値をdBに変換してVに加える(Eは0より小さいので、実際には引かれる)ようにした。Eで調整した音量設定値V'は、次の式で求められる。

V'= V + k * 20 * log10(E) (E >= Eminの時)
      V + k * 20 * log10(Emin) (E < Eminの時)

kはEの強さを調整するための定数で、0.05から0.3程度が良さそうであるが、いろいろな曲で試したところ、0.15辺りが最も適当だった。ただ、曲によって変わるので、更に調整が要りそうだ。Eminは想定する最小のEで、0.0001とした(log(0)はエラーになるので、それを防ぐために定義している)。

この式は全くの思い付き(と誤り)から出て来たものである。Eの詳細が不明なので、そのままdBに変換していいのか怪しいが、VはdBなので、VをEで調整するのなら、少なくとも、EをdBに変換した値を使うのは適切だと思う。

残念ながら、この方式は、元々音量が小さくなくて更に大きく聞こえる曲(例: 上記の"Easy"や"Le Freak")には効果がない。それらはEが大きいため(だから、うるさく聞こえるのだろう)、ほとんどVが減らないからである。それらには別の特徴量が使えるのかも知れない。

(10/9 11:09追記) 音量でもう一つ気になっていることは、クラシックの曲の正規化がうまく行かないことだ。クラシックの曲はポップ音楽と違ってダイナミックレンジ(音量の幅)が広く、平均音量が小さいことが多いため、ポップ音楽と同じように正規化すると音量設定値Vが10dB前後ととても大きくなってしまう。一方、DACは0dB以上の音は再生できないので、音質が劣化する。

これに対処するには、まず、目標音量Xを下げて(例: -20dB)、(形式的な)増幅の余地を増やす必要がある。また、10/6の追記とは逆に、energy(E)に応じて音量設定値Vを増やす方が良さそうだ。そこで、E(のdB値)に応じてloudness(L)を増やすことにした。ただし、LがXより大きい場合に更にLを増やすと、Vが減って逆に音量が下がってしまうので、Lを増すのはLが小さい場合だけにした。クラシック音楽用の音量設定値V''は、次の式とした。

V''= X' - L''
  X': クラシック音楽用の目標音量 (dB)
  
  L''= L' (L' < X'の時)
        L (L' >= X'の時)
  
    L'= L + m * 20*log10(1 - E) (E >= Eminの時)
         L + m * 20*log10(1 - Emin) (E < Eminの時)

mはEの強さを調整するための定数で、いろいろな曲で試したところ、0.05辺りが最も適当だった。また、X'は-24dBとした。これらも継続して調整が要りそうである。

なお、目標音量をかなり下げるために音質の劣化が心配だが、まず、ほとんどの場合に実際の設定音量は0dB付近になるため、大きな問題はない。なお、仮に設定音量が目標音量と同じくらいになった場合には音の有効ビット数が減るため、音質が劣化する。その有効ビット数は、元の音を16ビット相当(ダイナミックレンジ: 約100dB)とした場合に設定音量を-24dBに落とした場合には、概ね (100-24)/6= 12.7ビット程度になる。この場合でも、有効なダイナミックレンジは76dB程度あるはずだ。

実際に、いろいろな音量の曲に対してこの方式で音量正規化を行った場合と音量正規化を行わない場合の音量を比較したところ(どちらも、アンプの音量は最初に調整した後は変えないものとする)、音量が適正だと感じることがほとんどだった。数値的にも、それらの曲に対して約9dB(= 2.8倍)の幅で調整を行っていたので、効果はありそうだ(→ クラシック音楽でも、異なる曲を混ぜて聴く時には音量正規化はあった方がいい)。なお、この方式ではポップ音楽も正規化できるが、方式やパラメタが最適でないうえに、ポップ音楽はダイナミックレンジが狭い場合が多いため設定音量が目標音量(-24dB)付近になることが多いので、音量と音質の点で得策でない。そのため、この方式をクラシック音楽用のモードにし、従来のをポップ音楽用にした。

クラシック音楽用の音量正規化モードを追加したため、ミニプレーヤのUIを変更し、音量正規化のon/offでなく、off("-")またはモード(ポップ("P")/クラシック("C"))で表示するようにした。

それから、音量正規化のモードを切り替える際に音量が大きく増加することがある(例: クラシック → off)ので、安全のため、再生中にそのような切り替えを行った場合は一時停止するようにした。

最後に、気になっていた、静かな曲での正規化結果を比較してみる。以下は、"Speak to me"の先頭約20秒(鼓動)の部分の右チャネルの波形(上から順に、GMB (正規化off), Spotify(正規化off), GMB (正規化on), Spotify(正規化on), Spotify(今回の正規化))である。なお、それぞれの開始時刻は合わせていないので、波形の位置は異なる。

Pink Floyd "Speak to me"の先頭約20秒の右チャネルの波形比較

正規化した波形(最後の3つ)を見ると、明らかに、Spotifyの正規化は「やりすぎ」であり、そのためにおかしく聴こえていたことが分かる。一方、今回の正規化(一番下)は小さ目ではあるが、GMB(上から3番目)と同様の振幅になっている。聴いた感じでも問題なく、今回の方式が有効であることが確認できた。

なお、今回の正規化の振幅が小さ目なのは、この曲の音量がとても小さく、本来の音量設定値が上限(6dB)を超えているために、充分に音量を上げられないためである。

→ 音量制限の上限を解除して試したところ、振幅がSpotify以上に大きくなってしまった(フルスケールを超えた)。パラメタの調整(あるいは、上記のenergyの利用など)が要るようだ・・・ そして、Spotifyの正規化の処理は正しかったようだ。この点はがっかりした。

→ 音量設定値の上限を7.5dBにしたら振幅がGMBと同等になったので、当面はこれで試してみたい。

→ (19:40追記) どうやら、(当たり前ではあるが、)0dB(100%)より大きく増幅するのは良くないようで、少し長くクラシック(0dB超えの曲ばかり)を聴いたあとにポップに切り替えたら違和感が生じた(耳がずっと圧迫されていたような感じ)。また、当たり前だが、たまに音量がオーバーレンジ(0dBを超える)するのも余りいい気分でない(ただし、瞬間的なので聴いていても分からない)。それで、上限を0dBにすることにした。それで音量が小さくなってしまう曲はもともと小さく作っていると考えて、諦めることにする。

馴染みのない方のために説明すると、0dBを超えて増幅するというのは、デジカメのデジタルズームとかISO感度を高くするようなもので、確かにそれらしい画像は写って便利なのだが、無理してデータを作ってるから画質は期待できないということだ。

あと、"Speak to me"の冒頭の音がおかしく聴こえるので、Spotifyアプリの正規化は動的に処理(例: 現在までの音量などで現在の音量を調整する)しているのかと思っていたが、波形はそうでもないので、音量を上げ過ぎているだけなのかも知れない。ただ、目標音量を小にすると音量が下がり過ぎてしまうので、Spotifyアプリは今一つなことは確かだ。

副次的な効果として、今までは、音量正規化をon/offする際はSpotifyアプリを再起動する必要があるので、再生が停まり画面が変わってしまうなど、ちょっとしたストレスだったが、今回の方式では気軽にいつでも(まさに"on the fly")切り替えられるようになり、大変便利になった。実際には、このイライラを解消したいということが、今回の作業に着手する大きな動機になった。

(10/6 21:22, 21:39 変数名の重複を修正、設定値を更新)

 

PS. その後、調整・修正・改良しながら使っていて(というか、そればっかりしているがw)、上記の曲間のタイミングずれによる不意の大音量を解消したいと思っている。が、それは難しいことも分かった。今のところ、以下のようなことを考えている。

  • コンプレッサーやリミッターで大音量を制限する。
    • 大音量がほんの一瞬に抑えられるが、通常の曲(特に、クラシックは音量レベル(上記L)が小さいと認識されるため、大抵、音量(上記V)が最大に設定される)の大音量も制限してしまうので、(聴感上は分からないが、)常時は使いたくない。必要な時だけonにする必要がある。
  • コンプレッサーなどを使わないで回避する。
    • Spotify web APIのタイミングズレを補償する。
      • (無音で?)曲間を検知して、曲間と認識する。
      • 「スマート」な処理を作る?
      • 次の曲の先読み?
    • 我慢する。

切り替えて使うにしても、コンプレッサーなどはどうも気に入らない(onにしている時は妥協していることになる)ので、使わない方法を考えている。でも、できるかどうかは不明だ。まあ、あまり頻繁に起こらない(実際、昨日確実に起こっていた曲で今日は起こらない)ので、我慢するのが一番効率的なのかも知れないw

その他、以下のような改良をした。

  • 音量設定処理の遅延を防ぐ。
    • 曲間にSpotify web APIの認証トークン(有効期限がある)を更新すると音量設定処理が遅くなる可能性があるので、可能な限り、「忙しくない」時にトークンの更新をし、曲間での更新を抑えるするようにした。
      • 具体的には、再生中に一定間隔(例: 2分)で(無駄に)web APIをアクセスする。この時、トークンの有効期限を短め(例: -5分)に見て早目に更新しておく。一方、曲の切り替わり時のアクセスでは、有効期限ギリギリまで(例: -10秒)トークンの更新をしないように指示する。
  • 自動的に音量をリセットする。
    • 再生を停止してある程度(例: 20秒)時間が経ったら音量をデフォルト値(例: -10dB)に戻すようにして、(小音量の曲の再生後、)次に再生する曲の頭が不意に大音量にならないようにした。
      • ただ、次に再生する曲の頭が小さくなってしまうことがあるという弊害はある。

(10/5 10:50)

PS2. PSに書いた、Spotify web APIの曲の切り替わり通知タイミングずれによる意図しない大音量を防ぐ方法について考えた。曲の切り替わりを正確に検出して、その切り替わった時点で音量を設定すればいい。そのためには、まだ曲間になっていない場合にはそれまで待てばいいが、既に曲間が過ぎている場合には時間を戻して、出た音の音量を変える必要がある。果たして、そんなことはできるのか?

まず、曲の切り替わりを正確に検出するのが難しい。 一番簡単なのは無音検出だろうか。現在の再生位置が曲の終わり付近になった場合やSpotifyアプリから来る「曲が変わった」イベントの付近で(これらはある程度正確と考えられる)無音になったら「切り替わり」と判定するか。曲の中には終わったと見せかけて再度始まるものもあるが、さすがに終わりの数秒間ではなさそうだ。だが、今と次の曲がどちらもメドレーとかライブとか雑音が多くて、無音部分がなかったら駄目だ。。。

無音を検出すること自体は可能だが、ちょっと重い。そもそもそういうプログラムが要る(探せばあるだろう)。無音がない場合にも対応するには、音の特徴を分析するのだろうか。それは結構重い・・・

時間を戻すのは、不可能に思えて実は可能だw 戻す期間を数秒間に制限すれば、再生する波形をその時間分格納し、古いものから順に再生するようにすれば(ところてんのような感じ)、その数秒間は戻すことができる(正確には、Spotifyが再生したと思っている音はまだ再生されていないから、出てしまったはずの音(= 過去の音)を操作することができる)。問題は、再生に常にその数秒間の遅延が生じることだ。再生ボタンを押してから数秒待たないと音が出ないし、停めても数秒間は音が出る(こっちは何とかできる気がする)。それが許容できるだろうか。

一方、今日は問題が全然起こらなくなってしまって、「もしかしたら、いじっているうちに直ったのか?」と、淡い期待をするのだが、実際にはそんなことはないのは、今までの経験から明らかだw でも、滅多に起こらないことは確かなので、わざわざ上に書いたような大掛かりなものを作って苦労しなくてもいいような気がしている。ただ、技術的な興味から、やってみたい気分はある。

そして思ったのは、(昔の)日本にはこういう物好きな技術者が多く、それだけならまだいいが、お客や経営者が無理難題を吹っかけたにも関わらず、(24時間戦うw)彼らによって実現されてしまった製品を素直に販売してしまったから、ガラパゴス化してしまったのかも知れないということだ。

(10/5 21:28)

  •   0
  •   2

[10/1 8:18 この問題は解決した。原因と対処を最後に示す。]

面倒なことは、いつも突然やって来る。昨日、ふと、SpotifyとGMB(gmusicbrowser)を切り替えると音量が違うのが気になっていたので、それを可能な限り合わせたくなって、テスト信号を作って再生したら、思わぬことに気付いてしまった。

MP3のスイープ信号を再生したら、GMBからの音がおかしかったのだ。特定の周波数(例: 5.5kHz)が小さくなった。以下に問題の波形(問題の起こった5.5kHzの正弦波の再生波形の比較)を示す。上は問題がある場合、下は問題のない場合である(左チャネルだけを抜粋した)。なぜか変調が掛かっている感じで、音量が小刻みに振動している。そのために音が濁って聞こえる。

興味から、この変調波の周波数を調べたいのだが、普通にスペクトルを出しても出ず、なぜかLPFでも抽出できない(LFP後のスペクトルが出ない)。目視では24Hz程度と分かるが、なぜLPFで取れないのだろうか。振幅がとても小さいのか(そうなら、こんなに振れない気がする)。まだまだ知識が足らないようだ。。。

↑ 分かった! スペクトルを拡大したら、5.5kHz付近に2つの山があった。それらが干渉していたのだ。2つの差は約25Hzで、上記の目視と一致した。でも、なぜこういうことが起こるのだろうか? 新たな謎だ。

参考のため、実際の音(再生音を収録したもの)をこちらに置く。最初が問題のある場合、次が問題のない場合である。音量が大きいが、小さくしても現象は変わらなかった。多くの環境で再生できるようにMP3にしたので、環境によってはどちらも同じように(問題があるように聞こえる)可能性がある。

同じ音でもFLACのファイルを再生する場合は問題が起こらず、出力系をJACKからPulseAudioに換えても問題は起こった。それから、同じMP3のファイルを他のプレーヤー(例: XPlayer)やGstreamer(以下、GST)の再生プログラム(gst-play-1.0)で再生しても同じ現象が起こるが、問題の起こらないプレーヤー(例: Spotify, AlsaPlayer)もあるので、GMBが再生に使っているGSTのMP3デコーダ(デフォルトのもの)に問題がある可能性が高いことが分かった。

更に試したら、madというデコーダを使うと問題が起こらなくなることが分かった。以下に、gst-launch-1.0での例を示す。下記太字の"mad"を"decodebin"に変えると、問題が起こる。

gst-launch-1.0 filesrc location=test.mp3 ! mad ! audioconvert ! autoaudiosink

結局、GSTのデフォルトのデコーダ(decodebin?)に問題があるようなのだが、仮にGSTのバージョンが古いせいだとしても、OSのパッケージのものを使っているため、それより新しいものにバージョンを上げるのはかなりの手間(自分でコンパイルする)なので、上の例のようにGMBで使うMP3デコーダを変更するようにした。

MP3デコーダはmad以外にmpg123audiodecやavdec_mp3でも問題が起こらなかった。ただ、gst-launch-1.0で使う場合にはmadしか音が出なかった(他はprerollのエラーが起こった)。これは、僕がGSTの使い方を良く理解していないせいだ思う。

それで、3つの中では(名前から)一番品質が良さそうな(イメージの)avdec_mp3を使うことにした。ただ、何か問題があった時やデフォルトのデコーダで試したい時に手軽にデコーダを変更できるように、GMBの拡張設定で変えられるようにした。

他に分からなかったのは、GSTのパイプライン(上記のコマンド例のようなもの)でMP3デコーダを指定する順番が最初でないと うまく動かなかった(再生開始しない)ことだが、これも僕がGSTを良く理解していないせいだと思う。

 

昨夜から延々と試行錯誤と対処をして、ようやく本題の音量を合わせる話に進むことができた。テスト信号とメーターで音量を比較してみたら、結局、音量正規化を行わない場合には、どちらも同じ音量で再生されることが分かった(まあ、デジタルなのだから、大きく違ったらおかしいが・・・)。僕のシステムではDACの前に部屋の特性補正用のイコライザを入れているが、両方とも音量を100%にしてもオーバーフローは起こらないようだった。ただ、念のため(論理的でない「気休め」)、イコライザの前で1dB下げるようにした。

音量正規化を行う場合には、SpotifyとGMBの音量は異なっていた(これが、気になっていた音量差である)。それぞれの仕組みや目標音量が異なるためだろう。手持ちとSpotify両方にある数曲で調べたら、曲にもよるが、1〜3dB程度Spotifyが大きかった。それでミキサー(jack_mixer)を使って2dB程度下げたら、差が1dB以下となった。これで聴感的にも合えばいいが・・・ → 残念ながら、曲によってSpotifyの正規化後の音量が違うようで、あまり合わない感じだ。

まったく、手製のシステムは不意に問題が起こって気が抜けないものだ。まあ、オーディオ道 趣味なんてそんなものだろうw ただ、JACKだといろいろな部品をマウスで配線して手軽に試行錯誤や確認ができるのは便利だし、いろいろな知らなかったことが分かるのはおもしろい。

それから、MP3デコーダの問題はダウンロード購入したMP3音源の音質劣化を起こすことに気付いて確認したら、確かに若干音がおかしくなっていた。具体的には、ルプーのモーツァルト ピアノ協奏曲 第21番(1975)で弦(バイオリン)の音量が大きい箇所で違和感がある。実際、今年の頭に音が悪いことに気付いて書いている(これはこっちの問題だし、苦情を言ったら確実に泥沼化して疲弊しただろうから、黙ってて良かったw)。今聴くと、MP3デコーダを変更すると、違和感がほとんどなくなって、すっきりした気分のいい音(曇り空がちょっとした青空になった感じ)になる。確かに、録音が古いことによる音の悪さもあるのだが、MP3デコーダの問題が大きかったようだ。

もちろん、他のMP3音源でも同じ問題があるはずだが、特定の音(例: 5.5kHz)が続く場合にしか顕著にならないようで、たまたま僕の手持ちの曲ではそのパターンが少なかったらしく、気付かなかったようだ。実際、ルガンスキーのラフマニノフ ピアノ協奏曲 第2,3番(2005, 2003)ではまったく差が分からず、以前どおりのいい音にしか聞こえない。

それにしても、ルプーについては本当に音が悪いことが分かっていたなんて、僕の耳と環境は随分良くなったものだ。つい最近まで何がいい音か分からなかったことを思うと、全く感慨深い・・・

 

(10/1 8:18追記) MP3の音がおかしい問題の原因が分かり、対処できた。

しつこく試したり調べていたら、ヒントになる投稿が見つかった。どうも、GSTにインストールしていたFluendo MP3 Decoder(flump3dec、パッケージ: gstreamer1.0-fluendo-mp3)が古い(その投稿が2007年なので、それより前!)うえにバグがあったようだ。そして、今(実際には2007年以前から)はそれがなくてもMP3を再生できるとのこと。僕が自分でgstreamer1.0-fluendo-mp3をインストールしたのかは今となっては分からないが、余計だったようだ(← 別のPCには入っていないので、自分で入れたようだ)。

それで、gstreamer1.0-fluendo-mp3をアンインストールして問題のファイル(5.5kHzおよびスイープ)を再生してみたら、正しい音が出た(再度インストールしたら、やっぱり駄目になった)。ルプーのモーツァルト ピアノ協奏曲 第21番も大丈夫そうだ。それで、GMBのMP3デコーダの指定も止めて、デフォルトに戻した。

いつものように最後はあっけなかったが、原因が分かって良かった。それにしても、余計なパッケージは削除して欲しいものだ(→ Ubuntuの人)・・・

  •   0
  •   0