ラベル付きの文字起こしには両方の答えが正しいことが必要です。ラベルは単語の上に乗っているため、誤りがあっても本文に触れずに直せます。
会議の文字起こしは、二つの問いに同時に答えています。何が語られたか、そして誰が語ったかです。読者には一つの作業に見えます。行の横に名前が付いているだけです。しかしその下には二つの問題があり、それぞれに固有の入力と固有の失敗の仕方があります。
音声認識は言葉を聞き取ります。音声をテキストに変換し、うまく行けば単語ごとに開始時刻と終了時刻も示します。声が文の途中で変わったかどうかは気にしません。その仕事は文を正しく書き起こすことです。
話者ダイアライゼーションは声を聞き取ります。言葉は分かりません。タイムラインをターンに区切り、どのターンが同じ人のものかを判定します。話者1、話者2といった具合です。この語は「diary（日記）」に由来し、出力の姿としては的確です。誰がいつ発言権を持っていたかを記録した日誌です。
これと混同されやすい近い用語が三つあります。ダイアライゼーションは、誰かを知らないまま「誰がいつ話したか」を示します。話者識別は、登録された声の集合から、ある音声区間が既知のどの人物のものかを選びます。話者照合は「この声は本当に人物Xか」というはい・いいえの問いに答えます。この三つを区別しておくと、ベンダーの主張は読み解きやすくなります。「話者ラベル」という言葉は、ターン境界のおおよその推定から、録音をまたいで同じ人物に名前が付き続けるものまで、さまざまな意味で使われるからです。ラベルが何を約束でき、何を約束できないかを見るには、ダイアライザーの内部を見る必要があります。
ほとんどのダイアライゼーションシステムは、言語に関係のない三つのステップで動いています。
各ステップは単独でも失敗し得ます。小声の話者が取りこぼされたり、似た二つの声が一つにまとめられたり、穏やかな口調から熱を帯びた口調に変わった一人の話者が二つに割れたりします。
この分野では、これら全体をダイアライゼーション誤り率（DER）で評価します。発話時間のうち、見逃された部分、誤って音声と判定された部分、または誤った話者に割り当てられた部分の割合です。通常は、各境界の周囲におよそ0.25秒の許容幅（フォーギブネス・カラー）を設けます。この許容幅があるのは、人間でも機械でも、話者の切り替わりをミリ秒単位で特定することはできないからです。この許容は、ダイアライザーを単独で評価するには問題ありません。しかし文字起こしでは話が違います。境界が0.25秒ずれると、その境界が単語の上に乗ってしまうからです。
ここで二つの問題が交わり、ラベル付きの文字起こしの品質が決まります。ダイアライザーは境界をある程度不正確に置きます。前後に数分の一秒ずれることがよくあります。一方、認識器は同じタイムライン上に単語を置きます。両者を単純に重ねると、境界が単語の内側に入ってしまいます。その結果、「tomorrow」という一語の前半が話者1に、後半が話者2に振り分けられてしまいます。
ラベルは、正しくなるまでの間、しばらく誤っていることもあります。ダイアライザーは、聞いた音声が多いほど自分のグループに自信を深めていきます。そのため、初期のラベルは後から判明したことに照らすと誤って見えることがあります。ライブの文字起こしでは、一行が表示された後にラベルが修正されることもあります。VocalStackのリアルタイムAPIは transcript.amended フレームを送ります。これは確定済みの行のテキストや話者をその場で訂正するもので、読者には矛盾ではなく修正として見えます。
完全に正しく配置され、安定したラベルであっても、それはまだ単なる数字にすぎません。数字で会話を追うことはできますが、読者が読みたいのは名前です。
ラベルが名前になるまでには二つの段階があり、それらは互いの上に積み重なっています。
一つ目は、一つの録音の中での命名です。文字起こしが検出した各話者には、0から始まる番号が付きます。アクセスできる人は、録音中でも録音後でも各話者に名前を付けられます。名前は単語の上に重ねられた層なので、テキストに触れずに設定、変更、消去できます。APIでは、name を指定して PUT /v1/recordings/{id}/speakers/{idx} を使います。空の名前を指定すると消去されます。speaker が -1 の行にはラベルがありません。これは、ラベル付けが無効だった場合か、ライブの下書きでまだ話者が割り当てられていない場合のどちらかです。
二つ目は、録音をまたいだ認識です。これは最初の節で述べた識別の問題です。ダイアライザーが言えるのは、二つの声が異なるということだけで、それが誰であるかは言えません。「異なる」から「これはAnaだ」へ進むには、基準が必要です。その人自身の録音から取った、保存された声です。最低でも30秒のクリアな音声が必要で、数分あればより良くなります。サンプルは、照合される録音と似た音質であることも重要です。同じ人物でも、ノートパソコンのマイクとステージのマイクでは、同じ条件で録られた他人同士より機械には似て聞こえないことがあります。声が保存されると、文字起こしが聞き取ったすべての話者がそれと比較され、一致すると名前が文字起こしに反映されます。VocalStackでは、この機能はVoicesにあります。ファイルの文字起こしとダッシュボードのライブセッションでは、保存した声が自動的に照合されます。リアルタイムAPIのセッションは、identifyVoices に指定した声だけを認識します。
保存された声は生体情報です。どの録音でもその人物を認識できるだけでなく、VocalStackではその人物の台詞を読み上げるクローンとしても使えます。ダッシュボードでは、声を保存する前に本人の許可を得たことを確認するよう求められます。声はいつでも削除できます。
以上はすべて、そもそもラベルが必要だという前提に立っています。多くの場合、ラベルは必要ありません。
一人が講義を読み上げている場合、すべての行の前に「話者1」を付ける必要はありません。聴衆は誰がマイクを持っているか既に分かっています。そこで話者ラベルの設定には三つの選択肢があり、リアルタイムセッション、ブロードキャスト、文字起こし、録音のいずれでも同じです。
auto）。二人以上の声が聞こえた時点で、行に話者ラベルが付きます。一人だけの録音はプレーンテキストのままです。後から加わった二人目の声も検出されます。ダッシュボードの新しいライブ文字起こしフォームは、この設定から始まります。ファイルのアップロードでも同じ speakerLabels オプションを使えます。リアルタイムAPIでは、ストリーミングの途中で設定を変更することもできます。詳細はAPIリファレンスにあります。話者の分離と命名が料金に加算されることはありません（料金表は料金ページにあります）。したがって選択は費用ではなく、読者に何を見せたいかで決めてください。
オンにすれば、ダイアライゼーションは良い結果を出しますが、万能ではありません。それでもなお、二つの状況では苦戦します。
一つ目は重なりです。二人が同時に話すと、音声の一区間に二つの声が含まれます。重なりを考慮するダイアライザーは研究の場にも、そして次第に製品にも存在します。例えば、エンドツーエンドのニューラルダイアライゼーション（EEND）は、「誰が話しているか」を一つの答えではなく、同時に並ぶはい・いいえの問いの集合として扱います。しかし、大半の本番システムは依然として一区間に一人の話者を割り当てますし、その上の認識器も一度に一つの声を文字起こしします。白熱したパネルディスカッションでの話の重なりは、この分野で最も難しい音声です。どのベンダーのラベルも、そこでは劣化します。そして、誰もが後で引用したがるのも、まさにこの部分です。
二つ目は、非常に似た声です。兄弟姉妹の声は、埋め込みが近すぎて確実に分けられないことがあります。特に一時間にわたって短いターンを交互に話している場合はなおさらです。電話の音声は、誰にとっても事態を悪くします。帯域の狭い回線は8kHzでサンプリングされ、約3.4kHzより上の成分は伝わりません。しかし、一人の声を別の人の声と区別する特徴の多くは、そのカットオフより上にあります。同じ電話回線で話している二人は、あなたにとってよりも、ダイアライザーにとって似て聞こえます。
両方に対する最も実践的な対策は、どのモデルよりも上流にあります。話者一人ずつに専用のマイクを使うことです。話者ごとに一つのチャンネルがあれば、ダイアライゼーションは「どのチャンネルが大きいか」を問うだけの作業になります。重なりは、一つの濁った音声ではなく、二つのクリアなトラックになります。そして埋め込みが難しい部分を担う必要がなくなります。ただし、テーブルに置く一本のマイクの方が安価で、ほとんどの場合それしか手元にないので、この記事の残りの部分があるのです。
どちらの限界も、そのまま読者に伝わる必要はありません。ラベルは単語の上に重ねられた層なので、ラベルが間違っていても、テキストを失うことはありません。話者の名前は、録音のどの時点でも設定したり消去したりできます。ライブの文字起こしでは、ホストが実行中でも任意の単語や行を書き直せます。すべての修正は記録され、取り消すことができます。
単語側については、単語誤り率が測るものと見落とすもので修正レイヤーを詳しく解説しています。WERは認識器にとってのDERのようなもので、文字起こしを信頼できるものにするには両方が低くある必要があります。