Guided API機能 #1774 の検証タスク

[Hiroshiba]

内容

#1774 （Guided API機能）の品質検証タスクです。
この機能は参照音声によるイントネーションや音素長のガイド付き音声生成を可能にします。
この機能を一言でいうと、自分の音声を録音してイントネーションを自動調整する機能です。

現在は「実験的機能」としての導入が検討されています。
マージ可否を判断するため、様々な条件・話者・環境での品質およびロバスト性を評価します。

なぜ検証するのか

イントネーションや音素長が参照音声に近づくことで音声生成の表現力向上が期待できる一方、イントネーションの不自然さやドメイン外音声での性能低下、キャラクターにどれくらい合うのかなど懸念もあるため。

実現方法

以下の音声リストとテスト条件に沿って検証を実施し、結果をまとめる。
（流石に検証するだけにしてはだいぶ重たいタスクなのですが、今後もテスト手法やコードを使い回せるかな～と思って気合い入れて作ってみました）

Guided APIの使い方は

1. Guided API #1774 のブランチ(Patchethium:guided-1)をチェックアウト
2. uv run run.py（README.mdに書いています）
3. curlコマンドでAPIを叩く（見本。もちろんcurlじゃなくてpythonコードでもOK！）

---

テスト条件一覧

それぞれについて、zipでまとめてこのissueに添付する（ドラッグアンドドロップで添付できます）。
そのあとヒホが聞いてみます。（もしよかったらその視聴テストも付き合っていただければ！！聞いてみた感想で十分です🙏）

1. 入力音声のロバスト性・出力話者違い

• 同時に検証する
• 音声リスト１～１６の音声を入力
• 出力話者は４人、ずんだもん・きりたん・龍星・虎太郎（男女の高め低め音声）
• ファイル名に番号とか情報振ってわかりやすくしつつ、16×4の音声を生成

2. ノイズ耐性テスト

• 素人音声（ヒホの声）の３音声を使用
• ホワイトノイズを付与（元音声の最大振幅の：1/32, 1/16, 1/8, 1/4, 1/2）して入力音声とする
• 1/4くらいを耐えられれば超十分

3. 音量耐性テスト

• 素人音声（ヒホの声）の３音声を使用
• 音量を0.1倍, 0.25倍, 0.5倍, 2倍, 4倍, 10倍にして入力音声とする
• 振幅を √音量倍率 倍すればOK。音量4倍=振幅2倍。

---

以下が音声リストです：

• 素人音声（ヒホの声）:
  1. 平読み「おはようございます、こんにちは、こんばんは、さようなら」
  2. 早口「明日も23時ごろから放送したいと思うのでもしよかったらまたお会いしましょう」
  3. キャラ演技「僕の名前はずんだもんなのだ！」
• スマホ録音音声（ヒホの声）:
  4. 平読み「おはようございます、こんにちは、こんばんは、さようなら」
  5. 早口「明日も23時ごろから放送したいと思うのでもしよかったらまたお会いしましょう」
  6. キャラ演技「僕の名前はずんだもんなのだ！」
• プロの通常音声（JVS corpus） :
  7. jvs079 UT-PARAPHRASE-sent046-phrase2「早稲田との駆け引きに負けたとは思わないが、布石にも後悔するところがある。」
  8. jvs099 UT-PARAPHRASE-sent235-phrase1.wav「皮膚では厚さを感じないが、体の芯部から温める。」
  9. jvs035 UT-PARAPHRASE-sent258-phrase1「中庭を囲むように建物を配置」
  10. jvs014 UT-PARAPHRASE-sent136-phrase2.wav「同じ歩いたり、ビールを飲むんでも、女らしくしとやかに行動するようになるでしょ？」
• プロの感情音声（JVNV CC BY-SA 4.0）:
  11. M1_happy_free_09「今日はフランス料理のお店で、デュパンのクロワッサンを食べたよお。うわあ、あんな美味しいクロワッサンは初めてだったあ。」
  12. M2_sad_free_04「くっ･･･。私の祖母は末期のがんで、もうすぐ別れの日が近づいていると思うと、本当に悲しい。」
  13. F1_surprise_free_02「あああ！彼らが和解したと聞いて驚きました。以前はあんなに仲が悪かったのに、何がきっかけで和解できたのでしょうか？」
  14. F2_fear_free_10「ひー！あの森に入るのは怖い！そこに住む奇妙な生き物がいると聞いたからだ。」
• ずんだもん ROHAN4600データ（どの音声でも良いので２つ）:
  15. [ROHAN4600_1194]（長め）「ギュルビッチは、斜辺と角度から、造形の美しさを知覚できる。」
  16. [ROHAN4600_0259]（普通）「ディスポーザーがあれば、生ゴミを気軽に処分できます」

