Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[project-s] ハミングスタイルはTTSできないので、全スタイルでTTSできることを前提にしたアプリがエラーになる #1027

Closed
Hiroshiba opened this issue Jan 24, 2024 · 6 comments · Fixed by #1034

Comments

@Hiroshiba
Copy link
Member

Hiroshiba commented Jan 24, 2024

不具合の内容

project-sで不都合を思いついたのでメモです。

ハミングスタイルは他のスタイルと同様、style idと名前を持ちます。
今までのスタイルとの区別は新しく追加されるtypeで識別する予定です。
エディタ側ではこのtypeを用いてフィルタリングを行い、talkスタイルだけをTTS欄に、hummingスタイルは歌手として表示される形を考えています。

問題はサードパーティアプリで、style typeが新たに追加されて、かつTTS非対応なスタイルが増えることを知らないはずです。
なのでTTS一覧に普通にハミングが表示されたり、ハミングとわからない(nameがtalkのと一緒なので)形になりそうです。
アップデート準備期間が長ければ問題はないかもしれませんが、今回はいきなりの変更になるので、できればなんとかしたいです。

思いつく手はいくつかあります。

  1. スタイル情報を返すAPIの引数で返ってくるスタイルタイプを選別できるようにし、デフォルトではtalkだけ返す
  2. エンジン起動引数でハミングスタイルなどを返すかどうか制御可能にし、デフォルトではtalkだけ返す
    • こっちはエディタがハミングありで起動した場合に無力
  3. 何もしない

個人的には1が便利そうに感じてます。
やるならたぶん/speakers/speaker_infoの両方につける形かなと。
style_type_filter: list["talk" | "humming" | "sing_teacher"] | Noneみたいな引数を追加して、デフォルトは["talk"]とか・・・。

その他

なんかまだ見落としてることありそうな気がしないでもない。。。

@Hiroshiba
Copy link
Member Author

@y-chan お手空きの際にご意見いただけると。。。 🙇

@Segu-g
Copy link
Member

Segu-g commented Jan 28, 2024

1のアイデアに近いですが、ハミング用スタイルは別のURI('/sing/speakers'等)で提供し、既存の'/speakers'はそのままにしておくのはどうでしょうか?
トーク用の話者情報とハミング用の話者情報では、そもそもスキーマとして異なるものになり得るので、別のURIにするのも自然かなと思いました。

@Hiroshiba
Copy link
Member Author

Hiroshiba commented Jan 28, 2024

@Segu-g 確かにと思ったのですが、ちょっと記憶を掘り返して何でまとめたか思い出しました!!
将来ハミング用の機能を使ってトークを生成することがあり得るんですよね・・・・・・。
そうなった時hummingタイプのスタイルをsingで返すのか、talkでも返すのか、みたいなこと考えるともうまとめちゃった方が良さそうだなと。
(そして仮にそうなった時、「humming:口ずさむ」でしゃべり声生成することになってなんか変だということに気づきました。frame_decodeタイプとかにした方が自然かも・・・。)

@Segu-g
Copy link
Member

Segu-g commented Jan 28, 2024

@Hiroshiba なるほど!経緯が理解できました。
speakersinger の役割的な違いと、mora単位frame単位 の合成手法の違いの2軸があるということですね。
確かに /speakers はその名前的にも「話者」という役割的な側面がありそうです。

ただ、現状 frame_decode でしゃべり声合成することが標準でないことを考えると、互換を破壊してまでspeakerを変更する必要はないと思います。
frame_decode のオプションは新しく追加する必要があるので新しいURI (/singers or /sing/speakers or /frame_decoder/speakers 等)に記載し、
frame_decode でのしゃべり声合成が可能になるタイミングではサードパーティー開発者も対応すると思うので、その時になってから /speakers のスキーマを破壊的変更するのはどうでしょうか。

@Hiroshiba
Copy link
Member Author

Hiroshiba commented Jan 28, 2024

@Segu-g

その時になってから /speakers のスキーマを破壊的変更するのはどうでしょうか。

あれ、ここに認識の違いがあるかもです!
/speakersにスタイルTypeをフィルタリングできる引数を追加して、その引数のデフォルト値を["talk"]とする手を考えてました。
フィルタリングをNoneにすれば全部返ってくる想定です。

正確に言うとStyleModelの中にtypeが入るのですが、まあ破壊的変更ではない・・・かなと。

@Hiroshiba
Copy link
Member Author

こちらですが、とりあえず/singers/singer_infoを作成し、トーク用スタイルと分けることで一旦迂回することにしました!
/singersにはhummingスタイル・singing_teacherスタイル・songスタイルが返る形になります。
/speakersとSpeaker(キャラ)がかぶりますが、まあそれは集約する形で・・・。
@Segu-g さんありがとうございました!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants