|
Hello,
I am bulding a monophone recognizer using
mel-cepstral coefficients of order 24. I have read the paper on MSD-HMM's
and I want to make sure I understand it's correct implementation into the
modified HMM prototype definition for HTK. Is there any documentation that
I have missed that explains the <MSDINFO> line?
From the demo I extracted this line from the
prototype:
~o <VecSize> 78 <USER> <MSDINFO>
4 0 1 1 1 <StreamInfo> 4 75 1 1 1
1. From looking at the code I can tell that the 4
represents the number of streams where the first stream is the spectrum and the
last three belong to logf0 parameters. However, what do the 0 and 1's
mean? I assumed that 0 meant 0-dimensions
or discrete symbol. But it is in the first stream position for the
spectrum which is a continuous distribution.
2. Also, how does this line account for the
unvoiced logf0 case?
For my work, I am using a 5 state (3 emitting), 32
mixture, single stream model with mel-cepstral, delta, and delta_delta
parameters (75 in all). I used the following line in my prototype
definition
~o <VecSize> 75 <USER> <MSDINFO>
1 1 <StreamInfo> 1 75
<BeginHMM> <NumStates> 5 <State> 2 <Stream> 1 <NumMixes> 32 <Mixture> 1 0.03125 etc......
...And kept getting the following
error
HMM Def Error: GetToken: Symbol expected at line
1/col 2/char 1 in /(dir)/fcjf0-sa1.cmp
ERROR [+7050] HMError: HMM Def Error: LoadHMMSet: GetToken failed at line 1/col 0/char -1 /(dir)/fcjf0-sa1.cmp ERROR [+7050] HMError: ERROR [+2028] Initialise: LoadHMMSet failed FATAL ERROR - Terminating program /cluster/csip/emoore/htk/bin.linux/HCompV May data files (*.cmp) were generated using
essentially the same mkdata.pl script as in the demo, excluding the computation
of logf0. They were generated from 16-bit integer, 16Khz sampled raw data
files and the HTK headers were added according to the script.
I'm trying to determine if there is something wrong
with my HMM prototype definition or if the data files (*.cmp) have not been
created properly. I've only been using HTK for a few months now so this
might be an obvious problem, but it's eluding me at the moment.
Thanks.
----------------------------------------------------------------
Dr. Elliot Moore II, Post Doc Center for Signal and Image Processing Georgia Institute of Technology Electrical and Computer Engineering email: emoore@xxxxxxxxxxxxxx (ECE) em80@xxxxxxxxxxxxxxx (GT) WWW: users.ece.gatech.edu/~emoore |
This message has been 'sanitized'. This means that potentially
dangerous content has been rewritten or removed. The following
log describes which actions were taken.
Sanitizer (start="1080919139"):
Forcing message to be multipart/mixed, to facilitate logging.
Writer (pos="1232"):
Part (pos="1280"):
Part (pos="200"):
SanitizeFile (filename="unnamed.txt", mimetype="text/plain"):
Match (rule="8"):
ScanFile (file="/var/spool/filter/anomy/att-406d8463-HWN-unnamed.txt"):
Scan succeeded, file is clean.
Enforced policy: accept
Part (pos="2848"):
SanitizeFile (filename="unnamed.html", mimetype="text/html"):
Match (rule="8"):
ScanFile (file="/var/spool/filter/anomy/att-406d8467-202-unnamed.html"):
Scan succeeded, file is clean.
Enforced policy: accept
Note: Styles and layers give attackers many tools to fool the
user and common browsers interpret Javascript code found
within style definitions. References:
- http://www.securityfocus.com/bid/630
- http://archives.indenial.com/hypermail/bugtraq/2001/January2001/0512.html
Rewrote HTML tag: >>_STYLE_<<
as: >>_DEFANGED_STYLE_<<
Rewrote HTML tag: >>_/STYLE_<<
as: >>_/DEFANGED_STYLE_<<
Total modifications so far: 2
Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $