m4a/mp4 itunes files

Martin Aumueller aumuell at reserv.at
Fri Nov 18 23:48:19 CET 2005


Hi all, hi Scott,

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.

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?

Martin


More information about the taglib-devel mailing list