Popularimeter Tag Fails in 2.48c

I appreciate the convenience of the new extended field %rating winamp% in v. 2.48c. However, there is an unfortunate side-effect: all of my %popularimeter% and POPULARIMETER references have stopped working. By that I mean that both my tag panel field and my column script that uses this field show nothing.

It now appears that only ratings from WMP, MM, and Winamp can be shown or edited in Mp3tag. In my opinion, this is a step backward. Before, it was possible to show and edit raw POPM tags from any player. Now ratings are restricted to three players. I hope that a way can be found to restore the old popularimeter field and still keep the new Winamp field.

Thank you, Florian, for all the hard work that has gone into this great program!

Only popularimeter fields with certain email identifiers stop working because they get replaced by the more user friendly RATING XYZ fields.
I don't see a problem.

You are correct (as usual), and I now understand that it is still possible to use fields with other identifiers. I had not understood how that works. It is good news for me because it means that a single column script can display all POPM ratings.

Doug Mackie

maybe i'm a dunce, but i do see a problem, (using 2.49).

i am a big winamp user. i am the one who pushed them to add writing ratings to files, which they did.

as far as i know, they use POPM for id3, and RATING for vorbis. mp4/m4a's don't support "rate" atoms yet.

last time i checked in mp3tag, you used the popularimeter frame (POPM) to see what was in the field. that seemingly no longer works. if i check "extended tags" i don't see popularimeter anymore. i see RATING WINAMP and goofy values of 0-5 which DO NOT represent the literal data in the tags.

so if the real value is:


which is correct by id3/POPM spec, mp3tag just uses:


which is just the amount of "stars" in winamp.


i haven't checked vorbis yet, but 0-100 is used to make it compatible with MM and others, and to allow for granularity.

i want to see WHATS REALLY IN MY TAGS, not an interpretation of that which i get from the app anyway!

this has all been made ugly/compounded by some recent winamp bugs:




if i am missing the obvious, please enlighten me!

Hello Mr S,

Here is my understanding of why Mp3tag shows the number of stars for certain players.

There is no accepted standard or convention for the numerical values within the 0 to 255 rating range, nor is there a standard for the allowed number of rating stars. Some players even allow half stars. Such variants create a problem when Mp3Tag attempts to display a rating value because no single display formula can accurately show the number of stars intended by the player. In addition, editing raw values can be confusing and prone to errors for users who do not understand these variations.

Therefore, Mp3tag added special "extended" rating fields for a few popular players. These fields use the e-mail signature in the POPM tag to identify the player that wrote the rating and to return a number corresponding to the number of stars as shown within that player. Originally, there were just two such rating fields, for Windows Media Player and Media Monkey. Mp3tag v. 2.48 added one for Winamp. As you found, as of v. 2.49 raw POPM data for those players (only) no longer displays.

However, when you rate and save a file in Mp3tag by using the new Winamp rating field, that number is correctly saved as a Winamp POPM value and my tests show that the file does show the correct number of stars when played in Winamp 5.62. So, with Winamp files, I no longer see a need to work with the raw POPM data. And, as far as I see, the popularimeter tag works just as before in Mp3tag for all players other than the three mentioned above.

I prefer to show ratings as "stars" in column view in Mp3tag, using a script that I posted on April 12th. Scroll down to the eighth post in the thread for the current version of the script:
Column Script to Show All POPM Ratings as "Stars"

Doug Mackie, aka Retroman in the Winamp forums

hey Retroman,

thx for responding. but i can not fully express how TERRIBLE i think this is, and i hope FLORIAN will respond!

let me start out by saying i think there's a simple fix and our positions while opposed, are not mutually exclusive, (nor personal obviously).

the whole point, or philosophy imo, of mp3tag should be to show you WHATS REALLY IN YOUR TAGS, not some frigged up interpretation of it. it should also allow a user to DIRECTLY EDIT the values in the tags.

case in point: what if i want to add a value to the end of the POPM value, such as "7" in:


...now i can't. (7 in this case represents the playcount stat placeholder as per id3 spec)

