Archive for the ‘Linux’ Category

謎の多いiVideoのモバイルルーター、iV501。余り需要はないと思うが、使ってみて分かったことを書く。なお、以下はiVideo社とは関係なく、すべて私の推測や試行の結果である。質問には可能な範囲で回答するが、余りにも初歩的なものは控えて欲しい。例えば、書かれている単語の意味が全く分からない場合には、まずそこから理解すべきで、安直に試すべきではない。とにかく、自分でトラブルシューティングする覚悟が必要である。

本体のLED

右上の電源LED(後述)以外は全く挙動不審だw おそらく、何かの契機(通信・充電開始や電源ボタンを押したら?)で、それぞれの意味(LTE・Wi-Fi接続の有無)で点灯するが、しばらくすると省電力のために消えるのだろう。ただし、左下のメール(おそらくSMS)のLEDは無効で、他が点灯する時は常に点灯するようだ。

電源LEDは以下のような規則のようだ。以下では管理webの挙動や関連するweb API: goform_get_cmd_processの変数(前の投稿を参照)についても書く。

  • 充電中の場合
    • 電池のLED: 緑点滅: 1秒間隔 (消えることもある?)
    • Web: 充電しているアニメアイコン
      • 画像ファイル: img/battery_charging.gif
    • APIの変数:
      • battery_charging: 1
      • battery_pers: 4(満充電), 3, ...
  • 残量が充分ある場合
    • 電池のLED: 緑常時点灯 (消えることもある?)
    • Web: 普通の電池アイコン(黒い部分が残量に比例)
      • 画像ファイル(残量は推測):
        • img/battery_full.png: 100%
        • img/battery_three.png: 75〜100%
        • img/battery_two.png: 50〜75%
        • img/battery_one.png: 0〜25%
        • ※電源を抜くとすぐにthreeになるようなので、threeでも満充電の場合があると考えても良さそうである。
    • APIの変数:
      • battery_charging: 0
      • battery_pers: 4(満充電, 画像ではfullに相当), 3(画像ではthreeに相当), 2?, 1?
  • 残量が少ない(要充電)場合: まだなったことがないので不明。
    • 電池のLED: ?
    • Web: 電池内に赤枠のアイコン (最初に管理webを表示した時に一瞬なるので、これだと推測した)
      • 画像ファイル: img/battery_out.png
    • APIの変数:
      • battery_charging: おそらく0
      • battery_pers: 0?

備考

  • 電源LEDは通信時(ある程度データ量が多い時?)にも点滅するようだ。 ← 違う感じ。電源やPCに接続中は常時点灯? (2/5 17:25)
  • Web APIの変数battery_vol_percentはいつも"100"なので、残量とは関係なさそうだ。接続されている電池の仕様上の容量を示しているのだろうか?

管理web

URLはhttp://192.168.0.1で、最初にパスワード(ここには書かないが、良くあるもの)を入れる必要がある。どうやって分かったのか(他のZTEのルーターと同じなのかも知れない)、パスワードを公開されている方が居たので、私はそれを使っている。

なお、デフォルトの設定では、管理webも他のポートも、外からは接続できない(なぜか"closed"になっている343/tcp以外は応答しない)。ただし、2000/tcp以上のポートについては未確認。 → 外部からの攻撃でiV501を操作されたり、接続している機器が攻撃される可能性は低そうだが、TCP以外については不明だし、何らかのバグを突かれる可能性がないとは言えないので、全く安全と言うことはできない。あと、iV501から外部に情報を流出させている可能性は0とは言えない。

iV501にファイアウォール機能はあるが、機能が今ひとつ貧弱なので実用には向かない。他にポートフォワード機能などもあるが、試していない。

注意: 設定を変更して問題が起こってもiVideoのサポートは受けられないので、自己責任で行うこと。また、返却時には初期状態に戻すこと。

PCとのUSB接続

Linux(Ubuntu 16 LTSベース)では、PCに接続するだけでネットワークインタフェースとして認識され、すぐにLTE通信に使える。なお、AndroidスマフォのUSBテザリングとは異なり、接続するポートを変えてもインタフェース名は変わらない。インタフェース名は、擬似的なMACアドレスから作成されるようだ。このMACアドレスはどういう規則なのかは不明である(Ethernetでないので、固定値にしている気がする)。

iV501の内部には仮想CD-ROMも入っており、Windows用ドライバをインストールするアプリが入っている。また、内部(電池の下側, SIMの隣)にmicro SDを挿すと、Linuxにマウントされるはずだが、未確認である。

Linuxでは、接続すると自動的に上記の仮想CD-ROMがマウントされてしまうが、以下の内容のファイルを /etc/udev/rules.d/75-ign-zxic-mb-cd.rules (パスやファイル名は適宜調整すること)に作成したら、マウントしないようにできた。

SUBSYSTEMS=="usb", ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1557", 
  ENV{ID_FS_TYPE}=="iso9660|udf", ENV{UDISKS_IGNORE}="1"

なお、私がiV501をUSB接続する理由は以下である。

  • Wi-Fi接続でないから、PCでの通信が盗聴される可能性が減る(LTEについてはその限りではない)。
  • 電源をPCから取れるので、ACアダプタが不要になる。
  • (PCにWi-Fiインタフェースがないので、)Wi-Fi接続するための追加機器(ブリッジ)が不要になる。

注意: USB接続はiVideoのサポート対象外なので、自己責任で行うこと。

電池を入れずに起動できるか?

電池を入れずにPCのUSBポートにつなぐと、(全く動かない訳ではないが)惜しくも起動しない。Linuxでは、接続直後にUSBデバイスのconfigurationを設定する時にエラーになってしまって起動しない。

通信速度がものすごく遅い場合

月の終わりにレンタルを開始したら、前の人が多く使ったせいなのかキャリアの契約が始まってなかったのか、100kbpsくらいしか出なかった。私は交換してもらったが、同じルーター(実際にはSIM)でも、月が変わったら問題ない速度が出た。

Web API (2/5 19:28追加)

今のところ、goform_get_cmd_processでは以下の変数が取れることが分かっており、一部については内容を推測している(追記予定だが、自明なものが多い)。他にもありそうだが、管理webからアクセスされないので分からない。

  • modem_main_state
  • modem_init_complete
  • pin_status
  • blc_wan_mode
  • blc_wan_auto_mode
  • loginfo
  • fota_new_version_state
  • fota_current_upgrade_state
  • fota_upgrade_selector
  • network_provider
  • is_mandatory
  • sta_count
  • m_sta_count
  • signalbar
  • network_type
  • sub_network_type
  • ppp_status
  • rj45_state
  • EX_SSID1
  • sta_ip_status
  • EX_wifi_profile
  • m_ssid_enable
  • wifi_cur_state
  • SSID1
  • simcard_roam
  • lan_ipaddr
  • battery_charging
  • battery_vol_percent
  • battery_pers
  • spn_name_data
  • spn_b1_flag
  • spn_b2_flag
  • realtime_tx_bytes
  • realtime_rx_bytes
  • realtime_time
  • realtime_tx_thrpt
  • realtime_rx_thrpt
  • monthly_rx_bytes
  • monthly_tx_bytes
  • traffic_alined_delta
  • monthly_time
  • date_month
  • data_volume_limit_switch
  • data_volume_limit_size
  • data_volume_alert_percent
  • data_volume_limit_unit
  • roam_setting_option
  • upg_roam_switch
  • fota_package_already_download
  • ssid
  • dial_mode
  • ethwan_mode
  • default_wan_name
  • sms_received_flag
  • sts_received_flag
  • sms_unread_num
  • rssi
  • rscp
  • lte_rsrp
  • lan_station_list

 

まだ少ないが、他に分かったらまた投稿したい。

  •   0
  •   0

数日前から使っているiVideoのモバイルルーターiV501。カイロの代わりになりそうで今の時期には助かるとかw、いろいろな謎や、たまに惜しいところや間抜けなところがあるものの、全体的には必要充分で問題ない感じだ。それどころか、今朝、期待すらしていなかった機能を発見して、大いに感心した。

切っ掛けは、iV501の通信データ量や電池の状態を見るのに管理webを開く時に、いちいちパスワードを入れる(ご丁寧にも、ある程度時間が経つと自動でログアウトされる)のが面倒なので(いや、認証すること自体はまったく正しくて、何も文句は言えない)、何とかならないか(要は「チートできないか」)と、通信の解析や検索をしたことだった。

認証以外に、間抜けな惜しいことに電池の残量が4種類程度のアイコン(下図右上)でしか分からないので、可能なら数値(%)で知りたかった(結局はできなさそうだ)。電波強度(下図上部"Soft Bank"の右)も同様だった(こっちは数値(RSSI)で得られた。図の下の方("Signal Strength")には数値が出ている)。

iV501の管理web

検索しても詳細な情報が出て来ないので、管理webにアクセス中のPC(Firefoxブラウザ)とiV501の通信をブラウザのDevelopper toolで見てみたら、頻繁に状態を取得していた(無駄に多い(毎秒くらい)ので、止めたくなったくらいだ)。それは以下のようなURL(API)だった(月の通信データ量と電池残量の取得を簡略化した例)。

http://(IPアドレス)/
  goform/goform_get_cmd_process?cmd=monthly_tx_bytes
  %2Cmonthly_rx_bytes%2Cbattery_pers&multi_data=1

結果は、以下のようにJSONで返って来る。

{"monthly_tx_bytes":"2929233487","monthly_rx_bytes":"1500560020",
  "battery_pers":"4"}

惜しいことに、このURLは上記の管理webを表示する前の認証を通してからでないと、値を返さないものが多い。それで、特徴的な"goform_get_cmd_process"で検索してみたら、他にも使われているらしく、いろいろなことが分かった。

まず、このURL(API)はGoAhead Embedded Web Serverという、組み込み用webサーバソフトで使われているようで、ZTE社の製品(例: MF823)で使われているようだ。iV501がZTE製なのか、ZTEの下請け製なのか、それ以外(ごにょごにょ?w)かは不明だが、本体内部に"MF833"という表記があったので、ZTEに関係しているように思う。ただ、ZTEにはMF833というUSB接続のモバイルルーターがあるが、それとiV501とは違うようだ(が、中身は同じなのかも知れないと思った: これがあとですごい発見に繋がるw)。

いくつかのページでは、上記のURL(API)でモバイルルーターの情報取得や制御を行っている。ただ、なかなか最初の認証の通し方が分からなかったのだが、Developper toolを探していたら、運良くgoform_set_cmd_processが認証を通している通信が見付かり、その通りにしたらようやくできた。以下のようなURL(API)で認証が通る。

http://(IPアドレス)/goform/goform_set_cmd_process?goformId=LOGIN
  &password=(BASE64エンコードしたパスワード)

実は、Developper toolで見付ける前に、別のサイトでも見付けて上記に近いことを試していたのだが、パスワードの指定を間違えていて(HTTPの要求ヘッダからコピーしたため、"ユーザー名:パスワード"をBASE64エンコードしたものを指定していた)通らなかった。

