Any appetite for a 'normalisation' layer over non-std tags?

Adam Szmigin adam.szmigin at
Mon Apr 10 22:54:32 UTC 2017

Hi Michael (and others),

On 10/04/17 08:36, michaelhelmling at 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
   PropertyMap map;
   if(!(year() == 0))
   if(!(track() == 0))
   return map;

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?

Many thanks,

Adam Szmigin

More information about the taglib-devel mailing list