Open qryxip opened 8 months ago
なんかわかりませんが、windows-2019
でビルドできなくなるみたいですね… (2022
だと多分通る)
とりあえず設計はこんな感じです。
Synthesizer::morphable_targets(&self, StyleId) -> Result<BTreeMap<StyleId, MorphableTargetInfo>, _>
MorphableTargetInfo { is_morphable: bool }
Synthesizer::synthesis_morphing(&self, &AudioQuery, StyleId, StyleId, f32) -> Result<Vec<u8>, _>
ErrorKind::SpeakerFeature
pub(crate) SpeakerFeatureError
pub(crate) SpeakerFeatureErrorKind::Morph
C/Python/Javaとかがまだですが、設計レベルで今のうちに何か意見を頂けるとと思っています。
設計では特に意見無いのですが、そもそもモーフィングをコアに実装すべきなのかどうかでかなり悩んでいます。 主にメンテコスト(数千行?)に合うだけの需要があるのだろうか、という観点で・・・。
今のところ、まあRust以外の言語でも使えるのであれば、断る理由は特にないのかなという気持ちでいます。 ただ可能であれば、ちょっと実験的機能という立ち位置にして、将来なくなる可能性もなくはないことを示唆できると良いのかなと思いました! (といってもメンテナンスできる人がいなくなったらとか、どれかの機能をオミットする必要が出てきてしまったとか、そういう場合にしか消えることはなさそうですが)
C APIを除き、テストは今のところmorphable_targets
のみです。
synthesis_morphing
の方のテストについては、base, target, モーフィングの出力WAVをPyWorldで読んでスペクトログラムがそれっぽい範囲になっているかを見るといったのもよいのではと思っています。
synthesis_morphing
の方のテストについては、base, target, モーフィングの出力WAVをPyWorldで読んでスペクトログラムがそれっぽい範囲になっているかを見るといったのもよいのではと思っています。
もしwavファイルが完全一致しそうであれば、e2eテストのwavファイルのスナップショットテストとかどうでしょう。 試聴できますし、変更されていたときにgithub上で再確認できる(はず)なので便利かなと。 (あるいはスペクトログラム画像のスナップショットでも・・・。)
ORTの推論が決定的ではないので、完全一致は厳しそうです。
ただWAVをスナップショットにするというのはありな気がしてきました。WAVを読んで[i16]
の近似での比較をすればいいだけですし。
@qryxip
https://github.com/VOICEVOX/voicevox_core/pull/425#issuecomment-1426972183ので、完全一致は厳しそうです。 ただWAVをスナップショットにするというのはありな気がしてきました。WAVを読んで
[i16]
の近似での比較をすればいいだけですし。
あったしかに・・・。 wavは将来的な都合上、聴覚的には差がほぼ無いけど数値的には誤差があるように見えるようになるかもです。 (波形は周期構造で、その周波数に計算誤差があると誤差が蓄積して波形の周期が変わってきそう) なので誤差を許容する形での比較ならスペクトログラムのが目的に合いやすそうかもと思いました 🙇 テストフレームワークが許すなら、wavでスナップショットを取り、比較はスペクトログラムで行うみたいなのが最高かもです。
WORLD-rs、ライセンスがないので少し怖いです。(ライセンス関係はあまり詳しくないですが) White-Greenさんにライセンスを足してもらう必要がありそう?
@qryxip @sevenc-nanashi いろいろご指摘等ありがとうございます
内容
@White-Green さんのWhite-Green/WORLD_rsを利用してモーフィング機能を追加します。
permitted_synthesis_morphing
の追加関連 Issue
その他