In stream_decoder.c function find_metadata_() checks whether a file is valid or not. There are 4 cases it recognizes: 1) file begins with 'fLaC' 2) file begins with ID3 (skipped), followed by 'fLaC' 3) file may begin with 11111111 111110?? sync code (or 11111111111110, depends on endianess i suppose). That is - a raw file with FLAC frames, without header (right?). 4) file begins with ID3 (again - skipped), followed by the same sync code as in case 3
find_metadata_() accepts all 4 types of files. I don't know what was the intention behind accepting case 3, but case 4 ALSO matches mp3 files - they have ID3 at the beginning and FLAC-like two-byte sync code 11111111 11111011 afterwards. Sequence is slightly different, but when it is read as two separate bytes and the second byte is SHR'ed twice to form 00111110, it matches. Because of this FLAC decoder initially accepts an mp3 file as a valid FLAC file. Of course, once decoding starts, decoder throws an error and discards the file (at least i think it does, i never reached that far myself). Unfortunately, some applications using libFLAC may assume that lack of errors after FLAC__stream_decoder_process_until_end_of_metadata() indicates that header is read and stream information (channel number, for example) is available. Would you kindly check the find_metadata_() function to make sure it only accepts real FLAC sync codes, not the MP3 ones? Or at least mention in the documentation that FLAC__STREAM_DECODER_READ_FRAME status doesn't means that stream info is available. _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
