Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Less strict MP4 covr atom parsing #86

Closed
lazka opened this issue Jul 4, 2014 · 4 comments
Closed

Less strict MP4 covr atom parsing #86

lazka opened this issue Jul 4, 2014 · 4 comments
Labels

Comments

@lazka
Copy link
Member

@lazka lazka commented Jul 4, 2014

Originally reported by: Christoph Reiter (Bitbucket: lazka, GitHub: lazka)


From lalinsky on April 05, 2011 22:31:09

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.

Attachment: covr-with-name.diff covr-with-name.m4a

Original issue: http://code.google.com/p/mutagen/issues/detail?id=86


@lazka

This comment has been minimized.

Copy link
Member Author

@lazka lazka commented Jul 4, 2014

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):


From joe.wreschnig@gmail.com on April 17, 2011 04:50:06

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.)
@lazka

This comment has been minimized.

Copy link
Member Author

@lazka lazka commented Jul 4, 2014

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):


From lalinsky on April 05, 2011 13:40:35

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.
@lazka

This comment has been minimized.

Copy link
Member Author

@lazka lazka commented Jul 4, 2014

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):


From lalinsky on April 17, 2011 04:55:46

This issue was closed by revision r103 .

Status: Fixed

@lazka

This comment has been minimized.

Copy link
Member Author

@lazka lazka commented Jul 4, 2014

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):


From lalinsky on April 17, 2011 04:51:43

Thanks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.