Páginas

terça-feira, 5 de março de 2013

Lernado Python: La Python norma biblioteko


fonto: http://homepages.dcc.ufmg.br/~joaoreis/Site%20de%20tutoriais/aprendendopython/biblioteca_padrao.html
 
La norma biblioteko estas disponeblaj en ĉiuj Python instalado. Ĝi enhavas grandan nombron da utilaj moduloj. Estas grava ke vi familiarizar vin per ĉi biblioteko ĉar la plimulto de iliaj problemoj povas esti solvitaj per lia moduloj.
Ni esploros kelkajn el la plej kutime uzita moduloj. Vi povas trovi detalajn informojn sur la tuta moduloj en la oficiala dokumentaro kiu venas kun Python.
La sys modulo
La sys modulo enhavas sistemo-specifa funkciojn. Ni vidis ke sys.argv estas listo enhavanta la argumentoj pasis sur la komanda linio.
Uzado komandlinio argumentoj (sys.argv)
#! / Usr / bin / python
# - * - Kodigo: iso-8859-1 - * -
importado sys
def readfile (dosiernomo):
'' 'Printas dosieron al cxefeligo.'''
f = file (dosiernomo)
dum Vera:
f.readline linio = ()
se len (linio) == 0:
rompi
presi linio, # Observu la komo
f.close ()
# La skripto komenciĝas tie
se len (sys.argv) <2:
presi 'Neniu ago specifita.'
sys.exit ()
se sys.argv [1]. startswith ('-'):
eblo = sys.argv [1] [2:]
# Get sys.argv [1] sen la unuaj du signoj
se eblo == 'versio':
print 'Versio 1.2'
elif eblo == 'helpo':
print'' '\
Tiu programo montras la cxefeligo dosierojn.
Neniu numero de dosieroj povas esti precizigita.
Opcioj:
- Versio: Montras la version de tiu skribo
- Helpo: Montras helpo'' '
alie:
print 'Nekonata opcio.
sys.exit ()
alie:
por dosiernomo en sys.argv [1:]:
readfile (dosiernomo)

Ekzekuto:
Samuel @ araneo: ~ / python / skriptoj $ python manipulando_args.py
Neniu ago specifitaj.
Samuel @ araneo: ~ / python / skriptoj $ python-helpi manipulando_args.py
Tiu programo montras la cxefeligo dosierojn.
Povas transiris dosieron.
Opcioj:
- Versio: Montras la version de tiu skribo
- Helpo: Montras helpi
Samuel @ araneo: ~ / python / skriptoj $ python-versio manipulando_args.py
Versio 1.2
Samuel @ araneo: ~ / python / skriptoj $ python-eblo manipulando_args.py
Nekonata opcio.
Samuel @ araneo: ~ / python / skriptoj $ python manipulando_args.py test.txt
Programado estas amuza kiam vi finos la laboron.
Se vi volas fari vian laboron ankaŭ fun:
uzi Python!
Samuel @ araneo: ~ / python / skriptoj $

Ĉi tiu programo provas reprodukti la konduto de la kato komando jam konata al uzantoj de Linukso. Vi nur specifi la nomoj de iuj tekstaj dosieroj kaj la programon montras la normo eligo.
Kiam Python programo kuras, tio estas, ne la interpretisto estas en interaga reĝimo, ĉiam estas almenaŭ unu eron en la listo sys.argv kiu estas la programo la nomo kaj tiu nomo estas disponebla en sys.argv [0] a Ekde Pitono komencas rakonti de nulo. La alia komandlinio argumentoj sekvas ĉi artikolo.
Por fari la programon pli uzanto amika ni ofertas kelkajn eblojn kiuj la uzanto povas specifi lerni pli pri la programo. Ni uzas la unuan argumenton por kontroli se iu el tiuj ebloj estis aprobita. Se la opcio estis aprobita - versio, la versio de la programo estas montrata. Se la opcio estis aprobita - help malgranda helpo teksto estas montrata. Ĉi tie ni uzu la funkcion sys.exit por eliri la programon. Por detaloj de ĉi tiu funkcio vidu helpi (sys.exit).
Kiam neniu opcio estas indikita, kaj dosiero nomoj estas pasita al la programo, ĝi simple montras ĉiu linio de la dosiero. La dosieroj estas legitaj unu post alia.
Aliaj interesaj eroj, sys.version sys modulo kiu revenas la versio de la Python interpretisto, sys.stdin kiu korespondas al la normo eniro rivereto, sys.stdout kiu korespondas al la normo eligo rivereto kaj la rojo sys.stderr responda cxeferarigo .
La modulo la
Tiu modulo reprezentas ĝeneralajn karakterizaĵojn de la mastruma sistemo. Estas grava, se vi volas, ke via programo esti platformo sendependaj, tio permesas via programo por funkcii en Vindozo kaj Linukso sen postuli ajnan ŝanĝojn. Unu ekzemplo estas uzi la variablo os.sep anstataŭ uzi la specifa karaktero de la disiĝo vojon mastruma sistemo.
Jen listo de la plej gravaj partoj de ĉi tiu modulo:
  • os.name estas ĉeno kiu specifas la platformo vi uzas kiel "nt" por Vindozo kaj "POSIX" por Linukso;
  • os.getcwd () estas funkcio kiu prenas la aktuala dosierujo;
  • os.getenv () kaj os.putenv () funkcioj estas uzitaj por akiri kaj starigis medio variabloj, respektive;
  • os.listdir () estas funkcio kiu resendas liston de dosierujoj kaj dosieroj de specifita dosierujo;
  • os.remove () funkcio estas uzita por forigi dosieron;
  • os.system () estas funkcio uzata por ruli iu komando en konzolo;
  • os.linesep estas ĉeno kiu redonas la linio finilo de la platformo uzata. Por Vindozo estas '\ r \ n', por Linukso estas '\ n' kaj por Mac estas '\ r';
  • os.path.split () estas funkcio kiu redonas la katalogo vojo kaj la dosiero pasis kiel argumento:
Os.path.split >>> ('/ home / Samuel / test.txt')
('/ Hejmo / Samuel', 'test.txt')
>>>
  • os.path.isfile () kaj os.path.isdir () estas funkcioj kiuj kontrolu ĉu vojo pasis kiel argumento referencas al dosiero aŭ dosierujo, respektive. Same os.path.exists () kontrolas ke vojo ekzistas.
Esplori la lingvo dokumentado por detaloj pri tiuj funkcioj kaj variabloj.

domingo, 3 de março de 2013

Kreante la KD deĉenigis MODELO DIFINO DOSIERO

fonto: http://www.speech.cs.cmu.edu/sphinxman/scriptman1.html#3g

Maŝin-instruo kun kontinuaj modeloj

