search

VOICEVOX / voicevox_project

VOICEVOX内のプロジェクトを管理するリポジトリ
15 stars 3 forks source link

音声ライブラリを管理する機能をサポートする #21

Open y-chan opened 1 year ago

y-chan commented 1 year ago

経緯・目的

目標

Hiroshiba commented 1 year ago

issue作成ありがとうございます！！ 頑張っていきたいですね！！

インポートとインストールは意味合いが似てるので混乱しそうですね！ たぶんインストールが「エンジンが返すダウンロードリストに載っている音声ライブラリを突っ込むこと」、インポートが「載っていないものを突っ込むこと」なのかなと思いました。 であればこの差分を仮の名称にしてしまうのが良いのかなと思いました！

「ユーザーモデルのサポート」とか･･･？

あと今のところ @sevenc-nanashi さんがPRを出してくださっていますが、そこにコメントをして機能を追加していくよりも、ちょっとずつ機能を区切ってPR・マージを高速に行うのが良いのかなと思いました！ そのPRはどこまで実装すべきかを意識して進めていきたいですね！

y-chan commented 1 year ago

インポートとインストールは意味合いが似てるので混乱しそう

確かに、ちょっと意味合いが似ているかもですね... サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。

今の状況であれば、特定の人にタスクが偏ってしまいそうなので、これを分散させたいのは同意です。 目標をもう少しタスクレベルまで落とし込みたいなと思いました...!

Hiroshiba commented 1 year ago

サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。

なるほどです。 そもそも最初からvvlibを実装する形にすれば、ダウンロードはただvvlib一覧を返すだけになって二度手間もなくなって概念もわかりやすくなるかも･･･？

y-chan commented 1 year ago

最初からvvlibを実装する

良いと思います！ インストールAPI自体がvvlibを展開するだけの機構になっていれば、流れがある程度共通化・統合できるので、分かりやすくなる上、管理のしやすさも上がると思いました...!

後でちょっとフローを図に起こしてみたいと思います:eyes:

Hiroshiba commented 1 year ago

良いと思います！　段取りなどおまかせします･･･！（判断困ったらいつでも頼っていただければ！）

Hiroshiba commented 1 year ago

こちらそろそろ動かしていけるかも？ ガシガシ設計プロトタイプ＆切り分けって感じでしょうか

y-chan commented 1 year ago

すみません...! 最近忙しくて返答が遅くなりました...

とりあえずは設計かなと思っています！ フロー図を用意したいのでもう少しだけ時間がかかりそうです...!

y-chan commented 1 year ago

前回の返信からまた時間が空いてしまいました、申し訳ないです.... フローは以下のような感じで行こうかなと思います。(mermaidをうまく使いこなせてなくて、きれいではないですが...)

flowchart TB;
    subgraph ネットワーク;
    server;
    end;
    subgraph ディスク;
    library_folder[ライブラリフォルダ];
    end;
    subgraph エディタ;
    file_select[エディタ上でのvvlibファイル選択];
    download[エディタ上でのvvlibダウンロード];
    library_select[エディタ上でのインストール済みライブラリ選択];
    end;
    subgraph エンジン;
    dl(downloadable_libraries);
    il(install_library);
    il2(installed_libraries);
    uil(uninstall_library);
    end;
    dl-->download;
    file_select-->il;
    download-->il;
    il2-->library_select;
    library_select-->uil;
    server-->dl;
    server-->download;
    il-->library_folder;
    library_folder-->il2;
    uil-->library_folder;

ついでに、インストール時のユーザーフローも作成してみました。

flowchart TD;
    start[ライブラリ管理画面を開く];
    select_file[vvlibファイルを選ぶ];
    select_from_list[ダウンロード可能なライブラリを選ぶ];
    details_library(ライブラリ内の立ち絵や音声サンプル提示);
    view_tos(ライブラリ利用規約提示);
    install[インストール];
    start-->select_file;
    start-->select_from_list;
    select_file-->details_library;
    select_from_list-->details_library;
    details_library -->|次へ|view_tos;
    view_tos-->install;
Hiroshiba commented 1 year ago

@y-chan 眺めてみました！！

フローは以下のような感じ

アプデフローも一応あると良いかもと思いました！ あとフロー図と同じ用に実装・設計していくと良さそう？

installed_librariesに、アンインストールできるかの情報を含めたい

賛成です！　このこと忘れちゃいそうですね。。

vvlibの仕様

ここの決めが次の工程って感じしますね！

rootでbrand_nameはあると表示に便利そうです！ あとengine_manifestの経験から、manifest_versionもあると便利かなーと。

