harukary
日本語 English

Reference-guided visual pronunciation biofeedback

リファレンス音声との差分を視覚フィードバックで示し、子音も含めて発音を近づけるアプリケーションの実現可能性と設計方針。

pronunciationspeechbiofeedbackproduct-idea
目次

概要

リファレンス音声に対して、ユーザーの発音を視覚フィードバックで近づけるアプリケーションは実現可能である。

このアプリケーションの目的は、音声認識のように「ユーザーが何と言ったか」を当てることではない。目的は、リファレンス音声とユーザー音声の差分を検出し、その差分をユーザーが直感的に修正できる視覚情報として返すことである。

したがって、このアプリケーションは ASR アプリではなく、発音のバイオフィードバックアプリとして捉えるべきである。より正確には、Reference-guided visual pronunciation biofeedback と呼べる。

基本方針

リファレンス音声とユーザー音声を比較するとき、波形そのものを一致させる必要はない。

同じ発音でも、話者の性別、年齢、声質、声の高さ、話速、マイク距離、録音環境によって波形は大きく変わる。波形やスペクトログラムを単純に重ねるだけでは、発音として重要な差分と、声質や録音条件による差分が混ざってしまう。

比較すべきなのは、声質そのものではなく、発音として重要な音響属性の時間軌道である。

たとえば、母音であればフォルマントの位置や変化、子音であれば閉鎖、破裂、摩擦、有声化、後続母音への遷移が重要になる。文章であれば、話速、ポーズ、強勢、イントネーション、リズムが重要になる。

このアプリケーションでは、内部的には高次元の音響特徴を扱い、ユーザーにはそれを少数の直感的な修正方向として見せる。内部表現と UI 表現を分離することが重要である。

リファレンス音声

リファレンス音声には TTS を使える。

TTS を使う利点は、任意の単語や文を生成できること、複数話者や複数速度を作りやすいこと、同じ発話を安定して再生成できることにある。人間の録音データを大量に用意しなくても、初期の発音ターゲットを作れる。

ただし、TTS 1本を唯一の正解にするのは危険である。

TTS は発音が整いすぎている場合がある。また、特定の話者、性別、アクセント、発話スタイルに偏ることがある。一本の TTS 音声を正解にすると、人間として自然な発音の許容範囲を狭く見積もる可能性がある。

そのため、リファレンス音声は一本の線ではなく、分布として持つべきである。

たとえば、複数の TTS 話者、複数の話速、複数のピッチ、可能であれば少量の人間録音を組み合わせる。ユーザーの声質や年齢による差を吸収する正規化も必要になる。

UI 上では、このリファレンス分布を「発音のチューブ」または「許容帯」として表示する。ユーザーの発音は、そのチューブの中を通る線や点の軌道として表示する。リファレンスの範囲内に入っている部分は近い発音、外れている部分は修正が必要な発音として見せる。

比較すべき音響属性

比較すべき対象は、波形ではなく、発音属性の時間変化である。

内部的には、次のような特徴を扱う。

これらの特徴を使うことで、単に「似ている / 似ていない」を判定するのではなく、「どの時間位置で、どの属性が、どの方向にズレているか」を推定できる。

発音練習に必要なのは、総合スコアではない。ユーザーが発音を変えるためには、「どこをどう変えるべきか」が必要である。そのため、差分は時間軸と属性軸の両方で分解されている必要がある。

母音の扱い

母音は、比較的扱いやすい。

母音は一定時間続く安定した音として現れやすく、フォルマントやスペクトル包絡から、目標との差を推定しやすい。たとえば、口の開きに相当する差、響きの前後に相当する差、母音の長さの差は、音声だけでも比較的安定して検出できる。

ただし、実際の口腔状態を直接見ているわけではない。

音声から分かるのは、あくまで音響的な結果である。たとえば「目標より母音が狭く聞こえる」とは言えるが、「実際に顎が何ミリ足りない」とは言えない。UI では、身体状態の断定ではなく、音響的なズレと修正方向として表示するべきである。

子音の扱い

子音を扱うには、母音とは別の考え方が必要である。

母音は比較的「状態」として扱える。一方、子音は多くの場合、短い時間に起こるイベントとして現れる。閉鎖が起き、破裂が起き、摩擦が生じ、声帯振動が始まり、母音へ遷移する。これらの時間的構造を見なければ、子音を十分に評価できない。

たとえば「ぱ」と「だ」は、単に「口の開き」「前後の響き」「息の強さ」「リズム」だけでは十分に分離できない。

「ぱ」は、両唇の閉鎖、破裂、無声性、破裂後の声帯振動開始、後続母音への遷移を持つ。一方、「だ」は、舌先付近の閉鎖、破裂、有声性、短い VOT または負に近い VOT、/a/ への特有のフォルマント遷移を持つ。

この差を扱うには、次のような特徴が必要になる。

これらを内部で扱えば、「ぱ」と「だ」のような子音の違いも分離できる。

ただし、ユーザーにこれらの特徴をそのまま見せる必要はない。内部では高次元の音響イベントを解析し、UI では「声が始まるのが早い」「破裂が弱い」「摩擦が短い」「語尾が伸びている」のような直感的なフィードバックに変換する。

視覚フィードバックの設計

このアプリケーションの UI は、音声学の専門用語を見せるためのものではない。

ユーザーが必要としているのは、F1、F2、VOT、spectral centroid の値ではない。必要なのは、自分の発音をどう変えればリファレンスに近づくかである。

したがって、UI は「発音の線路に沿って進む」ような構造にするのがよい。

