[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: Your problem with SphinxTrain



--- "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



Why do you want this page removed?