Any appetite for a 'normalisation' layer over non-std tags?
adam.szmigin at xsco.net
Mon Apr 10 22:54:32 UTC 2017
Hi Michael (and others),
On 10/04/17 08:36, michaelhelmling at posteo.de wrote:
> Dear Adam,
> sorry, I've made a few typos in the haste. :-) The following should work:
> auto file = FileRef::create("/path/to/file.mp3"); // create() gives you
> a full-featured File object
> auto props = file.tag().properties();
> for (auto &composer : props["COMPOSER"])
> std::cout << "composer: " << composer << std::endl;
Please ignore my previous post.. I think I found the reason. I noticed
that the properties() method of TagLib::Tag is *not* marked virtual, so
calling Tag::properties() for any polymorphic sub-class of Tag will
always give only the 'standard' 7:
PropertyMap Tag::properties() const
if(!(year() == 0))
if(!(track() == 0))
But if I call File::properties() there is a dispatch via dynamic_cast to
the relevant derived class's 'hidden' properties() methods, which has
the full range of fields.
So it looks like this is deliberate behaviour and I have to go to
File::properties() if I want the 'exotic' fields.
Incidentally, I notice that Tag::properties() has become virtual in the
taglib2 branch, and File::properties() no longer does all that crazy
dynamic casting. So maybe all this is being addressed already in taglib2?
This brings me back to my original question as to whether there is any
appetite for normalising the more "exotic" tags in TagLib - presumably
via an enhancement to the base Tag::properties() and/or new
Tag::composer() etc. methods? Is this within scope for taglib2?
More information about the taglib-devel