[Flac-dev] Problem in FLAC__stream_decoder_process_metadata

[Josh Coalson]

--- Ingo Ralf Blum <ingoralfblum at gmx.de> wrote:
> I have a problem when I try to open a file, which is not a FLAC file.
> When I
> open a non-flac file with the stream decoder API, one of the first
> things called
> is FLAC__stream_decoder_process_metadata, which itself calls
> stream_decoder_find_metadata_. Unfortunately the non-flac file
> contains some
> content, which leads to the state set to
> FLAC__STREAM_DECODER_READ_FRAME.
> 
> However in FLAC__stream_decoder_process_metadata there isn't a case
> label for
> FLAC__STREAM_DECODER_READ_FRAME and so the assert is called.
> 
> I can't workaroud this, because DirectShow sometimes tries all source
> filters
> available on the system and so, when opening an AVI or MPEG files
> with my
> DirectShow filter this happens. I also don't have access to the file
> information, because I get the data as an anonymous stream, which can
> also be
> some sort of streaming data or such, so I can't check for the file
> extension to
> be ".flac" or similar. So I fixed this for now by adding another case
> label in
> FLAC__stream_decoder_process_metadata.
> 
> case FLAC__STREAM_DECODER_READ_FRAME:
>  decoder->protected_->state=FLAC__STREAM_DECODER_UNPARSEABLE_STREAM;
>  return false;
> 
> Perhaps this or something similar can be added to the CVS, if this
> behaviour is
> a bug and not a feature.

it is a bug, but the fix looks more like this:

 case FLAC__STREAM_DECODER_READ_FRAME:
  return true;

this is because at the stream level the metadata is
optional.  I realize this is not clear from the format
document and it's something I need to update.

the stream decoder has do be able to continue decoding
in the absence of the metadata.  almost by definition,
if you are using the stream decoder, you have already
determined that the content is FLAC.

this doesn't help you though!  what to do... well,
can you check the first 4 bytes coming in for the
'fLaC' signature?  even if you can't rewind your
input stream, you should be able to buffer 4 bytes
in a 'lookahead' buffer, and change your read callback
to consume that first.  but I admit I don't know
anything about direct show filters.

the other clean thing you can do is this: given the
patch I described above, you can just check to see
if you returned from ...process_metadata() without
getting a metadata callback.  if you did not get a
metadata callback, that means the input didn't even
contain the 'fLaC' marker.  if you did get a metadata
callback, you know it's FLAC and are ready to
...process_remaining_frames()

Josh


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com