Less strict MP4 covr atom parsing

[GoogleCodeExporter]

Normally the 'covr' atom should only contain 'data' subatoms, but it seems that 
some applications write an empty (well, 1 byte long) 'name' atom at the end of 
the 'covr' atom. See http://bugs.musicbrainz.org/ticket/5894 for an example. I 
think there is no problem white-listing some atom names that we know can be 
safely skipped. When I originally wrote the code, I mainly wanted to catch 
garbage caused by invalid atom sizes, ignoring 'name' should be fine (IMO). On 
save, Mutagen should correctly render the 'covr' atom only with 'data' subatoms.

Original issue reported on code.google.com by lalinsky on 5 Apr 2011 at 8:31

Attachments:

• covr-with-name.diff
• covr-with-name.m4a

[GoogleCodeExporter]

Another example http://article.gmane.org/gmane.comp.kde.devel.taglib/1457 (I 
totally forgot that I fixed this in TagLib a year ago). The fix is different, 
but the situation is exactly the same. The file contained a 'covr' atom with a 
correct 'data' subatom and an empty 'name' subatom, so it seems that some 
application is indeed consistently writing such tags.

Original comment by lalinsky on 5 Apr 2011 at 8:40

[GoogleCodeExporter]

This looks fine. I've added you as a project committer. You should be able to 
commit this directly now. Feel free to check in anything you feel isn't a 
dangerous change.

(That means please don't check in the ID3v2.3 writing patch, I need more time 
to go over it.)

Original comment by joe.wreschnig@gmail.com on 17 Apr 2011 at 11:50

[GoogleCodeExporter]

Thanks.

Original comment by lalinsky on 17 Apr 2011 at 11:51

[GoogleCodeExporter]

This issue was closed by revision r103.

Original comment by lalinsky on 17 Apr 2011 at 11:55

• Changed state: Fixed