[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Re: Your problem with SphinxTrain
- To: http://dummy.us.eu.org/robert
- Subject: Fwd: Re: Your problem with SphinxTrain
- From: robert b <http://dummy.us.eu.org/robert>
- Date: Wed, 8 Jan 2003 06:24:09 -0800 (PST)
--- "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