what if i want to mass change the email address? now i can't. etc etc... you could cite tons of reasons why you want access to the raw data! but just being able to SEE the raw data is imo, justification enough!

so here is my proposed workaround:

keep RATING WINAMP exactly as it is. imo, its fine for the folks who like it that way, (although they already get EXACTLY that info from winamp anyway).

...THEN reinstate "popularimeter" back to returning the RAW DATA! you could have both simultaneously, and why not????

i just can't get over this nonsenical change. i would never use RATING WINAMP, but i don't begrudge those who do. so why should POPULARIMETER be FORCED to NOT show the raw data?!?!??! what purpose does that serve? why begrudge me the whole reason i use mp3tag to begin with?

(i say that in general, not specifically to you)

mp3tag is purposely choosing to show NOTHING for the POPM frame [popularimeter] EVEN THOUGH the data is there. that literally makes no sense at all!

see below:

i don't want an interpretation, i want the raw data. thats why i'm using mp3tag to begin with.

indeed, even when using the appropriate "popularimeter" field; this is exactly the problem.

again, exactly the problem. just b/c you see no need, doesn't mean there is no need.

the solution is there, for both of us. RATING WINAMP for interpretations, POPULARIMETER for raw.

cool script, but really of no interest to me.

again, thx for your reply, and i hope you understand nothing personal, just vigorously arguing for my POV.

You make some good points, but I'm not entirely persuaded.

You can still paste the entire string into the POPM field in the tag panel and save the rating. I just tried that and it works fine. It then shows up in the Mp3Tag Winamp rating field as "5" while the POPM field shows blank.

You can still batch edit ratings by selecting files and pasting a new rating into the POPM field as above, but you can't change the e-mail address separately from the rest of the string. However, if you edit the e-mail address then Winamp will not recognize the rating (it shows as "no rating"). So I don't see the point.

Good idea, but only Florian can tell us why that was not done. The odd thing is that in v. 2.48 the raw Winamp string did appear in column view for the %popularimeter% field. In effect, that gave us the best of both worlds. I don't know why that column view was removed but I agree that it should be restored. It was very helpful when I was developing my column view script for ratings.

Doug Mackie

thx. but honestly, no one should have to persuade anyone about this. for example, i'm not persuaded that showing stars or 0-5 for RATING WINAMP in mp3tag makes any sense at all, since you can already do that in winamp, but i don't begrudge you the ability. i mean, if i'm looking in mp3tag in the first place, i'm looking for more than what a typical player app can do/show. i want to see the man behind the curtain, not the great OZ!

likewise, whether you think i should have the ability or not shouldn't matter, b/c i think i should have it. i tend to think you know this tho.

i don't want mp3tag rounding up or down my RG numbers either for example. nor do i want it to truncate my year tags to just 4 characters, show me exactly whats in the tag! i mean, where does this end?

first of all, that doesn't fix the DISPLAY issue. i can't see whats currently there!

secondly, i don't want to type whole strings in manually in another (or any) column, thats an ugly kludge.

thirdly, i can't mass do things like that in a way thats sensible.

first off, thats not true. winamp WILL show as stars things rated by other apps, as long as they are first scanned into the ML. tested it with 5.62 myself. see here:


secondly, mp3tag can do advanced things. this makes that harder. and its just an example to illustrate why 2.49 is doing it wrong.

right, and so we agree then, there is no reason to suppress the raw data from popularimeter, or make me use two columns when i only need one.

I think MrSinatra has shown that there is a problem and has described it very well.

I want to add my urgent request to have the popularimeter fields with certain email identifiers reinstated to display, use and edit the raw data.

I understand the desire to be more user friendly but I think it is a mistake to compromise the generality and adaptability of Mp3tag by removing things that more knowledgeable users find valuable. Some users would rather manipulate the raw tag information to serve their own needs instead of having it interpreted for them by the application. At the same time, keep the new RATING XYZ fields for those who find them useful.


Could someone explain to me why this is not simply a bug?

https://docs.mp3tag.de/mapping says

This description is for only ID3v2 tags. The playcounter is an optional value.

Syntax: Email|Rating|Playcounter
Example: Mp3tag|255|5
Note: The Rating is an integer between 0 (worst) and 255 (best).

