In sphinx2-0.4/src/libsphinx2fe/fe_sigproc.c, there is a function that creates the Hamming window:
void fe_create_hamming(float64 *in, int32 in_len)
{
int i;
if (in_len>1){
for (i=0; i<in_len; i++) /* was in_len-1 kal */
in[i] = 0.54 - 0.46*cos(2*M_PI*i/((float64)in_len));
}
return;
}
In the SourceForge CVS log for this source file we find:
Revision 1.4
Thu Dec 6 22:02:11 2001 UTC (2 years, 3 months ago) by lenzo
Changes since 1.3: +4 -2 lines
Remove a -1 from the normalizing factor of the hamming window.
Revision 1.3
Thu Dec 6 21:58:41 2001 UTC (2 years, 3 months ago) by lenzo
Changes since 1.2: +1 -1 lines
Off by one with the conservative -1. The hamming window should be normalized by the total number of samples in the window, rather than one less.
Every other description I've seen of the discrete-time Hamming window (e.g., http://www-ccs.ucsd.edu/matlab/toolbox/signal/hamming.html\) as well as the analogous source files in Sphinx3 and SphinxTrain uses (inlen-1) in the denominator of the argument to the cosine call. Note that this denominator is not for 'normalizing' the window, but rather for setting the range of the cosine function used in computing the window, so that it ranges from 0 to 2pi radians, so that the window is symmetric. This purpose requires (inlen-1), not inlen in the denominator, doesn't it? Does anyone know why this change was made, and made here only, not in Sphinx3 and SphinxTrain? One consequence is that the Sphinx2 processing uses a different window than the acoustic models used in their training; the difference is slight, but it's there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I think you are right. According to all the literature I have seen, it is should be (inlen-1).
But I would worry about it that much. Considering in this particular application, the window length is usually 100 or more, this doesn't make much difference.
Anyway, it is good to clarify the concept thought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In sphinx2-0.4/src/libsphinx2fe/fe_sigproc.c, there is a function that creates the Hamming window:
void fe_create_hamming(float64 *in, int32 in_len)
{
int i;
if (in_len>1){
for (i=0; i<in_len; i++) /* was in_len-1 kal */
in[i] = 0.54 - 0.46*cos(2*M_PI*i/((float64)in_len));
}
return;
}
In the SourceForge CVS log for this source file we find:
Revision 1.4
Thu Dec 6 22:02:11 2001 UTC (2 years, 3 months ago) by lenzo
Changes since 1.3: +4 -2 lines
Remove a -1 from the normalizing factor of the hamming window.
Revision 1.3
Thu Dec 6 21:58:41 2001 UTC (2 years, 3 months ago) by lenzo
Changes since 1.2: +1 -1 lines
Off by one with the conservative -1. The hamming window should be normalized by the total number of samples in the window, rather than one less.
Every other description I've seen of the discrete-time Hamming window (e.g., http://www-ccs.ucsd.edu/matlab/toolbox/signal/hamming.html\) as well as the analogous source files in Sphinx3 and SphinxTrain uses (inlen-1) in the denominator of the argument to the cosine call. Note that this denominator is not for 'normalizing' the window, but rather for setting the range of the cosine function used in computing the window, so that it ranges from 0 to 2pi radians, so that the window is symmetric. This purpose requires (inlen-1), not inlen in the denominator, doesn't it? Does anyone know why this change was made, and made here only, not in Sphinx3 and SphinxTrain? One consequence is that the Sphinx2 processing uses a different window than the acoustic models used in their training; the difference is slight, but it's there.
Yes, I think you are right. According to all the literature I have seen, it is should be (inlen-1).
But I would worry about it that much. Considering in this particular application, the window length is usually 100 or more, this doesn't make much difference.
Anyway, it is good to clarify the concept thought.
Sorry typo in last post.
I meant I would NOT worry about it.