余談: 個人的には、こういうゆるい認証もどきは良くないと思う。というのは、一度認証されたあとしばらくは、どんなクライアント(自分以外も!)も全パスにしてしまうからだ。本来は、認証されたら、それを識別するトークンのようなものを返して、それを以後の要求に添付させてチェックすべきだろう。が、そもそもHTTP(SSL/TLSでない)だし、このwebに外部からはアクセスできないので、まあ、大きな問題ではないかと思う(でも、良く報道されるセキュリティ問題は、こういう手抜きから始まることは確かだ)。

そういえば、光の時に使っていたBuffaloのルーターもこういう認証方式で、面倒で嫌いだった。もしかしたら、同じサーバソフトなのかも知れない。

認証を通した後で、最初のURL(API)で情報を取得すればいい。

ここまで来たら、「あとはプログラムを書くだけ(面倒だなぁ。誰か頼むwww)」で話は終わるかと思ったのだが、MF833で検索した時に上記のUSB接続のルーターが出て来たので、ふと、「iV501のUSBをPCに挿したらどうなるかな?」と思い、「まあ、どうせ電源だけだよな・・・」とは思いつつも、ダメ元で挿してみた。

(2/3 17:36) 重い腰を上げて、プログラムを作ったw 指定した情報(変数)をiV501から取得するプログラムと、それをMunin(グラフィカルなPCの状態表示ツール)に入れるものを作った。以下のような感じ(下図の右側)で、MuninにiV501の月ごとの累積通信データ量(上)と通信速度(下)が表示できるようになった。

iV501の月ごとの累積通信データ量(上)と通信速度(下)をMuninで表示(右側, 左側はPCのグラフ)

比較のため、PCの同様なグラフを左側に載せた。スマフォの通信データ量は少ないので、PCとiV501のグラフはほとんど同じ形であるが、スマフォで動画を観まくったりアプリをダウンロードしまくると違いが出そうだ。

ちなみに、iV501からの情報取得プログラムの実行例を以下に示す。出力は、JSONかshで変数を設定するコマンド文字列のいずれかで出せるようにした。例では、iV501から電波強度(RSSI)、月の累計送信・受信データ量、電池の充電状態・残量を取得している(後述のバグのせいで、送信・受信データ量が入れ替わっている)。

./bin/iv501-vars.sh rssi monthly_tx_bytes monthly_rx_bytes 
  battery_charging battery_pers
monthly_rx_bytes="2797359595";monthly_tx_bytes="6248242876";
  battery_pers="4";battery_charging="0";rssi="-84";

余談: iV501にバグがあるようで、月の通信データ量の送信と受信が逆になって送られて来る。いかにも間抜けだけど、こういうのは僕もやるから全然許せるw なお、管理webでは送受信の合計(リンク先左下の"Used")しか出ないので、発覚しないのだろう。

そうしたら、とんでもないことになった。なんと、iV501がLTEのネットワークインタフェースになってしまったのだ! Linuxなのに挿すだけで使えたよ。ちなみに、ifconfigコマンドでは以下のような感じで出る。

enx00xxxxxxxxxx Link encap:Ethernet HWaddr 00:xx:xx:xx:xx:xx
inet addr:192.168.0.X Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:909876 errors:0 dropped:0 overruns:0 frame:0
TX packets:791882 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:615270891 (615.2 MB) TX bytes:266268613 (266.2 MB)

挿す前は、仮に認識したとしても、制御用のシリアル通信程度しか期待していなかった(それで欲しい情報が取れれば、充分ありがたかった)が、いきなりNW-IFとして使えるなんて、全く予想外だった。通信速度も問題なく出た(Wi-Fi接続同様、ダウンロードが20-50Mbpsだった)。

もちろん、これでしばらく試すことにしたが、問題なく使えるなら、iV501用の電源アダプタが不要になるのはもちろん、先日買ってPCに組み込んだばかりのTP-LinkのWi-Fiブリッジがお払い箱になる。組み込んだ苦労やお金が水の泡になるが、物が一気に二つも減るから、そっちの方が気分がいい。それに、ブリッジを内蔵しておけば、PCが(実質)Wi-Fi対応になるから いつか役立つことがあるだろう。

 

それにしても、iVideoはもったいない。こんないいもの(良く考えたら、僕が欲しかった物そのものだ)を、そうとは知らせずに出しているのだから。ただ、これが彼らの上手(うわて)なところなのかも知れない。「モバイルルーター」として出すなら、およそどんな機器でもSSIDとパスワードを入れるだけで簡単に接続できるし、モバイルルーターは世の中に多く出回っていてお客も慣れているだろうから、説明もサポートも手間要らずだ。実際、説明書は簡素な紙1枚だけだった。

一方、PCにUSBで繋げる(「ドングル」とか「モデム」のカテゴリになる)となると、途端にハードルが上がる。OSの種類・バージョン、ドライバ、OSメーカーの認証、コネクタ・ケーブル、電源容量などなど・・・ たとえPCに繋がっても安心はできない。OSのネットワークの設定・切り替えなどがいろいろありそうで、やっぱり面倒だろう。それ以外にも、管理webなんて公開したら更に問題が生じる契機が増えて、サポートの手間が激増するだろう。であれば、そういうのはないことにして、Wi-Fiだけで使ってもらうほうが得策だ。

(彼らが実際にそこまで考えたかどうかは分からないが、)うまいやり方に感心した。言ってみれば「ないない詐欺」だw

そして、日本は本当に中国・台湾(韓国はまだ分からない)に負けたのを実感した。製品もサービスのやり方も全く負けている。

物についてだけ考えても、これが日本製だったら、高くて(2倍以上はしそうだ)機能が多過ぎて(でも、ほとんど使わない)、難解な分厚いマニュアルが付いて来て、それを補完する「簡単マニュアル」なんてのまでありw(だったら、最初からそれだけにすればいいのに・・・)、しかも、結局はちゃんと動かないとか、(昔と違って)すぐ壊れるってことが多そうではないか。

なんて おそろしい子だw

  •   0
  •   0

先日一度キャンセルした後に注文した、USBのWi-Fi子機が届いた。Amazonに山ほどある、とても小さいWi-Fi子機である。送料無料で約300円だった。国内(関西)なのに発送の連絡から結構掛かったのと、そこに書かれていた伝票番号がデタラメな数字だったので、「ここもだめかなあ?」と、(怒る気にもならずに)半分諦めていたのだが、今日ちゃんと届いたので安心した。どうも、週末を挟むと結構遅れるようなのと、普通郵便で発送したので番号をテキトーに入れたらしい。

で、早速PCに挿してみたが、案の定、動きやしないw USBデバイスとしては認識しているのだが、意味不明(というか、分かろうとしていないw)なエラーが出てWi-Fiデバイスとしては動かなかった。Wi-FiチップはMediaTekのMT7601Uだ。

それで、検索したらいくつか出て来た。

  1. カーネルに含まれているドライバを修正する(2017, 一部を無効にする。sergio-codeのまとめが分かりやすい)。
  2. フリーのドライバを入れる(2016)。
  3. MediaTekのドライバを入れて修正する(2014)。

2, 3, 1の順に試したが、違うと思って最後まで試さなかった1が効いた。動き出して、子機の情報がifconfigコマンドにちゃんと出た時は、思わず「おっ! (動いたぞ)」となった。

結局、僕のLinux(Ubuntu 16 LTSベース)では基本的には挿せば動くはずなのだろうが、デバイスの個体差(ファームのバージョン?)の問題なのか、ドライバを修正しないと動かなかった。その修正が一体どういうものなのか、それでいいのかはまだ分からないので、追って調べたい。

それにしても、この修正を見つけた人は一体どうやって分かったのか、すごく不思議だ。ソースを見ながらカットアンドトライしたのだろうか?? 全く尊敬する。

一通り動作確認したところ、問題はなかった。ちゃんとスリープにも対応しているようだ(長時間のスリープは未確認)。すごく熱くなるという口コミがあったが、今のところは少し熱い程度だ。ただ、(頻繁に壊れて買い直すのは面倒なので)寿命を伸ばしたいので、延長ケーブルを使ってPC後部のファンの後ろに置いた。

通信速度は変わらず10Mbps(ダウンロード)だった。これで速くなるかと思っていたのだが、良く考えたら、LTEに繋げているのは従来と同じNexus 4だから速くなる訳がない。モバイルルーターが来るのを待つしかない(でも、本当に来るのか怪しい・・・)。

ちょっと気になる点は、以下である。

  • 動きはするものの、まだエラーが出ている。
    • 内容不明なので、元々のエラー同様にあとで調べたい。
  • nmcliコマンドで表示される接続(リンク)速度が54Mbpsで、仕様の最大値の150Mbpsよりかなり遅い。
    • nmcliコマンドの見方が悪いのか、nmcliの出力が正しくないのか、Nexusが遅いのか、PCの設定が悪いのか、それ以外か不明。手持ちのWi-Fiルータを起動すれば分かるので、あとで試したい。
    • 調べたら、54Mbpsというのは802.11gの速度なので、もしかしたら、PCかNexusで802.11nが有効になっていないのかも知れない。

これで、安定して動いてそこそこ長く使えるのなら、随分安くて小さくていい買い物だが、果たしてどうなるか?

(1/21 0:05) 早くも駄目だった。どうも、連続して送信するとデバイスが落ちてしまうようだ(受信は大丈夫な感じ)。安直に見えた修正はやっぱり駄目なのかも知れない。試行錯誤が要りそうだ。。。

(1/21 8:50) いろいろ試したが、どうも、まともに動かないようだ。上に書いた修正は、必要な処理がUSBの通信エラーになるからスキップするだけの対症療法(スキップした処理が行われないから、それで正常動作する方が不思議だ)なので、おそらく、Linuxのドライバ(タイミング?)が良くないのだろう※。でも、この子機はそれをデバッグするほど価値のある(高い)ものではないので、あっさり諦めて別のを注文した。今度はTP-LINKの700円くらいので、Linuxで動いたという情報はあるし、3年保証だから、壊れ易いとしても少しは安心だろう(でも、実際には交換するのは面倒だったりするが)。

※例えば、昔のカーネルではちゃんと動いていた・いるという情報もあるので、ドライバ(ベースは結構古い)とカーネルが合っていないのかも知れない。

まあ、安物買いの銭失いそのものだ。しょうもない。。。

 

とりあえず、これでPCを長時間スリープさせてもNexusの電池が切れることはなくなったし、Nexusを持ち出す時も電源を抜くだけで良くなった。あとは、モバイルルーターが届けば通信速度が高速になるはずだが、先週、「発送した」という連絡があったきり、そこに記載された番号を調べてもずっと準備中みたいな感じなので、なかなか予断が許されない。まあ、中国の郵便(China post)は溜まるまで保留されるらしいし、到着予定は1/31なので、今焦っても仕方ない。

