Popularimeter Tag Fails in 2.48c

that sounds amazing, and i think is the best solution. to be clear, popularimeter [should] always show the raw data. then use scripts for different additional columns to convert that raw data to either a numerical value, or an actual star.

so say 196 is the POPM value. in that case mp3tag would show:

popularimeter = whatever txt string | 196 | #

but another column via a script would map that as


while yet another column via a script would map that as


while yet another column via a script would map that as


why 80? b/c 80 is the value that 196 is translated into on a 0-100 scale, which is how ratings are stored in the MM database. (in other words, all ratings from any format or spec are translated into a 0-100 scale in the MM db)

anyway, your proposal would be the ideal solution imo for mp3tag to follow!!

thank you Florian for your very detailed explanation. i hope you have time to implement this.

just FYI i am currently back at it, trying to nail down what values are written and read for MM for bombs and half stars. i don't anticipate being able to get them to make any more changes but from what i can gather there are some really strange things about how MM reads and interprets some values. however, whatever MM does, and will do going forward, i just want to know b/c it seems development has revived to some degree on winamp, and i am hopeful to get them to implement half stars, and to do it in such a way that is compatible with MM. (i know of no other app that writes values to POPM for bombs/half stars other than MM)

the good news is that at this point, EVERY app i know of writes 1,64,128,196, and 255 for whole stars (for id3 / POPM). that really simplified things.

Because I think the issue is similar in that it involves multiple columns and ratings, I wanted to be sure this was listed here in this thread, b/c it would make sense to fix all of this at once:




I also want to add that all apps I know of, now write the same exact 5 POPM values for the 5 whole stars, which makes ratings handling easier, namely 1, 64, 128, 196, and 255. I got MM to conform to windows explorer's de facto standard. Not sure tho about reading ranges, half stars, etc.

Hello there,

I would like to chip in to this ancient thread because I just spend 3 hours pulling hear off my head over this topic and I thought it deserves a post at least.

I'll reiterate the obvious - the lack of POPULARIMETER tag value when either any of the three player-specific tags are recognised and filled is incredibly confusing! Since the Main Tags website states clearly that POPULARIMETER tag is a direct representation of POPM ID3 tag I thought that this is the only tag I need to display in Mp3tag to understand the format of my ratings. I was wrong - the tag ratings in my music collection were managed by both Music Bee and Dopamine and while the former uses its own Email subtag, the latter uses the subtag of WMP, making me run in circles for the outrageous amount of time and trying to solve the mystery of falsely-reported blank tags and contradictions among all those programs.

From the user's perspective the behaviour of the tags superseding the others is simply unclear and undocumented.

I know this is unlikely to change, given that it hasn't in the last 9 years, but there you go, I had to vent it somewhere...

Thanks for reading!

This topic had its 10-year anniversary recently and I've (again) spent some time thinking about possible solutions.

I've already explained that removing the app-specific fields won't happen because too many users adapted their workflows to those fields. There are even third-party apps that use those field names now, even for FLAC and other formats (this was never my intention and clearly a mistake). This is the explanation that I gave at the time:

I've recently had another idea: since Mp3tag's options dialog now also has an advanced settings page, I could add a dedicated setting to disable the creation of those app-specific fields and display raw POPULARIMETER instead.

Prefer display of POPULARIMETER for ID3v2 rating over app-specific fields.

Before I go into this direction, I wanted to ask y'all if there is still interest for any of that and if there are any objections/problems with this proposed approach, which I'm currently not seeing.

1 Like

I've now added this option with Mp3tag v3.06f as a checkbox

Always display POPULARIMETER values for ID3v2 ratings

at Options → Tags → Advanced for those who prefer the raw POPULARIMETER field over the app-specific convenience fields.

1 Like

Thx Florian... I only am just now seeing this, it was in my junk folder unfortunately! :confounded:

I don't have f yet, will have to find it and try this out...

I am confused tho... why is this exclusive? Meaning, why can't Mp3tag display both the raw popm values, and the 3 app specific ones simultaneously? In other words, if I have a raw popm column, and a winamp column, why can't a result populate in both at the same time?

Thanks again for doing this... I have been considering redoing all my ratings, which is no small task, esp if I implement half stars.

Each tag field in Mp3tag really represents a field in the file's tag. So adding something like you've proposed would require Mp3tag to observe each of the field changes and populate any of the changes to derived fields. This is something I won't implement in Mp3tag.