m4a/mp4 itunes files

[Scott Wheeler]

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