(1/21 8:50) 仮に、無事モバイルルーターが届いても、今回の子機と同じようなことにならないかと結構心配になっている。まあ、その時はiVideoのルーターをレンタルしてしのいで、ゆっくりどうするか考えよう(おそらく、高い、ちゃんとした物を買うことになるのだろう)。

(1/21 19:50) モバイルルーターの件、「発送した」から一週間経っても配送状況が"Order generated/Shipping Label Created"(伝票が作成されただけ?)のまま変わらないので、しびれを切らして問い合わせたら、「通関がどうのこうので返送された」とか言う返事が返って来た。配送状況がずっと変わっていなかったのだから、そんなの嘘に決まっている(仮に本当に返送されたのなら、なぜ、聞かれて初めて連絡して来るのだ?)。でも、今回の子機のように、変な物を買ってお金を無駄にしてがっかりするよりは、ずっと良かった。

もう少ししたらiVideoのルーターをレンタルする。300GBで3300円と、僕には丁度いいのがうれしい。

 

ご注意: 外見が同じでも中身は別ということは大いにありそうなので、この情報はあくまでも一例として考えて下さい。実際、僕の買った物も、挿せば動くはずなのにそうではなかったです。購入される場合は、記載されたチップの番号で対応状況・口コミを確認することが重要です。

(1/21 8:50) 実際、今回失敗した物は、Realtekのチップを予想・期待していたのに実際はMediaTekでした。安い物にはいろいろなリスクがあります。

  •   1
  •   0

前回、iVideoの大容量LTEは「固定ルータにする」と書いたあとで、どうも夢が破れるのが気に入らなかったので、ちょっと試してみた。今、家でPCやスマフォ(AQUOS sense lite)とLTEを繋いでいるNexus 4を持って(もちろんAQUOSも)外に出てみた。

そうしたら、何ともいい感じなので結構驚いた。まあ、僕がセコいせいなのだが、AQUOSで契約しているプランのデータ量が500MB/月と少ないので、いつも外ではデータ量に気を遣わざるを得ず、Googleマップなんてどうしても必要な時だけにしていたし(でも、気のせいか、近頃はデータ量が少なくなったようだ)、Evernoteだって、開くたびに「データ量が増えるか?」とか思っていたし、Spotifyを使う時は低速モードにしていたのだが(注: 今日は使っていない)、そういう足枷がまったくなくなって、とんでもなく自由な気分、

好きなだけデータを使っていいんだぜ!!

という天の声が聞こえたのだ。

ちなみに、当然のことだが、外でもiVideoは全然問題なかった(ソフバン回線だから田舎にでも行けば話は変わるだろうが、ここら辺なら全く問題ない)。

でな訳で、方針を変えて、LTEは断然モバイルルータで繋ごうと思い、「ちょっと試す」ために、安いものを注文した。

正確には順序が違っていて、ルータを注文したのは昨日だが、細かい話は見逃して下さいw

また、PC用にもWi-Fi子機を注文した(これは、その前にUSBテザリングだとPCのスリープ時にNexusの電池が減るのを解消できるかと思ったのが大きい)。

 

なお、当然、「やっすいルーター」なんてヨドバシには売ってないのでw、先日退会したAmazonに再び入って、C国の怪しい店の中から少しは大丈夫そうなところを探して、3千円くらいのバッテリー内蔵のものを注文した。その前に、物(ルーター)自体についても、なかなかおもしろいと思ったUSB+Wi-Fi接続のものは「すごく熱くなる」とかいう口コミが多かったので、いろいろ比較・検討して、何となく大丈夫そうな気がするの(これはUSB接続ではなく、バッテリーが入っている)を見繕った。でも、もちろん実際にはどうか分からない。

Wi-Fi子機も同様だが、さっそくはまってしまった。注文して数日経っても発送するフシがないのでキャンセルした。なぜか、Amazonのwebでキャンセルしようとしてもできなかったので、Amazonのサポートに泣きついたら、意外なことに即座に状況を把握して対処してくれて、そういうところは日本よりいい・進んでいる(日本だったら、絶対に数日は掛かるね)と思ってしまった。なかなか難しい。

なお、Wi-Fi子機は、最初は本体約20円(+送料 200円)のを試したのだが、さすがに甘かったようなのでキャンセルして、今日、日本の会社の300円くらい(送料無料)のにした。日本の会社だからといって大丈夫な保証は全くないがw、口コミでは良さそうだった。さてどうなるか・・・ なんでAmazonはアドベンチャーゲームになるのかな?w

ちなみに、Linux対応については概ね大丈夫そうだ。ただ、苦労する可能性もありそうで、実際のところ、やってみないと分からない。そういうこともあって、駄目でも容易に諦められる「やっすいの」にした。なお、最初は当然国内の会社の製品を検討したのだが、「(熱くなって)すぐに壊れる」などの口コミが多かった(検討した全製品にあった。でも、なぜかヨドバシにはなかった)ので、「だったら本家本元のC国でいいや」ってことでAmazonにした。

 

まあ、細かい話はどうでも良くて、たった数時間で固定回線じゃないのはすごくいいことを実感した。当たり前のことなのかも知れないが、(特別に必要な場合を除いて、)もう光(固定回線)なんて時代遅れなんだね。

 

PS. これがうまく行けば、面倒ではあるけど、外でデータを使いそうな時にルーターも持つことにすれば、AQUOSをもっと安い回線(例: 完全従量制の0SIM)に換えて更に通信料を減らすこともできそうだ。ただ、面倒だからしなさそうではある。あと、0SIMはものすごく遅いようで、評判が悪過ぎる。でも、500MBまでは無料で、そういうのは他にないから考えたい気もする。 (1/16 6:56)

PS2. いいことを思い付いた。LTEのモバイルルーターをスマフォの裏にでも貼り付けておけば、ほとんどの場合で便利だ。今回注文した物のサイズは不明だが、できるだろうか? まあ、PCを停めずにちょっと外に出た時にPCの通信が停まるが、それほど大きな問題ではない気がする。 (1/16 12:16)

  •   0
  •   1

信じられないことに、1/10に届いてから今のところ何も問題ない。正確には問題はあるが、iVideoでなく こっちの問題だw

今までの通信データ量は測定する箇所やソフトによって異なるが、概ね5-8GBである。これなら、SIMの上限の900GB/月にはまず達しないだろう。良くある通信量による速度制限は3日で10GBなので(そういう制限があるとは書いてなかった)、それには掛かっていないから、隠れた制限の有無はまだ分からないが、少なくとも、説明にあった、他の人に迷惑を掛けるほどは使っていないようだ。参考までに、PCでの通信データ量と通信速度のグラフを載せる。

Spotifyを聴いている時は ほぼ一定の傾きでデータ量が増加している感じだ。たまにデータ量が急増する(速度のグラフが尖っている時)のはオンラインストレージに自動バックアップしているか、サーバをローカルにバックアップしている時である。なお、時々データ量が減るのは測定プログラムのバグである(テザリングのoff/onがうまく処理できていない)。

たまに通信速度を測ってみるが、安定の10Mbps程度だw 今日一回だけ、PCからのアクセスがすごく遅かったことがあったが、間違ってテザリングを断続させたせいかも知れない。また、動画はほとんど観ないが、特に問題なさそうだ。それから、突然通信が途切れることもない(ちょっと前に、PCのネットワークインタフェースが一瞬落ちて、すぐに繋がるということがあったが、頻発はしていないし、自動的に回復するから大きな問題はなさそうだ)。

そういう訳で、今までのところ、iVideoのSIMは、僕の日常的な使用に関しては何も問題がない。まあ、無線通信自体は大手キャリアのものだから当たり前なのかも知れないが、ここまで問題がないのには感心する。あと、ルータ代わりに使っている古いスマフォ(Nexus 4)も、過酷な使用に良く耐えているものだw

今までに見付かった問題を以下に挙げる。いずれも、iVideoには関係ないことである。

  • LTE通信用スマフォ(Nexus)の電池が切れる可能性
    • USBテザリングしているデスクトップPCをスリープさせると、USBに電源電圧は掛かっていてテザリングは切れないものの、なぜかNexusが充電しなくなってしまう。
    • Wi-Fiテザリングをしているせいか減る速度は速く(約12%/hだった)、約8時間で切れる計算だ。 → (1/13 3:14) その後、アプリを減らしてみたら約8%/hになって、約12時間まで伸びた。これくらいなら、切れる心配は少なそうだ。
    • いろいろ試したが対処できなかったので、何らかの理由でLTEルータを買わない時に改めて考えることにした。
    • 仮に電池が切れても、スリープ中なのでデスクトップPCは使っていないので、Wi-Fiテザリングをしているスマフォ(AQUOS sense lite)がモバイル通信になる程度で大きな問題はない。
  • スマフォ(AQUOS)からPCへのLAN経由の画像転送ができない。
    • (前回書いたもの) 対処は可能だが面倒なので、これも何らかの理由でLTEルータを買わない時に考えることにした。
  • 耳閉感や耳鳴りが再発
    • (これも前回書いたもの) どうも、中継用に使っていたPC(Vision-HT)のファンではなく、疲れや寝不足によるようだ。なかなか厄介だ。
  • 突然、PC(Linux)から通信ができなくなった。 (1/16 5:11追記)
    • Googleなどへのpingも通らない。一旦、LANを切断しても変わらなかった。
    • 「いよいよ速度制限が掛かってしまったか・・・」と思ったが、スマフォ(AQUOS)からは問題なかった。
      • → LTE接続用スマフォ(Nexus)のUSBテザリングをoff/onしたら直った。
      • やっぱり、スマフォをモバイルルータにするのは無理があるようで、ちゃんと使うならルータが必要だ。ちなみに、現時点でNexusでのモバイルの通信データ量は約20GBになっていた。

ルータの候補を探したが、余り高いものは買いたくないので、以下の2つしかない。

  • au Speed Wi-Fi HOME WHITE L01s HWS32SWA: 約8千円-1.2万円
  • NEC Aterm PA-HT100LN: 約1.2万円

通信速度と消費電力と小ささでNECが良さそうだ。速度はHWS32SWAのカタログ値は大きいが、WiMAXも合わせてCA(carrier aggregation)した場合なので、実際にはそれほど出ないと思う。そもそも、このSIMにすごい速さを期待するのは、八百屋で魚を求めるようなものだw あと、本当にあるとは思えないのだが、HWS32SWAのメーカーH社はスパイウェアが気になる。

モバイルルータも考えたが、Ethernetがないので不便だ。まあ、PCにWi-Fiの子機を付ければいいのだが、Linuxでちゃんと動く子機がなかなか少ないようで、失敗するのが嫌なのだ。それに、モバイルルータは内蔵電池の消耗が気になるので避けたい。

