CDF22の性能が良いことをうけて、CDF22の端点対応をする。 うーん、端点0次ホールドしたほうが圧縮率がほんの僅かに悪い。実装間違いを疑いつつコミット。
再び残差に注目した。まだ残差波形に対してflacをかけるとかなり小さくなる。これはやはりまだパス数を増やすべきという示唆だと思っている。
そして次は3パス（サブブロックのサイズを2倍, 4倍, ...と変える）を試してみた。するとまた劇的な減少が見られた。。。。LPCを連結するのではなく、ブロックサイズを変えて適用していくとかなりの効果が見られている。。。
さらにブロック内での分割数を増やしていくと、どんどん圧縮率が上がっていく。今まで見たような、連結や次数上げによる圧縮率上昇とは違ったレベルで、次数の影響を受けずに上がっていく。。。少なくとも、ワン・ツー・スゥイーツではtakのp4を超えたかもしれない。残差をflac(-8)で圧縮してももう小さくならない。
冷静になって見たいが、何故これが起きてるのか説明できない。スケールを変えることがなにか本質的に効いている？
もはや、リフティングによる分割+SSによる帯域別適応が可愛く見えるレベルで効いているように見受けられる。→そのとおりで、リフティング+SSは0.1%程度のゲインでしか無い…。
どうしよう。もうウェーブレットとか関係なくて、LPCの連打で高圧縮率を達成してしまっている。しかもLPCだから逆も早いのが分かっている。段階的に残差分散を減らすのがかなり効いているが、なぜうまくいっているか。裏付けが取れないのがすごい厳しい。
気になるのは係数記録サイズ。ネストするとそのノード数だけ係数を用意しなければならない。特に一番下段では次数を上げると圧縮率の向上度合いが良いが、大量の係数が必要になる。。嬉しいことには、LPC係数のビット幅を6bitとかに設定しても あまり圧縮性能が悪化しない ことを確認している。困ったら昔手を付けたPARCOR係数の量子化が効く可能性を考えている。