[Flac-dev] Problem in FLAC__stream_decoder_process_metadata

[Ingo Ralf Blum]

Hi Josh,

> 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.

you are right, this isn't clear.

> 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.

Not really. With DirectShow you register file types either by the extension,
which is what I do, or with magic values, similar to the mime-magic
functionality found on UNIX systems. However there seem to be problems with
that, so the graph builder, in some cases, simply tries all source filters. So,
when the MediaPlayer opens an AVI it loads all filters registered, e.g. my FLAC
filter, which in turn sets up the stream decoder and reads in the metadata.

What I do now is to provide a flag, which indicates that the file is opened,
then I call ..process_metadata. When the read callback is called it checkes,
whether the file is currently opening and if so, all read requests beyond a
certain byte position (e.g. the first 64 kB or so) are rejected. This should
prevent the ..._process_metadata from scanning through the whole file.

Second, I'll do this:

> 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()

This is the best solution I think. Thanks for your help.

Regards,

Ingo