Nearly everything inherits from a basic struct that is 8 bytes per atom: { length of self + children, quasi-human readable 4 char code describing contents }
Practically speaking, in C/C++, you can stride by length and switch() on the ftype, using it to cast the read-in data to whatever class/struct you desire.
All of this while being so brutally dumb that you can rewrite it over and over again in about 10 lines of code in most languages.
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; };
The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
Sounds almost like the IFF format, which was used for just about everything on the Amiga, and then later (with minor changes) as the basis to microsoft's RIFF, underlying wave files, .AVI and a lot of other formats.
The padding is to two bytes; the tag uses ascii exclusively and no space (33-127), although every format I remember uses upper case + digits. The length does not include tag and the length field, not the padding. Microsoft, in a typical "we don't care" move adopted the spec except they specified little endian whereas IFF is originally big endian.
The entire file must be one complete chunk, and is thus limited to 2GB (signed integer length).
The big difference between the QT Atom structure and RIFF is that RIFF is a series of independent chunks (IIRC), whereas Atoms are a big tree. Structurally nearly identical, though.
Don't know about RIFF, but IFF files are/can be a big tree - the outer chunk must be one of FORM, LIST or CAT, and many chunk types contain additional chunks, so depending on the file you might get structures of arbitrary depth.
