refine.tex

该压缩包为最新版htk的源代码,htk是现在比较流行的语音处理软件,请有兴趣的朋友下载使用

%/* ----------------------------------------------------------- */
%/*                                                             */
%/*                          ___                                */
%/*                       |_| | |_/   SPEECH                    */
%/*                       | | | | \   RECOGNITION               */
%/*                       =========   SOFTWARE                  */ 
%/*                                                             */
%/*                                                             */
%/* ----------------------------------------------------------- */
%/*         Copyright: Microsoft Corporation                    */
%/*          1995-2000 Redmond, Washington USA                  */
%/*                    http://www.microsoft.com                */
%/*                                                             */
%/*   Use of this software is governed by a License Agreement   */
%/*    ** See the file License for the Conditions of Use  **    */
%/*    **     This banner notice must not be removed      **    */
%/*                                                             */
%/* ----------------------------------------------------------- */
%
% HTKBook - Steve Young 15/11/95
%

\mychap{HMM System Refinement}{Refine}

\sidepic{Tool.hedit}{55}{ } 
In chapter~\ref{c:Training}, the basic processes involved in training
a continuous density HMM system were explained and examples were given
of building a set of HMM phone models.  In the practical application
of these techniques to building real systems, there are often a number of  
problems to overcome.  Most of these arise from the conflicting desire
to have a large number of model parameters in order to
achieve high accuracy, whilst at the same time having limited and uneven
training data. \index{HMM refinement}

As mentioned previously,
the \HTK\ philosophy is to build systems incrementally.  Starting 
with a set of context-independent 
monophone HMMs, a system can be refined in a sequence of stages.  Each refinement
step typically uses the \HTK\ HMM definition editor \htool{HHEd} followed
by re-estimation using \htool{HERest}.  These incremental manipulations of
the HMM set often involve parameter tying, thus many of \htool{HHEd}'s
operations involve generating new macro definitions.

The principle types of manipulation that can be performed 
by \htool{HHEd}\index{hhed@\htool{HHEd}}
are 
\begin{itemize}
\item HMM cloning to form context-dependent model sets
\item Generalised parameter tying
\item Data driven and decision tree based clustering.
\item Mixture component splitting
\item Adding/removing state transitions
\item Stream splitting, resizing and recasting
\end{itemize}
This chapter describes how the \HTK\ tool \htool{HHEd} is used,  its
editing language and the main operations that can be
performed.

\mysect{Using \htool{HHEd}}{usingHHEd}

The HMM editor \htool{HHEd} takes as input a set of HMM definitions and
outputs a new modified set, usually to a new directory.  It is invoked
by a command line of the form
\begin{verbatim}
    HHEd -H MMF1 -H MMF2 ... -M newdir cmds.hed hmmlist
\end{verbatim}
where \texttt{cmds.hed} is an edit script containing 
a list of edit commands.  Each command
is written on a separate line and begins with a 2 letter command name.
\index{model training!HMM editing}

The effect
of  executing the above command line would be to read in the HMMs listed in 
\texttt{hmmlist} and defined
by files \texttt{MMF1}, \texttt{MMF2}, etc., apply  the editing operations
defined in \texttt{cmds.hed} and then write the resulting system out
to the directory \texttt{newdir}.  As with all tools, \HTK\ will
attempt to replicate the file structure of the input in the output
directory.  By default, any new macros generated by \htool{HHEd} will be
written to one or more of the existing MMFs.  In doing this, \HTK\ will
attempt to ensure that the ``definition before use'' rule for macros is
preserved, but it cannot always guarantee this.  Hence, it is usually
best to define explicit target file names for new macros.  This can be
done in two ways.  Firstly,   explicit target file names can be 
given in the edit script
using the \texttt{UF}\index{uf@\texttt{UF} command} command.
For example, if \texttt{cmds.hed} contained
\begin{verbatim}
   ....
   UF smacs
   # commands to generate state macros
   ....
   UF vmacs
   # commands to generate variance macros
   ....
\end{verbatim}
then the output directory would contain an MMF called \texttt{smacs} 
containing a set of state macro definitions and an MMF called \texttt{vmacs} 
containing a set of variance macro definitions, these would be in addition
to the existing MMF files \texttt{MMF1}, \texttt{MMF2}, etc.

