目次
Julius は音響モデルとして，HMM (Hidden Markov Model) を用いることができる．コンテキスト非依存モデル (monophone)，およびコンテキスト依存モデルを triphone まで扱える．出力確率モデルは，対角共分散のガウス混合分布を基本とし，tied-mixture モデルやphonetic tied-mixture モデルも扱える． 本章ではJuliusで扱うことのできる音響HMMの仕様を述べるとともに，論理音素名から物理音素名へのマッピングや単語間トライフォンの扱いなどについても解説する．
Julius は，以下のような HMM を扱うことができる．
MFCC ベースの特徴量で学習されたもの（MFCC以外の場合，音声波形を直接認識することはできず，特徴抽出済み特徴量ファイルのみ入力とできる）
音素のコンテキスト依存性は，トライフォンに対応
マルチストリームに対応（バージョン4.1以降, それ以前はシングルストリームのみ）．
確率分布は，連続分布のみ．離散は対応していない．
共分散行列の型は，対角共分散のみ．
継続時間長モデルは，対応していない．
パラメータ共有は，モデル，遷移行列，状態，ガウス分布， 共分散それぞれのレベルで行える．
Tied-mixture モデルに対応
Multi-Space Probability Distribution HMM (MSD-HMM) に対応 (configure --enable-msd 時)．HTS で学習された音響モデルを扱える．（バージョン4.1以降）
話者適応は，サポートされていない．
モデル名の長さの上限は256文字，最大ストリーム数は50，状態数の制限は無い．
音響モデルが triphone であるかどうかは，内部の定義モデル名から自動判別される．モデル名が '+' や '-' を含んでいると，triphone モデルであると認識される．
トライフォン使用時は，同時に HMMList ファイルも指定する必要がある． HMMlist ファイルは，辞書上の音素表記と音響モデル内の HMM 名のマッピングを指定するものである．特にトライフォン使用時は，登場しうる全てのトライフォンに対して，対応する定義HMM名へのマッピングを記述したHMMList を与える必要がある．HMMList ファイルの仕様は本章の別節を参照のこと．
Julius は HTK の ASCII形式のHMM定義ファイル (MMF) を読み込むことができる（HTKのバイナリ形式を読み込むことはできない）．全ての音素定義を1つにまとめた単一の MMF ファイル(hmmdefs) として与えることができる．
[7]
ファイルは gzip で圧縮されたものをそのまま読み込める．
使用する際には，オプション "-h" で指定する．
共有マクロは ~t (遷移), ~s (状態),
~m (分布), ~h (モデル),
~v (共分散)を扱える．4.1 以降では，さらに
~w (ストリーム重み), ~p (混合分布マクロ: HTS 拡張)を扱える．これ以外の共有マクロ (~u ~i
~x等) には現バージョンでは対応していない．
定義ファイル中に "<TMix>" が含まれている場合，Julius はそのモデルを Tied-mixtureモデルとして扱う．この場合，認識中の音響尤度の計算順序が tied-mixture 用のものに変更される（計算単位が状態単位からコードブック単位に変更される）．単一のコードブックからなる通常のtied-mixtureモデルのほか，複数のコードブックを扱うこともできる．このため，例えば音素ごとにコードブックを持つ phonetic tied-mixture のようなモデルも扱える．
Julius は音響モデル適応をサポートしていない．音響モデル定義内に適応用の regression tree がある場合，それらは無視される．
また，モデルの定義においては，各モデルの初期状態と最終状態は出力分布を持ってはならない[8]．状態遷移については，すべての状態遷移を扱うことができる．初期状態から，あるいは最終状態への遷移がそれぞれ複数存在する場合， Julius はマルチパスモードで実行される（後述）．
音声波形を直接認識したい場合は，HMMがMFCC をベースとする特徴量で学習されている必要がある．特徴量の詳細については，特徴量抽出の章を参照されたい．
Julius は HTKのASCII形式のHMM定義ファイルを読み込めるが，これはテキスト形式であり，モデル構造を解析しながら読み込むため，大規模なモデルでは読み込みに時間がかかる． あらかじめJulius用バイナリ形式へ変換しておくことで，読み込み時間を短縮できる．また，gzip で圧縮されたファイルもそのまま読み込める．
Julius用バイナリ形式への変換は，付属のツール mkbinhmm を用いる．使用例を以下に示す．
% mkbinhmm hmmdefs binhmm
また，バイナリ形式では，その音響モデルで認識時に必要とされる特徴量抽出の条件パラメータを埋め込むことができる．これによって，音響モデルごとにパラメータを直接設定する必要がなくなる．オプションは，Julius で認識で使用する設定ファイルをそのまま mkbinhmm に与えればよい（無関係なオプション指定は無視される）．以下に例を示す．
% mkbinhmm -htkconf ConfigFile -C ... hmmdefs binhmm
これによって，hmmdefs がバイナリ形式の binhmm へ変換されると同時に，ヘッダ内に特徴量パラメータが書き込まれる．Julius
で使用する際には，このバイナリ音響モデルを指定するだけで，必要な特徴量パラメータ設定がされる．詳細は，特徴量抽出の章のセクション「方法３：バイナリHMMファイルへ埋め込む」を参照のこと．
使用する際には，ASCII形式と同様に，オプション "-h" で指定する．ファイル形式は自動判別される．
Julius では，音響モデルとともに HMMList と呼ばれるファイルで，単語辞書の音素表記，あるいはそこから生成されるトライフォンの論理音素名と実際の音響モデル上の物理音素名との対応を与えることができる．特に，トライフォン使用時には必須である．
トライフォン使用時，HMMList には，辞書上の単語内および単語間で登場しうる，すべてのトライフォンを記述する必要がある．対応が与えられていないトライフォンが起動時あるいは認識処理中に出現した場合，エラーとなる．
使用する際にはオプション "-hlist" で指定する．
なお，ファイル形式は自動判別される．
標準でサポートされているファイル形式は，テキスト形式である．フォーマットは以下のとおり．
一行に1つの対応を定義する．
第1カラムに論理音素名，第2カラムに対応する物理音素名（hmmdefs 内のHMM名）を指定する．
第2カラムを省略した場合，第1カラムと同じと解釈される．
同じ論理音素名を重複して登録した場合，エラーとなる．
以下に例を示す．第２カラムが空白のエントリは，その HMM 名が直接音響モデル内で定義されていることを意味する．
a-k+a a-k+a: a-k+a a-k+e a-k+e: a-k+e a-k+i a-k+i: a-k+i a-k+o a-k+o: a-k+o a-k+u a-k+u: a-k+u
バージョン 4.1 より，バイナリ形式がサポートされている．バイナリ形式では，検索用のパトリシア木インデックスも同時に保存されるため，読み込み時に検索インデックスを生成する必要がなく，起動が高速化される．
テキスト形式からバイナリ形式への変換は，付属のツール
mkbinhmmlistを使用する．
以下は，HMMList ファイル hmmlist をバイナリ形式に変換して binhmmlist に保存する例である．
% mkbinhmmlist hmmdefs hmmlist binhmmlist
変換の際は，定義のチェックのため，一緒に使用する予定の音響モデル定義ファイル hmmdefs も与える必要がある．なお，この音響モデルのファイル形式は HTK ASCII形式 / Juliusバイナリ形式のどちらでも構わない．
Julius における音素コンテキスト依存モデルの扱いについて述べる．
Julius は，与えられた音韻モデルが音素環境依存モデルであるかどうかを，
HMM の名称パターンから判定する．HMM名の中に記号
`+', `-' が両方とも１つ以上含まれていれば，そのモデルは音素環境依存モデルとして扱われる．なお，
依存関係は前後１履歴（トライフォン）までのみ考慮される．
トライフォンを使う場合，認識アルゴリズムも音素環境依存性を考慮したものになる．辞書の読み込み時に，単語内の音素をトライフォンに変換しながら読み込まれる．単語間の依存性は，第1パスでは近似計算が行われ，第2パスで正確に計算される．
音素環境依存モデルを使用する場合，単語辞書上の音素列をトライフォンに変換して認識を行う．辞書上のモノフォン表記からトライフォンへの変換は，ある音素 "X" に対して直前の音素が "L"，直後の音素が "R" である場合に "L-X+R" の形で行われる．たとえば，以下のような単語「英訳」を考える．
英訳+エイヤク+17 [英訳] e i y a k u
このトライフォン表記への変換は以下のようになる．なお単語の先頭・末尾については特別な処理が行われる（詳細は後述）．
英訳+エイヤク+17 [英訳] e+i e-i+y i-y+a y-a+k a-k+u k-u
Juliusでは，このような，単語辞書上の音素表記およびそれから生成されるモデル参照名を「論理音素名(logical phone)」，それに対して実際に音響モデル上で定義されているHMM名を「物理音素名(physical phone)」と呼ぶ．
論理音素名と同一名の物理音素名のモデルが音響モデル上で定義されていればよいが，実際には，学習時のコンテキストクラスタリングにより，辞書上のすべての可能なトライフォンについてHMMが定義されていないことがある．また， 全ての単語間の接続を考えるとき，音響モデル学習時に出現しなかった音素並びが登場しうる．このため，音素環境依存モデルを用いる場合は，登場する可能性のある全ての論理音素名について，対応する物理音素名へのマッピングを HMMList ファイルとして与える必要がある．これについて次節で述べる．
HMMListファイルは，登場しうるすべてのトライフォン論理音素名に対して， 音響モデルで定義されている物理音素名へのマッピングを指定する． トライフォン使用時には必ず指定する必要がある．ファイル形式については前節を参照のこと．
HMMList ファイルでのマッピング指定は，hmmdefs内の定義に優先するので注意すること．例えば，hmmdefs において
~h "j-u+q"
というHMMが定義されているとき，HMMList ファイルで
j-u+q y-u+q
のように指定すると，j-u+q のHMMは実際には使用されず，
y-u+qが使われることになる．
システムにおいて実際にどのようにマッピングされているかは，julius を
-check triphoneを付けて起動することでチェックできる．
プロンプトに対して "H" と入力すればヘルプが出てくる．
トライフォンの場合，連続音声認識において，ある単語内の先頭と末尾の音素は，その単語の前後に接続する単語の読みの影響を受けて変化する．このことは，ある単語の尤度計算を，その前後の単語に依存して分けて行う必要があることを意味し，大語彙では計算量が増大する．この単語をまたぐ音素環境依存性（単語間トライフォン）に対して，Julius では第1 パスで "pseudo phone" を用いた近似計算を行い，第2パスで正確なトライフォンを計算する方法を用いている．
Pseudo phone は，中心音素が同じ論理音素名を持つトライフォンHMM の集合である．例えば，読みが "k u" で終わる単語が辞書にあるとき，その末尾の音素 "u" に対して，
"k-u+i", "k-u+b",
"k-u+m" などの左コンテキストと中心音素が
"k-u" であるトライフォンの集合を抽出し，その集合を
k-u のような擬似的なバイフォンとして割りつける．これを Pseudo phone と呼ぶ．上記の k-u(+*) のように同じ中心音素と左コンテキストを持つトライフォンの集合，および
(*-)b+e のように同じ中心音素と右コンテキストを持つ集合を pseudo biphone，(*-)a(+*) のように中心音素が同じである全てのトライフォン集合は pseudo monophone と呼ばれる．
Pseudo phone のリストは，音響モデルおよび HMMList ファイルを読み込んだあとに，HMMList にある論理トライフォン名から自動的に生成される．
認識時には，pseudo phone は，それ自身が一つの論理バイフォンあるいは論理モノフォンとして辞書上の単語の先頭および末尾に配置される．第1パスではその集合内のすべてのトライフォンについて尤度計算を行い，スコアの高いものがその pseudo phone のスコアとして与えられる．第2パスでは，単語仮説のコンテキストから正確なトライフォンに置き換えられて尤度計算される．
なお，HMMList でバイフォン表記から物理音素名への明示的なマッピングが記述されている場合，そのマッピングは pseudo phone より優先される．HMMList 中にバイフォンやモノフォンが明示的に指定されている場合は，pseudo phone は使用されず，指定されたモデルが使用される．
音素間のパスの扱いの効率化のために，Juliusは，与えられた音響モデル内の状態遷移のパターンを調べ，そのパターンに対応する効率的な計算処理を選択する．以下に具体的に説明する．
音響モデル内の全てのHMMが以下の条件を全て満たすとき，モデル間の遷移がただ１つとなるので，Julius は処理を簡素化した高速なモードで動作する． これがJulius の通常モードである．
初期状態からの遷移が１つのみ
最終状態への遷移が１つのみ
上記の条件に当てはまらないモデルの場合，通常モードではうまく扱えないため，Juliusは「マルチパスモード」で動作する．マルチパスモードでは，任意の状態間遷移を扱えるよう拡張されたアルゴリズムが使用される．このモードでは，初期状態から最終状態への直接遷移（すなわちモデルそのものをスキップする遷移）も扱える．
マルチパスモードでは，音素間処理が複雑になるため認識速度が通常モードよりも1,2割程度低下する．また，木構造化辞書において単語の先頭および末尾に対応するノードが新たに作られるため，木構造化辞書が大きくなり，ビー ム幅を通常よりも若干広めに取る必要がある．
通常モードとマルチパスモードの切り替えは，与えられた音響モデルの遷移パターンから自動的に行われるほか，オプション-multipath,
-nomultipath で明示的に指定することもできる．また，複数の音響モデルを用いる場合，モードは個々の音響モデルに対して設定できる．
複数の音響モデルを用いる場合，音響モデルごとに特徴量抽出のパラメータを個別に設定する必要がある．モデル間で同一の特徴量を用いたい場合は，音響モデルごとに繰り返し同じ特徴量パラメータを指定する必要があることに注意すること． また，音声信号のサンプリング周波数，窓サイズ長，およびフレームシフト幅についても，音響モデル間で同一の値を設定する必要がある．