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->private_->input))
{
_______________________________________________
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