La sekva paŝo estas la KD-deĉenigis trejnado, en kiu HMMs estas trejnitaj por ĉiuj kunteksto-dependa telefonoj (kutime triphones) kiu vidas en la trejnado korpuso. Por la KD-deĉenigis trejnado, ni unue bezonas por generi modelo difino dosiero por ĉiuj triphones occuring en la trejnado aro. Ĉi tiu estas farita en pluraj paŝoj:
    Unue, liston de ĉiuj triphones ebla en la vortprovizo estas generita de la vortaro. Por atingi ĉi kompleta listo de triphones de la vortaro, ĝi estas unua necesa por skribi la liston de telefonoj en la jena formato:
      phone1 0 0 0 0
     phone2 0 0 0 0
     phone3 0 0 0 0
     phone4 0 0 0 0
     ...
    
    La phonelist uzata por la CI trejnado devas esti uzata por generi tion, kaj la ordo en kiu la telefonoj estas listigitaj devas esti la sama. Tuj poste, portempa vortaro estas generita, kiu havas ĉiujn vortojn krom la kompletigo vortoj (vortoj enmetitaj en + + () + +). La eniro
      SIL SIL
    
    devas esti adiciita al ĉi provizora vortaro, kaj la vortaro devas esti ordo en alfabeta ordo. La programo "quick_count" provizita kun la sfinkso-III pako povas nun esti uzata por generi la listo de ĉiuj eblaj triphones de la provizora vortaro. Ĝi portas la sekvaj argumentoj:
    FLAG PRISKRIBO
    -Q deviga flago diri quick_count konsideri tutan vorton paroj dum konstrui triphone listo
    -P formatan phonelist
    -B provizora vortaro
    -O eligo triphone listo
    Jen tipa eliro el quick_count
      AA (AA, AA) s 1
     AA (AA, AE) b 1
     AA (AA, AO) 1 1
     AA (AA, AW) e 1
    
    La "1" en AA (AA, AO) 1 indikas ke tiu estas vorto-interna triphone. Tio ĉi estas carry super el Sfinkso-II. La eliro de quick_count devas esti nun skribita en la jena formato:
      AA AA AA s
     AA AA AE b
     AA AA AO i
     AA AA AW TTT
    
    Ĉi tiu povas esti farita per simple anstataŭante "(", ",", kaj ")" en la eligo de quick_count de spaco kaj presi nur la unuaj kvar kolumnoj. Dum tio, ĉiuj okazoj de "1" devas esti anstataŭita de "i". Al la supro de la rezultanta dosiero la listo de CI telefonoj devas appened en la jena formato
      AA ---
     AE ---
     AO ---
     AW ---
     ..
     ..                                                         
     AA AA AA s
     AA AA AE b
     AA AA AO i
     AA AA AW TTT
    

    Ekzemple, se la eligo de la quick_count stokas en dosiero nomata "quick_count.out", la jena perl komando generos la telefono lerta en la dezirata formo. perl-Nae '$ F [0] = ~ s / \ (| \) | \, / / g; $ F [0] = ~ s/1/i/g; print $ F [0]; if ($ F [0] = ~ / \ s + $ /) {print "i"}; print "\ n" 'quick_count.out La supra listo de triphones (kaj poŝtelefonoj) estas konvertita al la modelo difino dosiero listigas ĉiujn eblajn triphones de la vortaro. La programo uzita de ĉi tiu estas "mk_model_def" kun jenaj argumentoj nombro de ŝtatoj por HMM
    FLAG PRISKRIBO
    -Moddeffn modelo difino dosieron kun ĉiuj eblaj triphones (alltriphones_mdef) esti skribita
    -Phonelstfn Listo de ĉiuj triphones
    -N_state_pm
    En la venonta paŝo ni trovas la nombro da fojoj ĉiu el la triphones listigitaj en la alltriphones_mdef okazis en la trejnado korpuso Por fari tion ni nomas la programo "param_cnt" kiu prenas la sekvaj argumentoj:
    FLAG PRISKRIBO
    -Moddeffn modelo difino dosieron kun ĉiuj eblaj triphones (alltriphones_mdef)
    -Ts2cbfn prenas la valoro ". daŭrigo." se vi konstruas kontinua modeloj
    -Ctlfn kontroli dosieron responda al via trejnado transskriboj
    -Lsnfn transskribo dosiero por trejnado
    -Dictfn trejnado vortaro
    -Fdictfn plenigita vortaro
    -Paramtype skribi "telefono" cxi tie, sen la duoblaj citiloj
    -Segdir / Dev / null
    param_cnt skribas el la grafoj por ĉiu el la triphones sur stdout. Ĉiuj aliaj mesaĝoj senditaj al stderr. La stdout do devas esti direktita al dosiero. Se vi uzas csh aux tcsh estus farita en la jena maniero:
      (Param_cnt [argumentoj]> triphone_count_file)> &!  LOG
    
    Jen ekzemplo de la eligo de ĉi tiu programo
      + + --- Rubo 98
     + Ridi + --- 29
     SIL --- 31694
     AA --- 0
     AE --- 0
     ...
     AA AA AA s 1
     AA AA AE s 0
     AA AA AO s 4
    
    La fina nombro en ĉiu vico montras la nombron de fojoj ke aparta triphone (aŭ plenigita telefono) estas okazis en la trejnado korpuso. Ne ke se ĉiuj eblaj triphones de CI telefono estas listigitaj en la all_triphones.mdef la CI telefono havos 0 grafoj ĉar ĉiuj okazoj de gxi estus mapita al triphone. Tiu listo de rakontita triphones uzas por Shortlist la triphones kiuj okazis minimuma nombro (sojlo) de fojoj. La antaŭselektita triphones aperas en la sama formato kiel la dosiero el kiu ili estis selektitaj. La antaŭselektita triphone listo havas la saman formaton kiel la triphone listo uzita por generi la all_triphones.mdef. La formatan liston de CI telefonoj devas esti inkluzivita en tiu kiel antauxe. Do, en la pli frua ekzemplo, se sojlo de 4 estis uzataj, ni akirus la antaŭselektita triphone lerta kiel
      AA ---
     AE ---
     AO ---
     AW ---
     ..
     ..                                 
     AA AA AO s
     ..
    
    La sojlo estas ĝustigitaj tia ke la tuta nombro de triphones super la sojlo estas malpli ol la maksimuma nombro de triphones ke la sistemo povas trejni (aŭ ke vi volas trejni). Ĝi estas bona por trejni kiel multaj triphones ebla. La maksimuma nombro da triphones povas tamen esti dependa de la disponebla memoro en via maŝino. La loĝistiko rilataj al ĉi estas priskribitaj en la komenco de ĉi manlibro. Notu ke thresholding estas kutime farita tiel redukti la nombron de triphones, por ke la rezultanta modeloj estos sufiĉe malgranda por havi en la komputilo la memoro. Se ĉi tiu ne estas problemo, tiam la sojlo povas agordi al plej malgranda nombro. Se la triphone okazas tro malmultaj fojoj, tamen, (tio estas, se la sojlo estas tro malgranda), tie estos plu sufiĉe da datumoj por trejni la HMM stato distribuoj konvene. Ĉi tio kondukas al malbone taksita KD deĉenigis modeloj, kiu siavice povas tuŝi la decido arboj kiuj devas esti konstruita uzanta tiuj modeloj en la sekva granda paŝo de la trejnado.
    Modelo difino dosiero estas nun kreita por inkluzivi nur tiuj antaŭselektita triphones. Ĉi tiu estas la modelo fino difino dosiero estu uzata por la KD deĉenigis trejnado. La reduktita triphone listo estas tiam la modelo difino dosieron per mk_model_def kun jenaj argumentoj: multaj regnoj por HMM
    FLAG PRISKRIBO
    -Moddeffn modelo difino dosiero por KD deĉenigis trejnado
    -Phonelstfn Listo de antaŭselektita triphones
    -N_state_pm
Fine, do, modelo difino dosiero kiu listigas ĉiujn CI telefonoj kaj vidis triphones estas konstruita. Ĉi tiu dosiero, kiel la CI modelo difino dosiero, asignas unika id estas al ĉiu HMM stato kaj utilas kiel referenco dosiero por manipuli kaj identigi la KD-deĉenigis modelo parametroj. Jen ekzemplo de la KD-deĉenigis modelo difino dosiero: Se vi listigitaj kvin telefonoj en via phones.list dosiero,
SIL B AE T
kaj specifi ke vi volas konstrui tri ŝtataj HMMs por ĉiu el tiuj telefonoj, kaj se vi havas parolo listigitaj en via transskribo dosiero:
<s> BAT A TAB </ s> por kiu via vortaro kaj fillerdict elementoj estas:
  Fillerdict:
 <s> SIL
 </ S> SIL
  Vortaro:
 Al AX 
 BAT B AE T
 TAB T AE B
