<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Good that you found out by yourself!
      ;-) The explanation for your observation is that currently neither
      Tag::properties() nor File::properties() are virtual due to binary
      compatibility (they will be in taglib-2.0). The implementation of
      File::properties() does some manual type-checking for calling the
      appropriate subclass method, which is not the case in
      Tag::properties() - it has either been overlooked or simply been
      considered unnecessary.<br>
      <br>
      Michael<br>
      <br>
      Am 09.05.2015 um 21:06 schrieb Rob Arnold:<br>
    </div>
    <blockquote cite="mid:992820C1-60C1-47B7-BB45-77BF7D369610@loci.net"
      type="cite">
      <pre wrap="">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 :)


</pre>
      <blockquote type="cite">
        <pre wrap="">On May 9, 2015, at 3:15 AM, Michael Helmling <a class="moz-txt-link-rfc2396E" href="mailto:michaelhelmling@posteo.de"><michaelhelmling@posteo.de></a> 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
</pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
taglib-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/taglib-devel">https://mail.kde.org/mailman/listinfo/taglib-devel</a>
</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>