あー　あとvvlibからインストールするとなると、エンジンが持っている話者情報は全部必要かもです。。 サンプル音声・スタイル名称・スタイルID・立ち絵・アイコンなどなど。 ここにある情報を全部まとめる感じになりそう？ https://github.com/VOICEVOX/voicevox_engine/blob/eee7f4a771c9e181ce58dd38a7ebe9e1ccb596dd/voicevox_engine/metas/Metas.py#L65

その場合vvlibをエンジンに対して2回(データ抽出とインストール)投げる

たしかに。パスを渡す感じでしたっけ、バイナリを渡す感じでしたっけ。 パス渡す感じなら、データ抽出用のAPI用意すれば全バイナリ読み出さなくても行けるので割とレスポンス素早いかも。

まあ、なんかvvlibだいぶ大変そうに思えてきました。。。 ジャストアイデアですが、vvlibやめて、自由なdownloadable_librariesのURLをエンジンに渡せるようにするとか･･･？

利用規約の提示

賛成です！

y-chan commented 1 year ago

いろいろ決めるべきことが決まってないことに今気づきました...遅くなってすみません...

あまりにも分かりづらい全体図ができたのでとりあえず隠しておきます...

全体図
```mermaid flowchart TB; subgraph ネットワーク; server; end; subgraph ディスク; library_folder[ライブラリフォルダ]; end; subgraph エディタ; file_select[エディタ上でのvvlibファイルの選択]; download_select[エディタ上でのダウンロードするvvlibの選択]; confirm_download[エディタ上でのサンプルボイスや立ち絵と利用規約の確認]; confirm_install[エディタ上でのサンプルボイスや立ち絵と利用規約の確認]; library_select[エディタ上でのインストール済みライブラリ選択]; download[エディタ上でのvvlibダウンロード]; end; subgraph エンジン; dl(downloadable_libraries); il(install_library); il2(installed_libraries); uil(uninstall_library); vl(validate_library); end; dl-->download_select; il2-->library_select; library_select-->uil; server-->dl; il-->library_folder; library_folder-->il2; uil-->library_folder; file_select-->vl; vl-->confirm_install; download_select-->confirm_download; vl-->il; dl-->confirm_download; confirm_download-->download; download-->vl; download-->il; confirm_install-->il; server-->download; file_select-->confirm_install; il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select; ```

アプデフロー

エディタ上でインストール済みのものとバージョンと比較してインストール可能か判断する方式が良いかなと思いました。

