Dissection of m4a format

[email protected]
Newsgroups gmane.comp.ipod.ephpod
Message-ID <Pine.LNX.4.44.0305031417480.23981-100000@server1.builderadius.com>
Forwarded:

---------- Forwarded message ----------


I've done some further dissection of the m4a format used by iTunes.

All the meta data that iTunes creates is stored within a "meta" atom, 
inside the "udta" atom.  The "udta" atom is a standard mp4 format atom 
-- and possibly the "meta" atom, though I'm not sure.
The "udta" atom, along with a bunch of other atoms, is a subset of the 
"moov" atom.  According to the mp4 spec, there is only one "moov" atom 
allowed in an mp4 file, and every mp4 file must have one.

The following chart shows the exact structure of the "udta" tag as found 
in an iTunes "m4a" file.

Every four-letter sequence at the beginning of  a line is an atom.  My 
usage of '(c)' stands for the copyright symbol, byte A9 in hex.

In the file, every atom is preceded by a four-byte big-endian value 
specifying the length of the atom, including it's data.  This is in 
compliance with the mp4 file spec.  The indents in the chart show which 
atoms are contained within others.

"(4 0's)" means a sequence of four bytes, all zeros
"0 0 C" means a sequence of two zero bytes, followed by a byte 
containing C (12) in hex.
Anything in quotes is a string.  Strings are not null-terminated, they 
just end.

---------------------------

udta
. meta
. . (4 0's)
. . hdlr
. . . (8 0's) "mdir" "appl" (10 0's)
. . ilst
. . . (c)nam
. . . . data
. . . . . 0 0 0 1 0 0 0 0 -- string indicator?
. . . . . "<string>"
. . . (c)ART
. . . . data
. . . . . 0 0 0 1 0 0 0 0
. . . . . "<string>"
. . . (c)alb
. . . . data
. . . . . 0 0 0 1 0 0 0 0
. . . . . "<string>"
. . . gnre
. . . . data
. . . . . 0 0 0 0 0 0 0 0 -- integer type?
. . . . . 0 B -- genre type?
. . . trkn
. . . . data
. . . . . 0 0 0 0 0 0 0 0
. . . . . 0 0
. . . . . 0 1 - track
. . . . . 0 11 - total ? what's with this byte ordering?
. . . . . 0 0
. . . (c)day
. . . . data
. . . . . 0 0 0 1 0 0 0 0
. . . . . "<string>"
. . . cpil -- part of a compilation
. . . . data
. . . . . 0 0 0 15 0 0 0 0 - single-byte type?
. . . . . 0 - dunno
. . . tmpo
. . . . data
. . . . . 0 0 0 15 0 0 0 0
. . . . . 0 0 - two bytes here, unlike above. Dunno why.
. . . (c)too
. . . . data
. . . . . 0 0 0 1 0 0 0 0
. . . . . "iTunes v4.0, QuickTime 6.2"
. . ----
. . . mean
. . . . 0 0 0 0
. . . . "com.apple.iTunes"
. . . name
. . . . 0 0 0 0
. . . . "iTunNORM"
. . . data
. . . . 0 0 0 1 0 0 0 0 - hhrm, string indicator again
. . . . " 000002A6 000002BC 00001E2D 000020B0 03EEE1B8"
. . . . " 03EEE1B8 00007C99 00006DEA A7A241F8 A7A245E0"
. . ----
. . . mean
. . . . 0 0 0 0
. . . . "com.apple.iTunes"
. . . name
. . . . 0 0 0 0
. . . . "iTunes_CDDB_IDs"
. . . data
. . . . 0 0 0 1 0 0 0 0
. . . . "17+9D0992D0E91D5F154412BCE78B3BD538+797034"
free -- an mp4 spec atom designating empty space in the file

The "udta" tag is always followed by a "free" tag.  This is so that, 
when a user makes changes to the tag info through iTunes, it can just 
use up some of the free space after the "udta" atom, instead of 
re-writing the whole file.  Rather clever.

------------------------------

Further analysis

If you tell iTunes to create an AAC file from a raw WAV file, instead of 
extracting one from a CD inside iTunes, it creates an m4a file with the 
same "udta" tag as above, EXCEPT the "----" atom containing the 
"iTunes_CDDB_IDs" string is NOT PRESENT.  This makes sense ... there is 
no CDDB data associated with that file to begin with.

If you use a hex editor to remove the "----" atom containing the 
"iTunNORM" data, adjusting the size of the "udat", "meta", and "moov" 
atoms to reflect the change, and then bring the file into iTunes, the 
file refuses to play.  Double click it, and nothing happens.  Also, 
iTunes can still show all the relevant data in the "get info" window, 
but if you try to change it, the change won't stick.

On the other hand, if you leave the "iTunNORM" atom intact, but change 
the number to a fake one, for example:
" 11111111 22222222 33333333 44444444 55555555 66666666 77777777 
88888888 99999999 00000000", it goes into iTunes just fine.  No problems.

--------------------------------

mp4's created by FAAC, and ALSO THE LATEST VERSION OF NERO, do not 
contain this meta data, and also start with a different header than an 
m4a does.  Even if you were able to get these files onto your iPod and 
they played correctly (as a previous poster claims), they would still 
never play in iTunes, because of the missing "iTunNORM" tag.

Happily, it appears that the only real differences between an mp4 and an 
m4a are this differing header, and the presence of iTunes data in the 
"udta" tag.  If someone wrote a program that would strip off the typical 
"mp41" header from an mp4, and replace it with Apple's "mp42" header, 
and then swap out the old "udat" tag for a new one in the above format, 
we'd have a way to make _any_ MPEG-4 audio track readable by iTunes and 
playable on an iPod, and we could take any track meta-data along for the 
ride.

The upshot of this is, we can process our PC "mp4" collections to appear 
exactly as iTunes and the Mac iPod expect them.

-g

http://garote.bdmonkeys.net

// eompost 3EB38CD5:4DBC.1:rcucbq



------------------------------------------------------
ephPod Mailing List 
FAQ and HomePage http://www.ephpod.com 
mailto:[email protected] to susbcribe 
mailto:[email protected] to unsusbcribe 
mailto:[email protected] the mailing-list itself
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.