I've done a bit more detailed analysis on how MB's implementing Ratings.
First, an enhancement request - my own personal preference would be to also allow the user to specify for ID3 (and all other file formats) a generic TXXX "Rating" field with 0/20/40/60/80/100, in other words matching MB's current Vorbis/FLAC. This will allow my FLAC files to be played on the PC as normal, and then when converting over to MP3 for export to my portable handheld, the rating tags will carry their data over from the original, just as the other more standard fields do.
MB seems to follow the MM "standard" in that it's using the "no@email" identifier, which is what causes MP3Tag to identify the field as "Rating MM" when the internal value is 40 80 or C4 (196). However I think the four 00 bytes following the significant byte, or perhaps some other departure from MM's scheme is what's causing MP3Tag to display it as a generic POPM ("Populimeter tag") when the internal value is set to 01 or FF (255).
For those thinking that MB is actually switching to a completely different tag structure for 1- and 5- star ratings, that's not true, it's just that MP3Tag is "mapping" the generic ID3-spec POPM tag to "Rating MM" "Rating WINAMP" and "Rating WMP" based on whose scheme the data in the frame is matching. MB just happens to come "close enough" to MM's, but just not for those two values.
Steven, if you believe that you're writing precisely the same POPM strings that the current shipping MM does for all five values (and BTW "zero" is/should be IMO a valid rating in addition to "unrated" = "remove the field"), then I'd suggest posting to the MP3Tag forum asking that they fix their bug and allow files rated by MB to be interpreted correctly.
Otherwise of course bringing your values into precise alignment with MM would of course be helpful to this almost-but-not-quite-hopeless cause of having cross-application Ratings compatibility.
when you rate a song with mediamonkey it also rewrites all the tags according to its naming concentions.
If you use version 2 from the weekly updates topic, it now writes ALBUMARTIST and when rating a song it also doesnt update other tags any more
Thanks for the information. The fact that there aren't true standards in this space does I suppose encourage devs to try to enforce their own ideas, since most users don't know or care about the underlying tech details. And this is somewhat more understandable for apps that claim to be full-fledged "library managers", but definitely IMO not appropriate for players.
I just found out that on my plain-vanilla Windows 7 system, using Windows Explorer's "Properties -> Details" interface to set a rating on an MP3 file causes **ALL tags other than the main six** to get completely wiped out.
Now there's an extreme example of what not to do, what a total cockup, but of course we've come to consider such madness par for the course from the Redmond crowd over the years.
We expect more from the independent professionals. . .
I feel very strongly that any app in this space should have configuration options to **not mess with tags** for users that do know and care about the implementation details of their meta-data.
Finally, I think it's great that you're now using ALBUMARTIST, that's in line with most other mainstream apps, even the Foobar crowd switched over a while ago. Just out of curiosity, why does (did) MB set the ENCODERSETTINGS field, what does that in practice accomplish?
Thanks again for a great application, and I hope to see it continue to improve, you seem very responsive to feedback.
