I'm trying to adapt the standard English model, and have hit a snag. First, system details: Mac OS X El Capitan, on a retina MacBook Pro. sphinxbase and sphinxtrain at versions 5prealpha.
sphinx_fe is failing at line 807 of sphinx_fe.c with a divide by zero error. I ran it through lldb, and it seems that it's not grabbing the config values for the number of channels (line 798), or the block size (line 799), and instead returning 0. The output to stdout of config values it does before starting to process the wavs makes sense, and has the values I expected, but it fails on the first call to sphinx_wave2feat_convert_file.
testing.fileids was used successfully for testing when I was tuning my keyword thresholds, and feat.params is just the standard model's version. Judging by where the code is dying, it hasn't even touched the first audio file.
Is this a known issue? I can't seem to figure out if it's something I did or not, but I'm just following the process at:
I rebuilt from a clean extract of the release tarballs, and I'm still experiencing the issue. otool says that it's pointing to the dylib that just got built along with sphinx_fe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, actually looking on the code, it sets the number of channels from wav header, see detect_riff function. So if your header is somehow corrupted, it will lead to unexpected behavior. I would try to standartize the wav files using sox. You can simply copy
sox orig.wav dest.wav
and sox should fix the header.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I'm trying to adapt the standard English model, and have hit a snag. First, system details: Mac OS X El Capitan, on a retina MacBook Pro. sphinxbase and sphinxtrain at versions 5prealpha.
sphinx_fe is failing at line 807 of sphinx_fe.c with a divide by zero error. I ran it through lldb, and it seems that it's not grabbing the config values for the number of channels (line 798), or the block size (line 799), and instead returning 0. The output to stdout of config values it does before starting to process the wavs makes sense, and has the values I expected, but it fails on the first call to sphinx_wave2feat_convert_file.
This is the command line I'm using:
sphinx_fe -argfile en-us/feat.params -samprate 16000 -c testing.fileids -di . -do . -ei wav -eo mfc -mswav yes
testing.fileids was used successfully for testing when I was tuning my keyword thresholds, and feat.params is just the standard model's version. Judging by where the code is dying, it hasn't even touched the first audio file.
Is this a known issue? I can't seem to figure out if it's something I did or not, but I'm just following the process at:
http://cmusphinx.sourceforge.net/wiki/tutorialadapt
Thanks!
Maybe you have several sphinxbase version installed and sphinx_fe links to older version. You can check that with
I suggest you to try with a clean checkout too.
I rebuilt from a clean extract of the release tarballs, and I'm still experiencing the issue. otool says that it's pointing to the dylib that just got built along with sphinx_fe.
Ok, actually looking on the code, it sets the number of channels from wav header, see detect_riff function. So if your header is somehow corrupted, it will lead to unexpected behavior. I would try to standartize the wav files using sox. You can simply copy
and sox should fix the header.
I've just committed a fix to make sphinx_fe more strictly handle input data.
Thanks! I'll give that a try.
That was it. Works now. Thanks!