tags..

[Michael Helmling]

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:
>> https://github.com/supermihi/UTagLib
>>
>> 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
>> similarly.
>> 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 
the problem).

Michael