Splitting out the taglib plugins?

[Martin Aumueller]

I also think that's a reasonable idea. The four plugins available within 
amaroK (sorry, I meant to type Amarok) are probably the most complete 
collection for supporting additional file formats in taglib. But as Paul 
already pointed out, many of them have shortcomings:
- audible, real and m4a lack tag write support
- tag write support in the mpeg4ip/libmp4v2 based mp4 plugin has problems, at 
least with files downloaded from iTunes via SharpMusique (but that's probably 
due to problems in libmp4v2)
These should be clearly documented, if the plugins are made available 
separately.

The code in the metadata plugins (I can at speak for wma, m4a & mp4 and 
audible at least) does not use any functionality from Qt/KDE/Amarok. So it 
should be quite easy to make them work independently. Just the file 
amarok/src/metadata/tplugins.cpp contains KDE specific code, this will 
probably have to be removed and a completely file name based method for 
choosing the right plugin to handle will probably have to be used - just as 
in taglib proper.

The taglib plugins collection could be compiled into a separate library that 
contains a static object that does the registration of the plugins with 
taglib, such that simply linking with (or LD_PRELOADing) the library would 
make the additional file formats available to all taglib based programs.

Martin


On Sat June 24 2006 22:08, Paul Cifarelli wrote:
> ok by me, but I really should add write support for rmff, people would
> expect that if it's a general purpose plugin (of course its useful for
> amarok too, I just never got to it...)
>
> Paul (foreboy)
>
> On Saturday 24 June 2006 2:04 pm, Diego 'Flameeyes' Pettenò wrote:
> > Hi everybody. For the ones of you that I don't annoy from time to time on
> > IRC, I'm the Gentoo packager for Amarok.
> >
> > I was wondering how everybody felt about releasing the TagLib plugins on
> > their own. Let's me explain. I'm working on TagLib bindings for Ruby
> > (RubyTag++[1]), and although I'm mostly waiting now for upstream TagLib
> > to fix a few bugs that I end up discovering on my testsuite, I'd like to
> > able to handle also AAC/M4A files and WMA, mainly because of the second
> > stage of my project ;)
> >
> > Basically after RubyTag++ works decently, I'm going to return to the work
> > on JulTagger, a Korundum(Ruby)-based audio file tagger for KDE.
> >
> > The problem is that as long as the plugins are internal to Amarok code,
> > it's not possible to use them in other software. The first solution would
> > be to take the code as it is, and package it in its own tarball, as eean
> > already suggested. This would work for the Amarok part, but would be a
> > bit un-optimal for other situations. The code would be duplicated once
> > compiled, it will still enlarge compile time for Amarok, and it will be
> > difficult to get them correctly in sync.
> >
> > What I tried to propose (but of course I don't count on), is to have
> > those TagLib plugins in their own repository, with a clean build system
> > (not KDE-based to avoid depending on it and turning away extra projects
> > interested in them, I would say simple plain autotools correctly used or
> > cmake proper), so that they can be used by other projects to complement
> > TagLib itself.
> >
> > If the extra dependency would be a problem for Amarok packaging (although
> > as long as the packagers know how they should work this shouldn't be an
> > issue), it would be possible to have an internal copy of the plugins
> > enabled by default, and a hidden, commented switch to use the external
> > copy of them, so that for instance source-based distribution (like
> > Gentoo, but I would suppose also FreeBSD's ports, and similar) would be
> > able to use the proper extra package.
> >
> > Thoughts, comments? (Please CC me as I'm not subscribed to the list)
> >
> > [1] http://flameeyes.is-a-geek.org/projects#rubytag++
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok