I've found that HCopy behaves unexpectedly when coding waveform files
with certain sample rates.=A0Specifically, the sample period is rounded
off to the nearest multiple of 100ns units, which causes problems.

The number of 100ns units per sample is given by 1E7 divided by the
sample rate of the WAV file.=A0For a 16000 Hz file, this is=A0625.
However, for a 22050 Hz file, this is=A0453.5147 (i.e. not a whole
number).=A0HCopy rounds this off to 454 (as shown in output below).

This means that HCopy interprets each sample in the WAV file as
representing fractionally=A0more time than it actually does. In turn,
there are more frames output than expected. From an hour long WAV file
(01:08:20.44)=A0sampled at 22050 Hz, this produces 410976 "10ms" output
frames, making the file appear as though it is 01:08:29.76 long -
about 9 seconds longer than it really is. If you do speech recognition
or keyword spotting using these features, the resulting times are
significantly out of alignment with the original WAV file!

To reproduce the problem, run the following command, where infile.wav
is a wav file with=A022050 Hz sampling rate, and output is stored in
outfile.plp. HCopy 3.4 is used.

Command:
HCopy -C coding.cfg -S coding.scp -T 3

coding.scp
infile.wav outfile.plp

coding.cfg:
SOURCEKIND =3D WAVEFORM
SOURCEFORMAT =3D WAVE
TARGETFORMAT =3D HTK
TARGETKIND =3D PLP_0_E
TARGETRATE =3D 100000.0
HPARM: SAVECOMPRESSED =3D T
HPARM: SAVEWITHCRC =3D T
HPARM: ZMEANSOURCE =3D T
HPARM: WINDOWSIZE =3D 250000.0
HPARM: USEHAMMING =3D T
HPARM: PREEMCOEF =3D 0.97
HPARM: NUMCHANS =3D 18
HPARM: LPCORDER =3D 12
HPARM: COMPRESSFACT =3D 0.3333333
HPARM: NUMCEPS =3D 12
HPARM: CEPLIFTER =3D 22
HPARM: ESCALE =3D 1.0
HPARM: ENORMALISE =3D T
HPARM: SILFLOOR =3D 50.0
HPARM: USEPOWER =3D T
HPARM: CEPSCALE =3D 10
HPARM: LOFREQ =3D 125
HPARM: HIFREQ =3D 3800

Output:
Source file format: WAV [WAVEFORM]
Target file format: HTK [PLP_E_0]
Source rate: 454 Target rate: 100000
infile.wav
=A0 =A0-> outfile.plp

Sorry if this has already been documented somewhere, but I thought
that this should be more clearly pointed out as it has quite a subtle
yet nasty effect.
The WAV file can easily be resampled with e.g. sox beforehand, to work
around the problem=A0(as in sox infile.wav -r 16000
infile.resampled.wav).