m4a tagging support?

[Brian Nickel]

Jochen,

The system I've come up with is a working solution. My method performs a
single file size change (when required) to write the smallest block
possible ILST, META, or UDTA, and then updates the necessary higher
level nested boxes and the offset tables. The only problem is
statistically impossible case where the MOOV box changes size from less
than to greater than 4GB.

- Brian

On Sat, 2006-09-16 at 11:32 +0200, Jochen Issing wrote:

> 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
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20060916/4002d8ca/attachment.html