Alternatively, the whole HMM system can be written to a single
file using the \texttt{-w} option.  For example, 
\begin{verbatim}
    HHEd -H MMF1 -H MMF2 ... -w newMMF cmds.hed hmmlist
\end{verbatim}
would write the whole of the edited HMM set to the file \texttt{newMMF}.

\index{master macro files!input/output}
As mentioned previously, each execution of \htool{HHEd} is normally followed
by re-estimation using \htool{HERest}.  Normally, all the information
needed by \htool{HHEd} is contained in the model set itself.  However,
some clustering operations require various statistics about the
training data (see sections~\ref{s:ddclust} and \ref{s:tbclust}).  
These statistics are gathered by \htool{HERest}\index{herest@\htool{HERest}} and 
output to a \textit{stats file}, which is then read in by \htool{HHEd}.
Note, however, that the statistics file\index{statistics file} 
generated by \htool{HERest}
refers to the input model set not the re-estimated set.  Thus
for example, in the following sequence, the \htool{HHEd} edit script in
\texttt{cmds.hed} contains a command 
(see the \texttt{RO} command\index{ro@\texttt{RO} command} 
in section~\ref{s:ddclust})
which references a statistics file  (called \texttt{stats}) 
describing the HMM set defined by \texttt{hmm1/MMF}.
\begin{verbatim}
    HERest -H hmm1/MMF -M hmmx -s stats hmmlist train1 train2 ....
    HHEd -H hmm1/MMF -M hmm2 cmds.hed hmmlist
\end{verbatim}
The required statistics file is generated by \htool{HERest}  but the re-estimated
model set stored in \texttt{hmmx/MMF} is  ignored and can be deleted.

\mysect{Constructing Context-Dependent Models}{mkCDHMMs}

\index{model training!context dependency}
The first stage of model refinement is usually to convert a set of
initialised and trained context-independent monophone HMMs to a 
set of context dependent models\index{context dependent models}.  As
explained in section~\ref{s:edlab}, \HTK\ uses the convention that a HMM
name of the form \texttt{l-p+r} denotes the context-dependent version of the
phone \texttt{p} which is to be used when the left neighbour is the phone
\texttt{l} and the right neighbour is the phone \texttt{r}.  To make a set
of context dependent phone models, it is only necessary to construct a HMM
list, called say \texttt{cdlist}, containing the required context-dependent models  and
then execute \htool{HHEd} with a single command in its edit script
\begin{verbatim}
    CL cdlist
\end{verbatim}
The effect of this command is that for each model \texttt{l-p+r} in \texttt{cdlist}
it makes a copy of the monophone \texttt{p}.  
\index{cloning}\index{cl@\texttt{CL} command}

The set of context-dependent models output by the above must be reestimated using
\htool{HERest}.  To do this, the training data transcriptions must be converted
to use context-dependent labels and the original monophone hmm list must be
replaced by \texttt{cdlist}.  In fact, it is best to do this conversion before
cloning the monophones because if the \htool{HLEd} \texttt{TC} 
command\index{tc@\texttt{TC} command} 
is used then the \texttt{-n} option
can be used to generate the required list of context dependent HMMs automatically. 

Before building a set of context-dependent models,
it is necessary to decide whether or not cross-word 
triphones\index{cross-word triphones} are
to be used.  If they are, then word boundaries in the training data can be ignored and
all monophone labels can be converted to triphones.  If, however, word internal triphones
are to be used, then word boundaries in the training transcriptions must be marked in
some way (either by an explicit marker which is subsequently deleted or by using a short
pause \textit{tee-model}).  This word boundary marker is then identified to \htool{HLEd}
using the \texttt{WB} command\index{wb@\texttt{WB} command} to make the \texttt{TC} command use biphones rather
than triphones at word boundaries\index{marking word boundaries} (see
section~\ref{s:edlab}).