ルータを検討していて気付いてしまったのだが、固定ルータにすると、前回書いたようには外出時に簡単に持っていけない問題が発覚した。スマフォをルータにするのは安定性や耐久性(特に電池)や管理・保守の点で難点があるので、通常は固定ルータを使い、外に持ち出す時にはSIMを抜いてスマフォ(Nexus)に挿すのが良さそうだ。が、SIMのサイズが違うこともあるので、面倒でやらなそうだな・・・ 早くも夢は破れたw

てな訳で、来週末辺りまで問題がなければ、OCNを解約してそのまま光回線は終了にして、LTEルータを注文したい。今度は、届いてから「あっ!」ってことがないようにしたいwww

  •   0
  •   1

ここ数日、「例のトリッキーなやつ」(先日の投稿の、Spotifyアプリのログから音量正規化のための値(RG値)を抽出して正規化する方法)が諦めきれず、悪戦苦闘していた。何度も諦めたのだが、そのたびにアイデアが出て来てしまって再挑戦する羽目になり、今日は随分いい感じになったのたが、やっぱり駄目だった。

記念(または証拠)に、最良の状態での動作光景を載せる。画面左上はRG値取得用Spotifyアプリ、右上はミュート(上側)・ゲイン調整+リミッター(下側)用アンプ、左下はミニプレーヤー、中央から右下は再生用Spotifyアプリである。曲間でのアンプの設定の変化や、プレーヤーの切り替わり(アプリ下部の緑の帯)に着目されたい(もちろん、手で操作している訳ではないし、マウスなどを自動操作するツールを使っている訳でもない)。

Spotifyアプリから音量正規化のための値を抽出して音量正規化している画面

動作の流れは以下である。

  1. Spotifyアプリ(音量正規化: off)が再生を開始する(またはトラックが変わる)のを待つ。
  2. アンプでSpotifyアプリの出力をミュートする。
  3. プレーヤーをRG値取得用Spotifyアプリ(音量正規化: on)に切り替える。
  4. その曲のRG値が取得できるまで(再生して)待つ。
  5. アンプにRG値を元に計算したゲイン(増幅量)を設定する。
  6. プレーヤーを再生用Spotifyアプリに切り替える。
  7. 曲の先頭に戻る。
  8. アンプのミュートを解除する。
  9. 再生を開始する。

基本動作はできた※のだが、試しに少し(15分くらい)動かしていたら、RG値取得用アプリとSpotifyサーバの通信ができなくなってRG値が取れなくなってしまった。再生用アプリの動作は問題ないので、短時間(RG値取得用アプリに切り替わっている時間は約2秒)で切り替えるとうまく動かなくなってしまうのかも知れない。まあ、再生し始めたと思ったらすぐに切り替えるなんておかしな使い方を想定していないのはもっともだから、仕方ない。

※本方式での音量正規化処理自体は、全く問題なかった。性能(音量の揃い具合)はSpotifyアプリよりも良かった(とはいえ、大差ではない)。また、前回(「と思いきや」のあと)失敗した、プレビュー版のRG値とは異なる場合が多かったので、そちらには得体の知れない値が入っているようだ。

あと、不思議なことに、投稿用に動画を撮り直そうとして再度動かしてみたら、プレーヤー切り替えのタイミングがずれて※、曲間で余計な音(RG値取得中または曲の先頭に戻る前の音)が出るようになってしまった(上の動画はボツのテイクを投稿用に少し編集している。でも、ちゃんと動いていたのは確かで、夢や幻や捏造ではないw)。だから、SpotifyのアプリもWeb APIも、こういうタイムクリティカルな用途には無理があるようだ。

※アプリの切り替え時間(= RG値の取得・処理時間= 曲間)は最初は4秒くらいだったのだが、それでは遅過ぎるので(結構苦労して)高速化・最適化したら不安定になったようだ。元の遅い版ならもう少し安定なのだろうが、それでは気分が悪いw それどころか、最初は1秒以内にしたいくらいだった。

そもそも、(前回も書いたが、)これをやりたかった理由の一つはダイナミックレンジをなるべく減らしたくないことだが、再度計算してみたら、Spotifyの音量正規化のQuietモード(基準音量: -23LUFS)を使っても2ビットも落ちないことが分かった※ので、ポップ音楽でそこまでこだわる意味は全くないから無理する必要はない。

※先日の試算では、音量を-23LUFSにするのに23dB下げると考えたが、それは誤りで、SpotifyがRG値の計算に用いているReplayGainの基準音量は-14LUFSなので、(-14-(-23)=)9dB下げる程度であり、それは(9/6=)約1.5ビット相当である。

あと、RG値取得用アプリが駄目になる問題は、例えば、通信できなくなったらしばらく(数分?)待ってアプリを再起動すれば回復できるだろうが、たとえ自動的にするとしても、再起動されるまでは聴けなくなって気分が良くないし、音量正規化のon/off切り替え時にアプリを再起動したくないからこの方法にしようとしたのに、(再生用ではないけど)やっぱり再起動が要るのでは馬鹿らしい。それに、上に書いたように、タイミングが変動して安定して動かないのでは、とても実用にはならない。

そんな訳で、結果的には無駄なことをして疲れたが、いろいろ(細かい)発見があっておもしろかったせいか、余りがっかりはしていない。むしろ、事前の予想どおり駄目だったものの、基本的には目論見どおりに動作して満足したし、方が付いてせいせいしたw

 

最後に、開発中に分かったことなどを少し書く。

  • Spotifyアプリを外部から制御するにはWeb APIとDbusの2種類でできるが、プレーヤーを切り替えて使う場合はWeb APIだけを使った方がいい。Dbusで操作すると、どのプレーヤーが対象か分からなくなったり、意図したプレーヤーが操作されなかったり、プレーヤーの切り替えがうまくいかない場合がある。
    • Web APIはかなり遅い(数百ms/回)のでDbus(数十ms/回)で高速化したかったのだが、残念ながら駄目だった。
  • SpotifyのWeb APIを短時間に頻繁に使うとサーバがエラーを返すようだ(本文に書いたエラーもこれと同様)。HTTP 500なのでアクセス制限(rate limit)ではないようだが・・・
  • 更に、頻繁に使わなくても謎の動作をする場合がある。Dbusを使わなくてもおかしくなることがあるようだ。
  • 曲の開始直後に先頭にシークすると前の曲にジャンプしてしまうようで、少し待たないといけないようだ。
  • Linuxのサウンド系には謎の損失(音量低下)があるようで、どこかで4dBくらい音量が下がる。PulseAudio(実際にはALSA)からJACKに入るところか、JACKからサウンドカード(実際にはALSA)に出るところかと想像している。
    • ポップ音楽用の音量正規化の場合、目標の音量をReplayGainと同じ-14LUFSにしたので、理論上はアンプのゲインをRG値そのものにすれば良いはずなのだが、この損失を戻すためのゲイン(4.5dB)を加算した。
    • なお、クラシック音楽用ではその損失を加味して、4dB下げるだけで目標の音量(-23LUFS)になった。
  • (書いても誰も分からない気がするが、)本方式の制御プログラムでは、2つのイベント入力(SpotifyアプリのログとDbusのイベント)を混ぜて受信することで、両方ともタイムアウトなしの受信にすることができ、イベントに対するレスポンス時間の短縮と負荷の軽減ができた。でも、本文に書いたように、高速化したら逆効果だったようだw

 

PS. それにしても、昨日(12/29)までは年末という気がしなかったのだが、今日(12/30)になったら急に「今年ももう終わりか」モードになって、妙に慌ただしい気分になってしまった。そして、「年末なのにプログラミングなんてしている場合かっ?」て気もしたが、特に他にすることもないので問題ないw

  •   0
  •   0

Spotifyの音量正規化の改良では散々試行錯誤したが、ようやく自分が納得できるかたちで実現できた。もちろん、結果(性能)も全く問題なかった。音量(Integrated loudness)の値は全く問題なかったし、随分聴いてみたが、(自作とは全然違って、)我慢できないほどうるさい曲(演奏)※も小さ過ぎるものもなく、随分手を焼いていた曲もあっさり大丈夫だった。これなら気楽に聴いていられそうで、ようやく目的が達成できた感じだ。

※正確には、「うるさい」と感じる演奏はある。が、その音量値は全く異常でなかった。ということは、音作り(周波数分布や音質の悪さ? いわゆる「海苔波形」?)によるのか、僕との相性が悪い(音の好みや聴覚のラウドネス特性とのズレ?)のだと思う。実際、不思議なことに、アンプの音量を小さくしていても、いつもうるさく感じる演奏はやっぱりうるさく感じる。つまり、「うるさい」は音量が大きいだけではないということだ。まあ、語義からしても当たり前か。

以下に試行錯誤の経過や内容を書く。

前回の投稿ではSpotifyの音量正規化のNormalとQuietを手で切り替えて使うと書いた。そして、前回も書いたが、音量を揃える(増やす)ために増幅してもそれほど音質が劣化しないことが分かったので、その方法を詳しく検討した。基本的には、単に(ソフトの)アンプで増幅すればいいのだが、使う要素(アンプの種類)や増幅する量を最適にしようとしたのだ。

まず、以下を試した。増幅量は+11dB(-23LUFSを-12LUFSにしようとした)にした。

  • JACKのjack_mixerのボリューム:音は悪くない感じがした。 → その後、長時間聴いたら耳閉感が起こった。
  • PulseAudioのボリューム (Spotifyのsink-input):音が悪い感じがした。わずかに耳閉感が出た。

PulseAudioでの増幅で音質劣化がありそうだったので、何種類かの増幅量で歪率を測定したが、オーバーフロー(0dBを超える)しなければ(+15dBくらいまで)は問題なさそうだった。それで、実際の曲で試したら、ポップ音楽でも意外にダイナミックレンジが広いようで、+9dBでも簡単にオーバーフローした。

それで、リミッターでオーバーフローしないようにすることにした。PulseAudioで増幅してオーバーフローすると、その時点で歪んでしまうので、あとにリミッターを入れても無意味なので、JACKのアンプ+リミッターの構成にすることにした。リミッターにもいくつかの種類があり、以下でオーバーフローさせて試したが、いいものは少なく、結局、Fast Lookahead limiterを使うことにした。これには入力にゲインがあって、それがアンプの役割をするので丁度良かった。

  • Fast Lookahead limiter: 一番いい感じ。過大入力でも、自然な音で0dBを超えないように制限される。
  • Wave Shaper (Sine-Based): 過大入力(例: +17dB)で音が変わる(歪む)。
  • Simple Limiter (Peak Env. Track.): 過大入力(例: +17dB)で「ワウワウ」になる。
  • Calf Sound GearのCalf Stereo Tools: 最初は良かったが、長く聴いたら耳閉感が起こった。
    • 後述のNon Mixerにした時に、バイパス機能とSoftClip(リミッター)があるので試した。

それから、Spotifyの音だけを増幅したいので、SpotifyのJACKへの出力を独立にし、更に、ポップ音楽用とクラシック音楽用で増幅をon/offする必要がある。

