LPCネットワークの検証に戻る。(i)1層あたりのパラメータを増やす, (ii)層数を増やす の2軸で様子見。 構成は全部LD法初期値から学習するものとする。（前回と(8, 8)の結果が違うのはモーメンタムに修正が入ったから）
| 音源 \ 手法 | ( 8) | ( 16) | ( 32) | ( 64) | ( 8, 8) | ( 16, 16) | ( 32, 32) | ( 8, 8, 8) | ( 16, 16, 16) | ( 32, 32, 32) | ( 8, 8, 8, 8) | ( 16, 16, 16, 16) | ( 32, 32, 32, 32) | FLAC(-8) |
| 薄紅先頭10sec | 64.78 | 63.84 | 63.16 | 62.33 | 63.80 | 63.08 | 62.25 | 63.43 | 62.64 | 61.91 | 63.20 | 62.45 | 61.61 | 64.94 |
| サマーマジック先頭10sec | 58.75 | 57.73 | 56.94 | 56.44 | 57.74 | 56.87 | 56.19 | 57.33 | 56.53 | 55.90 | 57.10 | 56.34 | 55.67 | 57.72 |
パラメータ/層を増やせば増やすほど圧縮率は改善していく（注意：パラメータ領域は記録していない）。 Pythonで観察したように、全体の総パラメータ数が同一ならば、2層構成が一番良い。
じゃあ、具体的にコーデックに仕立てようか。プリエンファシス含め前段に何が良いのかを確定させる。LPCNetは(8,8)で固定、Pは固定プリエンファシス、OPは最適プリエンファシスとしてチェック。
| 音源 \ 手法 | ( P, P) | ( P, OP) | ( OP, P) | ( OP, OP) | ( OP, OP, OP) | ( P, OP, OP) | ( OP, OP, P) |
| 薄紅先頭10sec | 64.78 | 64.49 | 63.99 | 63.80 | 63.80 | 64.46 | 63.95 |
| サマーマジック先頭10sec | 58.52 | 58.18 | 57.96 | 57.74 | 57.79 | 58.21 | 58.11 |
これは、間違いなく最適プリエンファシス2段で確定かな。他にも、(OP, OP)で固定してさらにLPCNetの前にLPCを入れると性能が良くなることを見ている。その次数はいくつがいいか？見てみよう。
| 音源 \ 手法 | 2 | 4 | 8 | 16 | 32 |
| 薄紅先頭10sec | 63.65 | 63.64 | 63.65 | 63.21 | 62.70 |
| サマーマジック先頭10sec | 57.67 | 57.54 | 57.51 | 57.20 | 56.88 |
次数を上げれば上げるほどよい。8であんまり改善しないのは、後段のLPCNetの1層目が1分割になることが多く、結果次数8が2連結になってしまい性能が上がりにくくなっていると考えられる。
LPCNetの前に入れるLPCもNetに取り込むべきではないかと考える。すると、層ごとのパラメータ数を変えるべきという発想に至る。 各層でパラメータ可変になるように対応した。2層がベストという観察だけど、LPCNet前のLPCも取り入れて3層で勝負してみる。つまり、プリエンファシス2段+LPCNet。悪ければ変える。
よし、汚くてもいいからコーデックに仕上げてみよう。出来上がり次第、CMakeでプロジェクトを作ってきれいに実装し、評価フェーズに入る。