ALBUMARTIST via tag.properties() question

[Michael Helmling]

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
> Hi, I’m trying to access the album artist tag via the property map from the generic Tag properties() method, but it and a few other tags (disc number for example) aren’t showing up in the map.  Am I misunderstanding the purpose of the property map?  
>
> I thought the simple generic interface was limited to a very few common tags like artist, title, etc. but that the property map would get filled out with all recognized properties, such as the ones described on it’s doc page linked below.  I know that album artist is implemented by several different actual tag types in the various file formats, but thought that they got mapped to the ALBUMARTIST key.
>
> Based on the API docs at http://taglib.github.io/api/classTagLib_1_1PropertyMap.html , I’m using “ALBUMARTIST” as the key, but even when I just iterate through the map, I don’t see it, just ALBUM, ARTIST, DATE, TITLE, GENRE, and TRACKNUMBER.  I’ve checked this with mp3, Apple Lossless (in a m4a container, as usual), AAC (m4a), and FLAC.  I’ve checked the tags on the files with mp3tag which reads and sets them fine
>
> I’m getting the Tag object from a TagLib::FileRef
>
> When scanning the mailing list archives, I found a short thread from late Sept 2014: Is there a way to get the specific Tag implementation from the generic one? ( https://mail.kde.org/pipermail/taglib-devel/2014-September/002702.html )
>
> But it didn’t really show a resolution.  To answer the question posed though, I’ve tried all the above file types, and am not seeing the properties() property map filled out completely, nor is there anything in the unsupportedData() list (where I thought it might all be shoved, if not put into the map)
>
> Here’s the code I was using to dump the properties.  It’s from an Objective-C++ file, if you’re wondering about the NSLog and [url fileSystemRepresentation] bits.  Try to ignore those :)  
>
>    
>     TagLib::FileRef f([url fileSystemRepresentation], false);
>     TagLib::Tag *t = f.tag();
> // <snip>    
>         auto props = t->properties();
>         NSLog(@"Remap Check for %s", [url fileSystemRepresentation]);
>         for (auto p : props) {
>             NSLog(@"Property: %s  => %s", p.first.toCString(true), p.second.toString().toCString(true) );
>         }
>         auto unsupportedData = props.unsupportedData();
>         for (auto s : unsupportedData) {
>             NSLog(@"Unsupported data item: \"%s\"", s.toCString(true));
>         }
>
> I wrote the property dump code to figure out why I was never seeing the below be anything other than an empty StringList.
> auto albumArtistList = props[“ALBUMARTIST”];
>
>
> Thanks for any pointers provided.  Taglib has made things a lot easier for me.  I hope it can handle this part easily too.
>
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel


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