So, before 5d0ac20, FLAC__stream_decoder_process_until_end_of_metadata() was provided a file at position 4 (i.e. after the FLaC magic number), and it was able to process the following metadata.

Just as a suggestion, maybe fseek(in, 4, SEEK_SET)?

Reference: FLAC__stream_decoder_process_until_end_of_metadata() implementation

Wait, according to 5d0ac20, FLAC files with ID3 tags don't start with the FLaC magic number. Instead, they start with the ID3 data, with the FLaC magic number appearing only after. Bummer…

What I don't know about FLAC__stream_decoder_process_until_end_of_metadata(), and having the answer to these could help:

• Does it support starting to read before the FLaC magic number? (i.e. reading through it)
• Does it support reading through ID3 data?

Does it support starting to read before the FLaC magic number? (i.e. reading through it)

Yes. It would be extremely strange/inconvenient if it couldn't do that, given that the stream decoder is just initialized and the next call is FLAC__stream_decoder_process_until_end_of_metadata():

Does it support reading through ID3 data?

I suppose yes. FLAC do support ID3v2 format.

You can see the implementation:
https://github.com/xiph/flac/blob/d1d72aa77cfeb71357b59411f981ff52ac1a1f60/src/libFLAC/stream_decoder.c#L1609

Assuming a regular FLAC file (i.e. much more than 64 KB filesize, and leading metadata less than 64 KB), how come it was still working after 5d0ac20? For instance, the file is already seeked after the metadata that provides the value for flac->channels.

My guess would be that FLAC__stream_decoder_init_ogg_stream and/or FLAC__stream_decoder_process_until_end_of_metadata already manage to rewind the file, except in the case that EOF has been reached (thus triggering eof_callback, unexpectedly actually).

If you search for "hack" (and more specifically, "hack note") in stream_decoder.c, you will notice there are already a handful of hacks related to Ogg FLAC and EOF.