helmling at mathematik.uni-kl.de
Wed Aug 17 12:17:29 UTC 2011
Am 17.08.2011 10:51, schrieb Lukáš Lalinský:
> On Wed, Aug 17, 2011 at 10:05 AM, Michael Helmling
> <helmling at mathematik.uni-kl.de> wrote:
>> In case you are interested, I am working on a taglib wrapper which I call
>> 'UTagLib' (U for unified) which realizes exactly that:
>> It aims to provide a general tag interface via a map string -> list of
>> strings (to support multiple values for the same tag, as most formats do).
>> The approach is inspired by the python library 'mutagen' which does things
>> Background routines try their best to realize this unified approach in
>> various formats. FLAC and Ogg are simple since they handle tags in this way,
>> ID3 support is a bit more involved because tag names not specified are
>> mapped to TXXX frames etc.
>> The wrapper is in a very early stage and not well tested yet, however it
>> seems to work for FLAC, Ogg and MP3 which are the only formats I use.
> I had a similar idea, but the implementation was a little different.
> There would be an generic tag container (string->stringlist) that
> would be completely independent of the file format. Every file format
> implementation would then have two functions to import and export the
> internal tags into the generic container. For now these functions
> would be non-virtual and you would have to dynamic_cast the pointers
> to get the right functionality, but in TagLib 2 we would simply make
> them virtual and everything would just work.
Do I get this right: Your idea is to create a suitable container class
and then two functions import: void->container and export:
container->void to each Taglib::FORMAT::File class, doing all the
conversions? Because if so, I think this is almost the same as I do: my
wrapper class just holds a private Taglib File object; on read, the tags
are converted to a string->stringlist map, and on write, that map is
translated to tags of the specific metadata format. These functions
should pretty much resemble your export/import functions.
> What do you think about this approach? Would you be interested to work
> on this as part of TagLib, not a separate library?
Sure, I'd love to see this functionality directly within taglib. My
wrapper was never meant to be a long-term solution anyway but rather a
"quick & dirty" method to have something to work with until a better
solution is available.
The main problem I see is the lack of consistent rules for how to
translate the tag names for the various metadata formats outside there;
in my program I have made lots of decisions which certainly are not
suitable for everyone, so perhaps the API user needs to be given some
finer control over the im/export behaviour for the various formats (the
handling of the COMMENT tag, mentioned in my readme file, illustrates
More information about the taglib-devel