by Chris » Fri Feb 09, 2018 5:51 pm
Well, the reason GZDoom isn't picking it up is because it does a raw search for a '=' character in the first 256 bytes of a file to find the first vorbis comment, then works backwards to find the metadata block header, then goes through the tags from there. However, the first = (0x3D) character appears in a part of the file that's not the comment metadata block, meaning it fails to parse it and fails to find the vorbis comments there. The next 0x3D byte, which is part of a vorbis comment, doesn't appear until the 299th byte, outside of the search range.
I'd need to get a better understanding of the FLAC bitstream format, and how these tags are inserted, to figure out how to correctly fix this. Given how the official libFLAC doesn't recognize it (it doesn't even let on that such metadata comments exist), the fact that anything else does makes me feel like this is a non-standard extension, which means correctly handling it will need further investigation. This whole current approach is a big kludge; it's simply trying to recognize a list structure in some arbitrarily-sized beginning chunk, only verifying that it hasn't got anything egregiously bad, and which isn't guaranteed to hold true even in a properly formatted file.
Well, the reason GZDoom isn't picking it up is because it does a raw search for a '=' character in the first 256 bytes of a file to find the first vorbis comment, then works backwards to find the metadata block header, then goes through the tags from there. However, the first = (0x3D) character appears in a part of the file that's not the comment metadata block, meaning it fails to parse it and fails to find the vorbis comments there. The next 0x3D byte, which is part of a vorbis comment, doesn't appear until the 299th byte, outside of the search range.
I'd need to get a better understanding of the FLAC bitstream format, and how these tags are inserted, to figure out how to correctly fix this. Given how the official libFLAC doesn't recognize it (it doesn't even let on that such metadata comments exist), the fact that anything else does makes me feel like this is a non-standard extension, which means correctly handling it will need further investigation. This whole current approach is a big kludge; it's simply trying to recognize a list structure in some arbitrarily-sized beginning chunk, only verifying that it hasn't got anything egregiously bad, and which isn't guaranteed to hold true even in a properly formatted file.