土曜日はkolme@西川口。とくにStep by stepがよい。Youtubeと比べると進歩が歴然。 移動中SoundStream読んでた。新しいのは残差のVQのやり方に尽きるかも?でも面白くはあるから紹介する。

日曜日の今日は、補助関数法をコーデックに移植して試している。 結果、手元の音源でわずかに圧縮率が改善している。(まだ不具合があるかも)

繰り返しの過程を見ている。目的関数値(残差L1ノルム)は単調減少しているが、係数が安定しない印象を受ける。これは少なくともPythonで簡単な信号を処理するときには見られなかった。 また、繰り返し回数や収束判定でもだいぶ圧縮率に差が出る(0.1%オーダー)。これはアルゴリズムバグを疑っている。

そして学習をスキップできるかと思ったら、そうでもなくて学習したほうが減る。。 学習にあたっては、1回だけ補助関数法を実行→次の層の残差計算 というやり方が考えられるけどどうだろう。試してみたい欲はあるが、理論がまったくない。 うーん、やはりBPは有効なのかも。なぜなら、最終的な残差を最小にするように層全体に対して学習が動くから。LPCと補助関数法は1層間に対してしか最適化しない。

残差イプシロン、目的関数イプシロンを変えてもだいぶ結果に差が出るのは怪しい。引き続きデバッグする。Python実装と比べても何も思い浮かばないから、もはやテストコード書いたほうがいいかも?

補助関数法の途中の補助変数の絶対値逆数が0割りの可能性があるので、そのイプシロンを設けたところイプシロンの値によってだいぶ結果が変わってくる。補助関数をもっと良いものを構成できないか、原論文を漁った。

  • 予測誤差の Golomb-Rice 符号量を最小化する線形予測分析 原論文。
    • Golomb-Rice符号の最短符号の範囲は広いから、絶対値関数の原点付近は単に0に近づけるより遊びをもたせるのが良いとの記述。それで別の補助関数を作成。その適用法はまだ読み込めてない。
    • 最適解の1つを出力するが、大域最適解は一意とは限らない。まじかあ。

プリセットをもう少し真面目に設定し直した。圧縮率とデコード速度でwavpack(-hh)は越えてる想定。