For some of my mp3s with ID3v2.3 tags Picard is not properly coping the POPM frame.
The original value is:
Popularimeter: MusicBee Rating=64 Count=0
and the value after saving with Picard becomes:
Popularimeter: MusicBee Rating=51 Count=0
I have tried all the combinations of options settings:
Metadata > Ratings > Enable track ratings => tried on/off
Tags > Clear existing tags => tried on/off
Tags > Preserve this tags: _rating,POPM,POPULARIMETER,~rating,rating
If I set Clear to on and the Preserve tags the value is converted from 64 to 51. My take is that the value should be copied untouched.
Is this a bug or something I’m not setting properly?
Can I copy over the POPM value with for example an script?
The problem is that Picard has it’s very own interpretation of how to map the star values to a POPM rating, and that’s not compatible with MusicBee.
I assume you have set the “rating e-mail” in Picard to “MusicBee”, so Picard will read this tag, convert the value to a 5 star rating (according to it’s very own definition) and when writing it back again converts this to the POPM rating value.
The only workaround currently is not to configure Picard to use the “MusicBee” POPM value (by setting the rating e-mail to something else).
What I want to have in Picard is actually some kind of presets, where you can select predefined typical mappings to choose with which player you want compatibility. Maybe even allow writing multiple POPM tags.
Thanks for your reply. I get that Picard have a different way to do the rating. Every player does. No problem with that. I’ve been looking at the id3.py file and looking at the formulas. I understand how 64 gets converted to 51.
But in my case I’m asking Picard to leave alone the ~rating by listing it in the Preserve option. Still Picard just goes and removes it from the saved file instead of copying it over. In this case there is no need to fiddle with emails
To me that seems like a bug.
I’ll investigate if it can be overcome with scripting.
Picard should actually not read or write MusicBees POPM tag unless it is configured to do so. Could you check your settings in Options > Metadata > Ratings?
Ok, let’s forget about the POPM tag coming from MusicBee, Windows Media Player, Media Monkey or whatever. right? That is not important.
POPM frame is part of the id3v2 specification, so it is not any special frame that should be dealt with. What is not in the specification is the value it should have. I don’t agree with the statement that Picard should not read or write the POPM tag. What Picard should not do is to perform any interpretation/parsing of the value of POPM unless I asked it to do it. But of course, if I ask in the setting to Picard preserve the ~rating (which is how the POPM frame is named in Picard), it should read from the original mp3 and write it to the new mp3 in order to copy the value as it is (without modifying it).
Having said that, in Options > Metadata > Ratings I have disable the track ratings. Because I understand that this setting is telling Picard to parse the POPM tag. Or am I wrong here?
Any way, as I said in my original post I’ve tried all combinations, so I don’t know what else I can check in Options > Metadata > Ratings.
TL;DR: Got to Options > Metadata > Rating and make sure you have not set the e-mail field to “MusicBee”, then Picard will ignore the MusicBee rating and not change it.
Actually Picard does not do anything to the POPM tags unless you have configured it to do so by setting the “email” field in Options > Metadata > Rating. Even if you insist it does not matter I take a bet that you have set it to “MusicBee”, otherwise Picard would not read this tag nor write back any modified value. Please change this and Picard will leave the MusicBee rating alone. See below for some background.
Actually it is not. ~rating is a scripting variable holding a value between 0 and 5, with the primary goal to hold the 5 star rating from MusicBrainz.org and provide a way to write this to files. It is not a representation of the POPM tag like the other tags, that’s also why you don’t see this in the metadata table for a file and you also can’t use this parameter to preserve the POPM tags. But as I said above, this does not really matter as Picard will not touch this tag unless configured specifically. The truth is that Picard does not have full support for POPM tags and ignores it for the most part.
Now for the background: In ID3 you can have multiple POPM tags, where each POPM tag is identified by an “email” field. Actually this does not need to be an e-mail, but is rather an identifier for who or what tool the rating applies. The original idea was for sure that there could be individual ratings for the same file by different users. But in reality tools just set their own fixed strings. E.g. Windows uses “Windows Media Player 9 Series”, MusicBee uses “MusicBee”.
E.g. you could have a file with three POPM values:
email
rating
MusicBee
196
Windows Media Player 9 Series
196
custom
204
By default Picard will neither read those values nor modify any of them. If you configure the e-mail field in Options > Metadata > Rating to e.g. “MusicBee” Picard will load the MusicBee field with a value of 196, convert this according to its own rules (and not MusicBees) to a value between 0 and 5 and store this in ~rating. On saving it will again take the value in ~rating, convert this back to a value between 0 and 255 and save this to the POPM field with email MusicBee.
What’s missing in Picard is full support for reading and writing arbitrary POPM tags. E.g. for proper support Picard needs to make all the POPM rating values available, e.g. you would have a rating:MusicBee tag with a value of 196 and rating:custom tag with a value of 204. Also as I mentioned in my first post even for writing the MB rating we need support for different mappings used as used by different players.
Thanks a lot for the explanation. Finally, it is clear now. So basically ~rating does not map to POPM tag and there is no way to specify POPM as a tag to preserve if the Clear existing tags setting is enable as it was my case. Leaving the email field blank indeed avoids Picard to convert the field to its own representation.
So in my case what can do is to uncheck the Clear tag settings. I miss that functionality but I prefer not to loose my ratings.