tiam via KD-deĉenigis modelo difino dosiero aspektos tiel ĉi:
  # Generated by / mk_model_def on Tue Mar 10 14:57:15 2000
 0.3
 5 n_base
 7 n_tri
 48 n_state_map
 36 n_tied_state
 15 n_tied_ci_state
 5 n_tied_tmat                                                                  
 #
 # Kolumnoj difinoj
 # Bazo lft rt p ATTRIB tmat ... stato id La ...
 SIL --- plenigita 0 0 1 2 N
 AE --- n / a 1 3 4 5 N
 AX --- n / a 2 6 7 8 N
 B --- n / a 3 9 10 11 N
 T --- n / a 4 12 13 14 N
 AE BT en / a 1 15 16 17 N
 AE TB en / a 1 18 19 20 N
 AX TT sn / a 2 21 22 23 N
 B SIL AE bn / a 3 24 25 26 N
 B AE SIL eo / de 3 27 28 29 N
 T AE AX eo / al 4 30 31 32 N
 T AX AE bn / a 4 33 34 35 N

 La # linioj estas simple komentojn.  La resto de la variabloj signifi la sekvajn:

   n_base: ne.  de CI telefonoj (ankaŭ nomata "bazo" telefonoj), 5 tie
   n_tri: ne.  de triphones, 7 en ĉi tiu kazo
   n_state_map: Tuta ne.  de HMM statoj (emisiaj kaj ne-emisiaj)
                 La Sfinkso appends ekstran fina ne-emisiaj stato
                 al cxiu HMM, de ĉi tie dum 5 +7 telefonoj, ĉiu precizigita per
                 la uzanto esti modelita per 3-stato HMM, ĉi tiu numero
                 estos 12phones * 4states = 48
   n_tied_state: ne.  de ŝtatoj de ĉiuj telefonoj post stato-interŝanĝo estas farita.
                 Ni ne dividas ŝtatoj en tiu etapo.  Sekve ĉi tiu nombro estas la
                 sama kiel la nombro de emisiaj ŝtatoj, 12 * 3 = 36
 n_tied_ci_state: ne.  de ŝtatoj por via CI telefonoj post stato-interŝanĝo     
                 estas farita.  La CI ŝtatoj ne estas dividitaj, nun aŭ poste.
                 Ĉi tiu nombro estas tial denove la tuta numero de elsendante CI
                 ŝtatoj, 5 * 3 = 15
  n_tied_tmat: La tuta nombro de transiro matricoj estas ĉiam la sama
                  kiel la tuteca nombro de CI telefonoj esti modelita.  Ĉiuj triphones
                  por donita telefono dividas la saman traira matrico.  Ĉi
                  nombro estas tial 5.

 Kolumnoj difinoj: La jenaj kolumnoj estas difinita:
        bazo: nomo de ĉiu telefono
        lft: maldekstra kadro de la telefono (- se neniu)
        rt: dekstra kunteksto de la telefono (- se neniu)
        p: pozicio de triphone.  Kvar pozicio markiloj estas subtenataj:
                b = vorto begining triphone
                kaj = vorto finas triphone
                mi = vorto interna triphone
                s = sola vorto triphone 
        ATTRIB: atributo de telefono.  En la telefono listo, se la telefono estas "SIL",
                aŭ se la telefono estas enfermita per "+", kiel en "+ BANG +", tiuj
               telefonoj estas interpretitaj kiel ne-parolado okazaĵoj.  Tiuj estas
                ankaŭ nomita "plenigita" telefonoj, kaj la atributo "plenigita" estas
                atribuita al ĉiu tia telefono.  La bazo telefonoj kaj la
                triphones ne havas specialajn atributoj, kaj do estas 
                etikedita kiel "n / a", staranta por "neniu atributo"
       tmat: la id de la traira matrico asociita kun la telefono      
  ŝtata id La: la IDS de la HMM ŝtatoj ligita kun ajna telefono.  Ĉi tiu listo
                estas eksigita de la "N", kiu staras por ne-emisiaj
                ŝtato.  Neniu id atribuas al ĝi.  Tamen, ekzistas, kaj estas
                listigita.

CREATING THE CD UNTIED MODEL DEFINITION FILE

TRAINING CONTINUOUS MODELS

The next step is the CD-untied training, in which HMMs are trained for all context-dependent phones (usually triphones) that are seen in the training corpus. For the CD-untied training, we first need to to generate a model definition file for all the triphones occuring in the training set. This is done in several steps:
    First, a list of all triphones possible in the vocabulary is generated from the dictionary. To get this complete list of triphones from the dictionary, it is first necessary to write the list of phones in the following format:
    phone1 0 0 0 0
    phone2 0 0 0 0
    phone3 0 0 0 0
    phone4 0 0 0 0
    ...
    
    The phonelist used for the CI training must be used to generate this, and the order in which the phones are listed must be the same. Next, a temporary dictionary is generated, which has all words except the filler words (words enclosed in ++()++ ). The entry
    SIL    SIL
    
    must be added to this temporary dictionary, and the dictionary must be sorted in alphabetical order. The program "quick_count" provided with the SPHINX-III package can now be used to generate the list of all possible triphones from the temporary dictionary. It takes the following arguments:
    FLAG DESCRIPTION
    -q mandatory flag to tell quick_count to consider all word pairs while constructing triphone list
    -p formatted phonelist
    -b temporary dictionary
    -o output triphone list
    Here is a typical output from quick_count
    AA(AA,AA)s              1
    AA(AA,AE)b              1
    AA(AA,AO)1              1
    AA(AA,AW)e              1
    
    The "1" in AA(AA,AO)1 indicates that this is a word-internal triphone. This is a carry over from Sphinx-II. The output from quick_count has to be now written into the following format:
    AA AA AA s
    AA AA AE b
    AA AA AO i
    AA AA AW e
    
    This can be done by simply replacing "(", ",", and ")" in the output of quick_count by a space and printing only the first four columns. While doing so, all instances of " 1" must be replaced by " i". To the top of the resulting file the list of CI phones must be appened in the following format
    AA - - -
    AE - - -
    AO - - -
    AW - - -
    ..
    ..                                                         
    AA AA AA s
    AA AA AE b
    AA AA AO i
    AA AA AW e
    

    For example, if the output of the quick_count is stored in a file named "quick_count.out", the following perl command will generate the phone list in the desired form. perl -nae '$F[0] =~ s/\(|\)|\,/ /g; $F[0] =~ s/1/i/g; print $F[0]; if ($F[0] =~ /\s+$/){print "i"}; print "\n"' quick_count.out The above list of triphones (and phones) is converted to the model definition file that lists all possible triphones from the dictionary. The program used from this is "mk_model_def" with the following arguments number of states per HMM
    FLAG DESCRIPTION
    -moddeffn model definition file with all possible triphones(alltriphones_mdef)to be written
    -phonelstfn list of all triphones
    -n_state_pm
    In the next step we find the number of times each of the triphones listed in the alltriphones_mdef occured in the training corpus To do this we call the program "param_cnt" which takes the following arguments:
    FLAG DESCRIPTION
    -moddeffn model definition file with all possible triphones(alltriphones_mdef)
    -ts2cbfn takes the value ".cont." if you are building continuous models
    -ctlfn control file corresponding to your training transcripts
    -lsnfn transcript file for training
    -dictfn training dictionary
    -fdictfn filler dictionary
    -paramtype write "phone" here, without the double quotes
    -segdir /dev/null
    param_cnt writes out the counts for each of the triphones onto stdout. All other messages are sent to stderr. The stdout therefore has to be directed into a file. If you are using csh or tcsh it would be done in the following manner:
    (param_cnt [arguments] > triphone_count_file) >&! LOG
    
    Here's an example of the output of this program
    +GARBAGE+ - - - 98
    +LAUGH+ - - - 29
    SIL - - - 31694
    AA - - - 0
    AE - - - 0
    ...
    AA AA AA s 1
    AA AA AE s 0
    AA AA AO s 4
    
    The final number in each row shows the number of times that particular triphone (or filler phone) has occured in the training corpus. Not that if all possible triphones of a CI phone are listed in the all_triphones.mdef the CI phone itself will have 0 counts since all instances of it would have been mapped to a triphone. This list of counted triphones is used to shortlist the triphones that have occured a minimum number (threshold) of times. The shortlisted triphones appear in the same format as the file from which they have been selected. The shortlisted triphone list has the same format as the triphone list used to generate the all_triphones.mdef. The formatted list of CI phones has to be included in this as before. So, in the earlier example, if a threshold of 4 were used, we would obtain the shortlisted triphone list as
    AA - - -
    AE - - -
    AO - - -
    AW - - -
    ..
    ..                                 
    AA AA AO s
    ..
    
    The threshold is adjusted such that the total number of triphones above the threshold is less that the maximum number of triphones that the system can train (or that you wish to train). It is good to train as many triphones as possible. The maximum number of triphones may however be dependent on the memory available on your machine. The logistics related to this are described in the beginning of this manual. Note that thresholding is usually done so to reduce the number of triphones, in order that the resulting models will be small enough to fit in the computer's memory. If this is not a problem, then the threshold can be set to a smaller number. If the triphone occurs too few times, however, (ie, if the threshold is too small), there will not be enough data to train the HMM state distributions properly. This would lead to poorly estimated CD untied models, which in turn may affect the decision trees which are to be built using these models in the next major step of the training.
    A model definition file is now created to include only these shortlisted triphones. This is the final model definition file to be used for the CD untied training. The reduced triphone list is then to the model definition file using mk_model_def with the following arguments: number of states per HMM
    FLAG DESCRIPTION
    -moddeffn model definition file for CD untied training
    -phonelstfn list of shortlisted triphones
    -n_state_pm
