Im trying to add support for M4a to my opensource java tagging library (www.jthink.net/jaudiotagger). Basic reading of tags is working ok but I have a few questions:
- I cant find any information about the format of '----' atoms, and what the purpose of them is.
- I only get the correct number back for trkn and disk if I only read the first 4 bytes of the data rather than read to the end of the atom, why is this ?
- I haven't been able to find any of the audio meta info such as bitrate and sampling rate except for audio length from Mvhd atom.

-- When writing metadata Ive hardly started, Im unsure what else will get affected when I add/edit fields. I understand that Ill have to calculate the length of the ILST atom, but does it affect any other atoms ?

I know their no official documentation, Ive read the AtomicParsely documentation which is good but are they any others sources, or answers to any of the above would be great help

thanks Paul

They're similar to TXXX in ID3V2. First there's a "mean" atom, containing some sort of "issuer" name, then there's a "name" atom, followed by a data atom, containing the value. Various applications use them for custom information, like gapless information in "iTunSMPB" or ReplayGain information.


Don't know really. The atoms contain an array of values (there's a type field saying the atom contains 16-bit ints, IIRC), where the second is track/disc number and (optionally) the third is total track/disc number. Don't know what the first/fourth value is...


Bitrate is simply file size / length. I'm not aware of any better way at least.

Sampling rate is a fairly complex, and depends on presence of SBR (which is hard to detect reliably). The mp4a atom contains one frequency value, but it isn't that reliable, IIRC. It can also be found in the esds atom; see libfaad for more information.

Ok I see , so is it always mean,name,data ...., with name corresponding to the TXXX key.


is this always the way to create custom information, or can there also be custom atoms ?


Oh I thought they were 32bit ints, does classtype of zero correspond to 16 bit ints then or does it just mean ints and somewhere else tells you it is actually an array of ints or did you just work it out ?


Not if its vbr, what about things like stero/mono.

thanks Paul

Don't know really. It's the only kind of "----" atoms I've seen...


Yes, 0 means 16-bit ints (see the Atomic Parsley web pages for some other possible values). Don't remember if I worked it out or just saw other code that treated it as an array. It's implicit, if the atom is bigger than one int...


That can be found in esds. Again, see libfaad.

By the way, I'm no MP4 expert; I just know enough to make them work in Rockbox.

Actually the Atomic Parsley docs say they are uint8 (unsigned 8bit ints) , anyone know is this wrong/outofdate


thanks for your help

That is incorrect, yes. If nothing else, it says both 0 and 21 are uint8. 0 is uint16 and 21 is uint32. Don't remember where I got that information from though...

With my test files based on 2 bytes per value I am finding that the track number field actually contains
four values (Ive added the slashes), the 2nd is the track no, the third is total tracks and first and fourth fields are always zero.
e.g. trkn : 0/1/10/0

This actually concurs with the example shown in the Atomic Parsley documentation (though its doesnt pick up on this point) which in the exammple shows the track data as 00 00 00 02 00 05 00 00 for track 2 of 5 ( I would have expected it to be 00 02 00 05)

Whereas the discnumber field always contains three values, the 2nd is the disk number, the third is total number of discs and the first is always zero.
e.g disk : 0/1/10

Anyone know what these extra values are, are they always zero and are they always there.

Also Im trying to improve the robustness of my atom traversal code. Given a particular atom, is there any way by reading the header (and subsequent data) of working out whether the atom contains either direct data or a child atom without knowing the internal workings of the atom. For example say I have a MOOV atom starting as follows

00 00 D8 DA 6D 6F 6F 76 00 00 00 6C 6D 76 68 64 (....moov....mvdh)

my code knows that a moov atom contains a mvdh child atom imediately after , but I would prefer if my code could just read any header and then decide whther it contains data or a child next and traverse tree as required, but I cant see how this can be done. I want to do this because I have worked out the hierachy of atoms that Im interested in but I dont know if the hierachy is strictly adhered to in all cases and would be better if code could cope with extra/missing atoms (within reason). This is the hierachy as I understand it:
(dots are just to preserve formatting)
|--- ftyp
|--- moov
|...........|
|...........|----- mvdh
|...........|----- trak
|...........|----- udta
|......................|
|......................|-- meta
|..............................|
|..............................|-- hdlr
|..............................|-- ilst
|....................................|
|....................................|---- @nam (Optional)
|....................................|---- ---- (Optional)
|
|--- mdat

thanks Paul

Average bitrate of the total file will always be filesize / playtime.

I don't think there is any sort of header flag to indicate whether an atom contains child atoms. My own M4A parser and all the other ones I've seen compare the atom type to a known list to determine whether a particular atom is a container or not.

.. and whether it is a container and has data as is the case of the meta atom. Ok thats a shame, I can do as you suggest do you know if the hierachy as ive shown it is fixed, could the ilst subatom ever come before the hdlr atom for example.

I'm not sure if changing the atom order will actually break anything, but a specification doc I found online seems to suggest they do have a preferred arrangement. My own code leaves everything alone except for the 'meta' atom (and the atom sizes of all the parents above it) and that seems to work fine for simple metadata replacement.

Oh, im not intending to change the order myself I wanted to know if I can rely on the order always been as I specified when reading.

Thats answers another query I had regarding what get affected when I change the metadata, you say it works for simple metadata replacement, are there any circumstances under which it wont work wrt to chnaging metadata ?

I assume the worst when reading and bounce through all the sub-atoms one at a time until I find the one I want rather than assume they're in a specific order. I figure it's best to be as robust as possible when reading and as non-disruptive as possible when writing.

I've swapped in entirely rewritten 'meta' atoms and gotten them to show up in iTunes just fine, so that one is fairly malleable. But changing anything outside of the image/text tag stuff is beyond my experience so I'm not sure how difficult it'd be.

I think that is all I want to change, anyone is there anything outside of the meta atom that I might want to change ?

FYI I found the sampling rate in the mdhd atom (moov.trak.mdia.mdhd)