The structure of the file is available here:
<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14496-12_2005(E).zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14496-12_2005(E).zip</a><br>
Looking at a file, it appears all the tag data is contained in the UDTA
box which contains a META box, which contains an ILST, which contains
the tag data. The contents of these are outlined here:
<a href="http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt">http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt</a><br>
<br>
The Entagged Tag Library (Java, C#)
<a href="http://entagged.sourceforge.net/index.php">http://entagged.sourceforge.net/index.php</a> has implimentations of WMA
and MP4 reading and writing and may be worth checking out.<br><br><div><span class="gmail_quote">On 21/11/05, <b class="gmail_sendername">Scott Wheeler</b> <<a href="mailto:wheeler@kde.org">wheeler@kde.org</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Friday 18 November 2005 23:48, Martin Aumueller wrote:<br>> Hi all, hi Scott,<br>
<br>First off, I'll be a bit slow at responding in general at the moment since I'm<br>in the process of moving and don't have home internet at the moment.<br><br>> On 11/18/05, Ismail Donmez <<a href="mailto:ismail@uludag.org.tr">
ismail@uludag.org.tr</a>> wrote:<br>> > On Friday 18 November 2005 21:21, Jochen Issing wrote:<br>> > > Hi,<br>> > ><br>> > > I am not quite shure what this is. This is in amarok project and
<br>> > > therefore is only available for amarok, am I right? Or will the code<br>> > > find its way into taglib, or is it already transitioning?<br>> ><br>> > They are bunch of taglib plugins implementing wma/m4a/audible tag
<br>> > support. I don't know if wheels will incorporate them into Taglib.<br>><br>> Taglib 1.4 offers the possibility to register handlers for new file<br>> types. The plugins found in kde's svn repository for amaroK use this
<br>> possibility and are based on code posted to this mailing list in May<br>> 2005. And they should not require any modifications in order to work<br>> with any taglib application using taglib.<br>><br>> Wma support within amaroK lacks write support, while mp4/aac support
<br>> is feature complete (tag reading and writing). Handling of aac tags<br>> requires libmp4v2, either from faad2 or from mpeg4ip. Faad2 fails to<br>> read the tags it has written itself (except when cleaning and
<br>> rewriting all tags), whereas with mpeg4ip everything works nicely. But<br>> as there are no distribution packages for mpeg4ip, I would welcome it<br>> very much if there was support for mp4 tags within taglib not based on
<br>> any external libraries to make dependency hell a little friendlier a<br>> place. And if you implemented mp4 tags independent of any external<br>> library it would fit taglib much better and I would not hesitate to
<br>> include it within amaroK.<br>><br>> As I read on this mailing list, Scott Wheeler is reluctant to include<br>> support for mp4/aac as there are no formal standards for metadata on<br>> these files and as he does not use this functionality and thus would
<br>> not be able to test and support it.<br><br>Well more that they're not documented formats. Well, WMA is, but the EULA on<br>the spec basically rules out reading it for use in OSS implementations.<br><br>With mp4 previously I'd had no way of checking to see if they broke playback
<br>in "canonical" implementations -- i.e. iTunes. However I do now have an<br>iBook, so I could test things if there were an implementation.<br><br>The "plugins" won't be integrated for several reasons:
<br><br>- the mp4 one uses an external library, which TagLib doesn't do<br>- the WMA one is read only, which doesn't fit with the current TagLib generic<br>interfaces (I may consider adding support for read only formats in
2.0) and<br>the code as I recall is pretty hack-ish<br>- In the latter I don't feel particularly confident that the sources are<br>"clean" since if I remember correctly they come from the mplayer sources,<br>which isn't exactly known for paying a lot of attention to licensing
<br><br>> Perhaps a solution for this situation is to extend the current plugin<br>> architecture in a way such that taglib would automatically load shared<br>> objects in certain places, so that implementing additional formats
<br>> becomes completely transparent to the application. And if taglib could<br>> include a contrib directory for unsupported formats that would be even<br>> nicer. Scott, what do you think of such an approach? Would you
<br>> consider extending the plugin architecture if I send you a patch?<br><br>I'm quite reluctant to do so; I intentionally maintain a pretty conservative<br>policy for TagLib inclusion since, well, people get pretty angry when things
<br>suddenly break their files. At this point at least application authors have<br>to specifically chose which things will be touching their users' files and in<br>the case of amaroK it's fairly easy to reassign bug reports to them in the
<br>case that there are broken files and so forth.<br><br>But a generic plugin system that used things just by virtue of them being<br>installed seems like it could be a dangerous path. Some formats are<br>relatively easy to break (there was one TagLib version, fortunately very
<br>quickly fixed that broke all FLAC files since it was one byte off in writing<br>things).<br><br>From a users perspective they don't really care that "Oh, your files are<br>broken because you have this plugin installed and it corrupted files by
<br>overriding the default handler..." They just know that their files won't<br>play anymore and they're pissed off. ;-)<br><br>Just following up on a couple of other questions that came up:<br><br>- Like Allan I haven't seen a spec for mp4 metadata. ID3 is indeed spec'ed
<br>out -- ID3v2 with formal specs, ID3v1 with informal, though it's so trivial<br>that such isn't a big deal.<br><br>- I'd consider a patch for the formats mentioned above, provided that they<br>were fairly clean, don't use external libs, etc.
<br><br>Cheers,<br><br>-Scott<br>_______________________________________________<br>taglib-devel mailing list<br><a href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/taglib-devel">
https://mail.kde.org/mailman/listinfo/taglib-devel</a><br></blockquote></div><br>