📝 この記事は forge.workstyle.tech に掲載した記事の転載です。
音素タイミングとは、たとえば「ま」の /m/ が再生開始から0〜80ms、/a/ が80〜200msに対応する、といった音素ごとの時刻情報だ。この例なら、各音素の継続長はそれぞれ80ms、120msとなる。
対象：複数のTTSを扱う製品で、リップシンク方式を選ぶ開発者。
入力と出力：再生音声、または時刻付き音素情報を入力に、VRMの口形と開きを出力する。
この記事で得られること：音素タイミングを採用しなかった理由と、採用へ判断を変える条件。
表現したい口と、利用できる情報を分ける
音量とスペクトルから口を作る方式には、表現上の限界がある。今回のRMS・帯域特徴に基づく方式では、両唇音の閉鎖、撥音「ん」、促音「っ」、無声化した母音を安定して表現できない。
たとえば、/m/、/b/、/p/で必要になる唇の閉鎖は、音量が大きければ口を開くという制御だけでは扱いにくい。「です」「ます」の語尾の /u/ で声帯の振動がなくなるように、母音が無声化する場合も、音の強さから口の意図を読み取るだけでは不足する。
音素とその継続長が分かれば、こうした動きを明示的に設計できる。ただし、音素情報があることと、製品の再生音声に合うタイミング情報があることは同じではない。さらに、情報を受け取るだけで自然な口になるわけでもない。口形への対応付けや、口形同士の遷移は別途必要になる。
私は今回、音素タイミングを採用しなかった。音素方式の価値を否定したのではなく、必要な情報と運用条件がそろっていなかったからだ。
利用しているTTSから継続長を受け取れなかった
今回使っているTTSのパイプラインには、日本語の読みを確定して音素列へ変換する処理がある。音素列は、たとえば「ま」を /m/、/a/ の順で表したものだ。しかし、利用している出力には音素ごとのタイミングが含まれていない。バックエンドが返す長さは、クリップ全体の長さだった。
全体の長さが分かっても、その時間を音素へどう配分するかは残る。均等に割り振るだけでは、実際に生成された音声と合う保証がない。
これは、当該TTSのあらゆる利用方法でタイミング取得が不可能だという主張ではない。今回接続している経路では、採用に必要な情報を受け取れていなかった、という制約である。
判断を変える条件は明確だ。実際に再生する音声に対応した時刻付き音素を、利用するAPIや別のアラインメント処理から取得できること。アラインメント処理は、たとえば「ま」の音素列と合成済み音声を照合し、/m/ と /a/ が音声のどの区間にあるかを求める処理だ。その対応を、対象の話者や文章で検証できること。この条件が満たされれば、音素方式は具体的な候補になる。
TTSの差し替えを製品の前提にしていた
製品ではTTSを差し替えられるようにしている。別プロダクトには、利用者自身のクラウドTTSを接続する使い方もある。
口の制御を特定のTTS内部情報へ強く依存させると、その情報を返すプロバイダと返さないプロバイダで、利用できる機能や品質が変わる。音声を再生できることだけでは、同じリップシンクを提供できなくなる。
今回選んだのは、再生されている音そのものを解析する方法だった。共通の入力を音声に置けば、TTSごとの音素情報の有無から距離を取れる。テキストと音声の時刻合わせも要らない。
もっとも、音声入力なら品質まで一定になるわけではない。話者の声質や音量分布が変われば、母音推定と開きの調整は再確認が必要になる。共通化できるのは入口であり、見た目の保証まで自動で共通化されるわけではない。
利用するTTSが限定され、各プロバイダの時刻付き音素を共通形式へ変換できるなら、事情は変わる。対応するTTSでは音素方式を使い、それ以外では音声解析へ戻す構成も候補になる。ただし、その品質差を製品として許容し、検証できることが条件だ。
不確かな継続長で同期を駆動したくなかった
今回の設計判断では、口形の違いよりも、音と口のタイミングがずれることを重く見た。形が細かくなっても、音より先に閉じたり、発音が終わってから開いたりすれば、改善とは言いにくい。
これは、どの用途でも常に同期だけが重要だという一般則ではない。今回の対話用アバターで、優先して守りたかった品質の軸である。
音素列から継続長を粗く推定して口を動かすと、その不確かな推定で同期を決めることになる。音声を直接解析する方式にも処理や描画の遅れはあり得るが、少なくとも、読みから別に作った時間配分を再生音声へ合わせる問題は持ち込まずに済む。
音素方式を採用するなら、タイムスタンプの形式を確認するだけでは足りない。再生開始、停止、再開を含めて、ブラウザ上で音と口が合うかを確かめたい。ネットワークから受け取った時刻と、実際の再生位置を同じものとして扱わない設計も必要だ。
合成済み音声を事前処理できる用途なら、アラインメント結果を確認する余地がある。対話の応答中に処理する場合とは、採用条件が異なる。
学習済みモデルも、応答予算への適合を判断できなかった
ここでいう応答予算は、たとえば利用者の発話終了からアバターが応答を始めるまでに許容する待ち時間だ。
音声から顔の動きを生成する学習済みモデルとして、NVIDIA Audio2Face-3Dも選択肢にあった。これは、TTSから音素タイミングを直接受け取る方式とは別の経路だ。
今回検討した構成では、外部サービスへの往復が入る。その処理を含めて、製品の応答予算を満たせるかは未検証だった。したがって、「遅いから使えない」と結論づける材料もなかった。採用判断に必要な情報が不足していた、というのが正確な説明になる。
導入を検討するなら、通信と推論だけでなく、再生や描画まで含めて計測する必要がある。返された動きを対象VRMへ適用できるかも確認したい。表現力が高いという期待だけでは、製品への適合性は決まらない。
採用する条件を、先に書いておく
今回の判断を整理すると、次のようになる。
| 判断軸 | 今回の状況 | 採用を検討できる条件 |
|---|---|---|
| タイミング情報 | 利用するTTS出力に音素別の継続長がない | 再生音声と対応した時刻付き音素を取得・検証できる |
| TTSの互換性 | 差し替え可能で、内部情報を共通に期待できない | 対応範囲を定め、共通化や代替動作を設計できる |
| 同期品質 | 不確かな継続長で口を駆動したくない | 実際の再生制御を含めて同期を確認できる |
| 学習済みモデル | 外部往復を含む応答予算への適合が未検証 | 実構成で遅延と出力品質を測定できる |
閉鎖や無声化を丁寧に見せる必要があり、時刻付き音素を確保でき、同期まで検証できる用途なら、音素方式を優先して検討する理由がある。逆に、TTSの自由な差し替えと即時の反応を重視する今回の条件では、音声解析を共通の入口にする判断が合っていた。
推定器はインターフェース越しに呼び出す構成にしている。現在の方式を使いながら、将来の差し替えを可能にするためだ。
「今回は採らない」を設計判断にするには、欠けている条件と、判断を変える条件の両方を書く必要がある。今回の音素タイミングも、その条件がそろったときに改めて評価する。