flac dev - Sep 2004 - ERROR: mismatch in decoded data, verify FAILED!

On Mon, Jun 25, 2001 at 01:54:02AM +0200, kai@adminhell.org wrote:
> On 24-Jun-2001 Matt Zimmerman wrote:
> > Can you try trimming down the WAV file
> > (e.g., with a program like xwave) until you have the smallest chunk
which
> > still triggers the failure?
> I tried to clip both ends of the original wav, but the error was only
> reproduceable, when I cut of the end of the wav. When i cut off only one
> second from the start of the soundfile verify did not complain anymore.
> So the "rest" is now about 25 megabytes. 
Interesting.  According to the transcript you sent, the error actually occurred
60% of the way through the file.  Since it doesn't happen when you trim a
bit
off the beginning, it sounds like it probably isn't being triggered by a
specific point, but by the accumulated state of the stream (or some other
cumulative effect).
> > If you can make the WAV file (or a portion of it that exhibits the
problem)
> > available, that would be a great help.  Note that there should not be
any
> > copyright issues associated with sending a small sample of a song.
> 
> I don't have a high bandwith link, so if you mail me an
ftp-account/login
> I`ll upload the wav to the place for vivisection purposes ;-)
I don't have anyplace for you to FTP it to at the moment...if you have
ssh/scp
available, let me know and I can arrange for a place where you can scp it.  If
you can get it through FLAC successfully (using different options), feel free
to do that to reduce the size of the transfer.
> BTW: flac running on "Linux jukebox 2.4.2 #3 SMP Fri May 25 19:01:56 
>         CEST 2001 i686 unknown"
I've put FLAC to work for the past couple of hours encoding some things at
-9,
and haven't hit the problem yet.  Of course, on this machine (PII/350), a
couple of hours is only about 3 tracks at -9.

-- 
 - mdz

On 24-Jun-2001 Matt Zimmerman wrote:
>> [...]
>> ERROR during encoding, state = 15:FLAC__ENCODER_MEMORY_ALLOCATION_ERROR
> 
> This error appeared in the other report as well.  It looks like a memory
> allocation failure is the cause of the problem.  Is the error easily
> reproducible given the failed WAV file?
Yes, always the same error - but only (no joke) on option -8 , not -9 or
anything below.
> Can you try trimming down the WAV file
> (e.g., with a program like xwave) until you have the smallest chunk which
> still triggers the failure?
I tried to clip both ends of the original wav, but the error was only
reproduceable, when I cut of the end of the wav. When i cut off only one
second from the start of the soundfile verify did not complain anymore.
So the "rest" is now about 25 megabytes. 
 
> If you can make the WAV file (or a portion of it that exhibits the problem)
> available, that would be a great help.  Note that there should not be any
> copyright issues associated with sending a small sample of a song.
I don't have a high bandwith link, so if you mail me an ftp-account/login
I`ll upload the wav to the place for vivisection purposes ;-)


BTW: flac running on "Linux jukebox 2.4.2 #3 SMP Fri May 25 19:01:56 
        CEST 2001 i686 unknown"

-- 
public crypto-key on request..
Key fingerprint = 8135 48FE 200C 4D4E E846  14B2 AAB0 D1AA A297 169C
fortune had this to say..
To get something done, a committee should consist of no more than three
men, two of them absent.

> > I tried to clip both ends of the original wav, but the error was
> > only
> > reproduceable, when I cut of the end of the wav. When i cut off
> > only one
> > second from the start of the soundfile verify did not complain
> > anymore.
> > So the "rest" is now about 25 megabytes. 
> 
> Interesting.  According to the transcript you sent, the error
> actually occurred
> 60% of the way through the file.  Since it doesn't happen when you
> trim a bit
> off the beginning, it sounds like it probably isn't being triggered
> by a
> specific point, but by the accumulated state of the stream (or some
> other
> cumulative effect).
The encoder doesn't keep any state beyond the frame boundary,
except the implied starting sample.  In other words, to trim
the beginning of a file down, you just have to trim off
n*blocksize samples.  You can actually use --skip to do this.
Just keep increasing the value for n until you find the
first trouble block, then strip n*blocksize samples off.

Once you hit a trouble block you can usually just cut off
everything after that one block also and still get the same
behavior.

Josh


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/