Popularimeter Tag Fails in 2.48c

thanks for the interest!

the most basic issue, is that %popularimeter% does not work as a column, meaning it does not show any data at all, if the text string ID in a POPM frame is one that mp3tag recognizes, namely:

windows media 9 series (RATING WMP)
rating@winamp.com (RATING WINAMP)
no@email (RATING MM)

the proposed solution is to allow both columns to work simultaneously. so if a file had:

rating@winamp.com|196|0

...in its POPM frame, then it would continue to show "4" in a RATING WINAMP column, but it would simultaneously show "rating@winamp.com|196|0" in a %popularimeter% column, instead of nothing, which it currently shows.

the main point is that I want to see the raw data in the one column, and currently I can't if it has one of those "recognized" txt ID strings.

"popularimeter" is missing from your listing to create columns btw. it used to be there, altho I can't recall if it was in the "information fields" or "extended fields" list.

--

you should also be aware of the following things:

just because the text id might seem to suggest a given program wrote the rating, does not mean a DIFFERENT program didn't write a different rating later. currently, MM will write 252 for 5 stars, but winamp will write 255. if a winamp user re-rates the file, OR gives it a different rating, the MM txt string REMAINS in place, but the value changes. this then completely breaks what you are trying to do in the "app" rating columns. see post 16.

Also, I have gotten the devs at MM to agree to use "255" instead of 252 and "1" instead of 23 going forward, but that change has yet to be released. in addition, winamp will in its next release, allow the user to specify their own email addy, as opposed to the default above, (also my request).

thx for your attention to this issue!

Surely the more basic issue is that %popularimeter% (and POPULARIMETER) does not work anywhere under those conditions - not just in a column definition. Correct?

It was missing as long ago as V2.44:

I too would like %popularimeter% to be restored to full function. And I suggest that until that time, the Help at http://help.mp3tag.de/main_tags.html be amended to show the current reduced function.

afaik, that is correct, and what I was implying, although I agree it is better stated directly.

Thanks.

I posted this a while back:

/t/14581/1

Florian,

Do you still need more feedback than what was given? I see that this wasn't addressed in the recent release.

Let me know if I can clarify anything for you?

my first post in this thread was from July 7 2011.

I will continue to be patient, however I would at least like to know from Florian what his assessment of this bug is? do I have any chance of finding that out?

thanks, -mdw

two years since the last post.

any chance this will be addressed?

the easiest fix is to just allow the popularimeter column to always work and show the raw data no matter what. no reason it can't work simultaneously with the other 'string specific' columns like RATING MM and so on.

I too would like some news on a fix to this.

hi Florian,

this bug has been around for about 7 years now, and is marked awaiting feedback.

here is the best summary:

the most basic issue, is that %popularimeter% does not work as a column, meaning it does not show any data at all, if the text string ID in a POPM frame is one that mp3tag recognizes, namely:

windows media 9 series (RATING WMP)
rating@winamp.com (RATING WINAMP)
no@email (RATING MM)

the proposed solution is to allow both columns to work simultaneously. so if a file had:

rating@winamp.com|196|0

...in its POPM frame, then it would continue to show "4" in a RATING WINAMP column, but it would simultaneously show "rating@winamp.com|196|0" in a %popularimeter% column, instead of nothing, which it currently shows.

the main point is that I want to see the raw data in the one column, and currently I can't if it has one of those "recognized" txt ID strings.

"popularimeter" is missing from your listing to create columns btw. it used to be there, altho I can't recall if it was in the "information fields" or "extended fields" list.

I think that if you have 2 columns, one with the value and field POPULARIMETER and (an empty) one with RATING WINAMP and you have already filled POPULARIMETER and then enter data in the column RATING WINAMP then you get 2 POPM fields as these 2 columns do not know anything about each other. There is (yet) no synchronization mechanism.

The main issue why this has not been addressed in the proposed way, i.e., having both POPULARIMETER with the raw data in Email|Rating|Playcounter and the different app-specific RATING MM, RATING WMP, ...) fields is the following:

Displaying both fields, where in fact one of them is a derived field, i.e., would really break Mp3tag's way of showing what's in the file. You'd end up with a POPULARIMETER field (showing what's inside the tag) and a RATING MM field, which is then only a view on the very same data. Mp3tag is designed to only show one field per real tag data (that's either raw POPULARIMETER or a app-specific rating). Changing that would require per-field level sync mechanisms, where changing one field would also automagically change another — this is a direction I don't want to go into.

In fact, @MrSinatra I was thinking of the way Mp3tag handles rating lately and read some of your posts here and on the Winamp and MediaMonkey forums. My initial goal with adding the app-specific rating fields was to ease the manipulation of them and to provide means to display something star-alike without having to use endless scripting that splits up the POPULARIMETER values. Those fields were added when MediaMonkey used completely different values than the other apps (you've analyzed this thoroughly).

I now think that adding those app-specific was a mistake — which is unfortunately not so easy to revert. My dream-solution is to remove the different app-specific RATING MM, RATING WMP, ... fields and to have Mp3tag show the raw data (POPULARIMETER, RATING, RATE, ...). To ease displaying this data, instead of having dedicated fields I can imagine having a scripting function, e.g., $rating(%field%) that converts the raw value in a star-like representation.

2 Likes

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

4

while yet another column via a script would map that as

****

while yet another column via a script would map that as

80

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:

https://community.mp3tag.de/t/no-support-for-reading-windows-explorer-ratings-in-m4a-mp4/15671

Thx.

EDIT:

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.