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

[Michael Helmling]

Hi Adam,

yes indeed, you should use File::properties() instead of
Tag::properties() for now because of the non-virtuality of
Tag::properties() (which has binary compatibility reasons).

Still, there is no need for a "normalization" layer because it is
already there. Note that FileRef::create() does *not* give you the same
as calling the FileRef() constructor. In your example, instead of

TagLib::FileRef fr{path.c_str()};
for (auto &prop_kvp : fr.tag()->properties()) {
  ...

use

auto /* TagLib::File */ f = TagLib::FileRef::create(path.c_str());
for (auto &prop_kvp : f->properties()) {
  ...


and you should see all the properties in the file.

Michael


On 11.04.2017 00:54, Adam Szmigin wrote:
> 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
> {
>   PropertyMap map;
>   if(!(title().isEmpty()))
>     map["TITLE"].append(title());
>   if(!(artist().isEmpty()))
>     map["ARTIST"].append(artist());
>   if(!(album().isEmpty()))
>     map["ALBUM"].append(album());
>   if(!(comment().isEmpty()))
>     map["COMMENT"].append(comment());
>   if(!(genre().isEmpty()))
>     map["GENRE"].append(genre());
>   if(!(year() == 0))
>     map["DATE"].append(String::number(year()));
>   if(!(track() == 0))
>     map["TRACKNUMBER"].append(String::number(track()));
>   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,
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20170411/84038903/attachment.sig>