リファレンス音声の分布を、時間軸に沿ったチューブとして表示する。ユーザーの発音を、そのチューブ上を進む線または点として表示する。目標に近い部分はチューブの中を通り、ズレている部分はチューブの外に出る。

発音後には、全体を細かく採点するのではなく、修正すべき箇所を1〜3箇所に絞ってハイライトする。ユーザーに同時に多くの問題を見せると、どこを直せばよいか分からなくなる。

表示するフィードバックは、次のような修正方向に圧縮する。

このように、内部特徴量は高次元でも、UI は低次元でよい。むしろ、UI を低次元にしないと、発音練習として使いにくくなる。

文章へのスケール

このアプローチは、単語だけでなく文章にもスケールできる。

ただし、文章全体を一つの距離で評価すると失敗しやすい。文章では、音がつながり、弱化し、脱落し、話速が変わり、ポーズが入り、文全体のイントネーションが変化する。そのため、文章を一枚のスペクトログラムとして比較するのではなく、階層的に処理する必要がある。

まず、リファレンス音声とユーザー音声を時間方向にアラインする。ここでは、DTW、CTC alignment、forced alignment、音声埋め込みベースの alignment などが使える。目的は、リファレンスのどの区間にユーザー音声のどの区間が対応しているかを取ることである。

次に、文全体の韻律を評価する。話速、ポーズ、強勢、文末イントネーション、リズム、流暢性は、文章単位で評価しやすい。

その後、局所的なズレを検出する。文全体の中で、修正価値が高い箇所を上位1〜3箇所に絞る。すべてのズレを同時に表示すると、ユーザーは修正できない。アプリケーションは、最も効果の高いフィードバックだけを選ぶ必要がある。

最後に、選ばれた箇所だけを子音、母音、リズムごとに評価する。たとえば、「この子音は破裂が弱い」「この母音は目標より狭い」「この摩擦音は短い」「この語尾が伸びている」「この強勢が弱い」のような形で返す。

この構造にすれば、文章にもスケールできる。

実現可能性

実現可能性が高い対象は、母音、音の長さ、リズム、強勢、イントネーション、語尾の伸びである。これらは音声だけでも比較的安定して検出でき、視覚フィードバックにも変換しやすい。

破裂音や摩擦音も実現可能性は高い。/p t k b d g/ のような破裂音では、閉鎖、破裂、VOT、後続母音への遷移が手がかりになる。/s ʃ f h/ のような摩擦音では、摩擦成分の強さ、持続時間、スペクトル形状が手がかりになる。

一方で、/r/ /l/ のような液体音、鼻音、文全体の自然さは難度が上がる。音声から推定はできるが、身体操作としてどう直すべきかは個人差が大きい。

さらに、実際の舌、唇、顎の状態を音声だけから一意に復元することはできない。同じ音響結果を複数の調音パターンで作れるため、口腔内の状態を断定する UI は避けるべきである。

制約

このアプリケーションは、実際の口腔状態を直接推定するものではない。

音声だけから分かるのは、発音の結果として現れた音響差である。そこから「こう動かすと近づく可能性が高い」という修正方向を提示することはできるが、身体の状態を断定することはできない。

避けるべき表現は、たとえば次のようなもの。

望ましい表現は、たとえば次のようなもの。

このように、実際の身体状態ではなく、音響的なズレと修正候補として返すことが重要である。

MVP

最初から全言語、全文、全子音を対象にするべきではない。

MVP では、短い単語または短文を対象にする。リファレンス音声は複数の TTS 話者から生成する。ユーザーは同じ発話を録音する。アプリケーションはリファレンス音声とユーザー音声を自動でアラインし、目標との差を時間軸上に表示する。

最初に扱うべき対象は、母音、リズム、強勢、破裂音、摩擦音である。フィードバックは上位1〜3箇所だけに絞る。

初期対象に向く音は、母音、/p t k/、/b d g/、/s ʃ f h/、語尾子音、強勢、リズムである。

/r/ /l/ のような液体音、舌形が重要な音、口腔内接触位置の推定が必要な音は後回しにする。

成功条件

このアプリケーションを成立させる条件は明確である。

第一に、波形一致ではなく、発音属性の一致を見ること。

第二に、TTS 1本ではなく、リファレンス分布を作ること。

第三に、子音を静的な状態ではなく、時間上のイベントとして扱うこと。

第四に、文章を階層的にアラインし、文全体、単語・音節、局所イベントの順に評価すること。

第五に、フィードバックを全箇所ではなく、修正価値の高い上位数箇所に絞ること。

第六に、UI は言語ラベルや音声学用語ではなく、ユーザーが修正可能な方向として見せること。

第七に、医療・療育用途では専門家監修を前提にすること。

位置づけ

このアプリケーションは、ASR アプリではない。

ASR は、ユーザーが何と言ったかを当てる。
このアプリケーションは、目標音声からどのようにズレたかを見せる。

ASR は認識のための技術である。
このアプリケーションは、発音を調整するためのバイオフィードバックである。

名称としては、Reference-guided visual pronunciation biofeedback が適切である。日本語では「視覚発音バイオフィードバック」または「見て近づける発音トレーニング」と呼べる。

未確認

実装に使う最適な音声埋め込みモデルは未確認。

TTS 分布だけで十分か、人間録音をどの程度混ぜるべきかは未確認。

子ども向け UI で最適なフィードバック粒度は未確認。

聴覚障害児への適用時に必要な専門家監修範囲は未確認。

言語ごとの許容差分をどう重み付けするかは未確認。