m4a tagging support?

[Jochen Issing]

Hi Brian,

thanks for your quick answer.
Well as I am somewhat familar with the mp4 file format and thought about the 
problem for some time already, I know about several solutions/hacks.
If yours is yet another one, let me know.

The hacks:
* take the whole moov-box, replace it with a free box and place it afterwards 
the mdat box. This avoids recalculation of any offsets, though it makes the 
structure of the mp4 file slightly worse. Anyway, the file format is still 
conformant, but one wastes the size of a whole moov box.
* Ignore the free boxes and recalculate always everything. This solution has 
no special cases and still preserves the mp4 file structure

The solution:
* Take the free/skip boxes into account and use it for buffering. If the size 
of the modified moov box exceeds the size of the old moov box, rewrite the 
offset table and add new buffers (free-boxes) at iTunes style positions.

I thought about adding another proxy or (free-space) manager, at which every 
free box registers itself on parsing. If any meta data changes, it reports 
the change of its size to the proxy/manager, which takes care of any 
restructuring.

If I understood you correctly, this is somewhat similar to your approach 
except for the proxy? Anyway, the placement of offset tables is a difficult 
field and I would say, that the mp4 file mechanism has its advantages. 
Although in this case, they are a bit inconvenient and make me hesitate from 
implementing write support.

Cheers,

jochen

On Saturday 16 September 2006 01:27, Brian Nickel wrote:
> On Fri, 2006-09-15 at 14:26 +0200, Jochen Issing wrote:
> > Wow, I haven't heard of it before. Can you tell something about how you
> > did the write support? Do you use the skip/free boxes as buffers and
> > reallocate the boxes in case of new data exceeding the free-boxes?
> >
> > Well for my part, I did read support and still need to do some
> > restructuring for a full write support. Because writing a tag into an
> > mp4file can require to rebuild the whole offset table - something that
> > has actually nothing to do with metadata, but who cares...
>
> I actually just found out about that yesterday when I was fretting for
> hours about why on earth files were getting corrupted when I attached
> inline pictures. I fixed that at about 2 in the morning and it's in
> subversion now.
>
> Basically, here is what I do:
> I have every box I use able to render its own content. If the box
> contains children and contains a FREE child or is a META box, it skips
> rendering any FREE boxes and adds a new one on the end at a size to
> avoid a change or a decent padding size.
>
> When rendering, I try finding the old ILST and slate it for replacement.
> If I don't have an old ILST box, I get the META box, stick the ILST
> inside and slate it for replacement. I do the same thing for META and
> UDTA. Since I know the size of what I'm replacing and the size of what
> I'm adding, I use file.insert to update the block.
>
> This is the tricky part: If the size change is non-zero I loop up the
> parent boxes, overwriting their headers with the size difference (this
> doesn't affect the file size except for the case of changing from a
> normal to a large size format in the header, in which case we're
> screwed). I then loop through the children of the MOOV box looking for
> TRAK boxes. When I find one, I look recursively for CO64 and STCO boxes
> and have them re-render their contents with the change in offsets.
>
> Long story short, it takes knowledge of 20 different box types to make
> this dream a reality and STCO is the single greatest flaw in the MPEG-4
> file format. Who on earth puts all their stuff in boxes and then
> memorizes the GPS coordinates of the stuff. You would memorize where the
> stuff is relative to the box you put it in. ASF is glorious compared to
> this monstrosity.
>
> It's a real pain to figure out, but once you get it, it's not too bad. I
> hope this helps.
>
>
> - Brian Nickel

-- 
 jochen issing
 gpg-sig: 0A121BC8
 www.mcf-music.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20060916/e3b7613a/attachment.pgp