Finally, therefore, a model definition file which lists all CI phones and seen triphones is constructed. This file, like the CI model-definition file, assigns unique id's to each HMM state and serves as a reference file for handling and identifying the CD-untied model parameters. Here is an example of the CD-untied model-definition file: If you have listed five phones in your phones.list file,
SIL B AE T
and specify that you want to build three state HMMs for each of these phones, and if you have one utterance listed in your transcript file:
<s> BAT A TAB </s> for which your dictionary and fillerdict entries are:
Fillerdict:
<s>   SIL
</s>  SIL
Dictionary:
A      AX 
BAT    B AE T
TAB    T AE B
then your CD-untied model-definition file will look like this:
# Generated by /mk_model_def on Thu Aug 10 14:57:15 2000
0.3
5 n_base
7 n_tri
48 n_state_map
36 n_tied_state
15 n_tied_ci_state
5 n_tied_tmat                                                                  
#
# Columns definitions
#base lft  rt p attrib   tmat  ...state id's ...
SIL     -   -  - filler    0    0       1      2     N
AE      -   -  -    n/a    1    3       4      5     N
AX      -   -  -    n/a    2    6       7      8     N
B       -   -  -    n/a    3    9       10     11    N
T       -   -  -    n/a    4    12      13     14    N
AE      B   T  i    n/a    1    15      16     17    N
AE      T   B  i    n/a    1    18      19     20    N
AX      T   T  s    n/a    2    21      22     23    N
B       SIL AE b    n/a    3    24      25     26    N
B       AE  SIL e   n/a    3    27      28     29    N
T       AE  AX e    n/a    4    30      31     32    N
T       AX  AE b    n/a    4    33      34     35    N

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

  n_base      : no. of CI phones (also called "base" phones), 5 here
  n_tri       : no. of triphones , 7 in this case
  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 5+7 phones, each specified by
                the user to be modeled by a 3-state HMM, this number
                will be 12phones*4states = 48
  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, 12*3=36
n_tied_ci_state:no. of states for your CI phones after state-sharing     
                is done. The CI states are not shared, now or later.
                This number is thus again the total number of emitting CI
                states, 5*3=15
 n_tied_tmat   : The total number of transition matrices is always the same
                 as the total number of CI phones being modeled. All triphones
                 for a given phone share the same transition matrix. This
                 number is thus 5.

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. Four position markers are supported:
               b = word begining triphone
               e = word ending triphone
               i = word internal triphone
               s = single word triphone 
       attrib: attribute of phone. In the phone list, if the phone is "SIL",
               or if the phone is enclosed by "+", as in "+BANG+", these
              phones are interpreted as non-speech events. These are
               also called "filler" phones, and the attribute "filler" is
               assigned to each such phone. The base phones and the
               triphones 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.

ENTRENAMIENTO kuntekston SENDEPENDA Modeloj

ENTRENAMIENTO kontinua Modeloj

Iam la ebena inicialización estas farita, vi estas preta por komenci trejnado la akustiko modeloj por la bazo aŭ "kunteksto-sendependa" aŭ CI telefonoj. Tiu paŝo estas nomata CI-trejnado. En CI-trejnado, la plat-inicializado modeloj estas re-taksita tra la antaŭen-malantaŭen re-korinklino algoritmo nomata Baum-Welch algoritmo. Ĉi tiu estas ripeta re-korinklino procezo, do vi devas kuri multaj "pasas" de la Baum-Welch re-korinklino super via trejnado datumoj. Ĉiu de ĉi tiuj paŝoj, aŭ ripetoj, ripetas, rezultigas iomete pli bonan aron de modeloj por la CI telefonoj. Tamen, ĉar la objektiva funkcio maksimumigita en ĉiu de la tezo pasas estas la verŝajneco, tro multaj iteraciones estus finfine rezultos en modeloj kiuj persvadis tre proksime al la trejnado datumoj. vi eble ne volas ke ĉi tio okazas pro multaj kialoj. Tipe, 5-8 iteraciones de Baum-Welch estas sufiĉa por prenantaj bonaj taksoj de la CI modeloj. Vi povas aŭtomate determinas la nombron de ripetoj, ripetas, ke vi bezonas rigardi la tuta verŝajneco de la trejnado datumojn al la fino de la unua ripeto kaj elektante por "konverĝo rilatumo" de likelihoods. Ĉi tiu estas simple la rilatumo de la plena verŝajneco en la nuna ripeto al tiu de la antaŭa ripeto. Kiel la modeloj ricevas pli kaj pli persvadis al la trejnado datumojn en ĉiu ripeto, la trejnado datumoj likelihoods tipe pliigi monotone. La konverĝo rilatumo estas tiel malgranda pozitiva nombro. La konverĝo rilatumo iĝas pli kaj pli kiel la iteraciones progreso, ĉar ĉiufoje kiam la aktualaj modeloj estas iom malpli diferencas de la antaŭaj. Konverĝo kvocientoj estas datumoj kaj tasko specifa, sed tipa valoroj al kiuj vi povas haltigi la Baum-Welch iteraciones por via CI trejnado povas varii de 0.1-0.001. Kiam la modeloj estas varianco-ununormigita, la konverĝo kvocientoj estas multe pli malgranda.
La plenumebla uzata por ruli Buam-Welch ripeto nomas "BW", kaj prenas la sekvan ekzemplon argumentojn por trejnado kontinua CI modeloj:
FLAG PRISKRIBO
-Moddeffn modelo difino dosiero por CI telefonoj
-Ts2cbfn ĉi flago devas esti aro al ". daŭrigo." se vi trejnis kontinua modeloj, kaj al ". semi". se vi trejnis duon-kontinua modeloj , sen la duoblaj citiloj
-Mixwfn nomo de la dosiero en kiu la miksaĵo-pezoj de la antaŭa ripeto estas stokitaj. Kompletan padon devas esti provizita
-Mwfloor Etaĝo valoro por la miksaĵo pezoj. Ajnan numeron sub la planko valoro estas metita sur la plankon valoro.
-Tmatfn nomo de la dosiero en kiu la transiro matricoj de la antaŭa ripeto estas stokitaj. Kompletan padon devas esti provizita
-Meanfn nomo de la dosiero kiun la rimedoj de la antaŭa ripeto estas stokitaj. Kompletan padon devas esti provizita
-Varfn nomo de la dosiero en kiu la varianzas fromt li antaŭa ripeto estas stokitaj. Kompletan padon devas esti provizita
-Dictfn Vortaro
-Fdictfn Plenigita vortaro
-Ctlfn kontrolo dosieron
-Parto Vi povas dividi la trejnado en N egalaj partoj per opcio flagon. Se estas M eldiroj en via kontrolo dosiero, tiam ĉi ebligos al vi kuri la trejnado aparte sur ĉiu (M / N) th parto. Tiu flago povas esti agordita por specifi, kiu el tiuj partoj vi volas aktuale trejni plu. Kiel ekzemplo, se via tuta numero de partoj estas 3, tiu flago povas preni unu el la valoroj 1,2 aŭ 3
-Npart nombro de partoj en kiuj vi jam fendis trejnado
-Cepdir dosierujo kie viaj karakterizaĵo dosieroj stokitaj
-Cepext la pligrandigo kiu venas post la nomo listigitaj en la kontrolo dosiero. Ekzemple, vi povas havi dosiero nomata / b / cd kaj eble listigita a / b / c en via kontrolo dosiero. Tiam ĉi flago devas esti donita la argumento "d", sen la duoblaj citiloj aux la skalara antaux gxi
-Lsnfn nomo de la transskribo dosieron
-Accumdir Interaj rezultoj de ĉiu parto de via trejnado estos skribita en ĉi tiu dosierujo. Se vi havas T signifas taksi, tiam la grandeco de la meznombro buffer de la aktuala parto de via trejnado estos T * 4 bajtoj (diri). Estos ankaux esti varianco buffer, buffer por miksaĵo pezoj kaj buffer por transiro matricoj
-Varfloor minimuma varianco valoro permesita
-Topn ne. de gaussians konsideri por komputanta la verŝajneco de ĉiu ŝtato. Ekzemple, se vi havas 8 gaussians / stato modeloj kaj topn estas 4, do la 4 plej verŝajne gaŭsa estas uzitaj.
-Abeam antaŭen beamwidth
-Bbeam malantauxen beamwidth
-AGC aŭtomata gajno kontrolo
-CMN cepstral meznombro normaligo
-Varnorm varianco normaligo
-Meanreest signifas re-proksumumo
-Varreest varianco re-proksumumo
-2passvar Opcio ĉi flago por "jes" lasas BW uzi la antaŭa rimedoj en la korinklino de la varianco. La nuna varianco estas tiam taksis kiel E [(x - prev_mean) 2]. Se ĉi tiu flago estas metita al "ne" la nuna takso de la rimedoj estas uzataj por taksi varianzas. Tio necesigas la korinklino de varianco kiel E [x 2] - (E [x]) 2, malstabila proksimumilo ke kelkfoje rezultas en negativaj taksoj de la varianco pro aritmetiko imprecision
-Tmatreest re-takso transiro matricoj aŭ ne
-Heroaĵo karakterizaĵo agordo
-Ceplen longo de baza trajto vektoro
Se vi kuras la trejnado en multaj partoj, aŭ eĉ se vi kuros al la trejnado en unu parto, la ruleblan por Baum-Welch priskribita supre generas nur intera buffer (s). La modelo fino parametroj, nome la rimedoj, varianzas, miksaĵo-pezoj kaj transiro matricoj, devas esti taksita per la valoroj stokitaj en tiuj bufroj. Ĉi tiu estas farita de la ruleblan nomita "normo", kiu portas la sekvajn argumentojn:
FLAG PRISKRIBO
-Accumdir Intera buffer katalogo
-Heroaĵo karakterizaĵo agordo
-Mixwfn nomo de la dosiero kiun vi volas skribi la miksaĵo pezoj. Kompletan padon devas esti provizita
-Tmatfn nomo de la dosiero kiun vi volas skribi la transiro matricoj. Kompletan padon devas esti provizita
-Meanfn nomo de la dosiero kiun vi volas skribi la rimedoj. Kompletan padon devas esti provizita
-Varfn nomo de la dosiero kiun vi volas skribi la varianzas. Kompletan padon devas esti provizita
-Ceplen longo de baza trajto vektoro
Se vi ne re-taksita iu el la modelo parametroj en la BW paŝo, tiam la responda flago devas esti preterlasita de la argumento donita al la normo ruleblan. La plenumebla estos alie provu legi neekzistanta buffer de la buffer dosierujon kaj ne iros tra. Tial se vi starigis-meanreest esti "ne" en la argumento por BW, tiam la flago-meanfn devas ne estos transdonita en la argumento por normo. Ĉi tio estas utila ĉefe dum adapto. Iteraciones de Baum-Welch kaj normo fine rezultos CI modeloj. La iteraciones povas haltis tuj la verŝajneco de la trejnado datumoj konverĝas. La modelo parametroj komputita per normo en la fina ripeto estas nun uzata por pravalorizi la modeloj por kunteksto-dependa telefonoj (triphones) kun deĉenigis ŝtatoj. Ĉi tiu estas la sekva granda paŝo de la trejnado procezo. Ni raportos al la procezo de formado triphones HMMs kun deĉenigis ŝtatoj kiel la "KD deĉenigis trejnado".