---

検証してくださる方大募集中です！！！！！！！！！！！！！

[nanae772]

とりあえず「１．入力音声のロバスト性・出力話者違い」の分だけ作ってみました！
ちょっと聞いてみた感じ荒かったり音声が乱れたりする部分もありますが、かなり凄い機能ですね…面白いです！

guided-api-test.zip

雑ですが一応生成したコードも載せておきます。(m4aは前もってwavに変換しました）

生成コード

import json

import requests

BASE_URL = "http://127.0.0.1:50021"

text_list = [
    None,
    # 素人音声
    "おはようございます、こんにちは、こんばんは、さようなら",
    "明日も23時ごろから放送したいと思うのでもしよかったらまたお会いしましょう",
    "僕の名前はずんだもんなのだ！",
    # スマホ音声
    "おはようございます、こんにちは、こんばんは、さようなら",
    "明日も23時ごろから放送したいと思うのでもしよかったらまたお会いしましょう",
    "僕の名前はずんだもんなのだ！",
    # プロの通常音声
    "早稲田との駆け引きに負けたとは思わないが、布石にも後悔するところがある。",
    "皮膚では厚さを感じないが、体の芯部から温める。",
    "中庭を囲むように建物を配置",
    # プロの感情音声
    "同じ歩いたりビールを飲むんでも女らしくしとやかに行動するようになるでしょ。",
    "今日はフランス料理のお店で、デュパンのクロワッサンを食べたよお。うわあ、あんな美味しいクロワッサンは初めてだったあ。",
    "くっ･･･。私の祖母は末期のがんで、もうすぐ別れの日が近づいていると思うと、本当に悲しい。",
    "あああ！彼らが和解したと聞いて驚きました。以前はあんなに仲が悪かったのに、何がきっかけで和解できたのでしょうか？",
    "ひー！あの森に入るのは怖い！そこに住む奇妙な生き物がいると聞いたからだ。",
    # ずんだもん ROHAN4600
    "ギュルビッチは、斜辺と角度から、造形の美しさを知覚できる。",
    "ディスポーザーがあれば、生ゴミを気軽に処分できます",
]

speaker_id_and_names = {
    1: "zunda",  # ずんだもん
    108: "kiri",  # 東北きりたん
    9: "kotaro",  # 白上虎太郎
    13: "ryuse",  # 青山龍星
}


def synthesize_with_guide(speaker_id: int, text_num: int) -> str:
    assert 0 < text_num < len(text_list)
    text = text_list[text_num]

    # 1. audio_query
    resp = requests.post(
        f"{BASE_URL}/audio_query", params={"speaker": speaker_id, "text": text}
    )
    resp.raise_for_status()
    query = resp.json()

    guide_wav_path = f"guide-wav/{text_num}.wav"
    # 2. guide API 呼び出し
    with open(guide_wav_path, "rb") as f:
        files = {"ref_audio": f}
        data = {
            "query": json.dumps(query, ensure_ascii=False),
            "normalize": "true",
            "trim": "true",
        }
        resp = requests.post(f"{BASE_URL}/guide", data=data, files=files)
        resp.raise_for_status()
        guided_query = resp.json()

    # 3. synthesis (調整済み音声生成)
    guided_wav_path = f"outputs/{speaker_id_and_names[speaker_id]}-{text_num}.wav"
    resp = requests.post(
        f"{BASE_URL}/synthesis",
        params={"speaker": speaker_id},
        headers={"Content-Type": "application/json"},
        data=json.dumps(guided_query, ensure_ascii=False),
    )
    resp.raise_for_status()
    with open(guided_wav_path, "wb") as f:
        f.write(resp.content)

    return guided_wav_path


for speaker_id in speaker_id_and_names.keys():
    for text_num in range(1, 17):
        synthesize_with_guide(speaker_id, text_num)

[Hiroshiba]

@nanae772 さんありがとうございます！！！！！
音声聞かせていただきました！！！

---

総評：
結構滑舌が悪くなる。
全体的にちょっと悪くなる感じで、録音によってだいぶ差がある感じ。入力音声の声質や喋り方・収録環境に依存してそう･･･？

おそらく元のTTS出力に比べてかなり編集しないと使える音声にならないので、現状導入は難しそう･･････？
（編集が楽になっていない）

精度さえ上がれば便利になりそう！！
たぶん音素アライメントとf0調整どちらもやってるけど、f0調整だけやるようにすると滑舌は変わらずイントネーション調整だけ楽になるかも？（本当は演技が付けられるので音素もアライメントしたいけど）

• 良い感じな例
  • キャラ演技「僕の名前はずんだもんなのだ！」
  • zunda-6.wav
  • 舌足らずさ（滑舌の悪さ）もあってかなかなかずんだもんっぽい
• だいぶ滑舌が悪めな例１
  • 8. jvs099 UT-PARAPHRASE-sent235-phrase1.wav「皮膚では厚さを感じないが、体の芯部から温める。」
  • zunda-8.wav
• ↑と同じでも目標話者が違うと結構聞き取れる
  • kiri-8.wav
  • 仮説：入力話者と出力話者の音素の長さの癖が似てると滑舌が良い？
• だいぶ滑舌が悪めな例２
  • ↓はずんだもんのROHAN音声入力の結果
  • 15. [ROHAN4600_1194]（長め）「ギュルビッチは、斜辺と角度から、造形の美しさを知覚できる。」
  • ryuse-15.wav
  • 仮説：声質によってアライメント精度が結構変わる？（もしかしたら音量とかかも）
• 収録環境？によってアライメント精度？が変わる例
  • 明日も23時ごろから放送したいと思うのでもしよかったらまたお会いしましょう
  • PC収録 zunda-2.wav
  • スマホ収録 zunda-5.wav
  • スマホ収録の方が聞き取りやすいけど、iphoneの録音アプリが何か加工してる可能性もありそう
  • 仮説：収録環境の音響に対する品質が結構変わる？（もしかしたら音量とかかも）

検証のために確認したいこと：

1. 結果は冪等？（２回やったらほぼ同じ結果になる？）
2. pauが扱えてない？（句読点の位置で母音が伸ばし棒になってそう？）

[Patchethium]

1. 冪等です。snfaはstochasticではありません。
2. pauの自動挿入機能が開発中で、発音列にpauがないとそうなりますね。（母音が棒になる）

[Hiroshiba]

@Patchethium ありがとうございます！！

僕が一部のテキストに、を入れ忘れていました 🙇
10番の文の句読点修正しておきました！

[Patchethium]

common voiceのtestセット、総計3925件の音声データでJuliusをgolden standardとして、pydominoとsnfaの10ms単位のphoneme boundary error(PBE)を評価した。簡単に言うと、発音の開始時間と終了時間のl1 norm：
$PBE=\frac{1}{N}\sum_i^N \frac{1}{|P|}\sum_{p\in P_i}\frac{1}{2}(|p_{start}^{ref} - p_{start}^{gt}| + |p_{end}^{ref} - p_{end}^{gt}|)$
評価コードは大雑把で、公開しても使いづらいと思うから結果だけを貼る：

lib	PBE	inference speed	model size
pydomino 1.2.1	10.513	10.60 it/s	20.92 MB
snfa 0.3.0	12.368	3.36 it/s	1.1 MB
snfa 0.2.1	14.468	-	-

[Hiroshiba]

ちなみにITAコーパスマルチモーダルデータベースではアライメント済みのラベルデータも配布されているので、そちらと比較するとJuliusも含めて精度が測れたりします！

[Patchethium]

お待たせ！
ITA コーパスの [itako, metan, sora, usagi] の朗読データセット（計 1296 件）で PBE を評価してみた。

lib	PBE	inference speed	model size
julius	30.965	4.89 it/s	252 MB
pydomino 1.2.1	2.724	10.60 it/s	20.92 MB
snfa 0.3.0	13.116	3.25 it/s	1.1 MB

結果を見るとjuliusがかなりひどくて、Ground Truthで評価できてよかったと思います。

pydomino について

精度と推論速度を見ると pydomino が圧倒的に良いんだけど、だいたい 2% くらいのサンプルで

Error processing file sora_recitation004.wav: Transition from u to ty is not defined.

みたいなエラーが出て止まることがある。
頻度は高くないけど、推論パイプラインに組み込むときにちょっと扱いづらいかも。

あと onnxruntime + C++ ランタイムが必要で、PyInstallerの周りに工夫しないといけないかも。core にすでにonnxの依存が入ってるから、実質 onnxruntime が二重になるのもちょっと気になるポイント。

snfa について（将来性）

snfaの性能はpydominoに下回るが、今後 Rust 実装（e2k-rs みたいな感じ）に移行する予定で、推論速度はそこそこ伸びるかもしれない。

さらに、0.3.0 で使ったデータより 3 倍大きい2024-12-06 の Common Voiceで再学習する予定もあって、精度の改善も期待できそう。そして現時点の実装はsnfaで、動作検証もできたので、使うならすぐって感じ。

まとめ

そんな感じで、どっちもメリット・デメリットあるので、最終的には @Hiroshiba に判断してもらえれば助かります！

[Patchethium]

PING @Hiroshiba