Hello!
I'm using the seekable stream decoder API of libFLAC 1.02
and I think that I found a possible bug in process_metadata().
The problem is as follows:
I have a file which isn't a FLAC sample (it's actually an
ACE archive) where process_metadata() returns TRUE. And even
worse, the metadataCallback() is never called (which means
process_metadata() succeeds, although no metadata is actually
processed). Is this legal? I thought that all FLAC streams
must have at least a STREAMINFO metadata block at the very
beginning. My program then fails because the channels/frequency
etc. variables arn't set (it relies on process_metadata()
calling the metadataCallback() at least once with the
STREAMINFO block).
It would be nice if someone could tell me if I'm doing
something wrong or if that's a bug in libFLAC 1.02.
BTW - stream_decoder_find_metadata() returns because this
condition is true:
else if(x >> 2 == 0x3e) { /* MAGIC NUMBER for the last 6 sync bits */
decoder->private_->header_warmup[1] = (FLAC__byte)x;
decoder->protected_->state = FLAC__STREAM_DECODER_READ_FRAME;
return true;
process_metadata() then breaks out of the while() loop because
of this condition:
case FLAC__STREAM_DECODER_READ_FRAME:
return true;
BTW2 - the errorCallback() is called once during process_metadata()
with status = FLAC__STREAM_DECODER_ERROR_LOST_SYNC
- Peter.
On Sun, 24 Feb 2002 15:31:42 +0100, you wrote:>I have a file which isn't a FLAC sample (it's actually an >ACE archive) where process_metadata() returns TRUE. And even >worse, the metadataCallback() is never called (which means >process_metadata() succeeds, although no metadata is actually >processed). Is this legal?Addition: today, I've scanned my HD for more of these problematic files and I found alot of them:(( Especially ACE archives cause this error, but also certain Baldur's Gate & Diablo2 save files(:-)) and even BMP files! What puzzles me is that none of these files has a 'fLaC' signature at the beginng. Doesn't libFLAC test this ID? - Peter.
--- Peter Kunath <research@deliplayer.com> wrote:> On Sun, 24 Feb 2002 15:31:42 +0100, you wrote: > > >I have a file which isn't a FLAC sample (it's actually an > >ACE archive) where process_metadata() returns TRUE. And even > >worse, the metadataCallback() is never called (which means > >process_metadata() succeeds, although no metadata is actually > >processed). Is this legal? > > Addition: today, I've scanned my HD for more of these > problematic files and I found alot of them:(( Especially > ACE archives cause this error, but also certain Baldur's > Gate & Diablo2 save files(:-)) and even BMP files! What > puzzles me is that none of these files has a 'fLaC' > signature at the beginng. Doesn't libFLAC test this ID?nope, it assumes that you've already determined that it's a FLAC stream. let me try and clear this up. it's not clear in the docs, which I need to fix, but the 'fLaC' magic number and metadata blocks are really only required for file storage. at the stream level, a FLAC stream will still play without them. when you interface to libFLAC at the stream level you are implicitly asserting that you know it's a FLAC stream. when you interface at the file level, you are also asserting that the file contains the magic number and at least the STREAMINFO block. if you try and decode something for which these are not true, you should always get an error callback. if you keep going, say on a file that has FLAC frames but missing the STREAMINFO, the decoder will resync and give you data. does that help? Josh __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com