--- "Samuel L. Bayer" <http://www.mitre.org/~sam> wrote: > Date: Thu, 2 Jan 2003 12:27:41 -0500 (EST) > From: "Samuel L. Bayer" <http://www.mitre.org/~sam> > To: http://dummy.us.eu.org/robert > Subject: Re: Your problem with SphinxTrain > > Hi. I finally got around to working on this again. By > new_fe_wrapper.h, I assume you mean: > > src/programs/wave2feat/new_fe_wrapper.h > > Yep. > > So, I assume that this file only affects wave2feat and therefore > only need to recompile wave2feat. > > Yep. > > I ran "setup_SphinxTrain" again to start from scratch > > Never got this far - I really only compiled wave2feat. I'm assuming > that you recompiled as well. > > After doing this, I still get a failure: > > ERROR: "corpus.c", line 1513: MFCC read failed. Retrying after sleep... > > in agg_seg in ./scripts_pl/01.vector_quantize/slave.VQ.pl > > Was this exactly the error that you got? > > No. I was only using wave2feat to convert to MFC for recognition in > Sphinx. So I never ran (or even compiled) the agg_seg executable. Did > you try running wave2feat by hand before invoking the scripts? I can't > find any calls to wave2feat in any of the scripts. > > The error I got was that Sphinx barfed during recognition, because the > file had more frames than the header claimed it had. The agg_seg code > seems to imply that it would do the same, for the following reason: > the line you reference in corpus.c can be invoked if areadfloat() > returns S3_ERROR (-1), and if the header size doesn't match the file > size, areadfloat() will return -1 (areadfloat.c, line 103). So one > possible cause for your error is the problem I had; however, that's > not the only way you might hit line 1513. > > By the way, it's easy to determine whether your MFC file still has > this problem. The first four bytes are an int which should describe > the number of frames, each of which is four floats long. Assuming a > 32-bit float, the size of the file should be the size described by the > int in the first four bytes, times four, plus the four bytes for the > header. I can't recall whether the size is little-endian or > big-endian; the code checks both. > > Good luck - > Sam