[REQUEST v2]: RVCモデルアップロード時にembedderを選択可能なようにする

[lenore-puwawa]

In a few words, describe your idea

RVCモデルアップロード時にembedderを選択可能なようにする

More information

お世話になっております。

現在、RVCモデルをアップロード時に生成される「params.json」内に設定される「embedder」はアップロード対象モデルが持っているconfig等から自動設定されていると思います。
これを、アップロード時に任意のembedderを選択できるようになると嬉しいというのが当リクエストになります。

イメージとしては、アップロード時に表示されるポップアップにリストボックスを追加、「自動設定(デフォルト値)」「contentvec」「jpHubert(rinna Hubert)」より選択した内容にて「params.json」の生成等を行うというものです。

当リクエストの目的ですが、従来はjpHubertのモデルを作成する場合、ddPn08さんのrvc-webuiを利用するのが主流でした。
しかし、上記リポジトリが今後更新される可能性が低いこともあり、jpHubertでの学習に対応されたApplioを利用するのが今は良いと思っています。
ただ、ApplioはddPn08さんのものとは異なり、作成されるモデルのconfigにembedder情報が設定されていない、あるいは設定されているがvc clientへのアップロード時にembedder情報が判定されていません。(v1と同じなら、configの数で本家かddPn08さんか判断、その後にembedder情報を読み取っているのでしょうか)
そのため、アップロード時に任意のembedderを指定できるようになると良いなと思った次第です。

ご検討のほど、よろしくお願いいたします。

[w-okada]

情報ありがとうございます。
applioがjpHubertに対応していることを知りませんでした。
詳細確認は必要ですが、優先度はあげて対応したいと思います（v2）。

[w-okada]

v2.0.72でモデルアップロードするときにapplioのhubertを選択できるようにしました。モデルが無いので動作検証がし切れてませんが、お時間があるときにお試しいただけると助かります。

[lenore-puwawa]

何かとお忙しいところご対応ありがとうございます。
applioにて作成したcontentvec、jpHubertのモデルにて以下を確認しました。

①アップロードを行う際に事前ダウンロードボタン押下→正常終了

②jpHubertのモデルアップロード(index付き)→正常終了
③アップロードしたjpHubertモデルにてindex有無でリアルタイム変換実施→正常終了(変換後音声も特に問題なさそうでした)
④アップロードしたjpHubertモデルをonnx変換→変換中のダイアログが表示されたまま5分経過してもonnx変換が完了しない。コンソールログは「gin_channels: 256 self.spk_embed_dim: 109」とだけ表示されていました。

⑤contentvecのモデルアップロード(index付き)→正常終了
⑥アップロードしたcontentvecモデルにてindex有無でリアルタイム変換実施→正常終了(変換後音声も特に問題なさそうでした)
⑦アップロードしたcontentvecモデルをonnx変換→正常終了
⑧変換されたonnxモデルにてindex有無でリアルタイム変換実施→正常終了(変換後音声も特に問題なさそうでした)

④について、該当箇所と思われるvcclient.logは以下になります。
2024-11-14 01:22:07,670 - vcclient - rvc_onnx_exporter - ERROR - rvc onnx export, unsupported embedder_type:applio_japanese_hubert_base_l12 - vcclient_dev\voice_changer\slot_manager\onnx_exporter\rvc_onnx_exporter.py - 77 2024-11-14 01:22:07,671 - vcclient - validation_error_log - ERROR - VCClientError: {"code":515,"reason":"Failed to export model. Unsupported model type.","action":"Please check the selected model files.","detail":"unsupported embedder_type:applio_japanese_hubert_base_l12"} - vcclient_dev\server\validation_error_logging_route.py - 26

他言語(中国語、韓国語)についてはモデルを所有していないので確認はできていませんが、おそらくjpHubert同様pthファイルによる変換は問題なし、onnxへの変換でエラーになるような気はします。

他に見ておきたいパターンがありましたらお申しつけください。

[w-okada]

ありがとうございます。これは反映漏れですね。。。
次のバージョンで修正します。

[w-okada]

v.2.0.73で修正しました。例によってモデルが無いので試せてませんが、お時間があるときにお試しいただけると助かります。

[lenore-puwawa]

早速のご対応ありがとうございます。
④の分のみ確認を行いました。

④アップロードしたjpHubertモデルをonnx変換→正常終了
⑤変換されたonnxモデルにてindex有無でリアルタイム変換実施→正常終了(変換後音声も特に問題なさそうでした)

ただ、onnxに変換したjpHubertモデル使用時にCPUへの負荷が大きくなっているようです。
こちらの環境の都合で画像になりますが、以下にデフォルトのonnxモデル(黄琴まひろさん)と今回作成したjpHubertによるonnxモデルの変換中のタスクマネージャーの画像を添付します。

デフォルトのonnxモデル

jpHubertによるonnxモデル

vcclient.logを確認すると、デフォルトのonnxモデルの場合は以下のような情報メッセージが出力されていました。
2024-11-15 17:36:15,544 - vcclient - rvc_pipeline - INFO - noise gate -101.41262207877575 < -100.0 - vcclient_dev\voice_changer\voice_change_manager\vc_pipelines\rvc_pipeline.py - 222

対し、jpHubertによるonnxモデルの場合は以下のような警告メッセージが出力されていました。(デフォルトのonnxと同じ情報メッセージは出力されていませんでした)
2024-11-15 17:36:58,312 - vcclient - voice_changer - WARNING - bulk conversion process is not started. - vcclient_dev\voice_changer\voice_change_manager\voice_changer.py - 269

また関係があるかわかりませんが、jpHubertのonnxモデル読み込み時のログにbulk_process_start_flag=Falseとありました。(デフォルトのonnxモデルの場合、上記がTrueになっていました)

[w-okada]

うーむ。
詳細はまだわかりませんが、
まず、デフォルトのモデルと、applioのhubertを使った場合で、大きな違いは、
applioだとhubertはtorch版を使っていて、デフォルトのモデルはonnx版のhubert(より正確にはcontentvec)を使っているというところです。

この違いに起因して発生する処理の違いは、
(hubertの処理は当然なので割愛するとして、)
(1) torch tensor -> onnx(numpy)への変換が発生する。
(2) 線形補完処理がtorchで実施される (デフォルトはonnxで実施される)
の二つです。

まずは、(1)の可能性をつぶしたいのですが、
作成したRVCのモデルをonnx変換する前のtorchの状態で使ってもcpu負荷は高いですか？（yesの場合は、(1)の変換処理が原因ではない？->(2)が原因の可能性が高い。noの場合は、(1)が原因か。）

（並行して、(2)の可能性をつぶすためにプログラムを一部修正して、線形補完処理をonnxでやるようにするテストバージョンを作成したいと思います。）

(1)がnoの場合、あるいは(2)のテストバージョンで解決しない場合は、applioのhubertのonnx版を作成する必要がありそうです。（これはどうすればいいか、悩む必要がある。）

[lenore-puwawa]

ご確認ありがとうございます。

作成したRVCのモデルをonnx変換する前のtorchの状態で使ってもcpu負荷は高いですか？

取り急ぎ上記について確認しましたが、答えはNoになります。（cpu負荷は正常な範囲）

[w-okada]

ありがとうございます。
おぉ、、、そうでしたか。となると、applioのhubertをonnx化してみる必要がありそうだが、、、要調査。