Thanks Andrew. Your fix is committed. Seeking still works wonderfully, as far
as I can see. :)
Andrew Gatt wrote:
> OK sorry people, looks like my patch testing before release needs a lot ot be
> desired! DO NOT apply this patch, it will break mp3 seeking and does not
> properly address why the eof error is set, nor does it clear it.
> However - this patch does! It now returns the correct number of frames read
> and behaves properly when seeking. This problem only occured with accurate
> frame counting enabled (#define getLength_accurate at top of mpegtoraw.cpp)
> as this requires the file to be read up to eof to count the number of frames.
> Anyway here's the patch that should be commited to CVS - once its been
> checked by someone else of course! :)
> -----Original Message----- From: audiere-devel-admin@...
> [mailto:audiere-devel-admin@... Behalf Of Andrew Gatt
> Sent: 21 July 2004 09:13 To: audiere-devel@... Subject:
> [Audiere-devel] Bug in input_mp3.cpp
> Chad (anyone else using CVS),
> I spotted a bug caused by my seeking additions in input_mp3.cpp, i was
> determining the total frames, after initialising the mp3 file to play, which
> triggered the eof error code and caused the decoding part of Mpegtoraw->run
> to bomb out every other read and report that it didn't decode as many frames
> that were asked for. Interestingly because audiere re-requests more frames
> before it gives up, the file will still play - more interestingly it seems to
> play with a slightly lower CPU overhead(!?) unless i was looking at it the
> wrong way. Anyway if, like me, you rely on an accurate frames_read value, you
> need to apply this patch. It literally just moves the total_frames
> determining before the file initialisation.
> Hope this helps. Andrew
> P.S. If Chads not about could someone verify and add it to the CVS. Its quite
> an important bugfix thanks.