so surely %popularimeter% is supposed to work.

i think its clear that this is a bug.

i have no beef with Florian "dumbing down" the app to do "RATING WINAMP" with 0-5 values, etc, for those who find that useful, but that ABSOLUTELY should not then cause the "POPULARIMETER" columns/values to STOP working!!!

in other words, feel free to ADD the app specific functions, but for the love of god don't depricate / remove the way it should work by spec!

RATING WINAMP is USELESS to me, totally useless. worse, i can't use mp3tag to even implement a workaround to get POPULARIMETER back the way it was. the whole point of mp3tag, imo, is to show you whats actually in your tags, not to interpret your tags for you.

i don't want to get too histrionic, but please, PLEASE, restore proper functionality. thanks.

QUOTE (chrisjj @ Jul 12 2011, 02:59) <{POST_SNAPBACK}>
Could someone explain to me why this is not simply a bug?

https://docs.mp3tag.de/mapping says

This description is for only ID3v2 tags. The playcounter is an optional value.

Syntax: Email|Rating|Playcounter
Example: Mp3tag|255|5
Note: The Rating is an integer between 0 (worst) and 255 (best).

so surely %popularimeter% is supposed to work.


can you PLEASE allow %popularimeter% to work SIMULTANEOUSLY with ratings in files by winamp, wmp, or whatever else? (see previous posts)


thanks!!! (love mp3tag otherwise!)

I second that MrSinatra, can't see any logical reason why the winamp rating function needed to REPLACE viewing the raw data

Thanks for the confirmation.

This leaves me mystified by the lack of any response from Florian during the year since the original report.

having just gotten winamp to fix the way they read ratings, i have yet another reason for Florian to please implement this request:

the way an app writes a rating varies, the syntax by spec is:

email addy | 0-255 rating value | playcount #

but what happens in reality is that some apps will overwrite an existing email addy (or similar text string ID) when writing the rating value, (bad behavior, i'm looking at you WMP and windows explorer) while some others DON'T, (good behavior, like winamp).

this means that you could have situations where the default email addy, like the one MM uses, is properly left in place by an app like winamp, yet has an UNEXPECTED value. for 5 stars, MM writes 252, but winamp writes 255.

its yet another reason why %popularimeter% should be left to show the raw data, if a user uses that column, irrespective of what the "app specific" rating columns do.

in order to get winamp to fix its issue with the way it READS ratings, i had to use a different program to analyze files. i could not get the raw data out of mp3tag.


ok, now i am finding bugs with the way Florian WANTS it to work.

check out this file:
dead link

the POPM frame for it is:


ergo it SHOULD be in the RATING MM column. it is NOT.

it shows up in the popularimeter one instead. i have a couple other MM rated files, and they seemingly have the same syntax and do show up in the RATING MM column.

so again, this just goes to show that the %popularimeter% column should never be deactivated just b/c mp3tag sees a given text string. and apparently, app rating columns don't always work even when the strings are present!


i suspect the reason its not working, is the 255 value as opposed to 252. further reason to not assume things based on the text string. the file was rated first by MM, then later by another app that appropriately does not overwrite an existing text string, but uses a # value MM does not.


is it forbidden to post links to example files at mediafire or elsewhere?

if so, i apologize, just wanted to show the issue. the link isn't dead tho afaik.

Well I couldn't download from this link and links to complete audio files will never stay long here for obvious reasons.
It would be best if you just posted the first ~50kb of the file since ID3v2 tags are at the beginning of the file. (if there's an embedded cover you might need a larger part)

unfortunately i have no idea how to do that.

the mystery is solved tho, mediafire now seemingly looks for things it thinks are copyrighted and then won't let you share them.

i posted at 4share instead:

it does require a login, but its free, and you could use FB to login, etc...

however, all you really need to do is enter the value i posted above for POPM into any mp3, and you will see one buggy permutation. the easy fix is to just reinstate %popularimeter% so that its "always on," regardless of what the app specific ratings columns are or aren't doing.

Please only links with a direct download.
But as you said the sample is not needed. The issue can be easily reproduced.