その前に、いつも評価用に使っている曲をSpotifyの正規化(Quiet)+増幅(+9dB)で試したところ、殆どのポップ音楽は問題なかったが、"Speak to me"は駄目で、Normalと同様な不自然さがあった。原因を調べたら、前回の投稿の付録に詳しく書いたが、オーバーフローがリミッターでカットされる時間が長いためだと分かった。それで、増幅量を+6dBに減らし、リミッターの回復時間を長く(2秒)にすることで不自然さを緩和した。回復時間を"Speak to me"の鼓動の周期より長くすれば、ずっと音量が下がったままになるので、不自然さが緩和されるのだろう。完璧ではないが、"Speak to me"のような曲は例外的だから許容できると考えた。ただ、他の曲が不自然になるかも知れないので、その時に調整したい(今のところは問題ない)。

結局、以下の3つのモードを作ることにした。

ポップ向けでの増幅量について: 通常のReplayGainで正規化する(あるいは、0dBまで目一杯出す)他のプレーヤー(具体的にはgmusicbrowser, GMB)と音量を揃えるにはなるべく上げる方がいいが、前述したオーバーフローによる劣化も嫌なので、試行錯誤(勘?w)で決めた。+7dBだと、SpotifyのQuietモードでの基準音量 -23LUFSを-16LUFSまで上げることが期待できる(当初は+10dBして-13LUFSくらいにしたかったが、やり過ぎのようだ)。

3つのモードはミニプレーヤーのボタン(右端の"Sp", "S", "-")で切り替える。音量正規化の有無はSpotifyを再起動すればいいが(とはいえ、重いから避けたかったが、それ以外に方法がないので仕方ない)、JACKのアンプで外部から制御できるものがなかった(後述するように、実はそうではないが、当時はそう思っていた)ので、増幅の有無の切り替えが困難だった。それで、接続(配線)を変えることにした。簡単に書くと、以下のように切り替える。

  • 増幅あり: Spotify → アンプ → ミキサー → 補正用イコライザ → 出力
  • 増幅なし: Spotify → ミキサー → 補正用イコライザ → 出力

なお、なるべくSpotifyを再起動しないで済むように、右クリックで音量正規化モードの切り替えを逆順にできるようにしたのだが、順番を覚えていないためにやっぱり再起動になる羽目になるので、マウスオーバーでガイドを出すようにした。

なお、プログラム(xdotool)でリミッター(アンプも兼ねる)のEnableボタン(中央付近)を押すことでも、増幅の有無の切り替えが可能なので試してみたのだが、勝手にマウスが動くと(その後自動で元に戻しても)結構ストレスに感じるし、その時の操作状態によっては誤動作・操作することもあるので止めた。

その後、モード切替のたびに接続(配線)を変えるのは全然スマートでないし、遅いし、JACKサーバへの負荷が重そう(頻繁に繰り返すとおかしくなりそうな気がした)なので、避けられないか考えた。それで、以下の2種類を順に試した。

  1. OSC(Open Sound Control)という仕組みで外部プログラムから制御可能な、Non Mixer(エフェクタも入れられるミキサー)を使い、リミッターの増幅量を変える。
    • Non Mixerはエフェクタのon/off(Bypass)を外部プログラムから制御できないので、増幅なしの場合にはリミッターの増幅量を0dBにすることで、offの状態にした。
    • この方法には実用上は何も問題がなく、充分良かったのだが、微妙に気に入らないために別の方法を探して、次の項のjack-rackになった。例えば、以下が気に入らなかった。まあ、車で言えばトヨタのように、「ソリが合わない」ってやつだろうかw まあ、jack-rackが駄目なら戻ればいい。
      • 外部からBypassが制御できない。ゲインでもできるけど、何か直接的でない。
      • 大げさ: ウインドウが無駄に大きいけど小さくできない(確か、一番幅を狭くした状態がこれ)。
      • 名前が悪い(結構真面目に良くない)。「おフランス」なのだろうか?
  2. MIDIでjack-rack(エフェクタを入れるソフト)を外部プログラムから制御し、リミッターのon/offを切り替える。
    • 試行錯誤の結果(以前試した記録が役に立った)、MIDIを使う方法が分かり、どうにかjack-rackも制御できるようになったので、リミッターのon/offが外部から制御できるようになった(のEnableボタンを押すのと同じ効果)。
      • ただし、ちょっとしたバグがあり、jack-rackの起動後にMIDI設定のダイアログが出てしまうが、仕方ない(これを自動で閉じるようにしたら動作がおかしくなってしまったので、手で閉じることにしている)。
      • ↑面倒だし目障りなので、xdotoolで"OK"ボタンを押すようにして自動で閉じるようにした。ただ、ウインドウサイズが変わると予期せぬ事態が起こりそうだ。 (18:19)

MIDIについての特記事項を以下に列挙する。

  • JACKサーバ: MIDIドライバ(midi-driver)に"seq"を指定する。
    • 上記設定をすればa2j_control(a2jmidid)は不要と思われる。
  • MIDIの配線: 当然ながら、JACKで、外(ALSA?)からのMIDI情報の出口(僕の環境では"Midi-Through:midi/playback_1")と制御対象の要素(jack-rack)を接続しておく(図左側の赤線)。
  • MIDI制御情報の送信: sendmidiコマンドを利用した。他にもあるが、僕には一番使いやすかった。
    • 実行例: sendmidi dev "Midi Through Port-0" ch 1 cc 0 0: (僕の環境・設定において)jack-rackの"Enable"をoffにする。
      • 注: 上記MIDIデバイス名はJACKでのもの(一つ上の項に書いた)とは異なる(ALSAのもの?)。sendmidi listコマンドで名前を確認すること。
  • jack-rackの設定: 制御したい要素(例: ボタン)上で右クリックすると設定ダイアログが出るので、そこにチャネル番号(sendmidiのchに指定する番号)とコントローラー番号(sendmidiのccに指定する番号。正式な名称は不明)を設定する。
    • この方法がなかなか分からなくて諦めていたのだが、jack-rackのgithubのページでようやく分かった。
    • Enableについては、設定値に127以上を指定しないとEnable状態にならない(Disable状態にする時は0でいい)ので、0と256を指定することにした。
    • あとで使うかも知れないので、Input gainとWet/dryも設定できるようにした。
  • どうしてか、(音と違って)JACKでの正式なMIDIのポート名は"system:midi_playback_1"のような分かりにくいものになり、起動のたびに番号が変わる感じで(要確認: 思い違いかも知れない ← クライアント(jack-rack)側の名前の番号は、起動順序で変わるのかも知れない)、自動で配線を保存・復元する機能がうまく動かなかった。それで、現在使っているMIDIの線は1本と少ないので、自動保存・復元の対象にせずにJACKの起動スクリプトで個別に配線することにした。
    • JACKの設定などで直るのかも知れない。
    • ↑JACKの設定ではなく自動で割り振られるようなので、JACKサーバ起動時にMIDIポート名の変換テーブルを作り、接続の自動保存時に、そのテーブルを元に、クライアントの起動順序で変わらないポート名(alias)に変換して保存するようにした(変換後の名前でも接続できるので、復元は問題ない)。 (12/23 22:42)
  • MIDIではデバイスの設定状態を取得することができない(標準的な方法がない)ので、アンプの状態は常に「上書き」する(現在の状態と比較するようなことは行わない)ことにし、設定後に状態をファイルに保存しておき、ミニプレーヤー(minisp)の起動時に保存された状態を再設定することにした。
    •  (ソフトの)MIDIは高速だしデータ量も少ないから、これで大きな問題はなさそうだ(世の中の電子楽器は基本はそうなのだろう)。
    • また、再生停止中にJACKサーバが再起動することもあるので、再生開始時にそれを検出したら(サーバの起動後に起動時刻をファイルに記録しておく)保存された状態を再設定することにした。上で「問題ない」と書きつつも、毎回無意味に設定するのは気分が悪いので、ここでは無駄な設定を省くようにしたw

それから、Spotifyの音量正規化(改良版)の性能を自作の方式と比較した結果を書く。双方で共通する38曲(演奏)について比較した。

判定条件

  • 音量の許容範囲: 基準(中心)から±2LUFS以内 (幅: 4 LUFS)
    • 音量(Integrated loudness)が上記許容範囲内なら問題なし(○)とする。
    • 問題なしの外側2 LUFSを可(△)とし、可の外側を不可(×)とする。
    • 下記の「偏差」は、音量が許容範囲の外側(○以外)に出た量である。

Spotify (Quietモード)+増幅 (ポップ音楽用: "Sp")

  • 設定
    • 基準音量: -16 LUFS
    • 音量の許容範囲: -18 .. -14 LUFS
  • 結果
    • 範囲内(○): 35曲 (92%)
    • 可(△): 3曲 (7.9%)
    • 不可(×): 0曲 (0%)
    • 合計: 38曲
  • 統計量
    • 音量の平均: -15.8 LUFS
    • 音量の標準偏差: 1.39
    • 偏差の平均: 0.1 LUFS
    • 偏差の標準偏差: 0.39

自作の方式 (ポップ音楽用: "Pk")

  • 設定
    • 基準音量: -20 LUFS
    • 音量の許容範囲: -22 .. -18 LUFS
  • 結果
    • 範囲内(○): 25曲 (61%)
    • 可(△): 9曲 (22%)
    • 不可(×): 7曲 (17%)
    • 合計: 41曲
  • 統計量
    • 音量の平均: -19.5 LUFS
    • 音量の標準偏差: 2.80
    • 偏差の平均: 0.74 LUFS
    • 偏差の標準偏差: 1.54

はっきり言って完敗である。Spotifyには不可(×)の曲がまったくなかったのには感心する。しかも、範囲内(○)に収まっている率が1.5倍と高く、音量のばらつき(音量の標準偏差)は半分以下、偏差の平均は1/7以下である。(数値的には)充分に音量が揃っていると言える。

ただ、負け惜しみではあるが、Spotifyは必要なデータを使って「普通に音量正規化(ReplayGain)をしている」のだから、良くて当たり前だとは思う。が、自作で情報(RG値)が不足した状態でいくら頑張っても勝ち目はないし、意味がないことは確かだ。

最後に、今回分かったことなどを列挙する。

  • クラシック音楽は予想以上にダイナミックレンジが広い。例: チェロの演奏(「無伴奏チェロ」 "Suite No. 5 in C Minor BWV 1011: V. Gavottes I & II")でもピークが平均値+約18dBまである。
  • 思い込みかも知れないが、日本のポップ音楽は比較的音量が揃っている。正規化後の音量が申し合わせたかのように基準値付近だった。国民性?
  • どうしてか、Calf Studio Gear(JACK Audioのエフェクタのスイート)はやっぱり駄目だった。リミッターですら耳閉感が起こる。根本的に作りが悪いのだろうか? でも、誰も文句を言っていないようだから、僕との相性なのか・・・
  • 少しだけでもMIDIの使い方が分かったのは収穫だ。演奏はしないが、JACKの要素の制御に使えるのが便利だ。
  • 同様に、今回は使わないことになったが、OSCも制御に便利そうだ。ただ、手間を掛けてそういう新しいのを作らずに、Dbusを使えば良かったのにとも思う・・・