TRAINING CONTEXT INDEPENDENT MODELS

TRAINING CONTINUOUS MODELS

Once the flat initialization is done, you are ready to begin training the acoustic models for the base or "context-independent" or CI phones. This step is called CI-training. In CI-training, the flat-initialized models are re-estimated through the forward-backward re-estimation algorithm called the Baum-Welch algorithm. This is an iterative re-estimation process, so you have to run many "passes" of the Baum-Welch re-estimation over your training data. Each of these passes, or iterations, results in a slightly better set of models for the CI phones. However, since the objective function maximized in each of theses passes is the likelihood, too many iterations would ultimately result in models which fit very closely to the training data. you might not want this to happen for many reasons. Typically, 5-8 iterations of Baum-Welch are sufficient for getting good estimates of the CI models. You can automatically determine the number of iterations that you need by looking at the total likelihood of the training data at the end of the first iteration and deciding on a "convergence ratio" of likelihoods. This is simply the ratio of the total likelihood in the current iteration to that of the previous iteration. As the models get more and more fitted to the training data in each iteration, the training data likelihoods typically increase monotonically. The convergence ratio is therefore a small positive number. The convergence ratio becomes smaller and smaller as the iterations progress, since each time the current models are a little less different from the previous ones. Convergence ratios are data and task specific, but typical values at which you may stop the Baum-Welch iterations for your CI training may range from 0.1-0.001. When the models are variance-normalized, the convergence ratios are much smaller.
The executable used to run a Buam-Welch iteration is called "bw", and takes the following example arguments for training continuous CI models:
FLAG DESCRIPTION
-moddeffn model definition file for CI phones
-ts2cbfn this flag should be set to ".cont." if you are training continuous models, and to ".semi." if you are training semi-continuous models, without the double quotes
-mixwfn name of the file in which the mixture-weights from the previous iteration are stored. Full path must be provided
-mwfloor Floor value for the mixture weights. Any number below the floor value is set to the floor value.
-tmatfn name of the file in which the transition matrices from the previous iteration are stored. Full path must be provided
-meanfn name of the file in which the means from the previous iteration are stored. Full path must be provided
-varfn name of the file in which the variances fromt he previous iteration are stored. Full path must be provided
-dictfn Dictionary
-fdictfn Filler dictionary
-ctlfn control file
-part You can split the training into N equal parts by setting a flag. If there are M utterances in your control file, then this will enable you to run the training separately on each (M/N)th part. This flag may be set to specify which of these parts you want to currently train on. As an example, if your total number of parts is 3, this flag can take one of the values 1,2 or 3
-npart number of parts in which you have split the training
-cepdir directory where your feature files are stored
-cepext the extension that comes after the name listed in the control file. For example, you may have a file called a/b/c.d and may have listed a/b/c in your control file. Then this flag must be given the argument "d", without the double quotes or the dot before it
-lsnfn name of the transcript file
-accumdir Intermediate results from each part of your training will be written in this directory. If you have T means to estimate, then the size of the mean buffer from the current part of your training will be T*4 bytes (say). There will likewise be a variance buffer, a buffer for mixture weights, and a buffer for transition matrices
-varfloor minimum variance value allowed
-topn no. of gaussians to consider for computing the likelihood of each state. For example, if you have 8 gaussians/state models and topn is 4, then the 4 most likely gaussian are used.
-abeam forward beamwidth
-bbeam backward beamwidth
-agc automatic gain control
-cmn cepstral mean normalization
-varnorm variance normalization
-meanreest mean re-estimation
-varreest variance re-estimation
-2passvar Setting this flag to "yes" lets bw use the previous means in the estimation of the variance. The current variance is then estimated as E[(x - prev_mean)2]. If this flag is set to "no" the current estimate of the means are used to estimate variances. This requires the estimation of variance as E[x2] - (E[x])2, an unstable estimator that sometimes results in negative estimates of the variance due to arithmetic imprecision
-tmatreest re-estimate transition matrices or not
-feat feature configuration
-ceplen length of basic feature vector
If you have run the training in many parts, or even if you have run the training in one part, the executable for Baum-Welch described above generates only intermediate buffer(s). The final model parameters, namely the means, variances, mixture-weights and transition matrices, have to be estimated using the values stored in these buffers. This is done by the executable called "norm", which takes the following arguments:
FLAG DESCRIPTION
-accumdir Intermediate buffer directory
-feat feature configuration
-mixwfn name of the file in which you want to write the mixture weights. Full path must be provided
-tmatfn name of the file in which you want to write the transition matrices. Full path must be provided
-meanfn name of the file in which you want to write the means. Full path must be provided
-varfn name of the file in which you want to write the variances. Full path must be provided
-ceplen length of basic feature vector
If you have not re-estimated any of the model parameters in the bw step, then the corresponding flag must be omitted from the argument given to the norm executable. The executable will otherwise try to read a non-existent buffer from the buffer directory and will not go through. Thus if you have set -meanreest to be "no" in the argument for bw, then the flag -meanfn must not be given in the argument for norm. This is useful mostly during adaptation. Iterations of baum-welch and norm finally result CI models. The iterations can be stopped once the likelihood on the training data converges. The model parameters computed by norm in the final iteration are now used to initialize the models for context-dependent phones (triphones) with untied states. This is the next major step of the training process. We refer to the process of training triphones HMMs with untied states as the "CD untied training".

FLAT inicialización DE CI MODELO PARAMETROJ

ENTRENAMIENTO kontinua Modeloj

CI-modeloj konsistas el 4 parametraj dosieroj:
  • mixture_weights: la pezoj donita al ĉiu Gaŭsa en la Gaŭsa miksaĵo responda al stato
  • transition_matrices: la matrico de stato transiro probabloj
  • signifas: per tuta Gaussians
  • varianzas: varianzas de ĉiuj Gaussians
