mutagen appears to munge hex tags inside of mp4 container

[GoogleCodeExporter]

(This issue was surfaced via the beets tagger's use of mutagen, reference : 
http://code.google.com/p/beets/issues/detail?id=209 )

The following pastebin :

http://pastebin.com/diff.php?i=LmZphea0

shows that, according to AtomicParsley, the "Encoding Params" atom got munged 
somehow :

before
------
Atom "----" [Encoding Params] contains: hex 0x76657273 00000001 61636266 
00000001 62726174 0001F400 63646376 00010504 

after
-----
Atom "----" [Encoding Params] contains: vers

Adrian Sampson, author of beets, contributes some additional detail :

" This seems to be an incompatibility in the ways that AtomicParsley and 
Mutagen look at MPEG-4 atoms. Just opening and saving an AAC file with Mutagen 
causes AtomicParsley to lose the hex data in that field (although Mutagen can 
still see it). "

This may or may not be a bug in Mutagen. This bug submission hopes to cover the 
case where it is. :D

Original issue reported on code.google.com by teh.awes...@gmail.com on 23 Dec 2011 at 2:32

[GoogleCodeExporter]

Can you please upload the file somewhere or send it to me via email 
lalinsky@gmail.com?

Original comment by lalinsky on 29 Dec 2011 at 8:29

[GoogleCodeExporter]

I sent you the file via email. :)

Original comment by teh.awes...@gmail.com on 29 Dec 2011 at 4:31

[GoogleCodeExporter]

I'm also seeing this when writing to MP4 files. Should be categorized as a bug, 
not an enhancement.

Somehow unicode objects aren't being encoded properly.

Original comment by dsu...@gmail.com on 2 Feb 2012 at 2:41

[GoogleCodeExporter]

I was able to work around this by encoding to utf-8. For example:

tags[atomid] = value.encode('utf-8')

Original comment by dsu...@gmail.com on 4 Mar 2012 at 3:29

[GoogleCodeExporter]

OK, it throws away the version and flags of the freeform data and in this case 
"Encoding Params" is binary and not text.

One thing that seems odd, is that it catches all exceptions during loading and 
simply throws away all tags if parsing one of them fails.

Attached patch prevents loading such files, but this is not a solution.

Possible Solution: Introduce a Freeform class that holds those flags (subclass 
from string to stay compatible). Rework exceptions to not throw away tags if 
loading fails.

Ideas welcome.

( So I don't have to search for it again: 
http://web.archive.org/web/20091024221536/http://geocities.com/xhelmboyx/quickti
me/formats/mp4-layout.txt )

Original comment by reiter.christoph@gmail.com on 25 Jul 2012 at 5:45

• Changed state: Accepted
• Added labels: Priority-High, Type-Defect
• Removed labels: Priority-Low, Type-Enhancement

Attachments:

• 103-error.patch

[GoogleCodeExporter]

Attached is a possible fix: Introduces MP4FreeForm which saves the format flags 
similar to MP4Cover.

Also attached: The file used in the report above.

Original comment by reiter.christoph@gmail.com on 19 Oct 2012 at 11:24

Attachments:

• mutagen-103-v2.patch
• mutagen-103.m4a

[GoogleCodeExporter]

This issue was closed by revision r135.

Original comment by reiter.christoph@gmail.com on 20 Oct 2012 at 1:04

• Changed state: Fixed

[GoogleCodeExporter]

Amazing. Thanks, Christoph.

Original comment by adrian.sampson on 20 Oct 2012 at 4:51