FLAC: Raptor Audio encodes Vorbis comments with bad FLAC block sizes but correct Vorbis field sizes

[GoogleCodeExporter]

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/dist-packages/mutagen/__init__.py", line 214, in
File
    if score > 0: return Kind(filename)
  File "/usr/lib/python2.6/dist-packages/mutagen/__init__.py", line 73, in
__init__
    self.load(filename, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/mutagen/flac.py", line 584, in load
    while self.__read_metadata_block(fileobj): pass
  File "/usr/lib/python2.6/dist-packages/mutagen/flac.py", line 532, in
__read_metadata_block
    block = self.METADATA_BLOCKS[byte & 0x7F](data)
  File "/usr/lib/python2.6/dist-packages/mutagen/_vorbis.py", line 68, in
__init__
    self.load(data, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/mutagen/flac.py", line 248, in load
    super(VCFLACDict, self).load(data, errors=errors, framing=framing)
  File "/usr/lib/python2.6/dist-packages/mutagen/_vorbis.py", line 108, in load
    raise error("file is not a valid Vorbis comment")
mutagen._vorbis.error: file is not a valid Vorbis comment

Attached is the start of the file.

The file comes from: http://ubuntuforums.org/showthread.php?p=8618319
Summary: He ripped lots of music, some of the files fail to import in
Rhythmbox, QL and Exaile but the tags show up in nautilus properties.

Original issue reported on code.google.com by reiter.christoph@gmail.com on 10 Jan 2010 at 10:29

Attachments:

• invalid_vorbis_comment.flac

[GoogleCodeExporter]

The file is corrupt.

Metadata block #1 (as reported by metaflac) has a length of 48 bytes which I 
assure
you is too small to encapsulate the vorbis comment block that is contained
nevertheless intact within the file.

I managed to fix the file using a hex editor and writing at address 2D(hex) the 
value
AF(hex) for 175 bytes, the actual payload size.

I was able to successfully read the metadata using mutagen afterwards.

Fixed file is attached.

Original comment by nondicti...@gmail.com on 10 Jan 2010 at 11:19

Attachments:

• invalid_vorbis_comment-fixed.flac

[GoogleCodeExporter]

The FLAC file is absolute garbage; the Vorbis metadata block claims it's 48 
bytes
long, which is just wrong. If it was 36 bytes I'd say it wrote out the reference
string header length + reference string + 0 frame count and that's how it got 
36, and
then didn't make the tag larger when it added the actual TITLE etc. tags. But 
it's
48, which doesn't make any sense.

I could probably hack up something that makes sure the FLAC block size matched 
the
Vorbis comment size (it's really easy in this case - 48 bytes is obviously not 
enough
to contain 4 byte length + 32 byte vendor + 4 bytes count + min. 6 * 5 bytes 
tags),
but while it's easy to detect, I'm not sure I want to try to work around it, 
because
it's harder to fix than to detect.

I'll look at the source for libFLAC, because it seems to have some kind of 
workaround
for this. Which is probably why EasyTag can load it.

Original comment by joe.wreschnig@gmail.com on 11 Jan 2010 at 12:14

[GoogleCodeExporter]

libFLAC's support is not intentional AFAICT. It just slurps data linearly, so
although it reads 48 bytes for the Vorbis comment, it throws that out and 
assumes
that parsing the Vorbis comment itself will give it the correct size. I checked 
in a
change to make Mutagen do a synch flag check at what it thinks is the start of 
the
audio data, which should allow us to back-patch the correct block size after 
parsing,
once I figure out if there's an API-compatible way to route the original fileobj
through all the MetadataBlock constructors.

Original comment by joe.wreschnig@gmail.com on 11 Jan 2010 at 1:09

• Changed title: FLAC: Raptor Audio encodes Vorbis comments with bad FLAC block sizes but correct Vorbis field sizes

[GoogleCodeExporter]

After poking at this for several hours I'm very reluctant to try to code a 
workaround
into the FLAC loader in Mutagen. I've never seen this bug before and the code 
would
be tricky given the way the FLAC loader is currently written. A rewrite of the 
FLAC
metadata loader could support it but until/if we make mutagen.flac2 this is out 
of
the question, I think.

The good news is that it should be easy to write a standalone script that knows 
how
to fixup these files just by looking for the FLAC comment header and scanning 
the
Vorbis comment size, no Mutagen involved.

Original comment by joe.wreschnig@gmail.com on 18 Jan 2010 at 12:27

[GoogleCodeExporter]

Here is another one: http://code.google.com/p/quodlibet/issues/detail?id=465#c5
(line_65.flac)

This one fails now because of the "End of metadata did not start audio" check.
The last block is a padding with a valid length but with garbage after it.

And I would guess that libFLAC ignores last blocks which are padding.

Original comment by reiter.christoph@gmail.com on 21 Mar 2010 at 3:46

[GoogleCodeExporter]

And line_66.flac is again one of those 48 bytes files.

Original comment by reiter.christoph@gmail.com on 21 Mar 2010 at 3:58

[GoogleCodeExporter]

I have a mostly-working fix for this, but I think it's getting worse. Someone 
on IRC showed me this file yesterday, which looks like it was a 
not-really-48-byte file, and then something tried to tag it as if it was, 
leaving garbage data after the last metadata block.

ogg123 will still play them, though, so we'll try to parse them. But we can't 
fix them without risking intruding on the audio data.

Original comment by joe.wreschnig@gmail.com on 19 May 2011 at 1:20

• Changed state: Accepted

Attachments:

• overwrite.flac

[GoogleCodeExporter]

This issue was closed by revision r108.

Original comment by joe.wreschnig@gmail.com on 24 May 2011 at 4:44

• Changed state: Fixed

[GoogleCodeExporter]

Issue 121 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 29 Aug 2012 at 3:58