// doc/tutorial_running.dox
  
  // Copyright 2009-2011 Microsoft Corporation
  
  // See ../../COPYING for clarification regarding multiple authors
  //
  // Licensed under the Apache License, Version 2.0 (the "License");
  // you may not use this file except in compliance with the License.
  // You may obtain a copy of the License at
  
  //  http://www.apache.org/licenses/LICENSE-2.0
  
  // THIS CODE IS PROVIDED *AS IS* BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  // KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  // WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  // MERCHANTABLITY OR NON-INFRINGEMENT.
  // See the Apache 2 License for the specific language governing permissions and
  // limitations under the License.
  
  /**
   \page tutorial_running Running the example scripts (40 minutes)
  
    \ref tutorial "Up: Kaldi tutorial" <BR>
    \ref tutorial_looking "Previous: Overview of the distribution" <BR>
    \ref tutorial_code "Next: Reading and modifying the code" <BR>
  
  
  \section tutorial_running_start Getting started, and prerequisites.
  
  The next stage of the tutorial is to start running the example scripts for
  Resource Management. Change directory to the top level (we called it kaldi-1),
  and then to egs/. Look at the README.txt file in that directory, and
  specifically look at the Resource Management section. It mentions the LDC
  catalog number corresponding to the corpus. This may help you in obtaining the
  data from the LDC. If you cannot get the data for some reason, just continue
  reading this tutorial and doing the steps that you can do without the data, and
  you may still obtain some value from it. The best case is that there is some
  directory on your system, say /export/corpora5/LDC/LDC93S3A/rm_comp, that
  contains three subdirectories; call them rm1_audio1, rm1_audio2 and
  rm2_audio. These would correspond to the three original disks in the data
  distribution from the LDC. These instructions assume that your shell is bash. If
  you have a different shell, these commands will not work or should be modified
  (just type "bash" to get into bash, and everything should work).
  
  Now change directory to rm/, glance at the file README.txt to see what the overall structure is, and cd to s5/. This is the basic sequence of experiments that corresponds to the main functionality in version 5 of the toolkit.
  
  In s5/, list the directory and glance at the RESULTS file so you have some idea
  what is in there (later on, you should verify that the results you get are
  similar to what is in there). The main file we will be looking at is
  run.sh. Note: run.sh is not intended to be run directly from the shell; the idea
  is that you run the commands in it one by one, by hand.
  
  \section tutorial_running_data_prep Data preparation
  
  We will first need to configure whether the jobs need to run locally or on the
  Oracle GridEngine. Instructions on how to do this are in cmd.sh.
  
  If you do not have GridEngine installed, or if you are running experiments on
  smaller datasets, execute the following command on your shell.
  
  \verbatim
  train_cmd="run.pl"
  decode_cmd="run.pl"
  \endverbatim
  
  If you do have GridEngine installed, you should use the queue.pl file with
  arguments specifying where the GridEngine resides. In this case, you would
  execute the following commands (The argument -q is an example and you would want
  to replace it with your GridEngine details)
  
  \verbatim
  train_cmd="queue.pl -q all.q@a*.clsp.jhu.edu"
  decode_cmd="queue.pl -q all.q@[ah]*.clsp.jhu.edu"
  \endverbatim
  
  The next step is to create the test and training sets from the RM corpora. To do
  this, run the following command on your shell (Assuming your data is in
  /export/corpora5/LDC/LDC93S3A/rm_comp):
  
  \verbatim
  local/rm_data_prep.sh /export/corpora5/LDC/LDC93S3A/rm_comp 
  \endverbatim
  If this works, it should say : "RM_data_prep succeeded". If not, you will have to work out where the script failed and what the problem was.
  
  Now list the contents of the current directory and you should see that a new
  directory called "data" was created. Go into the newly created data directory
  and list the contents. You should see three main types of folders :
  
  - local : Contains the dictionary for the current data. 
  - train : The data segmented from the corpora for training purposes. 
  - test_* : The data segmented from the corpora for testing purposes.
  
  Let's spend a while actually looking at the data files that were created. This should give you a good insight of how Kaldi expects input data to be. (Also for more details refer : \ref data_prep "Detailed data preparation guide")
  
  The Local Directory : 
  Assuming that you are in the data directory, execute the following commands : 
  
  \verbatim
  cd local/dict
  head lexicon.txt
  head nonsilence_phones.txt
  head silence_phones.txt
  \endverbatim
  
  These will give you some idea of what the outputs of a generic data preparation
  process would look like. Something you should appreciate is that not all of
  these files are "native" Kaldi formats, i.e. not all of them could be read by
  Kaldi's C++ programs and need to be processed using OpenFST tools before Kaldi
  can use them.
  
  - lexicon.txt : This is the lexicon.
  - *silence*.txt : These files contain information about which phones are silent and which are not. 
  
  Now go back to the data directory and change directory to /train. Then execute the following commands to look at the output of the files in this directory :
  
  \verbatim
  head text
  head spk2gender
  head spk2utt
  head utt2spk
  head wav.scp
  \endverbatim
  
  - text - This file contains mappings between utterances and utterance ids which will be used by Kaldi. This file will be turned into an integer format-- still a text file, but with the words replaced with integers.
  - spk2gender - This file contains mappings between speakers and their gender. This also acts as a list of unique users involved in training. 
  - spk2utt - This is a mapping between the speaker identifiers and all the utterance identifiers associated with the speaker. 
  - utt2spk - This is a one-to-one mapping between utterance ids and the corresponding speaker identifiers. 
  - wav.scp - This file is actually read directly by Kaldi programs when doing feature extraction. Look at the file again. It is parsed as a set of key-value pairs, where the key is the first string on each line. The value is a kind of "extended filename", and you can guess how it works. Since it is for reading we will refer to this type of string as an "rxfilename" (for writing we use the term wxfilename). See \ref io_sec_xfilename if you are curious. Note that although we use the extension .scp, this is not a script file in the HTK sense (i.e. it is not viewed as an extension to the command-line arguments).
  
  The structure of the train folder and the test_* folders is the same. However the size of the train data is significantly larger than the test data. You can verify this by going back into the data directory and executing the following command which will give word counts for training and test sets:
  
  \verbatim
  wc train/text test_feb89/text
  \endverbatim
  
  The next step is to create the raw language files that Kaldi uses. In most cases, these will be text files in integer formats. Make sure that you are back in the s5 directory and execute the following command:
  
  \verbatim
  utils/prepare_lang.sh data/local/dict '!SIL' data/local/lang data/lang 
  \endverbatim
  
  This will create a new folder called lang within the local folder which will contain an FST describing the language in question. Look at the script. It transforms some of the files created in data/ to a more normalized form that is read by Kaldi. This script creates its output in the data/lang/ directory. The files we mention below will be in that directory.
  
  The first two files this script creates are called words.txt and phones.txt (both in the directory data/lang/). These are OpenFst format symbol tables, and represent a mapping from strings to integers and back. Look at these files; since they are important and will be frequently used so you need to understand what is in them. They have the same format as the symbol table format we encountered previously in \ref tutorial_looking "Overview of the distribution".
  
  Look at the files with suffix .csl (in data/lang/phones). These are colon-separated lists of the integer id's of non-silence, and silence, phones respectively. They are sometimes needed as options on program command lines (e.g. to specify lists of silence phones), and for other purposes.
  
  Look at phones.txt (in data/lang/).  This file is a phone symbol table that also 
  handles the "disambiguation symbols" used in the standard FST recipe.
  These symbols are conventionally called \#1, \#2 and so on;
   see the paper <a href=http://www.cs.nyu.edu/~mohri/pub/hbka.pdf> "Speech Recognition
  with Weighted Finite State Transducers" </a>.  We also add a symbol \#0
  which replaces epsilon transitions in the language model; see
  \ref graph_disambig for more information.  How many disambiguation symbols
  are there?  In some recipes the number of disambiguation symbols is the same
  as the maximum number of words that share the same pronunciation.  In our recipe
  there are a few more; you can find more explanation \ref graph_disambig "here".
  
  The file L.fst is the compiled lexicon in FST format. To see what kind of information is in it, you can (from s5/), do:
  
  \verbatim
   fstprint --isymbols=data/lang/phones.txt --osymbols=data/lang/words.txt data/lang/L.fst | head
  \endverbatim
  
  If the bash cannot find command fstprint, you need to add OpenFST's installation path to the PATH environment varible. Simply run the script path.sh will do this:
  
  \verbatim
  . ./path.sh
  \endverbatim
  
  The next step is to use the files created in the previous step to create an FST describing the grammar for the language. To do this, go back to the directory s5 and execute the following command : 
  
  \verbatim
   local/rm_prepare_grammar.sh
  \endverbatim
  If successful, this should return with the message "Succeeded preparing grammar for RM." A new file would be created in /data/lang called G.fst.
  
  \section tutorial_running_feats Feature extraction
  
  The next step is to extract the training features. Search for "mfcc" in run.sh and run the corresponding three lines of script (you have to decide where you want to put the features first and modify the example accordingly). Make sure the that directory you decide to put the features has a lot of space. Suppose we decide to put the features on /my/disk/rm_mfccdir, we would do something like:
  
  \verbatim
  export featdir=/my/disk/rm_mfccdir
  # make sure featdir exists and is somewhere you can write.
  # can be local if you want.
  mkdir $featdir
  for x in test_mar87 test_oct87 test_feb89 test_oct89 test_feb91 test_sep92 train; do \
    steps/make_mfcc.sh --nj 8 --cmd "run.pl" data/$x exp/make_mfcc/$x $featdir; \
    steps/compute_cmvn_stats.sh data/$x exp/make_mfcc/$x $featdir; \
  done
  \endverbatim
  
  Run these jobs. They use several CPUs in parallel and should be done in around two minutes on a fast machine. You may change the --nj option(which specifies the number of jobs to run) according to the number of CPUs of your machine. Look at the file exp/make_mfcc/train/make_mfcc.1.log to see the logging output of the program that creates the MFCCs. At the top of it you will see the command line (Kaldi programs will always echo the command line unless you specify --print-args=false). 
  
  In the script steps/make_mfcc.sh, look at the line that invokes split_scp.pl. You can probably guess what this does.
  
  By typing
  \verbatim
  wc $featdir/raw_mfcc_train.1.scp 
  wc data/train/wav.scp
  \endverbatim
  you can confirm it.
  
  Next look at the line that invokes compute-mfcc-feats. The options should be fairly self-explanatory. The option that involves the config file is a mechanism that can be used in Kaldi to pass configuration options, like a HTK config file, but it is actually quite rarely used. The positional arguments (the ones that begin with "scp" and "ark,scp" require a little more explanation.
  
  Before we explain this, have a look at the command line in the script again and examine
  the inputs and outputs using:
  \verbatim
  head data/train/wav.scp
  head $featdir/raw_mfcc_train.1.scp
  less $featdir/raw_mfcc_train.1.ark
  \endverbatim
  Be careful-- the .ark file contains binary data (you may have to type "reset" if your terminal doesn't work right after looking at it).
  
  By listing the files you can see that the .ark files are quite big (because they contain the actual data). You can view one of these archive files more conveniently by typing (Assuming you are in the s5 directory and have run script path.sh):
  
  \verbatim
  copy-feats ark:$featdir/raw_mfcc_train.1.ark ark,t:- | head
  \endverbatim
  
  You can remove the ",t" modifier from this command and try it again if you like-- but it might be a good to pipe it into "less" because the data will be binary. An alternative way to view the same data is to do:
  
  \verbatim
  copy-feats scp:$featdir/raw_mfcc_train.1.scp ark,t:- | head
  \endverbatim
  
  This is because these archive and script files both represent the same data (well, technically
  the archive only represents one eighth of it because we split it into eight pieces).  Notice
  the "scp:" and "ark:" prefixes in these commands.  Kaldi doesn't attempt to work
  out whether something is a script file or archive format from the data itself,
  and in fact Kaldi never attempts to work things out from file suffixes.  This is
  for general philosophical reasons, and also to forestall bad interaction with
  pipes (because pipes don't normally have a name).
  
  Now type the following command:
  \verbatim
  head -10 $featdir/raw_mfcc_train.1.scp | tail -1 | copy-feats scp:- ark,t:- | head
  \endverbatim
  
  This prints out some data from the tenth training file.  Notice that in
  "scp:-", the "-" tells it to read from the standard input, while "scp" tells
  it to interpret the input as a script file.
  
  Next we will describe what script and archive files actually are.
  The first point we want to make is that the code sees both of them
  in the same way.  For a particularly simple example of the user-level
  calling code, type the following command:
  
  \verbatim
  tail -30 ../../../src/featbin/copy-feats.cc
  \endverbatim
  
  You can see that the part of this program that actually does the work is just
  three lines of code (actually there are two branches, each with three lines
  of code).  If you are familiar with the StateIterator type in OpenFst you will 
  notice that the way we iterate is in the same style (we have tried to be
  as style-compatible as OpenFst as possible).
  
  Underlying scripts and archives is the concept of a Table.  A Table is basically
  an ordered set of items (e.g. feature files), indexed by unique strings
  (e.g. utterance identifiers).  A Table is not really a C++ object, because we have
  separate C++ objects to access the data depending whether we are writing,
  iterating, or doing random access.  An example of these types where the object
  in question is a matrix of floats (Matrix<BaseFloat>), is:
  \verbatim
  BaseFloatMatrixWriter
  RandomAccessBaseFloatMatrixReader
  SequentialBaseFloatMatrixReader
  \endverbatim
  These types are all typedefs that are actually templated classes.  We won't go
  into further detail here.
  A script (.scp) file or an archive (.ark) file
  are both viewed as Tables of data.  The formats are as follows:
  
   - The .scp format is a text-only format has lines with a key, and then an "extended filename" 
     that tells Kaldi where to find the data.  
   - The archive format may be text or binary (you can write in text mode
     with the ",t" modifier; binary is default).  The format is: the key (e.g. utterance id), then a
     space, then the object data.  
  
  A few generic points about scripts and archives:
   - A string that specifies how to read a Table (archive or script) is called an rspecifier;
     for example "ark:gunzip -c my/dir/foo.ark.gz|".
   - A string that specifies how to write a Table (archive or script) is called a wspecifier;
     for example "ark,t:foo.ark".
   - Archives can be concatenated together and still be valid archives (there is no
    "central index" in them). 
   - The code can read both scripts and archives either sequentially or via random access.
     The user-level code only knows whether it's iterating or doing lookup; it doesn't
     know whether it's accessing a script or an archive.
   - Kaldi doesn't attempt to represent the object type in
     the archive; you have to know the object type in advance 
   - Archives and script files can't contain mixtures of types. 
   - Reading archives via random access can be memory-inefficient as the code may have
     to cache the objects in memory.
   - For efficient random access to an archive, you can write out a corresponding 
     script file using the "ark,scp" writing mechanism (e.g., used in writing the mfcc
     features to disk).  You would then access it via the scp file.
   - Another way to avoid the code having to cache a bunch of stuff in memory when doing
     random access on archives is
     to tell the code that the archive is sorted and will be called in sorted 
     order (e.g. "ark,s,cs:-").
   - Types that read and write archives are templated on a Holder type, which is a type
     that "knows how" to read and write the object in question.
  
   Here we have just given a very quick overview that will probably raise more questions
   than it provides answers; it is just intended to make you aware of the kinds of
   issues involved.  For more details, see \ref io.
  
  To give you some idea how archives and script files can be used within pipes,
  type the following command and try to understand what is going on:
  \verbatim
  head -1 $featdir/raw_mfcc_train.1.scp | copy-feats scp:- ark:- | copy-feats ark:- ark,t:- | head
  \endverbatim
  
  It might help to run these commands in sequence and observe what happens. With copy-feats, remember to pipe the output to head because you might be listing a lot of content (which could possibly be binary in the case of ark files). 
  
  Finally, let us merge all the test data into one directory for the sake of convenience. We will do all our testing on this averaged step. The following commands will also merge speakers, taking care of duplicating and regenerating stats for these speakers so that our tools don't complain. Do this by running the following commands (From the s5 directory). 
  
  \verbatim
  utils/combine_data.sh data/test data/test_{mar87,oct87,feb89,oct89,feb91,sep92}
  steps/compute_cmvn_stats.sh data/test exp/make_mfcc/test $featdir
  \endverbatim
  
  Let's also create a subset of the training data (train.1k) which will retain only a 1000 utterances per speaker. We will use use for training. Do this by executing the following command : 
  
  \verbatim
  utils/subset_data_dir.sh data/train 1000 data/train.1k 
  \endverbatim
  
  \section tutorial_running_monophone Monophone training
  
  The next step is to train monophone models.  If the disk where you installed
  Kaldi is not big, you might want to make exp/ a soft link to a directory somewhere
  on a big disk (if you run all the experiments and don't clean up, it can get up 
  to a few gigabytes).  Type
  \verbatim
  nohup steps/train_mono.sh --nj 4 --cmd "$train_cmd" data/train.1k data/lang exp/mono &
  \endverbatim
  You can view the most recent output of this by typing
  \verbatim
  tail nohup.out
  \endverbatim
  You can run longer jobs this way so they can finish running even if we get disconnected,
  although a better idea is to run your shell from "screen" so it won't get killed.
  There is actually very little output that goes to the standard out and error of this
  script; most of it goes to log files in exp/mono/.
  
  While it is running, look at the file data/lang/topo.  This file is created immediately.
  One of the phones has a different topology from the others.  Look at data/phones.txt
  in order to figure out from the numeric id which phone it is.  Notice that each entry in
  the topology file has a final state with no transitions out of it.  The convention in
  the topology files is that the first state is initial (with probability one) and the
  last state is final (with probability one).
  
  Type 
  \verbatim
  gmm-copy --binary=false exp/mono/0.mdl - | less
  \endverbatim
  and look at the model file.  You will see that it contains the information in 
  topology file at the top of it, and then some other things, before the model parameters.
  The convention is that the .mdl file contains two objects: one object of type TransitionModel,
  which contains the topology information as a member variable of type HmmTopology, 
  and one object of the relevant model type (in this case, type AmGmm).  
  By "contains two objects", what we mean is that the objects have Write and Read
  functions in a standard form, and we call these functions to write the objects
  to the file.  For objects such as this, that are not part of a Table (i.e. there
  is no "ark:" or "scp:" involved), writing is in binary or text mode and can be
  controlled by the standard command-line options --binary=true or --binary=false
  (different programs have different defaults).  For Tables (i.e. archives and scripts),
  binary or text model is controlled by the ",t" option in the specifier.
  
  Glance through the model file to see what kind of information it contains.  At
  this point we won't go into more detail on how models are represented in Kaldi;
  see \ref hmm to find out more.
  
  We will mention one important point, though: p.d.f.'s in Kaldi are represented by
  numeric id's, starting from zero (we call these pdf-ids).  They do not have
  "names", as in HTK.  The .mdl file does not have sufficient information to map
  between context-dependent phones and pdf-ids.  For that information, see the tree file:
  do
  \verbatim
  copy-tree --binary=false exp/mono/tree - | less
  \endverbatim
  Note that this is a monophone "tree" so it is very trivial-- it
  does not have any "splits".  Although this tree format was not intended to be
  very human-readable, we have received a number of queries about the tree format so we
  will explain it.  The rest of this paragraph can be skipped over by the casual reader.
  After "ToPdf", the tree file contains an object of the
  polymorphic type EventMap, which can be thought of as storing a mapping from a
  set of integer (key,value) pairs representing the phone-in-context and HMM state,
  to a numeric p.d.f. id.  Derived from EventMap are the types ConstantEventMap
  (representing the leaves of the tree), TableEventMap (representing some kind of
  lookup table) and SplitEventMap (representing a tree split).  In this file
  exp/mono/tree, "CE" is a marker for ConstantEventMap (and corresponds to the
  leaves of the tree), and "TE" is a marker for TableEventMap (there is no "SE", or
  SplitEventMap, because this is the monophone case).  "TE 0 49" is the start of a
  TableEventMap that "splits" on key zero (representing the zeroth phone position
  in a phone-context vector of length one, for the monophone case).  It is
  followed, in parentheses, by 49 objects of type EventMap.  The first one is NULL,
  representing a zero pointer to EventMap, because the phone-id zero is reserved
  for "epsilon".  An example non-NULL object is the string "TE -1 3 ( CE 33 CE 34
  CE 35 )", which represents a TableEventMap splitting on key -1.  This key represents
  the PdfClass specified in the topology file, which in our example
  is identical to the HMM-state index.  This phone has 3 HMM states, so the value
  assigned to this key can take the values 0, 1 or 2.
  Inside the parentheses are three objects of type ConstantEventMap, each representing 
  a leaf of the tree.
  
  Now look at the file exp/mono/ali.1.gz (it should exist if the training has progressed
  far enough):
  \verbatim
   copy-int-vector "ark:gunzip -c exp/mono/ali.1.gz|" ark,t:- | head -n 2
  \endverbatim
  This is the Viterbi alignment of the training data; it has one line
  for each training file.  Now look again at exp/mono/tree (as described above) and look for the highest-numbered
  p.d.f. id (which is the last number in the file).  Compare this with the numbers in
  exp/mono/ali.1.gz.  Does something seem wrong?  The alignments have numbers in them
  that are too large.  The reason is that the alignment file
  does not contain p.d.f. id's.  It contains a slightly more fine-grained identifier
  that we call a "transition-id".  This also encodes the phone and the transition within
  the prototype topology of the phone.  This is useful for a number of reasons.
  If you want an explanation of what a particular transition-id is (e.g. you are looking
  at an alignment in cur.ali and you see one repeated a lot and you wonder why),
  you can use the program "show-transitions" to show you some information about the transition-ids.
  Type
  \verbatim
    show-transitions data/lang/phones.txt exp/mono/0.mdl
  \endverbatim
  If you have a file with occupation counts in it (a file named *.occs), you can give this as
  a second argument and it will show you some more information.
  
  To view the alignments in a more human-friendly form, try the following:
  \verbatim
   show-alignments data/lang/phones.txt exp/mono/0.mdl "ark:gunzip -c exp/mono/ali.1.gz |" | less
  \endverbatim
  For more details on things like HMM topologies, transition-ids,
  transition modeling and so on, see \ref hmm.
  
  Next let's look at how training is progressing (this step assumes your shell is bash).
  Type
  \verbatim
  grep Overall exp/mono/log/acc.{?,??}.{?,??}.log
  \endverbatim
  You can see the acoustic likelihoods on each iteration.  Next look at one of the files
  exp/mono/log/update.*.log to see what kind of information is in the update log.
  
  When the monophone training is finished, we can test the monophone decoding. Before decoding, we have to create the decode graph. Type:
  \verbatim
  utils/mkgraph.sh --mono data/lang exp/mono exp/mono/graph
  \endverbatim
  
  Look at the programs that utils/mkgraph.sh calls. The names of many of them start with "fst" (e.g. fsttablecompose), most of these programs are not actually from the OpenFst distribution. We created some of our own FST-manipulating programs. You can find out where these programs are located as follows. Take an arbitrary program that is invoked in utils/mkgraph.sh (say, fstdeterminizestar). Then type:
  \verbatim
  which fstdeterminizestar
  \endverbatim
  
  The reason why we have different versions of the programs is mostly because we
  have a slightly different (less AT&T-ish) way of using FSTs in speech recognition.
  For example, "fstdeterminizestar" corresponds to "classical" determinization in which
  we remove epsilon arcs.  See \ref graph for more information. After graph creation process, we can start the monophone decoding with:
  
  \verbatim
  steps/decode.sh --config conf/decode.config --nj 20 --cmd "$decode_cmd" \
    exp/mono/graph data/test exp/mono/decode
  \endverbatim
  
  To see some of the decoded output
  \verbatim
  less exp/mono/decode/log/decode.2.log 
  \endverbatim
  You can see that it puts the transcript on the screen.  The text form of the
  transcript only appears in the logging information: the actual output of this
  program appears in the file exp/mono/decode/scoring/2.tra. The number in those 
  tra files represent the language model(LM) scale used the decoding process.
  Here we use LM scale equals from 2 to 13 by default(see local/score.sh for details). 
  To view the actual decoded word sequence from a tra file(take 2.tra as an example), type:
  \verbatim
  utils/int2sym.pl -f 2- data/lang/words.txt exp/mono/decode/scoring/2.tra
  \endverbatim
  There is a corresponding script called sym2int.pl.  You can convert it back
  to integer form by typing:
  \verbatim
  utils/int2sym.pl -f 2- data/lang/words.txt exp/mono/decode/scoring/2.tra | \
   utils/sym2int.pl -f 2- data/lang/words.txt 
  \endverbatim
  The <DFN>-f 2-</DFN> option is so that it doesn't try to convert the utterance
  id to an integer.
  Next, try doing
  \verbatim
  tail exp/mono/decode/log/decode.2.log 
  \endverbatim
  It will print out some useful summary information at the end, including the
  real-time factor and the average log-likelihood per frame.  The real-time factor
  will typically be about 0.2 to 0.3 (i.e. faster than real time).  This depends
  on your CPU, how many jobs were on the machine and other factors.  This script
  runs 20 jobs in parallel, so if your machine has fewer than 20 cores it may be
  much slower.  Note that we use a fairly wide beam (20), for accurate results; in a
  typical LVCSR setup, the beam would be much smaller (e.g. around 13).
  
  Look at the top of the log file again, and focus on the command line.  The optional
  arguments are before the positional arguments (this is mandatory).  Type
  \verbatim
  gmm-decode-faster
  \endverbatim
  to see the usage message, and match up the arguments with what you see in the log file.
  Recall that "rspecifier" is one of those strings that specifies how to read a table,
  and "wspecifier" specifies how to write one.  Look carefully at these arguments and try
  to figure out what they mean.  Look at the rspecifier that corresponds to the features, and
  try to understand it (this one has spaces inside, so Kaldi prints it out with single quotes
  around it so that you could paste it into the shell and the program would run as intended).
  
  The monophone system is now finished and we will do triphone training and decoding in the 
  next step of tutorial.
  
    \ref tutorial "Up: Kaldi tutorial" <BR>
    \ref tutorial_looking "Previous: Overview of the distribution" <BR>
    \ref tutorial_code "Next: Reading and modifying the code" <BR>
  <P>
  
  */