flowchart TB;
    subgraph ネットワーク;
    server;
    end;
    subgraph エディタ;
    download_select[エディタ上でのダウンロードするvvlibの選択];
    confirm_download[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
    download[エディタ上でのvvlibダウンロード];
    end
    subgraph エンジン;
    dl(downloadable_libraries);
    il(install_library);
    il2(installed_libraries);
    vl(validate_library);
    end;
    subgraph ディスク;
    library_folder[ライブラリフォルダ];
    end;
    dl-->download_select;
    server-->dl;
    il-->library_folder;
    library_folder-->il2;
    download_select-->confirm_download;
    vl-->il;
    dl-->confirm_download;
    confirm_download-->download;
    download-->vl;
    download-->il;
    server-->download;
    il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select;

brand_name manifest_version

良さそうです！ 今の所こんな感じでしょうか。

vvlibからインストールするとなると、エンジンが持っている話者情報は全部必要かも データ抽出用のAPI用意すれば

vvlibファイル周りが若干ネックなのは変わりないのですが、validate_library API(仮名)をエンジン側に生やし、そこを通すと話者関連情報が得られるようにすれば良いかなと思いました。ここまでは今までの提案どおりなのですが、新たにvalidate_libraryを通さないとライブラリがインストール出来ないようにするのはどうかなと思いました。これは、validate_libraryの時点でエンジン側で音声ライブラリをキャッシュしておき、install_library時はファイルを渡すわけではなく、library_uuidなどを使ってvalidate_library時にキャッシュした情報からインストールするようにすれば、データの流れがある程度まとまって、処理の回数も減らせるのはないかなと思いました(全体図には少し反映しています)。 代わりに、インストールキャンセル時のためにdestroy_library API(仮名)とかもはやしてあげる必要があるのが若干ネックかもです。

validate以外のことをするという点で、名前は変えたほうがいいとは思いますが、いい名前が思い浮かばず...

Hiroshiba commented 1 year ago

@y-chan

全体図

まとめてくださったの助かります、ありがとうございます！！ エディタ上でのサンプルボイスや立ち絵と利用規約の確認が２回あるの、ちょっと不自然だけど仕方ない感じですねぇ。

ここはエディタも絡むので @sevenc-nanashi さんの意見も聞いてみたいかもです。

vvlibファイル周りが若干ネックなのは変わりないのですが、validate_library API(仮名)をエンジン側に生やし、そこを通すと話者関連情報が（略）

validateでデータが降ってくるというのはかなり挙動として謎ですが、ありかもと思いました。 キャッシュに関してですがそもそもzipなどからデータを取得するのは高速なので、ファイルパス指定であればキャッシュ不要にできそうに思いました。web APIとして変なのですが、まあ需要を考えるとこれでも良いかなという気持ちです･･･。 あるいは「仮登録（元validate）」で何かしらのIDを返し、その後ID指定して「インストール」･･･？

あとvvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃますね。VOICEVOXみたく全モデル把握してる場合は良いけど、ユーザーモデルの場合は不都合かも。（VOICEVOXの場合もNemoみたいなのは別途インストール可能にしたいかも） 大変な作業なので、優先度どうすべきなのか僕の中でまとまってないです。。

brand_nameとか

持たせたい値、良さそうに思いました！ あと、エンジンのengine_manifest.json側に、対応しているライブラリのmanifest_versionをもたせたほうが良いかもとか思いました（supported_library_manifest_versionとか？）

y-chan commented 1 year ago

エディタ上でのサンプルボイスや立ち絵と利用規約の確認が２回ある

これは、グラフ上でエディタ上でのvvlibファイルの選択からのものとエディタ上でのダウンロードするvvlibの選択からのもので、データフローが違うために分けているのと、グラフ上の同じノードを使うと処理が分かりにくくなるから分けただけで、多分実際には同じ処理を使うことになり、それぞれの工程で1回だけになると思います...!

ファイルパス指定であればキャッシュ不要にできそう web APIとして変

私も、Web APIとしては変かなと思ったので、キャッシュ方式を考えていました。 ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。

vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう

うーん、これは特に問題ないのではと思っています。 今のところ、COEIROINKのユーザーモデル機能では、zipファイルにモデルやmetas.jsonと合わせて、話者関連情報なども含めて配布する形になっているので、話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています(エンジンには、モデルの配置と話者関連情報の両方を配置してもらうように設計してもらえばいいと思っているのですが、それ以外に私が把握できていない問題がありそうですかね...?)。

エンジンのengine_manifest.json側に、対応しているライブラリのmanifest_versionをもたせたほうが良い

これは確かにそうですね！エンジンが未対応のライブラリはインストールできないようにしないと、未対応の仕様に対応できずに変な動作が起きる可能性があると思うので、追加する必要はありそうだと思いました！

Hiroshiba commented 1 year ago

ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。

まあそうですよね･･･。 実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか･･･？

vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう

うーん、これは特に問題ないのではと思っています。 話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています

あれ、ちょっとわかってないので認識合わせしたいです。 OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか･･･？ 👀

VOICEVOXエディタはそもそも話者情報（SpeakerInfo）が必須なので、それをvvlib内かエンジン内に含める必要があるはず。 vvlibに話者関連情報を持たせない場合、エンジンがどこかからか話者関連情報を取得する必要があるのですが、そこどうしようかな～と。

y-chan commented 1 year ago

実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか･･･？

まあPoCを作ってみてどういうふうになるか見てみるのはわりとありだと思います！ バイナリを投げる方式は一度SHAREVOXで作ったことがあって、動きそうではあったので、キャッシュ方式の検証APIを考えてもいいかも。

OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか･･･？ 👀

うーん、たしかにちょっと認識の齟齬がありそうです。 まず前提に、私自身はvvlibの仕様として話者関連情報は必ず含めなければならない仕様になっているべきではあると思っています。 ただ、それをlibrary_manifest.jsonとして同梱するかはちょっと検討した方がいいという意見でした。 多分、https://github.com/VOICEVOX/voicevox_project/issues/21#issuecomment-1485103760 の意見を見たときに、「話者関連情報もlibrary_manifest.jsonとして導入した方がいい」という意見として取ってしまったのが認識の齟齬の原因です...

なので、vvlib内にspeaker_infoフォルダを作り、そこにエンジンと同構造の話者関連情報を必ず導入するようにするといった仕様を決めちゃっていいかなと思います。 それであれば決まったフォルダを探索すれば話者関連情報を得られるので、以前例に上げたvalidateAPIにvvlibを投げて話者関連情報を得ると言ったことをしなくとも、エディタ側でも処理可能になると思います。 簡易的なバリデーション(話者関連情報の取得と、library_manifest.jsonの検証)をエディタ側で行い、インストール時にエンジン側でしっかりとしてバリデーションを行えばフローも簡単化されていいかなと思いました。

あと、思ったのですがlibrary_manifest.jsonじゃなくてvvlib_manifest.jsonのほうがいいのかもしれない...?(engine_manifest.jsonになぞらえるならlibrary_manifest.jsonだと思いますが、VOICEVOXにおいてlibraryは動的ライブラリ: coreの用語ではあると思うので)

Hiroshiba commented 1 year ago

あ、なるほどです！

library_manifest.jsonに全部書くのはたしかに大変かもです。 まあファイル構造だけ定義した場合、vvlibを読む側はOS違いに対応したり、いろんな音声ファイル・画像ファイルの拡張子に対応したり、将来互換性確認のためにファイル存在を調べたりしないといけなくなるので、jsonにしといたほうが全体で見ると楽かも･･･？

うーん！　でもエンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました！ 将来ファイル構造変えねばってなったときに再検討しますか。

エディタ側であるvvlibから情報得るの、良い気がしました！ エディタ側の検証は、表示に必要な情報があるかのチェックくらいにしとくと楽そう。

library_manifest.jsonじゃなくてvvlib_manifest.json

どちらでも良いかなと思いました！　どちらかというとvvlib_manifestが良さそうかなと。

y-chan commented 1 year ago

エンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました！ 将来ファイル構造変えねばってなったときに再検討しますか。

今までファイル構造が変わったことは、スタイルごとに立ち絵が変更できる点ぐらいだったので、あまり神経質にならなくてもいいかなと思っています...!

表示に必要な情報があるかのチェックくらいにしとくと楽そう

そうですね、存在確認と、ファイル形式が問題ないかを検証するだけで、エディタ側で情報の表示が出来ると思うので、これでいいかなと思いました！

どちらかというとvvlib_manifestが良さそうかなと。

vvlib_manifestで行こうと思います....!

y-chan commented 1 year ago

全体像がある程度まとまったと思うので、検証APIをなくした全体図を再掲しておきます。

flowchart TB;
    subgraph ネットワーク;
    server;
    end;
    subgraph ディスク;
    library_folder[ライブラリフォルダ];
    end;
    subgraph エディタ;
    file_select[エディタ上でのvvlibファイルの選択];
    extract_data[vvlibファイルの検証];
    download_select[エディタ上でのダウンロードするvvlibの選択];
    confirm_install[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
    library_select[エディタ上でのインストール済みライブラリ選択];
    download[エディタ上でのvvlibダウンロード];
    end;
    subgraph エンジン;
    dl(downloadable_libraries);
    il(install_library);
    il2(installed_libraries);
    uil(uninstall_library);
    end;
    dl-->download_select;
    il2-->library_select;
    library_select-->uil;
    server-->dl;
    il-->library_folder;
    library_folder-->il2;
    uil-->library_folder;
    download_select-->confirm_install;
    confirm_install-->|ダウンロードしてインストールの場合|download;
    download-->il;
    confirm_install-->|ファイルからインストールの場合|il;
    server-->download;
    file_select-->extract_data;
    extract_data-->confirm_install;
    il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select;

この方向で不足しているAPIから実装していこうと思います...! また、vvlibの最低限仕様は以下のようにしたいと思います

xxx.vvlib  # root
├─ vvlib_manifest.json
│       - name: 音声ライブラリの名前
│       - version: 音声ライブラリのバージョン
│       - uuid: 音声ライブラリのUUID
│       - brand_name: エンジンブランド (VOICEVOXなど)
│       - engine_name: エンジンの名前 (VOICEVOX Engineなど)
│       - engine_uuid: エンジンのUUID
│       - manifest_version: マニフェストバージョン
└─ speaker_info
     ├─ <uuid>
     │   ├─ icons
     │   │   └─ <x>.png
     │   ├─ portraits  # Optional
     │   │   └─ <x>.png
     │   ├─ voice_samples
     │   │   ├─ <x>_001.wav
     │   │   ├─ <x>_002.wav
     │   │   └─ <x>_003.wav
     │   ├─ metas.json
     │   ├─ policy.md
     │   └─ portrait.png
     └─ ...
Hiroshiba commented 1 year ago

良いと思います！！

音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました！

y-chan commented 1 year ago

音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました！

これで良いと思います！

Hiroshiba commented 7 months ago

メモです。 release-0.15で、エディタからのvvlib機能への対応情報表示をフィルタリングするようにしました。（まだ必ず非対応なため） vvlib機能が正式サポートされたら忘れずに解除できればと！

Hiroshiba commented 7 months ago

@y-chan 0.15のときにengine_manifestのsupported_vvlib_manifest_versionを消した（nullにした）のですが、これは引き続き消したままにしようと思います。 というのもまだ仕様が固まってなくて、どのバージョンが一番最初のバージョンになるかわからないので･･･。

manage_libraryの方はtrueにするので開発には支障がないと思っていますが、最終的にリリースする時に入れ忘れないよう注意が必要かもです。 （まあ入れ忘れたとしても、一番最初に破壊的変更があった時に書けば問題ないと思います）

tarepan commented 5 months ago

VOICEVOX ENGINE での議論場所: https://github.com/VOICEVOX/voicevox_engine/issues/536