これにて音量正規化問題は一旦終了!

一段落して、心置きなく気楽に音楽が聴ける。

 

と思いきや、、、毎度のことながら、そうは問屋が卸さなかったwww

昨夜、複雑なために一旦諦めたトリッキーなSpotifyの音量正規化用の値(以下、RG値)取得の方法を、なるべく簡単に実現するにはどうしたらいいかなどと考えながらSpotifyのログを眺めていたら、思わぬ展開になった。すごく簡単に取れるかも知れないことが分かったのだ。

RG値はSpotifyアプリのログに出ることは分かっていたが、音量正規化をonにしないと出ないし、その仕様がいつなくなるかも知れないのだが、SpotifyのWeb APIのGet a Trackなどで取れるプレビュー(試聴)用のMP3ファイルに入っていたのだ。全くコロンブスの卵というか、灯台下暗しだ。

その前に、RG値も入っていると思われる、ヘッダ部("head file")取得用URLがログから分かり、その中身はBase64エンコードされたOggだったので、「もしや!?」と思ったのだが、曲のデータ同様中身が暗号化されていてお手上げだった。

ただ、プレビュー用のファイルを普通にsoxiやexiftoolやプレーヤーで情報を表示してもなぜかRG値(例: REPLAYGAIN_TRACK_GAIN)が出ないので諦め掛けたのだが、ffprobeでは"Side data"として出た。だから、通常のMP3での格納方法ではないのかも知れない。あるいは、僕がMP3に詳しくないだけか?

↑調べたら、MP3のRG値は「LAMEタグ」というものに入るようだ(MP3の標準タグ(ID3v2?)に入らないのかは分からない)。eyeD3というコマンドに--lametagというオプションを指定すると見られる(そうしないと見られない!)。あ、lameはフリーのMP3エンコーダだから、LAMEタグという名前からして、それが独自に付けているようだ。ということは、入ってないものも、将来なくなる可能性もありそうだ。MP3は随分使われているのに、RG値すら標準で入れられないのだとしたら、なかなか面妖だなあ。。。 (18:51)

それで、その値が正しいかを確認するため、数曲で全体(全曲)とプレビュー版のRG値(track gain)を比べた。なお、全体のRG値はSpotifyアプリのログから抽出した。

  • 夏の扉
    • 全体: -8.71 dB
    • プレビュー版: -9.30 dB
    • 差: -0.59 dB
  • どうにもとまらない
    • 全体: -8.64 dB
    • プレビュー版: -9.10 dB
    • 差: -0.46dB
  • Speak to me
    • 全体: +13.49 dB
    • プレビュー版: +14.10 dB
    • 差: +0.61dB
  • Born to be wild
    • 全体:-3.64 dB
    • プレビュー版: -3.40 dB
    • 差: +0.24 dB

一見、全体とプレビュー版で随分値が違っていたのでがっかりし掛けたが、差を求めたら1dB未満(0.5dB前後?)なので、使えるかも知れないと考えた。

最初はRG値の差は圧縮率の違い(全体: 160kbps, プレビュー: 96kbps)によるものだと思ったが、その後、プレビュー版は先頭の30秒だけで、RG値もその部分のものであるために異なっているのではないかという懸念が生じた。それで、先頭の音量は小さく、後半に大きくなる曲("Stairway to heaven")で確認したら、プレビュー版のRG値も全体ものらしいことが分かった。: プレビュー版のRG値は全体の値とほぼ同じで、更に、手持ちのもの(マスタリングが異なるかも知れない)の先頭を切り出してRG値を求めたら、(先頭は音量が小さいため、)プレビュー版や全体より随分大きな値になった。以下にそれらの値を示す。

  • Spotify
    • 全体: -5.26 dB
    • プレビュー版: -5.0 dB
  • 手持ちの曲の先頭(30秒)の切り出し: +5.2dB (GMBで求めた)

実際、手持ちの演奏のラウドネス(Integrated loudnessをebur128コマンドで求めた)は13.3LUFS違っていた。

  • 全体: -11.1 LUFS
  • 曲の先頭(30秒): -24.4 LUFS

念のため波形を比較すると、確かに先頭と全体の平均音量は10dBくらい違っていそうだから、きっと大丈夫だ。

"Stairway to heaven"の振幅: 上: 全体, 下: 先頭30秒 (縦軸はdB)

実際、Spotifyの立場で考えると、プレビューを提供するためだけに全部の曲のRG値を計算し直すのは馬鹿らしいし、プレビュー版の再生時に正規化するとしたら(実際にはしないと思う)、全体のRG値でする方が本来の雰囲気に近く、「試聴」の意図に合うから、全体のRG値を入れている(実際には全体の値を捨てずに残しているだけ?)のは腑に落ちる。想像だが、この値はレーベルから提供された試聴用ファイルに入っているものなのではないだろうか? (音源提供者向けの案内を調べれば分かるかも知れない)

プレビュー版内のRG値を使う場合には、以下のような手順で「普通の」(自分の好きな基準音量に合わせられ、Spotifyアプリのリミッターを回避する)音量正規化ができそうだ。

  1. Spotifyアプリが再生開始するのを待つ。
  2. API: Get a Trackを使い、プレビュー版を取得する。
    • Get a trackのpreview_url要素より。
  3. プレビュー版のファイル(MP3)からtrack gainを抽出する。
    • ffprobeを使う (exiftoolやsoxiでは出ない)
  4. 音量正規化処理を行う。
    • 抽出したtrack gainに従って、音量補正値をアンプに設定する。
      • 基本的にはtrack gain(dB)そのものをを設定すればいいが、オーバーフローを回避するために、適切にオフセットする(下げる)必要がある。

あとは作るだけ。だが、ちょっと疲れた。それに、寒いしお腹空いたしw

 

と書いたところで、思わぬ落とし穴に気付いた。: すべての曲に、あるいは、今後もずっと、プレビュー版にRG値が入っているか疑問だ。入ってない曲があったり、いつかなくなる可能性がありそうだ。上に書いたように、この値は使われることがないだろうし、意図的に捨てていないからあるだけで、Spotifyのサービスの仕様ではないからだ。

そうなっても、(今までのように、)いくらでも回避策は考え付くだろうが、結局、堂々巡りになりそうな感じだ。それだったら、(音質などが完璧ではないものの、)気楽に聴ける今の状態で満足するのが一番得策な気はするが・・・ うーむ。 まあ、興味本位で「お遊び」でやるなら ありかな(いや、全部遊びだがw)。

↑イマココ

(12/25 12:41) 「プレビュー版のRG値で正規化」をちょっと試してみた。結論は、やっぱり駄目だった。以下に理由を書く。

  • 予想どおり、RG値が入ってない曲がある。確率は5%程度ではあるが、少なくない。
  • 更に、RG値がおかしい曲もあった。こちらは10%程度と多い。
    • 数曲について、Spotifyアプリのログに出る全体(正式版)のRG値とプレビュー版のRG値を比較したところ、正規化後の音量が駄目だったものは大きく異なっていた。
    • 逆に、プレビュー版のRG値で正規化でも問題ない場合は近かった。
    • 当然ながら、全体のRG値で正規化した音量を計算したら基準範囲内だったので、問題なさそうだった。

どちらも致命的だ。評価用プレイリスト(ポップ・クラシック合計約90曲)で試したところ、ポップ音楽はまあまあだったが、クラシック音楽は惨憺たる結果だった。うまく行くものもあるから、その曲のプレビューのRG値が良くないのだが、どうしてそうなのかは分からない。プレビュー部分だけのRG値が入っているとか、元の版が違う(プレビュー用は初期のマスタリングなど?)とか、テキトーに計算したとかだろうか。いくら原因が分かっても、プレビュー自体すらなくてもいいような状態でSpotifyは全く保証していないので、対処してもらえる訳がない。

プレビューですらこんなことでは、以前書いた、ログからRG値を抽出する「トリッキーな方法」なんて余計駄目だろう。

いずれにしても、結果としてはイマイチだった。これがうまく行ったらすごくいいと思うが、やっぱり問屋が卸してくれなかった・・・ まあ、作るのはそれほど大変でなく、いつものようにおもしろかったからいいや。

そういう訳で、今は元の状態に戻して、「気楽に聴ける」状態になった(この音量正規化が破綻しないのには本当に感心するw)。これを試した一番の理由の、正規化をon/offする時のSpotifyの再起動を回避する件については、別の方法を考えたい。

一応、設定画面を開かずに、外部から音量正規化をon/offする方法はないかSpotifyに聞いたが、「ない」とのことだった。まあ、それは仕方ない。きっと、かなりニッチな要望なのだろう・・・ (12/25 15:38)

(とりあえずは、)本当に一件落着■

 

(題の漢字は、各自自由にご想像下さいw)

  •   0
  •   0

どっかの国の政府とか軍隊みたいに、勝算がないのに精神論(利権も?)で金・労力を投入して無理な行軍を延々と続けて、最後に、さまざまな言い訳をしながら形式上は「成功」などと発表してドヤ顔して(それどころか、首謀者が逃亡・知らん顔して、)煙に巻くのは愚の骨頂だ。駄目なものはなるべく早く気付いて切る(少なくとも、再検討や方向転換する)のが重要だ。

試行錯誤しているSpotifyの音量正規化処理の改良だが、ポップ音楽モードがそこそこ うまく行って、クラシック音楽モードも調整して目処が立ったものの、今朝寝ながら思い付いた(気付いた)。Spotifyアプリの(標準の)音量正規化機能がどのくらいのものなのか、それと今回の自作の方式にどのくらいの差があるのか確認しようと。特に、曲の特徴量のデータが誤っているのではないかというくらい大音量になるいくつかの曲(例: "Take My Breath Away", "Catacombae")は、Spotifyアプリの音量正規化ではどうなるのか興味があった。

やってみたら、多くの収穫があった。

  • Spotifyアプリの音量正規化の性能はいい。自作の方式よりずっと音量が揃う。ポップ音楽での音量幅(ラウドネスの不揃い度)は、自作の方式では、(試した数曲の音量の範囲が広かったとはいえ、)おかしい音量になる曲を除いても、目分量でSpotifyの2倍(LUFS値の幅)くらいだった。おかしい音量になる曲を含めれば数倍になる。
  • Spotifyアプリの音量正規化のうち、Quietモードでは、Normalモードと違い、すごく静かな曲(例: "Speak to me")を不自然にしてしまうコンプレッサー(のような処理)が働かないようだった。
  • Spotifyアプリの音量正規化用の値は、ログやコンソール出力から取得できる。ただし、音量正規化をonにしていないと出ない。

