MP4: Match itunes atom structure more closely

[GoogleCodeExporter]

Hello,

after encoding an AAC (m4a) file e.g. with the FDK AAC encoder the 'meta' atom 
tree is written to the file including the '\xa9too' (encoded by) tag.

After re-editing the meta atom structure with mutagen.MP4 a 'free' padding atom 
is written unnecessarily expanding the file size (up to 1024 bytes?) For users 
not having a focus on the tag writing speed benefits it's wasting of the 
storage space. Is there any other reasons for that?

In addition there are some AAC player implementations which obviously have 
issues with 'free' atoms within the meta atom tree even if it's iTunes format 
conform.

Therefore, an implementation of a function which re-writes the atom tree 
structure from scratch without any padding would by highly appreciated.

To my understanding MP4.delete() does not solve the issue.

Thank you!

ra666ack

Original issue reported on code.google.com by ra666...@googlemail.com on 3 Mar 2014 at 2:42

[GoogleCodeExporter]

Thanks for the report.

As you suspected, padding is used to make future changes faster since there is 
no file resize/move needed. 1024 is really nothing for normal files, so I don't 
think that's an issue. We could however reduce/remove padding for smaller files.

With which players are you experiencing issues because of 'free' atoms?

Original comment by reiter.christoph@gmail.com on 3 Mar 2014 at 5:25

• Changed state: NeedInfo

[GoogleCodeExporter]

Hi,

the problematic players I experienced are hardware network players by Ph***ps 
St****ium np3700 and np3900 (not confirmed by the customer support so far).
However, modyfing the m4a tag using the mp3tag software removes the free atom. 
The same file will be played without any problems.
Please find attached the atom comparison of the same m4a file.

Therefore I wonder if you could provide a function which rebuilds the whole 
atom tree structure without any paddings.

Original comment by ra666...@googlemail.com on 3 Mar 2014 at 6:11

Attachments:

• [Vergleich m4a tags.pdf](https://storage.googleapis.com/google-code-attachments/mutagen/issue-171/comment-2/Vergleich m4a tags.pdf)

[GoogleCodeExporter]

Thanks. Have you verified that removing the 'free' code in mutagen fixes it or 
is this just a guess based on the diff?

Original comment by reiter.christoph@gmail.com on 4 Mar 2014 at 5:51

[GoogleCodeExporter]

Hi Christoph,

it was a guess but your comment inspired me to modify a file using a HEX editor.
It seems the player has an issue with the order of the atoms. If 'mdat' appears 
before udta.meta.ilst the palyer won't play that file. Moving 'mdat' to the end 
of the file fixes the issue (The 'stco' atom was changed accordingly).

The customer service was informed about that obvious player bug and will be 
challenged.

I assume the implemented approach in mutagen.MP4 is iTunes conform. However, do 
you see a possibility to implement a switch which decides where to write the 
tag information (beginning/end of the file)?

ra666ack

Original comment by ra666...@googlemail.com on 5 Mar 2014 at 8:11

Attachments:

• [m4a mdat atoms.pdf](https://storage.googleapis.com/google-code-attachments/mutagen/issue-171/comment-4/m4a mdat atoms.pdf)

[GoogleCodeExporter]

Thanks for investigating.

Checking some random iTunes files, mdat is also at the end there, so mutagen is 
probably doing something wrong.

Original comment by reiter.christoph@gmail.com on 5 Mar 2014 at 8:38

• Changed title: MP4: Match itunes atom structure more closely
• Changed state: Accepted
• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Hi Christoph,

before you start any activities on this "issue"...
I figured out that mutagen works correctly. It's ffmpeg with implemented 
libfdk-aac module which writes the metadata information to the end of the file. 
Using the ffmpeg switch "-movflags +faststart" re-writes the moov atom to the 
beginning of the file.

Anyway it would be a cool feature of mutagen. This is useful e.g. for streaming.

Sorry for the confusion...

Regards ra666ack

Original comment by ra666...@googlemail.com on 6 Mar 2014 at 5:30

[GoogleCodeExporter]

mutagen has moved to Bitbucket: https://bitbucket.org/lazka/mutagen/issue/171

Original comment by reiter.christoph@gmail.com on 4 Jul 2014 at 3:33

• Changed state: Duplicate