All \HTK\ tools can read and write
HMM definitions in text or binary form.  Text is good for seeing exactly
what the tools are producing, but binary is much faster to load and store, and
much more compact.  Binary output is enabled either using the standard option
\texttt{-B} or by setting the configuration variable 
\texttt{SAVEBINARY}\index{savebinary@\texttt{SAVEBINARY}}.
In the above example, the HMM set input to \htool{HHEd} will contain a small
set of monophones whereas the output will be a large set of triphones.
In order, to save storage and computation, this is usually a good point to
switch to binary storage\index{binary storage} of MMFs. 

\mysect{Parameter Tying and Item Lists}{parmtying}

As explained in Chapter~\ref{c:HMMDefs}, \HTK\ uses macros to support a 
generalised parameter tying facility.  Referring again to
Fig.~7.\ref{f:hierarch}, each of the solid black circles denotes a potential
{\em tie-point} in the hierarchy of HMM parameters.  When two or more
parameter sets are tied, the same set of parameter values are shared by all
the {\em owners} of the tied set.  Externally, tied parameters\index{tied parameters} are
represented by macros and internally they are represented by structure 
sharing.  The accumulators needed for  the numerators and denominators of
the Baum-Welch re-estimation formulae  given in section~\ref{s:bwformulae}
are attached directly to  the parameters themselves. Hence,  when the values
of a tied parameter set are re-estimated, all of the data which would have
been used to  estimate each individual untied parameter are effectively
pooled leading to more robust parameter estimation.\index{model training!tying}

Note also that although parameter tying is implemented in
a way which makes it transparent to the \HTK\ re-estimation and recognition
tools, in practice, these tools do notice when a system has been tied
and try to take advantage of it by avoiding redundant computations.  

Although macro definitions could be written by hand, in practice,
tying is performed by executing \htool{HHEd} commands and the
resulting
macros are thus generated automatically.  The basic \htool{HHEd} command for
tying a set of parameters is the \texttt{TI} command which has the form
\begin{verbatim}
   TI macroname itemlist
\end{verbatim}
This causes all items in the given \texttt{itemlist} to be tied together
and output as a macro called \texttt{macroname}.  Macro names are
written as a string of
characters optionally enclosed in double quotes.  The latter are necessary
if the name contains one or more characters which are not letters or digits.

\sidefig{itemtree}{62}{Item List Construction}{2}{
Item lists use a simple language to identify sets of points in the 
HMM parameter hierarchy illustrated in Fig.~7.\ref{f:hierarch}.  
This language is defined fully in the reference entry
for \htool{HHEd}.
The essential idea is that item lists\index{item lists}  represent paths down the hierarchical
parameter tree where the direction {\it down} should be regarded as 
travelling from the {\it root}
of the tree to towards the {\it leaves}.  
A path can be unique, or more usually, it can
be a pattern representing a set of paths down the tree.  The point at
which each path stops identifies one member of the set represented by
the item list.  
Fig.~\href{f:itemtree} shows the possible paths down the tree.  In
text form the branches are replaced by dots and the underlined node
names are possible terminating points.  At the topmost level, an
item list is a comma separated list of paths enclosed in braces.
}

Some examples, should make all this clearer.  Firstly, the
following is a legal but somewhat long-winded way of specifying
the set of items comprising states 2, 3 and 4 of the HMM called \texttt{aa}
\begin{verbatim}
     { aa.state[2],aa.state[3],aa.state[4] }
\end{verbatim}
however in practice this would be written much more compactly as
\begin{verbatim}
     { aa.state[2-4] }
\end{verbatim}
It must be emphasised that indices in item lists are really {\it patterns}.
The set represented by an item list consists of all those elements which
match the patterns.  Thus, if \texttt{aa} only had two emitting states, the above item
list would not generate an error.  It would simply only match two items.
The reason for this is that the same pattern can be applied to many different
objects.  For example, the HMM name can be replaced by a list of names 
enclosed in brackets, furthermore each HMM name can include `?' characters
which match any single character and `*' characters which match zero or
more characters.  Thus \index{item lists!pattern matching}
\begin{verbatim}
     { (aa+*,iy+*,eh+*).state[2-4] }
\end{verbatim}
represents states 2, 3 and 4  
of all biphone models corresponding to
the phonemes \texttt{aa}, \texttt{iy} and \texttt{eh}.  If \texttt{aa} had just 2 emitting
states and the others had 4 emitting states, then this item list would include