Por komenci trejni la CI modeloj, ĉiu el ĉi tiuj dosieroj devas havi iujn komencajn enskriboj, kio estas, devas esti "inicializado". La mixture_weights kaj transition_matrices estas inicializado uzanta la ruleblan mk_flat. Ĝi bezonas la sekvaj argumentoj:
FLAG PRISKRIBO
-Moddeffn CI modelo difino dosieron
-Talpo HMM topologio dosieron
-Mixwfn dosiero kiun vi volas skribi la inicializado miksaĵo pezoj
-Tmatfn dosiero kiun vi volas skribi la inicializado transiro matricoj
-Nstream nombro de sendependa trajto torentojn por kontinuaj modeloj tiu nombro devus esti aro al "1", sen la duoblaj citiloj
-Ndensity numeron de Gaussians modeli ĉiu stato. Por CI modeloj, tiu nombro devus esti aro al "1"
Al pravalorizi la rimedojn kaj varianzas, tutmondaj valoroj de tiuj parametroj estas unue taksita kaj poste kopiis en taŭgaj pozicioj en la parametro dosierojn. La tutmonda meznombro estas komputita uzanta ĉiujn vektoroj vi havas en via trajto dosierojn. Ĉi tiu estas kutime tre granda nombro, do la laboron estas dividita en multaj partoj. En ĉi tiu etapo vi diru al la Sfinkso kiom partoj vi volas dividi tiun operacion en (depende de la komputanta instaladoj vi havas) kaj la Sfinkso "amasigas" aŭ kolektas ĝis la vektoroj por ĉiu parto aparte kaj skribas gxin en intera buffer sur via maŝino. La plenumebla init_gau uzas tiucele. Ĝi bezonas la sekvaj argumentoj:
FLAG PRISKRIBO
-Accumdir dosierujo en kiu vi volas skribi la intera buffers
-Ctlfn kontrolo dosieron
-Parto parto nombro
-Npart tuteca nombro de partoj
-Cepdir pado al karakterizaĵo dosieroj - ĉi estos aldonita antaŭ ĉiuj vojoj donita en la kontrolo dosieron
-Cepext dosiernomo etendo de trajto dosieroj, ekz. "MFC" por dosieroj nomiĝas / b / c.mfc. Duoblaj citiloj ne bezonis
-Heroaĵo tipo de funkcio
-Ceplen dimensinombro de bazo karakteriza vektoroj
-AGC aŭtomata gajno kontrolo faktoro (max / neniu)
-CMN cepstral meznombro normaligo (jes / ne)
-Varnorm varianco normaligo (jes / ne)
Iam la bufroj estas skribitaj, la enhavo de la bufroj estas "ununormigita" aŭ uzata por komputi tutmonda meznombra valora por la karakteriza vektoroj. Ĉi tiu estas farita uzante la ruleblan normo kun la sekva flago agordoj:
FLAG PRISKRIBO
-Accumdir buffer katalogo
-Meanfn dosiero kiun vi volas skribi la tutmonda meznombro
-Heroaĵo tipo de funkcio
-Ceplen dimensinombro de bazo karakteriza vektoro
La sekva paŝo estas "amasigi" la vektoroj por komputanta tutmonda varianco valoro. La plenumebla init_gau, kiam nomas duafoje ĉirkaŭe, prenas la valoro de la tutmonda meznombro kaj kolektas aron de (vektoro-globalmean) 2 valoroj por la tuta aro de datumoj. Ĉifoje, ĉi ruleblan bezonas la sekvajn argumentojn:
FLAG PRISKRIBO
-Accumdir dosierujo en kiu vi volas skribi la intera buffers
-Meanfn globalmean dosieron
-Ctlfn kontrolo dosieron
-Parto parto nombro
-Npart tuteca nombro de partoj
-Cepdir pado al karakterizaĵo dosieroj - ĉi estos aldonita antaŭ ĉiuj vojoj donita en la kontrolo dosieron
-Cepext dosiernomo etendo de trajto dosieroj, ekz. "MFC" por dosieroj nomiĝas / b / c.mfc. Duoblaj citiloj ne bezonis
-Heroaĵo tipo de funkcio
-Ceplen dimensinombro de bazo karakteriza vektoroj
-AGC aŭtomata gajno kontrolo faktoro (max / neniu)
-CMN cepstral meznombro normaligo (jes / ne)
-Varnorm varianco normaligo (jes / ne)
Denove, tuj la bufroj estas skribitaj, la enhavo de la bufroj estas "ununormigita" aŭ uzata por komputi tutmonda varianco valoro por la karakteriza vektoroj. Tio denove faris uzante la ruleblan normo kun la sekva flago agordoj:
FLAG PRISKRIBO
-Accumdir buffer katalogo
-Varfn dosiero kiun vi volas skribi la tutmonda varianco
-Heroaĵo tipo de funkcio
-Ceplen dimensinombro de bazo karakteriza vektoro
Iam la tutmonda meznombro kaj varianco tutmonda estas komputita, ili devas esti kopiita en la rimedoj kaj varianzas de ĉiu ŝtato de ĉiu de la HMMs. La tutmonda meznombro estas skribita en taŭga stato poziciojn en duona dosieron dum la tutmonda varianco estas skribita en taŭga stato pozicioj en varianzas dosiero. Se vi uzas la skriptoj provizita kun la sfinkso pako, vi trovos tiujn dosierojn kun "flatinitial" kiel parto de lia nomo en la model_parameters dosierujo.
La plata rimedoj kaj varianzas dosiero povas esti kreita uzanta la ruleblan cp_parm. Por povi uzi tiun plenumeblan vi devos krei copyoperations mapo dosiero kiu estas du-kolumna dosiero, kun la maldekstra kolumno id-ing la stato * al * kiu la tutmonda valoro devas esti kopiitaj, kaj la dekstran kolumno id-ing la stato * de * kiu devas esti kopiita. Se estas "nphones" CI telefonoj kaj ĉiu ŝtato havas "nEstate_per_hmm" elsendante ŝtatoj, ekzistas volo esti ntotal_Estates = nphones * nEstate_per_hmm linioj en la copyoperations mapo dosiero; la stato id-s (sur la maldekstra kolumno) kuri de 0 thru (ntotal_Estates - 1). Jen ekzemplo por 3-stato hmm (nEstate_per_hmm = 3) por du telefonoj (nphones = 2) (ntotal_Estates = 6, do, ŝtata IDS varius de 0-5):
  0 0
 1 0
 2 0
 3 0
 4 0
 5 0
cp_parm postulas la sekvajn argumentojn.
FLAG PRISKRIBO
-Cpopsfn copyoperations mapaj dosieron
-Igaufn enigo tutmonda meznombro (aŭ varianco) dosiero
-Ncbout numeron de telefonoj fojoj la nombro de ŝtatoj por HMM (tio estas, nombro de ŝtatoj)
-Ogaufn eligo inicializado per (aŭ varianzas) dosiero
cp_parm devas kuri dufoje, unufoje por kopii la rimedoj, kaj iam por kopii la varianzas. Ĉi kompletigas la inicialización procezo por CI trejnado.

FLAT INITIALIZATION OF CI MODEL PARAMETERS

TRAINING CONTINUOUS MODELS


CI models consist of 4 parameter files :
  • mixture_weights: the weights given to every Gaussian in the Gaussian mixture corresponding to a state
  • transition_matrices: the matrix of state transition probabilities
  • means: means of all Gaussians
  • variances: variances of all Gaussians
