ALBUMARTIST via tag.properties() question

[Rob Arnold]

Thank you.
So turns out that if you get the property map like I did in the sample code I had in my msg,
TagLib::FileRef f(filename, false);
TagLib::Tag *t=f.tag();
auto props = t->properties();

that the property map isn’t completely filled out - just has the basic stuff.
But if you get the property map as:
TagLib::FileRef f(filename, false);
auto props = f.file()->properties();

Then the property list is fully populated with all tags as well as the unsupporrtedData() filled in.  Just what I need.  I discovered this after (belatedly) looking at the example code.  I don’t get why the properties from the Tag shouldn’t have worked though - and the FileRef file() member is documented as being something you probably shouldn’t use, so surprises me.  But it works and its in the examples, so I’m running with it :)


> On May 9, 2015, at 3:15 AM, Michael Helmling <michaelhelmling at posteo.de> wrote:
> 
> Hi Rob,
> 
> you're absolutely correct about the purpose and functionality of the
> properties() interface, and it should work for all tag types that
> implement it (containing ID3v2, APE and Xiph comments). It does not for
> ID3v1, however - have you checked that your mp3 files are using ID3v2?
> (they might have both; in that case: make sure that ALBUMARTIST exists
> not only in the v1-Tag).
> Otherwise, I don't have an explanation. Please check that you are using
> a recent version of taglib. If the problem remains, perhaps you can
> upload one example file so that we can try to reproduce your issues.
> 
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20150509/8f4d7e35/attachment.sig>