m4a/mp4 itunes files

[Brian Nickel]

The structure of the file is available here:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14496-12_2005(E).zip
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:
http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt

The Entagged Tag Library (Java, C#)
http://entagged.sourceforge.net/index.php has implimentations of WMA and MP4
reading and writing and may be worth checking out.

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