To begin training the CI models, each of these files must have some initial entries, ie, they must be "initialized". The mixture_weights and transition_matrices are initialized using the executable mk_flat. It needs the following arguments:
FLAG DESCRIPTION
-moddeffn CI model definition file
-topo HMM topology file
-mixwfn file in which you want to write the initialized mixture weights
-tmatfn file in which you want to write the initialized transition matrices
-nstream number of independent feature streams, for continuous models this number should be set to "1", without the double quotes
-ndensity number of Gaussians modeling each state. For CI models, this number should be set to "1"
To initialize the means and variances, global values of these parameters are first estimated and then copied into appropriate positions in the parameter files. The global mean is computed using all the vectors you have in your feature files. This is usually a very large number, so the job is divided into many parts. At this stage you tell the Sphinx how many parts you want it to divide this operation into (depending on the computing facilities you have) and the Sphinx "accumulates" or gathers up the vectors for each part separately and writes it into an intermediate buffer on your machine. The executable init_gau is used for this purpose. It needs the following arguments:
FLAG DESCRIPTION
-accumdir directory in which you want to write the intermediate buffers
-ctlfn control file
-part part number
-npart total number of parts
-cepdir path to feature files - this will be appended before all paths given in the control file
-cepext filename extension of feature files, eg. "mfc" for files called a/b/c.mfc. Double quotes are not needed
-feat type of feature
-ceplen dimensionality of base feature vectors
-agc automatic gain control factor(max/none)
-cmn cepstral mean normalization(yes/no)
-varnorm variance normalization(yes/no)
Once the buffers are written, the contents of the buffers are "normalized" or used to compute a global mean value for the feature vectors. This is done using the executable norm with the following flag settings:
FLAG DESCRIPTION
-accumdir buffer directory
-meanfn file in which you want to write the global mean
-feat type of feature
-ceplen dimensionality of base feature vector
The next step is to "accumulate" the vectors for computing a global variance value. The executable init_gau, when called a second time around, takes the value of the global mean and collects a set of (vector-globalmean)2 values for the entire data set. This time around, this executable needs the following arguments:
FLAG DESCRIPTION
-accumdir directory in which you want to write the intermediate buffers
-meanfn globalmean file
-ctlfn control file
-part part number
-npart total number of parts
-cepdir path to feature files - this will be appended before all paths given in the control file
-cepext filename extension of feature files, eg. "mfc" for files called a/b/c.mfc. Double quotes are not needed
-feat type of feature
-ceplen dimensionality of base feature vectors
-agc automatic gain control factor(max/none)
-cmn cepstral mean normalization(yes/no)
-varnorm variance normalization(yes/no)
Again, once the buffers are written, the contents of the buffers are "normalized" or used to compute a global variance value for the feature vectors. This is again done using the executable norm with the following flag settings:
FLAG DESCRIPTION
-accumdir buffer directory
-varfn file in which you want to write the global variance
-feat type of feature
-ceplen dimensionality of base feature vector
Once the global mean and global variance are computed, they have to be copied into the means and variances of every state of each of the HMMs. The global mean is written into appropriate state positions in a means file while the global variance is written into appropriate state positions in a variances file. If you are using the scripts provided with the SPHINX package, you will find these files with "flatinitial" as part of its name in the model_parameters directory.
The flat means and variances file can be created using the executable cp_parm. In order to be able to use this executable you will have to create a copyoperations map file which is a two-column file, with the left column id-ing the state *to* which the global value has to be copied, and the right column id-ing the state *from* which it has to be copied. If there are "nphones" CI phones and each state has "nEstate_per_hmm" EMITTING states, there will be ntotal_Estates = nphones * nEstate_per_hmm lines in the copyoperations map file; the state id-s (on the left column) run from 0 thru (ntotal_Estates - 1). Here is an example for a 3-state hmm (nEstate_per_hmm = 3) for two phones (nphones = 2) (ntotal_Estates = 6; so, state ids would vary from 0-5):
0   0
1   0
2   0
3   0
4   0
5   0
cp_parm requires the following arguments.
FLAG DESCRIPTION
-cpopsfn copyoperations map file
-igaufn input global mean (or variance) file
-ncbout number of phones times the number of states per HMM (ie, total number of states)
-ogaufn output initialized means (or variances) file
cp_parm has to be run twice, once for copying the means, and once for copying the variances. This completes the initialization process for CI training.

Kreante la HMM topologio DOSIERO

Skribante kontinuaj Modeloj

La HMM topologio dosiero konsistas el matrico kun bulea enskriboj, ĉiu eniro indiactes ĉu specifa transiro de stato = row_number al stato = column_number estas permesita en la HMMs aŭ ne. Ekzemple 3-stato HMM sen saltas permesita beteen ŝtatoj havus topologio dosiero kun jenaj elementoj:
  4
 1,0 1,0 0,0 0,0
 0,0 1,0 1,0 0,0
 0,0 0,0 1,0 1,0 
La nombro 4 estas entute la nombro de sates en HMMs. La Sfinkso aŭtomate appends kvara ne-emisiaj finanta stato al la 3 stato HMM. La unua ero de 1,0 signifas ke transiro de stato 1 ĝis stato 1 (mem) estas permesita. Laŭe, la traira matrico taksita por ĉiu telefono havus "transiro-probablo" en loko de ĉi bulea eniro. Kie la eniro estas 0.0, la responda transiro probablo ne estos taksita (estos 0). Vi povas aŭ skribi el la topologio dosieron permane, aŭ uzi la skripto skripto make_topology.pl provizita kun la sfinkso pako fari ĉi tion. La skripto bezonas la sekvajn argumentojn:
  states_per_hmm: ĉi tiu estas nur entjero specifante la
                          nombro de ŝtatoj por hmm
         skipstate: "jes" aŭ "ne" depende ĉu vi
                          deziras la HMMs esti saltis stato transiroj
                          aŭ ne.
Notu ke la topologio dosiero estas komuna por ĉiuj HMMs kaj estas sola dosiero enhavanta la topologio difino matrico. Ĉi tiu dosiero ankaŭ difinas vian modelon arkitekturo kaj estas kutime metita en la model_architecture dosierujo. Tio estas tamen nedeviga, sed rekomendis. Se vi kuras skriptoj de la sfinkso trejnado pako, vi trovos la dosieron kreita en la model_architecture dosierujo.

CREATING THE HMM TOPOLOGY FILE

TRAINING CONTINUOUS MODELS

The HMM topology file consists of a matrix with boolean entries, each entry indiactes whether a specific transition from state=row_number to state=column_number is permitted in the HMMs or not. For example a 3-state HMM with no skips permitted beteen states would have a topology file with the following entries:
4
1.0     1.0     0.0     0.0
0.0     1.0     1.0     0.0
0.0     0.0     1.0     1.0 
The number 4 is total the number of sates in an HMMs. The SPHINX automatically appends a fourth non-emitting terminating state to the 3 state HMM. The first entry of 1.0 means that a transition from state 1 to state 1 (itself) is permitted. Accordingly, the transition matrix estimated for any phone would have a "transition-probability" in place of this boolean entry. Where the entry is 0.0, the corresponding transition probability will not be estimated (will be 0). You can either write out the topology file manually, or use the script script make_topology.pl provided with the SPHINX package to do this. The script needs the following arguments:
        states_per_hmm : this is merely an integer specifying the
                         number of states per hmm
        skipstate      : "yes" or "no" depending on whether you
                         want the HMMs to have skipped state transitions
                         or not.
Note that the topology file is common for all HMMs and is a single file containing the topology definition matrix. This file also defines your model architecture and is usually placed in the model_architecture directory. This is however optional, but recommended. If you are running scripts from the SPHINX training package, you will find the file created in the model_architecture directory.

Kreante la CI MODELO DIFINO DOSIERO

