Bugs are related with using static prior for MPE training within HMMIRest: 1) The prior MMF and the source MMF cannot have both an INPUTXFORM defined, even if the transform is the same. The solution is to remove the transform from the prior MMF. 2) In the HTK book (discriminative training section, p147-148), the recommended configuration values for MPE training with static prior are: PRIORTAU = 25 STATICPRIOR = TRUE The presence of "ISMOOTHTAU" in the config file changes HMMIRest behaviour. If ISMOOTHTAU is not defined: - only 2 sets of accumulators per chunk are dumped - the MMI criteria is reported, but it makes no sense - worryingly, the numeric values of AvCor and MPE criteria are different than those reported when ISMOOTHTAU is defined (I set it to 50) As I understand, ISMOOTHTAU should not be used when requesting STATIC prior, so HMMIRest behaviour when it is defined and when it is not should be the same (compare wISMOOTH.log and woISMOOTH.log to see the differences). 3) I am using a global semitied INPUTXFORM: 3.1) If the source MMF has an INPUTXFORM, when loading the accumulators and dumping the new MMFs, an ERROR is thrown: "ERROR [+7035] PutMacroHdr: Unable to find ~j Macro to write". If the config file has the parameter "SAVEINPUTXFORM = FALSE", the problem doesn't occur. 3.2) Unfortunately, if the INPUTXFORM is in a separate MMF, I cannot get HMMIRest to work. It either ignores the xform, which results in a low MPE criteria, or segfaults (see segfault.log). I had to: - add "-a" flag in HMMIRest call - add " BASE" into the xform MMF - so the xform would be applied, I: - renamed the xform to "mfckl" - set the parameter "INXFORMMASK" to "*.rdn_%%%%%" (all the training files have extension *.rdn_mfckl) - rename the xform's MMF to "mfckl.HLDA" However, HMMIRest still crashes with the error: "HMM Def Error: symbol expected at line... in /.../mfckl.HLDA", although is in the xform MMF: === mfckl.HLDA === ~j "mfckl" * BASE 1 39 9.312957e+00 1 39 1 39 39 ... ====== I never use the "-a" flag because the semitied xform is always contained together with the HMMs in a single MMF file. Unfortunately, I am forced to hit problem 3.2 because of 3.1. I guess that fixing 3.1 would be the easiest solution. I will be checking the code meanwhile and will let you know if I find out a solution. I have been looking at bug 3.1 and it is related to bug 1. The problem is caused by HMMIRest.c:Initialise(). 1) LoadHMMSet() is called twice and HParm.c:SetParmHMMSet() 3 times (I don't know why not 2). In the 3rd SetParmHMMSet (for the prior MMF), the main MMF transform is already defined in defChan, and it has a different name than the newly defined in the MMF prior transform, resulting in HTK throwing an error. 3.1) In this case, there is no xform defined in the prior MMF. However, in the 3rd HParm.c:SetParmHMMSet() call, cfg_xf->nUse is wrongly increased to 1, which causes the 7035 error at a later stage. I have continued working in using a static prior in MPE training within HTK3.4.1, I think that I have figure out the reason of "bug 2", when using: PRIORTAU = 25 STATICPRIOR = TRUE I have got quite a poor performance using STATICPRIOR, so in a first atemp to improve it, I tried different values of PRIORTAU (25, 50 and 75). Surprisingly, the resulting models are identical. So I had a look at HMMIRest.c to figure out what is going on: A) If ISMOOTHTAU is defined: - THREEACCS is TRUE - UpdateModels() calls FixHMMForICrit() - FixHMMForICrit() calls AddPriorsFromPriorHMM(..., k=1.0, Tau=PriorTau, MMI=FALSE) - mean and variance of all models are updated by adding 100*prior_mean and 100*prior_var respectively ==> PRIORTAU is not used, 100 is instead and mean/var occupancies are set to 100 ==> FIX: "Tau", not 100, should be used instead both for the mean/var update and their occupancies assignment - _FixHMMForICrit is called to perform I-smoothing to all mixtures with ISMOOTHTAU value B) If ISMOOTHTAU is NOT defined: - THREEACCS is FALSE - UpdateModels() calls FixHMMForICrit() - FixHMMForICrit() call AddPriorsFromPriorHMM(..., k=1.0, Tau=PriorTau, MMI=TRUE) - mean and variance of all models are updated by adding ISmoothTau*prior_mean and ISmoothTau*prior_var respectively ==> However, ISmoothTau is not defined, being its value 0.0, which implies that static prior smoothing is not done and the later step of I-smoothing won't be done either. I have been doing A, which yields a better MPE criteria. I am afraid that even fixing A my performance would be as bad... I high value of TAU (100) should keep the models close to the prior HMM, hence performance should not change too much. I am sure that Mark will have something to say about it.