Failure to read FLAC file: "CannotReadException: Flac file has invalid block type 101"

[Dan Gravell]

I have a 192/24 FLAC file, originally purchased from an audiophile download site, which cannot be opened by jaudiotagger - the stack trace is:

Exception in thread "main" org.jaudiotagger.audio.exceptions.CannotReadException: Flac file has invalid block type 101
    at org.jaudiotagger.audio.flac.metadatablock.MetadataBlockHeader.<init>(MetadataBlockHeader.java:89)
    at org.jaudiotagger.audio.flac.metadatablock.MetadataBlockHeader.readHeader(MetadataBlockHeader.java:60)
    at org.jaudiotagger.audio.flac.FlacInfoReader.read(FlacInfoReader.java:60)
    at org.jaudiotagger.audio.flac.FlacFileReader.getEncodingInfo(FlacFileReader.java:42)
    at org.jaudiotagger.audio.generic.AudioFileReader2.read(AudioFileReader2.java:63)
    at org.jaudiotagger.audio.AudioFileIO.readFile(AudioFileIO.java:361)
    at org.jaudiotagger.audio.AudioFileIO.read(AudioFileIO.java:197)

According to the FLAC spec block types can be:

BLOCK_TYPE
0 : STREAMINFO
1 : PADDING
2 : APPLICATION
3 : SEEKTABLE
4 : VORBIS_COMMENT
5 : CUESHEET
6 : PICTURE
7-126 : reserved
127 : invalid, to avoid confusion with a frame sync code

If 101 is reserved, I think we should still be able to read the file. It retains forward compatibility in case future FLACs start using a new block type.

If the block type is < 0 or > 126 I think it's appropriate that some sort of CannotReadException is thrown.

The trouble at the moment is that the BlockType is an Enum parameterised by the block type ID and therefore this doesn't scale so well to support all the reserved types.

What do you think the best way forward on this is?

[IJabz]

Hmm, well it says blocks 7-126 are reserved for future use, and I took this to mean reserved to be added to Flac spec in future, but this is likely to happen slowly, i.e they may add support for Block type 8 next. In contrast if you have a file with block type 101, is this actually valid, my first thoughts are that it is not.

[Dan Gravell]

I didn't check whether the BlockType is used for behaviour later. I thought we could simply ignore the block if it was a reserved, but valid (not 127 or greater) block type.

[IJabz]

What im saying is I not sure that it is valid, i.e I those blocks are reserved for use by Flac standard, not just by some guy deciding to use them

[Dan Gravell]

I see - fair point. I was thinking of it from the perspective of de facto uses for new block types evolving later.

I still think it would be ideal to see if JAT could ignore the block and attempt to read the next block if it exists. The complexity there might be communicating the fact that the previous block type was "suspicious" if the subsequent read fails.

[IJabz]

Maybe, do you have access to the file it would help to know if there really is a 101 block, and what it created it or if the file is actually corrupt.

[Dan Gravell]

Sure, what's the best way to share it privately?

[IJabz]

You could dropbox, have you looked at it yourself then

[Dan Gravell]

Yes - I debugged it. Looks like it's the last block. Shall I just issue a PR?

[IJabz]

Want I want to know is why there is a block 101 and what has created it, as far as I know that is not currently valid ?

[Dan Gravell]

I don't know why, but the file was purchased from https://store.acousticsounds.com/ .

I'm not sure I agree it's not currently valid although that comes down to semantics; according to the spec the only block types that are invalid are those numbered 127 and above.

[IJabz]

AFAIK its not currently valid since the Flac spec makes no mention of block 101 as defined blockType, if an application needs custom support in Flac they would then register a APPLICATION_BLOCK instead, see https://xiph.org/flac/id.html. So really unless I see some understanding of why thereis a block 101 I would have to treat as invalid.

[Dan Gravell]

Ok... close this as "invalid" then :)

[IJabz]

Not fixing as explained in comments