La unua paŝo estas prepari modelo difino dosiero por la kunteksto sendependaj (CI) telefonoj. La funkcio de modelo difino dosiero estas difini aŭ havigi unikan nombraj identecon por ĉiu ŝtato de ĉiu HMM ke vi iras por trejni, kaj havigi ordonon kiu estos sekvita skribe el la modelo parametroj en la modelo parametro dosierojn. Dum la trejnado, la ŝtatoj estas referenciado nur per tiuj nombroj. La modelo difino dosiero tiel parte specifas vian modelon arkitekturo kaj estas tial kutime stokas en dosierujo nomita "model_architecture". Vi estas kompreneble senpaga por stoki ĝin kie vi bonvolu, se vi estas kurante la trejnado skriptoj provizita kun la sfinkso-III pako.
Por generi ĉi CI modelo difino dosiero, uzu la ruleblan mk_model_def kun jenaj flago agordoj:
FLAG PRISKRIBO
-Phonelstfn phonelist
-Moddeffn nomo de la CI modelo difino dosiero kiun vi volas krei. Kompletan padon devas esti provizita
-N_state_pm nombro de ŝtatoj por HMM en la modeloj, kiujn vi volas trejni. Se vi volas trejni 3 stato HMMs, skribi "3" cxi tie, sen la duoblaj citiloj
Pipon cxefeligo en log-dosiero ci_mdef.log (diri). Se vi listigitaj nur tri telefonoj en via phonelist, kaj specifi ke vi volas konstrui tri ŝtataj HMMs por ĉiu el tiuj telefonoj, tiam via modelo difino dosiero aspektos tiel ĉi:
                    
 # Generated by / mk_model_def on Tue Mar 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
 #
 # Kolumnoj difinoj
 # Bazo lft rt p ATTRIB tmat ... stato id La ...
 SIL --- plenigita 0 0 1 2 N
 A --- n / a 1 3 4 5 N
 B --- n / a 2 6 7 8 N

 La # linioj estas simple komentojn.  La resto de la variabloj signifi la sekvajn:

   n_base: ne.  de telefonoj (ankaŭ nomata "bazo" telefonoj), ke vi havas
   n_tri: ne.  de triphones (ni klarigos ĉi poste)
   n_state_map: Tuta ne.  de HMM statoj (emisiaj kaj ne-emisiaj)
                 La Sfinkso appends ekstran fina ne-emisiaj stato
                 al cxiu HMM, de ĉi tie dum 3 telefonoj, ĉiu precizigita per
                 la uzanto esti modelita per 3-stato HMM, ĉi tiu numero
                 estos 3phones * 4states = 12
   n_tied_state: ne.  de ŝtatoj de ĉiuj telefonoj post stato-interŝanĝo estas farita. 
                 Ni ne dividas ŝtatoj en tiu etapo.  Sekve ĉi tiu nombro estas la
                 sama kiel la nombro de emisiaj ŝtatoj, 3 * 3 = 9
 n_tied_ci_state: ne.  de statoj por via "bazo" telefonoj post stato-interŝanĝo
                 estas farita.  En ĉi tiu stadio, la nombro de "bazo" telefonoj estas
                 la sama kiel la nombro de "ĉiuj" telefonoj ke vi modeli.
                 Ĉi tiu nombro estas tial denove la tuta numero de emisiaj
                 ŝtatoj, 3 * 3 = 9
  n_tied_tmat: La HMM por ĉiu CI telefono havas transiron probablo matrico 
                  asociita ĝin.  Ĉi tiu estas la tuteca nombro de transiro 
                  matricoj por la donita aro de modeloj.  En ĉi tiu kazo, ĉi 
                  nombro estas 3.

 Kolumnoj difinoj: La jenaj kolumnoj estas difinita:
        bazo: nomo de ĉiu telefono
        lft: maldekstra kadro de la telefono (- se neniu)
        rt: dekstra kunteksto de la telefono (- se neniu)
        p: pozicio de triphone (ne necesa en tiu etapo)
        ATTRIB: atributo de telefono.  En la telefono listo, se la telefono estas "SIL", 
         aŭ se la telefono estas enfermita per "+", kiel en "+ BANG +", la sfinkso 
         komprenas tiujn telefonojn esti ne-parolado okazaĵoj.  Tiuj estas 
         ankaŭ nomita "plenigita" telefonoj, kaj la atributo "plenigita" estas 
         atribuita al ĉiu tia telefono.  La bazo telefonoj ne havas specialan 
         atributoj, kaj do estas etikedita kiel "n / a", staranta por 
         "Neniu atributo"   
       tmat: la id de la traira matrico asociita kun la telefono
  ŝtata id La: la IDS de la HMM ŝtatoj ligita kun ajna telefono.  Ĉi tiu listo
                estas eksigita de la "N", kiu staras por ne-emisiaj
                ŝtato.  Neniu id atribuas al ĝi.  Tamen, ekzistas, kaj estas
                listigita.

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.

LA SERIO DE BAZO, kaj pli alta ORDO Feature vektoroj

La aro de funkcio vektoroj vi komputita uzanta la Sfinkso front-end ruleblan nomas la aro de bazo karakteriza vektoroj. Ĉi tiu aro de bazo trajtoj povas esti etendita al inkluzivi kio estas nomitaj pli alta klaso karakterizaĵoj. Iuj komunaj sufiksojn
  1. La aro de diferenco vektoroj, kie la komponantoj saĝa diferenco inter * iuj * okazante kaj antaŭante vektoro (j), uzata por akiri taksi de la deklivo aŭ tendenco en la nuna tempo momenteto, estas la "etendo" de la aktuala vektoro. Tiuj estas nomataj "delto" karakterizaĵoj. Pli taŭga nomo estus la "tendenco" karakterizaĵoj.
  2. La aro de diferenco vektoroj de diferenco vektoroj. La komponanto-saĝa diferenco inter la postaj kaj antaŭaj "delto" vektoroj estas la "etendo" de la aktuala vektoro. Tiuj estas nomataj "duobla delto" trajtojn
  3. La aro de diferenco vektoroj, kie la komponantoj saĝa diferenco inter la n ^ a okazante kaj n ^ a antaŭa vektoro estas la "etendo" de la aktuala vektoro. Tiuj estas nomataj "longtempe delto" trajtojn, diferencante de la "delta" trajtoj en nur ke ili kaptas tendencoj dum pli longa fenestro de tempo.
  4. La vektora formita el la unuaj elementoj de la nuna vektoro kaj la unua elementoj de iu de la pli supre "etendo" vektoroj. Tio nomiĝas la "povo" trajto, kaj lia dimensinombro estas malpli ol aŭ egala al la sumo de la trajto tipoj vi konsideras.
Karakterizaĵo fluoj
En duon-kontinua modeloj, ĝi estas kutima praktiko, por gardi la identecojn de la bazo vektoroj kaj ilia "etendo" vektoroj disigas. Ĉiu tia aro estas nomata kiel "trajto kurento". Vi devas specifi kiom karakterizaĵo riveretoj vi volas uzi en via duon-kontinua modeloj kaj kiel vi volas ilin aranĝis. La karakterizaĵo-aro ebloj aktuale subtenata de la Sfinkso estas:
c/1..L-1 /, d/1..L-1 /, c/0/d/0/dd/0 /, dd/1..L-1 /: legi tion kiel cepstra / dua lasta komponanto,
deltacepstra / dua lasta komponanto,
cepstra / unua komponanto deltacepstra / unua komponanto doubledeltacepstra / unua komponanto,
doubledeltacepstra / dua lasta komponanto
Tio ĉi estas 4-fluo karakterizaĵo vektoro uzata plejparte en duon-kontinua modeloj. Ne estas aparta avantaĝo al ĉi aranĝo - iu permuto donus al vi la samaj modeloj, kun parametroj skribita en malsamaj ordoj.
Jen iu kiu ne evidente el la skribmaniero uzita por la 4-fluo karakterizaĵo aro: la dimensinombro de la 4-fluo karakterizaĵo vektoro estas 12cepstra +24 deltas +3 powerterms +12 doubledeltas
la deltas estas komputita kiel la diferenco inter la du kadroj cepstra forigitaj cxe cxiu flanko de la nuna kadro (12an de tiuj), sekvita de la diferenco inter la cepstra kvar kadroj forigitaj cxe cxiu flanko de la nuna kadro (12 el tiuj). La povo rivereto uzas la unua komponanto de la du-kadroj-forigis deltas, komputita uzanta C 0.
(Pli veni ....)

THE SET OF BASE AND HIGHER ORDER FEATURE VECTORS

BEFORE YOU TRAIN

THE SET OF BASE AND HIGHER ORDER FEATURE VECTORS
The set of feature vectors you have computed using the Sphinx front-end executable is called the set of base feature vectors. This set of base features can be extended to include what are called higher order features. Some common extensions are
  1. The set of difference vectors, where the component-wise difference between *some* succeeding and preceding vector(s), used to get an estimate of the slope or trend at the current time instant, are the "extension" of the current vector. These are called "delta" features. A more appropriate name would be the "trend" features.
  2. The set of difference vectors of difference vectors. The component-wise difference between the succeeding and preceding "delta" vectors are the "extension" of the current vector. These are called "double delta" features
  3. The set of difference vectors, where the component-wise difference between the n^th succeeding and n^th preceding vector are the "extension" of the current vector. These are called "long-term delta" features, differing from the "delta" features in just that they capture trends over a longer window of time.
  4. The vector composed of the first elements of the current vector and the first elements of some of the above "extension" vectors. This is called the "power" feature, and its dimensionality is less than or equal to the total number of feature types you consider.
Feature streams
In semi-continuous models, it is a usual practice to keep the identities of the base vectors and their "extension" vectors separate. Each such set is called a "feature stream". You must specify how many feature streams you want to use in your semi-continuous models and how you want them arranged. The feature-set options currently supported by the Sphinx are:
c/1..L-1/,d/1..L-1/,c/0/d/0/dd/0/,dd/1..L-1/ : read this as cepstra/second to last component,
deltacepstra/second to last component,
cepstra/first component deltacepstra/first component doubledeltacepstra/first component,
doubledeltacepstra/second to last component
This is a 4-stream feature vector used mostly in semi-continuous models. There is no particular advantage to this arrangement - any permutation would give you the same models, with parameters written in different orders.
Here's something that's not obvious from the notation used for the 4-stream feature set: the dimensionality of the 4-stream feature vector is 12cepstra+24deltas+3powerterms+12doubledeltas
the deltas are computed as the difference between the cepstra two frames removed on either side of the current frame (12 of these), followed by the difference between the cepstra four frames removed on either side of the current frame (12 of these). The power stream uses the first component of the two-frames-removed deltas, computed using C0.
(more to come....)