Spotifyアプリの結果を聴いたら悔しいくらいだった(上記の困った曲が何の問題もない音量で出ていた)。悔しいけれど、結局、自作の方式でいくら頑張っても苦労ばかりで余りメリットはなさそうだ(そもそも、目的はそこにない)。それよりは、Spotifyアプリの音量正規化をうまく使えばいい。

一番手軽なのは、音量正規化をする場合は常にQuietモードを使うことだ。これなら、ポップ音楽でもクラシック音楽でも切り替え不要で、静かな曲でも音が不自然になることはなさそうだ。ただ、目標音量が-23LUFS程度と小さいので、もったいない気がする。特に、ポップ音楽では、もっと音量を上げてSN比を向上させたりダイナミックレンジを減らさないようにできる(だからNormalモードを使いたいのだが、例のコンプレッサーが邪魔だ・・・)。が、そもそも、音量正規化して聴くというのは、BGMのように気軽に聴いている時であり、その時にSNだのダイナミックレンジだのと言っても無意味だ。逆に、真剣に聴く時には音量正規化を使わないから、これで問題ないとも言える。

少し前に試行錯誤中に知ったのだが、Spotifyアプリの音量正規化はトラックモードとアルバムモードを自動で切り替える(アルバム再生時は後者になる)とのことなので、自作しようと思った切っ掛けの一つの、アルバムモードがないことも解決できた(この機能は後から追加されたのか、最初からあったが公表されていなかったのか)。そういう点でも、特にモバイルなどで切り替えずに使いたいなら、Quietモードにしておけば不便はない(まあ、モバイルでは周囲が騒がしいので、すごく静かな曲が不自然でも問題なさそうだから、Normalでもいいとも言える)。

ただ、Quietモードのもう一つの問題は、音量が小さいので他のプレーヤー(僕の場合は、gmusicplayer, GMB)と合わないことだ。これは結構厄介だ。Spotify(音量正規化)からGMBに切り替えた途端に大音量(約+11dB, 3.5倍)になるので、常に注意が要るし(大抵忘れて驚くw)、アンプの音量調整が煩雑だ。アンプの音量を変える代わりに他のプレーヤーの音量を下げる手もあるが、やっぱり「もったいない」から避けたい。逆に、Spotifyアプリの音量を後で大きくして合わせる手もあるが、一旦小さくしているのを増幅すると音質が劣化するから嫌だ。

書いた後で気付いたが、小さくしたのを増幅すると音質が劣化するというのは本当だろうか? (アナログでなく)ディジタルなので、増幅でオーバーフローしない限り、小さくした時より劣化することはない気がして来た。あとで検討したい。 ← データフォーマットにも関係ありそうだ。 → 検討結果を付録に記載した。 (12/19)

調べると、-23LUFSというのはEUの放送の基準レベル、あるいは、クラシック音楽向けだそうで(USや日本の放送は-24LUFS)、それに合わせるのは悪くないとは思うものの、自分の閉じた環境なのに一律に低く合わせるのはやっぱりおかしい気がする(実際、SpotifyやYouTubeの基準は-14, -13LUFSと、-23LUFSよりかなり大きい)。

以下に、候補とそれぞれの欠点をまとめる。

  • 自作の音量正規化
    • 音量を揃える能力がSpotifyより低い。
    • 全然揃わない曲がある。
    • 原因: Spotifyから音量正規化のための値(ReplayGain)が取れないので、音響的特徴量から推測しているため。
  • Spotifyの音量正規化: Quietモードのみ
    • ポップ音楽でダイナミックレンジがもったいない。
    • 音量が小さいので、音質が劣化する?
    • 他のプレーヤーと音量が揃わないので不便。 → 増幅すると音質が劣化する(要確認 → 検討結果を付録に記載した。 (12/19))。
    • 原因: Quietモードは音量が小さいため。
  • Spotifyの音量正規化: Normal, Quietモードを切り替える。
    • Normalで不自然になる曲(静かなもの)がある。
    • 原因: Spotifyアプリの処理(コンプレッサー?)が入ることがあるため。

上述のとおり、自作の音量正規化が駄目なのはSpotifyからReplayGainが取れないためなのだが、どうにかして取る方法はないかと試行錯誤していたら、思わぬことで取れた! 既に書いては居るが、アプリのログやコンソール出力に表示されるのだ。以下に"Speak to me"での例を示す。太字がトラックのReplayGainである。

02:05:55.089 I [libvorbis_ogg_decompressor.cpp:401] track gain: (13.25Db), track peak: (0.409425dB), album gain: (-5.09dB), album peak: (1.02865dB), normalization: trackgain

ちなみに、それらはGMBでの同じ曲(同じマスターと思われる)でのReplayGainの値と概ね合っていた。

なお、peakの単位が"dB"と書いてあるが、誤りであろう(正しくは単位なし)。同じく"Db"もtypoだろう。ここら辺は そうなる状況が分かる。つい指が動いたとか、余計にコピペしたとか。「(見ると気になるけど、)デバッグ用だからまあいいか」、みたいなw

それで、自作の音量正規化にSpotifyのReplayGain(以下、"RG")値を使う(苦肉の)策を考えた。理論的には、RG値取得用と再生用の2つのSpotifyアプリを使えばできそうだ。以下に手順概要を示す。

  1. 再生用Spotifyアプリを音量正規化offにする。
  2. RG値取得用Spotifyアプリをログまたはコンソール出力ありで起動する。
  3. RG取得用Spotifyアプリの音量正規化をon(NormalまたはQuiet)、音量=0(-∞ dB)にする。
  4. RG取得用Spotifyアプリで再生開始する。
  5. ログまたはコンソール出力からRG値を取る。(すぐに出るはず)
  6. RG取得用Spotifyアプリを一時停止する。
  7. 得られたRG値で再生用Spotifyアプリの音量を調整する。(現在の自作と同じ方法)
  8. Spotify APIを使い、有効なプレーヤ(デバイス)を再生用Spotifyアプリに切り替える。
  9. 再生用Spotifyアプリで最初から再生開始する。

ちょっと手で試して、やればできそうな気はしたが、(すっかり忘れて居た)昔のGoogle play musicの時(→ )と同様に、余りにもトリッキーで嫌になるくらいだ。また、アプリが2個なのでメモリも2倍食いそうなのも嫌だ。そもそも、ログにRG値が表示されるのは仕様でもなんでもないので、出なくなったら元の木阿弥だ。。。

だから、やっぱり筋が悪い。

そして、作るのは面倒だw

それで、とりあえずは、Spotifyの音量正規化機能を使うことにし、ポップ音楽とクラシック音楽でNormal(ポップ)とQuiet(クラシック)を切り替えて使ってみて、Normalでどのくらい不自然な曲があるかで判断することにした。Normalで駄目な曲は(DBに記録しておいて)自動でQuietに切り替える手が考えられるし、多かったらQuietだけ使うとか、上のトリッキーな手を使うことも考えられる。

それにしても、「とりあえず」のNormalとQuietを手で切り替えて使うにも自作ミニプレーヤー(minisp)に多少の変更が要るので、「ちょっと疲れたから、まあ明日にするか・・・」と一休みしているw ← イマココ

相変わらず寄り道が多く、先は長いw

 

(12/19 16:40) 付録: (デジタルで)増幅すると音質が劣化についての検討

結論は、「理論的には劣化しないが、現実には劣化する」である。以下に理由を書く。

まず、本文に書いた状況での音質劣化は、音量を下げた時点で生ずるものが主である。音量を下げることによってデータの有効ビット数が減るため、振幅分解能が減る(例: ものすごく小さい音が消える)ためだ。音を格納するデータフォーマットが浮動小数点型であれば、おそらく分解能が減ることはないが、整数型の場合には減る。その程度は以下のように試算できる。

音量を-23dB下げた場合、1ビットは約6dBなので、23/6= 約3.8ビット減る。

これによるダイナミックレンジの減少量は、データフォーマットを16ビットとすれば、3.8*6= 22.8dBである(音量を下げた分(23dB)そのもの)。

(2020/1/2 12:28記) 注: その後、Spotifyが音量正規化値の計算に使っているReplayGainの基準音量は-14LUFS相当であることが分かった。そのため、実際に下がる音量は9dB程度で、減るビット数は1.5ビット程度と少なく、特にポップ音楽では、音質の劣化もダイナミックレンジの減少もほとんど問題にならない。

実害について考えれば、対象はポップ音楽であり、そのダイナミックレンジを高々18dB(約3ビット分)程度と推測すれば、音量を下げた残りのビット数は16-3.8= 12.2ビットで、音源の3ビットより充分大きいので、記録された振幅がよほど小さくない限り、問題ないと考えられる。

次に、増幅の影響を考える。増幅は乗算なので全く音質が劣化する要素はないが、現実には、処理系や出力のデータフォーマットは整数型で取り得る範囲が有限なため、大きく増幅すると上限を超えて(オーバーフローして)音質が劣化する。つまり、波形の超過分がカットされるので、音が変質する(例: 歪む)。

この検討中に気付いたのだが、私が"Speak to me"で感じた不自然な感じは、オーバーフローによるものだった。具体的には、音量正規化時に過大に増幅するとオーバーフローが生じ、その超過分をカットすると生じる(これはリミッターの動作であり、本文中の「コンプレッサー」は実際にはリミッターであった)。

不自然さが起こる原因を詳しく推測すると、この曲は低音(鼓動)が強いため、それがオーバーフローしてカットされるのだろう。カットされるのが単発的(不定期)や短時間(瞬間的)に起こるのなら気づきにくいからまだいいのだが、この曲の場合は、定期的に起こる鼓動で、テンポが遅いために比較的長時間音が大きい状態なので、カットされる期間が長く、その間の他の音の聞こえ方が変わって不自然になるのだろう。

この現象はSpotifyアプリの音量正規化だけでなく、私の環境でも起こったので気付いた。具体的には、次のような処理をした時に、Spotifyアプリの音量正規化(Normal)と同様の不自然さが生じた。

Spotifyアプリの音量正規化(Quiet) → アンプ(増幅率: 6-9dB程度) → リミッター

また、Spotifyアプリの音量正規化(Quiet)だけでは不自然さは生じなかったので、問題はリミッターに起因する可能性が高い。

なお、「リミッターが原因だったら使わなければいい」ということはない。リミッターがなくても、超過分はどこかで(例: DACで出力する時)カットされ、それはリミッターよりもひどい音質劣化を生じる可能性が高い。

(12/19 22:23) 補足: 上でデータフォーマットを16ビットと想定したのは、Spotifyアプリの出力がそう("s16le")だからで、通常のOSのサウンドシステムはもっとビット数の多いフォーマットをサポートする。例えば、私の使っているJACK Audioは32ビット浮動小数点である。だから、音質の観点ではSpotifyに音量正規化をさせるのは得策でない。上述の、音量を下げることによるダイナミックレンジの低下などが起こる。が、もし仮にJACKの中やその手前のPulseAudioで行うなら、劣化する可能性はほとんどない。

