split decoder into sosoa and vocoder

[Yosshi999]

ストリーミング処理を見据え、decoderからvocoderを切り離す

[Hiroshiba]

ありがとうございます！！！　ちょっと時間かかるかもですがレビューさせていただこうと思います！！

check_contourのテストが落ちてるけど、色々あって使っていないので無視で良さそう･･･！！

[Hiroshiba]

@Yosshi999 すみません、ちょっと確認させていただければ！

Discord の方でお伺いしたのですが、やはり計算誤差は出てしまう感じでしょうか？
聞いた時に問題のないエラーでも、最終的に品質が何か微妙かもとなった時に必ずここに立ち返ってこなくちゃいけなくなるので、可能なら完全一致させておきたい気持ちがちょっとあります。

でも実際聞いた時に問題ないのであればあまりモチベーションとしても微妙だと思うので、ちょっとこちらで頑張ってみようかなと思ってお聞きした次第です！！
どのあたりが原因で誤差が出ていそう、みたいな検討ってついていたりしますか･･･？

[Yosshi999]

この分割自体は出力の変化は発生していません（今のrun.pyはランダム性を持つのでseedを固定する必要がありますが、）mainブランチのonnxとこのブランチのonnxの出力結果の差は0でした

差分が確認されているのは、https://github.com/Yosshi999/streaming_hifigan/blob/master/04_chunking_onnx.py で実験したtransformersのFastSpeech2ConformerModelであり、フルサイズで生成した波形と、（十分なoverlapを持たせたうえで）hifiganをチャンクごとに生成した波形を比較したときに、[-1, 1]の値域のなかで最大 2.6524067e-06 の誤差が発生したものです。時間を横軸にとって誤差を縦軸に取ったときのグラフがランダムだったのでチャンク由来というよりはfloatの数値誤差だとおもいます。

いっぽうで自分が気になっているのは、同じく上記の実験でちょっとチャンクの実装を変えて、入力のmelspectrogramの右端を0でパディングした時に後方の結果が変わることです。すべてのconvolutionはzero paddingだと思っていたので原因がわからず奇妙に思っています（それでも誤差の最大は 0.0019995747 どまりではあります）。

(おまけ)overlapがhifiganのreceptive fieldより足りないと下のようにつなぎ目で誤差が発生します

[Hiroshiba]

おお、なるほどです！！！　完全一致素敵！！！

fastspeechの方の計算結果が合わないのはちょっと分かりませんが、右端のパディングに関してはもしかしたら学習時にスペクトログラムをリフレクトするようにしてるかも･･･？
numpy.padのmodeをreflectにする方もちょこちょこいらっしゃる印象です。信号処理的にはこれがそこそこ良い･･･みたいな感じだった記憶･･･。
https://numpy.org/doc/2.0/reference/generated/numpy.pad.html

まあもしリフレクトにしてたとしたら、前の方はゼロパディングで計算結果が合ってるのはよくわからないのですが。。。。。
な、何かの参考になればということで。。。

[Hiroshiba]

あ、こちらちょっとマージさせていただこうかどうか迷っています！
というのもdecode.onnxができなくなるので、新キャラとかの対応が難しくなるな～と。
なのでストリーム周りの色々が前進し次第マージさせていただければと思っています！！

もしよかったら出来上がった.onnxをこのプルリクエストにアップロードお願いしても良いでしょうか 🙇
コアの方で誰かが試すときとか、そのonnxがあると嬉しそうだなぁと。
多分.zipに固めれば、プルリクエストのコメント欄にドラッグ&ドロップでアップロードできると思います！（便利）

お願いばかりですみません！
難しそうであればこちらで作ってアップロードしてみようと思います！！