I had a problem where the seekable_stream_decoder was
getting stuck in
an infinite loop sometimes. It looks like I'm not the only
one that's
had the problem:
http://lists.xiph.org/pipermail/flac-dev/2004-
February/001508.html
see also sourceforge bug #1154585
The problem is easiest to reproduce with a small flac file.
The one
I'm using is only 45 kB. Simply write a routine that calls
FLAC__seekable_stream_decoder_seek_absolute to seek to
random places
within the file, read a couple of bytes, and repeat. It
will get
stuck eventually.
The cause of this problem is the first few lines of code in
the
frame_sync_ function of stream_decoder.c. It checks to see
if all the
frames have been decoded already. If they have, it returns
EOS. This
optimization is well intentioned, and fine for non-seekable
streams.
However, seekable_stream_decoder uses this code as well, and
once all
the frames have been decoded, you can't seek anymore. The
fix is to
simply remove this block of code, so it can put the decoder
into the
state it needs to be in: ...READ_FRAME.
For those who really need a patch, here it is:
--- stream_decoder.c 2005-01-30 10:21:23.000000000 -0500
+++ stream_decoder.c 2006-10-27 23:51:11.000000000 -0400
 -1327,6
+1327,7
FLAC__uint32 x;
FLAC__bool first = true;
+#if 0
/* If we know the total number of samples in the
stream, stop
if we've read that many. */
/* This will stop us, for example, from wasting time
trying to
sync on an ID3V1 tag. */
if(decoder->private_->has_stream_info
&&
decoder->private_->stream_info.data.stream_info.total_
samples) {
-1335,6
+1336,7
return true;
}
}
+#endif
/* make sure we're byte aligned */
if(!FLAC__bitbuffer_is_consumed_byte_aligned(decoder->pri
vate_->input))
{
_______________________________________________
Flac-dev mailing list
Flac-devxiph.org
http:
//lists.xiph.org/mailman/listinfo/flac-dev
|