search for: gibod

fixed in cvs http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Mon, 6/1/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac-dev] Bug in bitreader for short reads? > To: flac-dev at xiph.org > Date: Monday, June 1, 2009, 10:16 AM > It seems that the bitstream > reader is not working as it should (verified...

you're right, this is fixed in CVS, see http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Sun, 5/31/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac] Bug in bitreader for short reads? > To: flac at xiph.org > Date: Sunday, May 31, 2009, 10:40 PM > It seems that the bitstream > reader is not working as it should (verified in versi...

I've upgraded to FLAC 1.1.3, and now I have some streams where seek does not work anymore, but they used to work before. After a bit of debugging, it looks like those streams (created a long time ago with an old version of FLAC) have a seek table where all the entries have a stream offset of 0. The result is that in the function seek_to_absolute_sample_, on line 3076 (file

It seems that the bitstream reader is not working as it should (verified in version 1.2.0 and 1.2.1). The problem is as follows: if the data read by the read callback is not a multiple of 4, the bit reader will end up in a very bad state, where the bits_consumed field will grow without ever being reset to 0, and that causes everything to fail. This is not a case that's encountered very

It seems that the bitstream reader is not working as it should (verified in version 1.2.0 and 1.2.1). The problem is as follows: if the data read by the read callback is not a multiple of 4, the bit reader will end up in a very bad state, where the bits_consumed field will grow without ever being reset to 0, and that causes everything to fail. This is not a case that's encountered very