その後の増幅はJACKで行っているので、通常の増幅率ではオーバーフローしないから、音質劣化も発生しないはずだ。しかし、元々のデータが最大値に近いほうに詰められているためにオーバーフローするし、そうでなくてもDAC(サウンドカード)に出す時にオーバーフローする。それを防ぐには、リミッターを入れるか、音量を下げて(= 適当な値で除算して)全体的なレベルを小さくして(= 小さい方にずらす)DACに出すことが考えられる。

結局、後者はSpotifyの音量正規化(Quietモード)の小さい音のまま出力することと同等である。もちろんそれでも良かったのだが、他のプレーヤーと音量を合わせたいから増幅しようとした。

 

PS. SpotifyアプリからのRG値取得には、音楽圧縮フォーマット展開用ライブラリ(vorbisを使っているようだ)をすげ替えればできるかと思ったのだが、自前で作っているかスタティックリンクしているらしく、外部のものは使っていなかった。考えが甘かったが、まあ、そうれはそうだろう・・・ あとは、逆コンパイルしてバイナリエディットとかいう手もあるかも知れないが、「うーん」だ。それに、プログラムの改ざん検証をしているかも知れないから、できないかも知れない。

なんてことを考え出すから、寄り道が増える訳で・・・

  •   0
  •   0

使っているうちに不満(例: うるさい曲がある)が出て来たために、Spotifyの自作ミニプレーヤー(minisp)の音量正規化処理で、音量の補正量をやはり自作再生履歴DB(Mlhi)に記録しおいてそれがあれば使えるようにしようと思ったのだが、そもそも、元々の方式がいい加減では補正ばかりになって良くないことに気付いた。それで、まずは音量正規化処理を改良することになり、今は、その改良した方式の評価のために、Spotifyで再生している曲の音量を自動で測定する機能を作っている※。音量はできるだけ聴感に近い方がいいので、ラウドネス(Integrated loudness: "I", 参考)にした。随分目的から離れてしまった気がするが、きっと気のせいだろうw 自分でやり出したこととはいえ、なかなか面倒だが、いろいろな物を組み合わせて機能を実現するのはおもしろい。

※なぜ自動化しようと思ったのかというと、ラウドネスメーターはあらかじめ曲の先頭で計測開始しておかなければ、正確なIntegrated loudnessの値が出ないので、だらだらと評価がてら聴いていて「大き/小さ過ぎるかな?」(調整がおかしい?)と思ってからでは遅く、再計測しなくてはならないからである。再計測にしたって、曲全体を再度聴くのは苦痛なので、先頭だけなど一部になって、正確でなくなってしまう。曲間で自動リセットしてくれるような測定アプリがあればいいが、そういうものはなかった。また、GUIに表示された測定値を見て手で記録するのは面倒だし間違い易いから、自動でファイルに記録できれば好都合だ。

更に、複数の補正条件・設定の比較についても、それぞれの条件で評価用のプレイリストを再生しておけば(僕が聴いて居なくても、スピーカーで音を出さなくても)通して測定できるので、(この機能が完成した暁には)容易になるはずだ。

更に、普通に再生しながら、補正条件とその結果の音量を測定してDBに記録しておき、次回はそれに基づいて最適な音量に調整するってことも可能な気がしていて楽しい。

更に、今思い付いたが、AIみたいな機能で、長時間いろいろな曲を自動再生して勝手に学習させて、設定を自動調整するなんてのもいかにもおもしろそうだが、先は長いし、そもそもSpotifyを聴くだけなのにそこまでする必要があるのかと・・・w

こうやって風呂敷夢を広げるから、大変になるのだ。

詳しくは別に書くつもりだが、音量正規化の基本的な処理は、従来と同じようにSpotify APIで取得できる曲(トラック)の特徴量(loudnessとenergy)を組み合わせて、曲の本来の音量を推測(復元)し、それを元に正規化している。今回は、その推測の方法を改良しようとしている。今までは思い付きで対数あるいは指数関数を使っていたが、今は下のグラフのような、energyによって特性(係数)が変化する式を試している。グラフはいかにももっともらしくて うまく行きそうに思えるが、そんなことはないw それに、これは何かの理論に基づいている訳ではなく、やっぱり思い付きや試行錯誤からの経験によるものである。試すとまあまあうまく行く(しないよりはずっといい)のだが、やっぱり限界はあるし、値に問題はなくても聴覚に合わないことがある(合わないものが充分に少なくなったら、補正量をDBに入れようと思っている。が、いつになることやら・・・)。

あと、以前のように、公開DBに音量正規化用の値(再生ゲイン)などがないか探したたら、2つ見付かった。一つは前回も見付かったDynamic range databaseで、もう一個はAcousticBrainzだ。前者は、前回は(記憶している限りでは)APIがないのとレパートリーが狭そうなので止めた。後者は、言い方は悪いが「玉石混交」(「ゴ○屋敷」などもっとひどい言い方はあるが、それは言い過ぎだろう)で、全く手軽に使えないので却下した。確かにデータは多いのだが、全然整理されておらず、ただ数字があるだけで、同じIDなのにそれぞれ随分違っていてどれが正しいのか分からず、禄に検索もできなかったら、どうやって使うのかと思う。

作業の途中で分かったことも多かった。SpotifyのAPIから得られるloudnessは多くの場合はIntegrated loudnessまたはReplayGainと同様(同等)のものなのだろうが、そうでないことも多い。中で変・特殊な処理(音量(loudness)が小さいけどenrgyが大きい曲では更にloudnessを小さくしているフシがある)をしている可能性と、データが誤っている場合もありそうだ。そもそもSpotifyアプリで使っている再生ゲインを出してくれれば、こんな苦労をしなくて済むのだが(アプリの一時ファイルを見たりしたが、それらしい値は見つからなかった)・・・

そもそも、Spotifyアプリの音量正規化処理が「普通」だったら、こんな苦労は全くしなくていい(実際、したい訳じゃなくて、ただ音楽を聴きたいw)のだが、前回書いたように、やっぱり謎の処理をしていることが分かった(何人かの方が書かれていた: )。どうやら、アプリにコンプレッサーとかリミッターのような処理が入っていて、特にすごく音量が小さい曲(僕が気付いた曲: Pink Floyd: "The dark side of the moon"の"Speak to me")でおかしくなるようだ。再生ゲインの値がおかしい可能性はあるにしても、せめてその余計な機能がなければまだ良かったのに、どうもお節介な感じだ・・・

ラウドネスの測定プログラムは、GUIのものならいくつかあるのだが、測定・記録を自動化するのは困難なので、スクリプト(jack_captureで音を録り、ffmpegのebur128フィルタでラウドネスを計算する)を作ってミニプレーヤーに組み込んだ。基本的には、ただ再生しているだけでデータが貯まるから楽ちんなのだが、例によっていろいろ凝るから本末転倒になって、処理が複雑になればバグは増えるからデバッグが大変で、また勝手に疲れている。 ← イマココ

 

PS. 以前、「Spotifyには満足している」と書いたが、誤りではない。が、それはあくまでも曲目と音質についてであって、機能は別であるw

PS2. これを書いていて、技術バカにありがちな、「フラット(あるいはリニア)信仰(あるいは症候群、至上主義)」という言葉を思い付いた。やっぱり、こだわり過ぎは駄目なんだろうと思う。が、気軽に聴いている時に、曲のたびに「うるさい!!」とか「小さい・・・」とイライラしてボリュームを調整するのは嫌だってのは大いにある。

PS3. Evernoteやスマフォ・PCのおかげで紙やペンとは無縁の日々なのだが、さすがにグラフの形を考えるのはEvernoteでは無理で(タブレットなら手描きできそうだが、それも煩雑な気がする)、紙が必要だった。が、すぐに使えたのは小さい電話用のメモ帳しかなかったw

(12/14 13:11 少し修正)

  •   0
  •   0

「一体何なんだ」と言いたいが、前回の投稿の後、昨日から今日に掛けて更にトラブルが重なって起こった。

  • スマフォ(AQUOS sense lite)のアイドル時の消費電力率が増える現象が再発した。: 原因不明
  • 自宅とサーバのオンラインバックアップのエラー: 原因不明(「たまに起こる」としか言えない)・・・
  • サーバからの上記のエラーやその他の通知が、Gmailの迷惑メール判定で何通か届いていなかった。: 近頃、誤判定が増えた感じ。

スマフォの消費電力率の問題は今までにも起こっていて、何度も試行錯誤して直ったと思ったのに解決していなくてがっかりした。増えるといっても、長時間アイドル時に平均0.6%/h以下のものが1%/h近くになる程度なのだが、アプリ(My battery monitorなど)で見ると、アイドル状態なのにアクティブ率が100%のままで(= スリープしていない)下がらず、どうも気分が悪い。どうしても直らないようなら、定期的に再起動させようかと思う。が、再起動も電力を食うのでどっちが得だろうか?

オンラインバックアップの問題も今までにも何度か起こっていて、主な直接的な原因は、たまにバックアップソフト(duplicacy)の内部状態とストレージ(Backblaze B2)の状態が合わなくなることのようだ。起こる都度、暫定対処や様子見(再実行で直ることがある)をして来た。それで大きな問題はなさそうなのだが、本当に問題ないかが分からないのが怖い。

本当の原因はネットワークかバックアップソフト(自作+duplicacy)かストレージのどれかなのだろうが、どれかは不明だ。おそらくduplicacy(通信エラーに対するロバスト性が足りない)だとは思うが、サポート依頼を出すにも説明が困難ではある(でも、出せばスパっと分かってくれることもある)。エラーはサーバのバックアップで起こることが多いので、とりあえず、ネットワークへの送信速度を下げてみた。

Gmailの問題は初めて気付いた。今までにも迷惑判定で落とされたものがあるかも知れないが、仕方ない(「なんかおかしい」ということはあった)。たちが悪いのは、Gmailの迷惑メールはThunderbirdの迷惑メールフォルダには出ないことが多くて(出ることもある)気付かないことだ。Googleの商売のせいか、G Suite(有料版)でないと迷惑メール判定の強度調整(そういうのがあればの話)ができないようなので、落とすと困る差出人からのは迷惑メールにしないフィルタを登録してその場しのぎをし、更に、サーバからの通知メールはGmailに送らないようにした。

根本的な対処には、可能な限りGmailを使わない方がいいのだろうが、(アカウントの生成や破棄が)手軽で容量はふんだんだし、Androidには必須なので、根絶はなかなか難しい。。。 とりあえずは、重要な用途には使わない方が良さそうだw

あんなの飾りです。普通の人にはそれが分からんのですよ??

 

題は見直し中にSpotifyで掛かったより。(9:52)

PS. 更に、ついさっきはUbuntuの更新リポジトリの国内サーバにも接続できなかった。一時的なものだろうが、随分重なるものだ。 (8:42)

  •   0
  •   0