短い動画を自動で生成する自作ツールで、ナレーションの音声を合成していた時のことだ。読みのアクセントを整えるため、バラバラに出てくる数字句を1つのアクセント句へまとめる処理を入れたら、検査ゲートが突如として真っ赤に染まった。
「2024年」という西暦を9モーラの1句へ結合した瞬間、ピッチの誤差がプラス9.3からプラス11.8へ一気に跳ね上がった。
何度テイクを回しても通らない。
音声合成エンジンが悪いのかと疑い、別のテイクを探索させたが、どれだけ回数を増やしても判定は不合格で止まり続ける。
9モーラ結合で跳ねる誤差
日本語の形態素解析エンジンであるpyopenjtalkなどの処理系では、数字の並びを漢字に直してアクセント句を組み立てていく。OpenJTalkの結合規則に従い、前半のモーラ数と後半の型を足し算して1つの句にまとめれば滑らかに読めるはずだと考えていた。
「にせん」と「にじゅう」と「よねん」を全部つなげた9モーラの1句だ。
ルール通りに計算すると、前半6モーラに後半の1型を足してアクセント型は7になる。
7型ということは、7モーラ目にあたる「ヨ」にピッチの最高点が存在しなければならない。
だがテストを走らせると、音声エンジンが吐き出す波形はことごとく基準を外れる。生成テイクをいくら差し替えても、検査スクリプトは容赦なく首を横に振り続けた。
6テイク実測で見えた2つの山
エンジンがどんな音を出しているのかを直接確かめるため、同じ西暦表現で6テイク分のピッチ実測値を並べてみた。数字を追ってみると、人間の耳にも明らかな現実が浮かび上がる。
ニ セ ン ｜ ニ ジュ ー ｜ ヨ ネ ン
319 329 389 ｜ 342 367 334 ｜ 262 235 266エンジンが出している音は、「にせん」でピッチを389まで上げて一度落とし、「にじゅう」で367まで再び上げ、「よねん」に向かって200台まで綺麗に下がりきっている。
山が2つある。
日本語の自然な発話として、ここはそもそも2つのアクセント句に分かれて発音されていた。
計算式が要求していた最高点の「ヨ」は、実測値で262しかない。全体の中で一番低い谷底に沈んでいた。
計算型と実音の乖離
一番低く発音されている音に対して「お前が一番高くなれ」と命令しているのだから、どんなテイクを持ってきても合格するわけがない。完全に言いがかりである。
数式上は正しいはずの型が、エンジンが出力する自然な日本語の物理特性と真っ向から衝突していた。
型の計算が保証されていたのは、過去に実測で確認を取っていた「十一億円」のような2語の結合までだった。「二十」と「四年」の組み合わせは計算上だと4型になるが、エンジンの実音は2型で鳴るため、3つ目の結合には到底使えない。
人間が数式で先回りして型を決めつけるアプローチそのものが限界を迎えていた。
いくら規則をこねくり回しても、エンジンがその通りに喋らなければ検査は永久に赤のままだ。
実音からの下がり目読み取りと結合選別
そこで、西暦の年号表現をアクセント句の結合処理から完全に外すことにした。「1900億円」や「4億3100万円」「7511人」のように、実測でピッチの崩れが消えている結合だけを残す。
残りの数字句についても、推測で規則を増やすのはやめた。
探索中にエンジンが実際に鳴らしたテイクから直接ピッチの下がり目を読み取る方式へ切り替えた。追加の合成処理は走らせず、すでに手元にあるテイクの波形を再利用する。
計算で出した型が全テイクで破れており、かつ実音から拾った別の1つの型で全テイクに説明がつく場合だけ、その実音型を採用する。人間が個別に調整した句や、形態素解析がそのまま出した素直な句には一切触らない。
判定処理も、ピッチを測る処理と欠陥を判定する処理の2つにきれいに分離した。同じ音声を、型を変えてその場で測り直せるようにするためだ。
西暦の結合を外したことで跳ね上がっていた誤差は消え、実測で裏づけの取れた結合だけを維持する設計に落ち着いた。
262の谷底で大人しく喋っていたエンジンへ、足し算の都合だけで山登りを強要していたのは私の方だ。