> I have done the experiments about discriminative training successfully
> when the TARGETRATE=3D100000.0 (frame shift is 10ms) with the Version
> 3.4, and then because of some portable devices consideration I try to
> train the hmm model with the new feature (the
> TARGETRATE=3D160000.0,frame shite is 16ms and WINDOWSIZE is 32ms).=20
>=20
> Besause of the HDecode in V3.4 is fixed with the frameduration 10ms,
> so I edit the code in HLVRec-traceback.c, and replace "ln->time =3D
> path->frame / 100.0;" /* fix frame duration! */ with "ln->time =3D
> path->frame / 100.0 * 1.6;". And I add the "HARC:FRAMEDUR=3D0.016" to
> the config file due to the same reason in HArc.c and HFBLat.c.
>=20
> But with these lattices generated by edited HDecode, the HMMIRest tool
> still reports errors such as:
> ERROR [+1] There is a problem with lattice frame length.  Set
> ARC:FRAMEDUR to frame length in seconds (e.g 0.01)
> FATAL ERROR - Terminating program HMMIRest
>=20
> Would you give me some advices if I want to do discriminative training
> with the feature whose frame shift is 16ms?

Hi

As far as I remember the issue here is that times after multiplication
aren't precisely aligned, so little floating point mismatch makes
HMMIRest think that frame step is not correct. I solved this problem by
using different configs:

For HDecode/HMMIRest:

TARGETKIND =3D  MFCC
TARGETRATE =3D 100000.0

For everything else:

TARGETRATE =3D 185000.0

This way the times in lattices generated by HDecode are not correct, but
they match with the frame counts so HMMIRest thinks everything is fine.

The alternative solution would be to finally fix the time extraction
algorithm in HFBLat.

Since it's a bug in HTK, I'd add htk-developers to CC.