Páginas

domingo, 3 de março de 2013

CREATING THE CI MODEL DEFINITION FILE

TRAINING CONTINUOUS MODELS

The first step is to prepare a model definition file for the context independent (CI) phones. The function of a model definition file is to define or provide a unique numerical identity to every state of every HMM that you are going to train, and to provide an order which will be followed in writing out the model parameters in the model parameter files. During the training, the states are referenced only by these numbers. The model definition file thus partly specifies your model architecture and is thus usually stored in a directory named "model_architecture". You are of course free to store it where you please, unless you are running the training scripts provided with the SPHINX-III package.
To generate this CI model definition file, use the executable mk_model_def with the following flag settings:
FLAG DESCRIPTION
-phonelstfn phonelist
-moddeffn name of the CI model definition file that you want to create. Full path must be provided
-n_state_pm number of states per HMM in the models that you want to train. If you want to train 3 state HMMs, write "3" here, without the double quotes
Pipe the standard output into a log file ci_mdef.log (say). If you have listed only three phones in your phonelist, and specify that you want to build three state HMMs for each of these phones, then your model-definition file will look like this:
                    
# Generated by /mk_model_def on Thu Aug 10 14:57:15 2000
0.3
3 n_base
0 n_tri
12 n_state_map
9 n_tied_state
9 n_tied_ci_state
3 n_tied_tmat
#
# Columns definitions
#base lft  rt p attrib   tmat  ...state id's ...
SIL    -   -  - filler    0    0       1      2     N
A      -   -  -    n/a    1    3       4      5     N
B      -   -  -    n/a    2    6       7      8     N

The # lines are simply comments. The rest of the variables mean the following:

  n_base      : no. of phones (also called "base" phones) that you have
  n_tri       : no. of triphones (we will explain this later)
  n_state_map : Total no. of HMM states (emitting and non-emitting)
                The Sphinx appends an extra terminal non-emitting state
                to every HMM, hence for 3 phones, each specified by
                the user to be modeled by a 3-state HMM, this number
                will be 3phones*4states = 12
  n_tied_state: no. of states of all phones after state-sharing is done. 
                We do not share states at this stage. Hence this number is the
                same as the total number of emitting states, 3*3=9
n_tied_ci_state:no. of states for your "base" phones after state-sharing
                is done. At this stage, the number of "base" phones is
                the same as the number of "all" phones  that you are modeling.
                This number is thus again the total number of emitting
                states, 3*3=9
 n_tied_tmat   :The HMM for each CI phone has a transition probability matrix 
                 associated it. This is the total number of transition 
                 matrices for the given set of models. In this case, this 
                 number is 3.

Columns definitions: The following columns are defined:
       base  : name of each phone
       lft   : left-context of the phone (- if none)
       rt    : right-context of the phone (- if none)
       p     : position of a triphone (not required at this stage)
       attrib: attribute of phone. In the phone list, if the phone is "SIL", 
        or if the phone is enclosed by "+", as in "+BANG+", the sphinx 
        understands these phones to be non-speech events. These are 
        also called "filler" phones, and the attribute "filler" is 
        assigned to each such phone. The base phones have no special 
        attributes, and hence are labelled as "n/a", standing for 
        "no attribute"   
      tmat   : the id of the transition matrix associated with the phone
 state id's  : the ids of the HMM states associated with any phone. This list
               is terminated by an "N" which stands for a non-emitting
               state. No id is assigned to it. However, it exists, and is
               listed.

Nenhum comentário:

Postar um comentário