Value of ID3v2 POPM field and MM's Rating

by **MrSinatra** » Wed Oct 31, 2018 10:58 am

Lowlander wrote: ↑Wed Oct 24, 2018 1:17 pm No, because it actually depends on the range to work.

I've glanced back it seems you're just trying to make it seem pretty (in order (I know the feeling)). How would changing the reading values change things? Other than breaking the Addon I don't see any value to this. Are you having Ratings from other software/Apps incorrectly read by MediaMonkey (mapped to a full star when it should be a half star)?

If half stars aren't supported either use an App that does or don't use half stars in MediaMonkey as you're likely always gonna get it translated to a full star value no matter what MediaMonkey writes. You mention WinAmp and MP3Tag, but don't seem to discuss any specific issue. If there are specific compatibility issues with other (popular) software/apps then please discuss them as that would be a good reason to change things.

how am i supposed to debate someone who admits to not reading my posts, ignores my questions, and dismisses my concerns as trivial and aesthetic, even though that's patently false, as they are logical and concerning compatibility?

lets not get ahead of ourselves, the most pertinent question at this point is do any other apps support either writing or reading (or both), of either bombs or half stars (or both)? if so which apps, and how? twonky? dbpoweramp? foobar? etc...? how in or out of line are they with MMs implementation?

i want to know what the state of the marketplace is, to determine if a de facto standard exists, and what the level of compatibility is. this kind of comparison is what resulted in MM changing 5 stars to 255, and 1 star to 1, instead of 252 and 23 (or whatever the previous values were MM used). its a useful exercise to know these things, so that as many apps as possible can play nice with each other.

by **Lowlander** » Wed Oct 24, 2018 1:17 pm

No, because it actually depends on the range to work.

I've glanced back it seems you're just trying to make it seem pretty (in order (I know the feeling)). How would changing the reading values change things? Other than breaking the Addon I don't see any value to this. Are you having Ratings from other software/Apps incorrectly read by MediaMonkey (mapped to a full star when it should be a half star)?

If half stars aren't supported either use an App that does or don't use half stars in MediaMonkey as you're likely always gonna get it translated to a full star value no matter what MediaMonkey writes. You mention WinAmp and MP3Tag, but don't seem to discuss any specific issue. If there are specific compatibility issues with other (popular) software/apps then please discuss them as that would be a good reason to change things.

by **MrSinatra** » Wed Oct 24, 2018 12:05 pm

Lowlander wrote: ↑Wed Oct 24, 2018 11:08 am That would break some scripts as mentioned previously, they depend on the range value for each star value.

scripts can be rewritten. i think sensible handling and universal compatibility is more important than niche legacy support. i can't ask winamp for example, to copy the current implementation as is, its too wacky. jmho.

how many people do u think even use these scripts? it sounded to me like there was only one that still works, and not all that commonly used.

and how many people have files with POPM values outside of what MM currently actually writes?

by **Lowlander** » Wed Oct 24, 2018 11:08 am

That would break some scripts as mentioned previously, they depend on the range value for each star value.

by **MrSinatra** » Wed Oct 24, 2018 8:56 am

hi guys,

thx very much for both your responses.

i am taking them to mean that MM still writes those exact raw numbers for those values/stars.

can you please point me to any other apps that actually write and or display bombs/half stars based on in tag values? i am trying to establish if there is any de facto standard out there, and how strong it is. all the apps i know about, don't write half stars, and read them such that they get mapped to full stars, (up or down depending on each apps behavior).

i understand that there probably is no appetite to make any more changes to what is written by MM, so i won't advocate any changes. however, i am curious about how MM reads/interprets values? specifically a seemingly non intuitive, non linear logic to such display.

aax said:

Instead of the linear increase in the number of stars as the rating values go up, the stars displayed are all mixed up:
bomb, 1★, bomb, 0.5★, 1★, 1.5★, 0.5★, 1★, 1.5★, 2★, 1.5★, 2★, 2.5★, 3★, 2.5★, 3★, 3.5★, 4★, 4.5★, 5★

Here's what MediaMonkey 4.1.2.1706 displays, writes, and reads:
Code: Select all
stars  writes (reads)

0   = 0   (0, 2-8) -bomb
0.5 = 13  (9-18, 30-39)
1   = 1   (1, 19-28, 40-49)
1.5 = 54  (29, 50-59, 70-90)
2   = 64  (60-69, 91-113)
2.5 = 118 (114-123, 134-141)
3   = 128 (124-133, 142-167)
3.5 = 186 (168-191)
4   = 196 (192-218)
4.5 = 242 (219-247)
5   = 255 (248-255)

so is the above still accurate? b/c if it is, i agree with aax it is problematic. the problem is well illustrated by his star chart, leading off his quote. there is no rhyme or reason to it, and can potentially confuse users by displaying odd, conflated results, as aaf showed.

again, there is no way to cleanly get around MS' mangling of the low end of the scale, but having said that, here is the reading i would propose, (which respects your current written values as is) b/c it makes clear to the user if a value is exactly equal to a bomb or whole star value; or if its a gradient above or below a given whole star value.

proposed reading:

Code: Select all

stars  writes (reads)

0   = 0   (0) -bomb
0.5 = 13  (2-53)
1   = 1   (1)
1.5 = 54  (54-63)
2   = 64  (64)
2.5 = 118 (65-127)
3   = 128 (128)
3.5 = 186 (129-195)
4   = 196 (196)
4.5 = 242 (197-254)
5   = 255 (255)

this is much more sensible, and linear. again, the low end of the scale can't be helped bc of MS, but other than that, this reading scale lets the user know that if they have anything displayed OTHER than a bomb or whole star, the POPM raw value is not exactly equal to 0,1,64,128,196, or 255. also, while they won't know the exact raw number value (for values other than bombs and whole stars), they will know what range it falls in, b/c it rounds up. (in other words, a user would know that for example 3.5 stars has to be a value above 128, but below 196. that logic is completely missing in the current implementation).

i am trying to figure this out so MM, winamp, mp3tag, etc all have compatible, if not exact handling. is there a good reason why my proposed reading ranges can't or shouldn't work?

my only caveat to my proposal is i would like to know about other apps first, so i could compare to what they have already established as de facto standard behavior.

thanks guys!

by **Peke** » Mon Oct 22, 2018 9:18 am

To add to above, as Jiri pointed we decided to to use this table as over the years analyzing that table was the most compatible one with many other apps supporting Half star system or not.

by **jiri** » Mon Oct 22, 2018 4:56 am

i am just curious as to how the POPM values were "picked" ...meaning why is 13 a half star, or 242 4.5 stars?

I'd say that they weren't really 'picked', but rather they happen to be mapped this way because of the way several intervals of the 0-100 range are mapped to intervals in the 0-255 range (per the source code above). It possibly isn't the best mapping, it's just the way we chose few years ago...

Jiri

by **MrSinatra** » Fri Oct 19, 2018 3:39 pm

hi Jiri,

thanks for posting the code. i kind of understand it, but i'd be one terrible dev, ha.

the part tho that i def didn't twig before, but i get now, is that MM maps all values from id3/POPM or any given format / spec into a single ultimate 0-100 scale in a separate MM db. thats very good to know and explains to me why some other posters in this thread were saying what they were saying, (mostly about breaking scripts, etc).

so i am asking things b/c ultimately if i know what MM does, i can try to get winamp to be compatible, and try for better handling in mp3tag as well.

i believe this is correct, please tell me if i got any of this wrong:

MM writes the following POPM values:

Code: Select all

  0 = Bomb
  1 = 1 whole star
 13 = 0.5 star
 54 = 1.5 stars
 64 = 2 whole stars
118 = 2.5 stars
128 = 3 whole stars
186 = 3.5 stars
196 = 4 whole stars
242 = 4.5 stars
255 = 5 whole stars

i am just curious as to how the POPM values were "picked" ...meaning why is 13 a half star, or 242 4.5 stars? in other words, why were those specific raw number values chosen to be written for those half stars? (i know why the whole star values are what they are, universal compatibility)

i have more questions but i just want to get confirmation and answers on this first. thanks so much for your time and indulging me!

by **jiri** » Fri Oct 19, 2018 2:04 am

This is the current write algorithm:

Code: Select all

        if value<=0 then
          mp3value := 0
        else
        if value<=25 then
        begin
          if value = 20 then
            mp3value := 1  // Special value, so that 1 star is written as POPM=1 (to be compatible with many other apps, like WMP, WinAmp, etc.)
          else
            mp3value := value + 3;
        end
        else
        if value<=45 then
          mp3value := value + 24
        else
        if value<=65 then
          mp3value := value + 68
        else
        if value<=85 then
          mp3value := value + 116
        else
        begin
          if value = 100 then
            mp3value := 255  // Special value, so that 5 stars is written as POPM=255 (to be compatible with many other apps, like WMP, WinAmp, etc.)
          else
            mp3value := value + 152;
        end;

value is what's stored in MM DB, which is in the range 0-100, 0 = bomb, 10 = the default value for half star, 20 = 1 star, etc. mp3value, is what's written to ID3v2 tag.

So, e.g. 1.5 stars equals 30 in MM DB and is written as 54 in ID3v2.

Jiri

by **MrSinatra** » Thu Oct 18, 2018 7:04 pm

aax wrote: ↑Mon Jun 23, 2014 5:50 pm
Don't worry, this isn't about the values that are being written; they work as they should.

However, the representation of non-standard values (values that aren't 0, 13, 1, 54, 64, 118, 128, 186, 196, 242, 255) is seriously messed up. I noticed this accidentally, and then did a test to see what's up and here are the results:
https://dl.dropboxusercontent.com/u/113 ... 2.1706.png

Instead of the linear increase in the number of stars as the rating values go up, the stars displayed are all mixed up:
bomb, 1★, bomb, 0.5★, 1★, 1.5★, 0.5★, 1★, 1.5★, 2★, 1.5★, 2★, 2.5★, 3★, 2.5★, 3★, 3.5★, 4★, 4.5★, 5★

So I checked some other players to see how they map the display of stars (they mostly all match, but don't use half-stars):
WMP 12
Win Explorer (8.1)
Winamp v5.666
foobar2000 v1.3.2

Here's what I'd like to propose, put in context:
Code: Select all
Rating   WMP 12           Win 8.1 Explor   Winamp v5.666    foobar2000 1.3.2   MediaMonkey 4.1.2.1706         Proposed reading
stars    writes (reads)   writes (reads)   writes (reads)   writes (reads)     writes (reads)                 for MediaMonkey
-------  ------------------------------------------------------------------------------------------------     ----------------

0        ---              ---              ---              ---                  0 (          0,     2-8)  |  0             0
0.5      ---              ---              ---              ---                 13 (       9-18,   30-39)  |  0.5        2-22
1          1    (1-31)      1    (1-31)      1    (1-31)      1    (1-32)        1 ( 1,   19-28,   40-49)  |  1      1, 23-31
1.5      ---              ---              ---              ---                 54 (29,   50-59,   70-90)  |  1.5       32-63
2         64   (32-95)     64   (32-95)     64   (32-95)     64   (33-96)       64 (      60-69,  91-113)  |  2         64-95
2.5      ---              ---              ---              ---                118 (    114-123, 134-141)  |  2.5      96-127
3        128  (96-159)    128  (96-159)    128  (96-159)    128  (97-159)      128 (    124-133, 142-167)  |  3       128-159
3.5      ---              ---              ---              ---                186 (             168-191)  |  3.5     160-195
4        196 (160-221)    196 (160-223)    196 (160-223)    196 (160-223)      196 (             192-218)  |  4       196-223
4.5      ---              ---              ---              ---                242 (             219-247)  |  4.5     224-254
5        255 (222-255)    255 (224-255)    255 (224-255)    255 (224-255)      255 (             248-255)  |  5           255
The logic behind choosing those value-ranges for display of those stars is pretty simple: if you were to use any non-standard value from a certain range you would still see the expected number of stars throughout all those players (half-stars rounded up, since it's more logical than down).

EDIT: Oh, and here's an archive with the files I used for testing, and the results, if anyone wants to try for themselves.

the above is an excellent post.

my question is does it still represent what MM is doing now? the next to last column in the code section above? (not the proposed last column)

MrSinatra wrote: ↑Tue Jun 24, 2014 2:01 pm only 255 should be 5 stars. ANYTHING below 255 should NOT be 5 stars.

just FYI I requested the devs here and at winamp change their apps to be more in line with windows explorer, we used that as the benchmark, and I am grateful they did so. but the MM problem is that explorer and all the other big apps only use full stars, not half stars or bombs.

I tried to get MM to change its scale behavior for half stars, if only for logics sake, but their POV at the time was that they wanted to maintain backwards compatibility, which was reasonable imo. however, for the sake of discussion, here is how I would WRITE values, assuming that maintaining de facto standards was important (it is to me):

here is how I would WRITE values:
0 = Bomb
16 = 0.5 Star
1 = 1 Star
32 = 1.5 Stars
64 = 2 Stars
96 = 2.5 Stars
128 = 3 Stars
162 = 3.5 Stars
196 = 4 Stars
226 = 4.5 Stars
255 = 5 Stars

obviously, there isn't much to be done about the non-linear way the raw values write for 0 to 1 star. we can thank MS for that.

here is how I would READ values:

Bomb = 0
1.0 Star = 1
0.5 Star = 2-31
1.5 Star = 32-63
2.0 Star = 64
2.5 Star = 65-127
3.0 Star = 128
3.5 Star = 129-195
4.0 Star = 196
4.5 Star = 197-254
5.0 Star = 255

again, not much you can do about the MS mangling of the low end of the scale.

my understanding is that MM only writes one kind of value for a bomb, one kind of value for a given half star, and one kind of value for a full star. i know what it now writes for full stars. i would like to know exactly what it writes for bombs and half stars?

by **MrSinatra** » Thu Oct 18, 2018 4:06 pm

i'd also like to know what MM is currently doing. i posted a few years back and got MM to agree to make some changes, so that all apps would compatible with each other, so like this:

The following list details how Windows Explorer reads and writes the POPM frame:

224-255 = 5 stars when READ with Windows Explorer, writes 255
160-223 = 4 stars when READ with Windows Explorer, writes 196
096-159 = 3 stars when READ with Windows Explorer, writes 128
032-095 = 2 stars when READ with Windows Explorer, writes 64
001-031 = 1 star when READ with Windows Explorer, writes 1

Windows Explorer uses the following syntax:

Windows Media Player 9 Series | 255 | 0

WMP also writes the same values as described above, and reads the same way as well, EXCEPT for the cutoff between 4 and 5 stars, which is slightly different and basically of no consequence. WMP uses 221/222 instead, for reasons that are not clear

i would like the same kind of chart as above for what MM does now, b/c they have a bomb and half stars, and whats read and written for that is not covered above.

by **Blake888** » Sat Nov 05, 2016 4:43 am

Can someone tell me the values that media Monkey writes to the POPM tag for the 10 star values of rating. Have the values written changed between different versions of Media Monkey, and if they have then could soem history of those changes be provided too.

by **MrSinatra** » Tue Nov 10, 2015 2:41 pm

hi all,

just revisited this thread, fun read (for me). i have def noticed vast improvements "in the wild" in just about all app's cross compatibility. i don't often come across cases anymore where one app doesn't correctly handle the rating created by another app.

i am curious though, can someone confirm what MM now writes for each star/half star, and then state how MM reads/interprets the 0-255 range?

Aff wrote:
MrSinatra wrote:its like saying the glass is full when its actually 7/255ths from full. why is that full, and not 8/255ths?
If you had to decide if it is full or empty, you wouldn't say it's empty, would you? What is "full" to you? Think of the glass. Is it full only if you couldn't add any other water molecule without flowing over?

yes, ...and "full" is "equal"; although the analogy doesn't quite fit (no pun intended) b/c a glass of water is a nebulous, near philosophical construct in that context. this however is formal math. think of it this way: anything less than one, is not one. thats simple and straight forward. so applied here, anything less than 255, is not 255, and ergo not equal to 5 stars.

now, you can argue converting 0-255 to a 0-100 scale (or 0-99 as MS did it) and rounding up or down or whatever, is in a different sense also mathematically correct; but for the purposes of tagging, its better for the MM user to know if the value in the tag is one of the 5 whole numbers or not, namely 1,64,128,196,255. if it is NOT one of those values, the user has a visual indication its a granular value, something that rounding up 254 to 5 whole stars would hide from the user. So its very practical, tagging wise, to do it this way.

by **Aff** » Sun Jun 29, 2014 8:20 am

MrSinatra wrote:it makes no sense to try to do that by mathematically translating a up 0-255 scale to 0-100, esp since MS already mangled the low end of the scale.

A mathematical translation would be some sort of comprehensible logic at least.

MrSinatra wrote:say iTunes decides to write POPM values to tags, and they support not only full stars and half stars, but ALSO quarter stars!

If iTunes wrote 4 3/4 stars and MM still used 1/2 stars, I would like to see 5 stars in MM, not 4 1/2.

MrSinatra wrote:if another app writes 249 and doesn't show 5 stars

No such app AFAIK, and I don't think any developer would ever do this.

MrSinatra wrote:explain why MM writes 242 for 4.5 stars for example, as that is well above its halfway point for its equally arbitrary range of 219-247?

That's a good question. MM always subtracts 10 from the next full star value for half stars. Doesn't make any sense to me.
It should be nearer to the mathematical mean value, but such that it is rounded up to 5 in other players.

MrSinatra wrote:its like saying the glass is full when its actually 7/255ths from full. why is that full, and not 8/255ths?

If you had to decide if it is full or empty, you wouldn't say it's empty, would you? What is "full" to you? Think of the glass. Is it full only if you couldn't add any other water molecule without flowing over?

by **Lowlander** » Tue Jun 24, 2014 7:56 pm

The purpose of the granularity is to allow Addons the change the rating in small steps. If you make full stars a single value you take the meaning of this away. Note this is only for reading POMP and interpreting them, any full stars written by other programs would still be shown correctly in MM as well as any half stars for those programs that do. Any hypothetical quarter stars would be rounded to their nearest half star equivalent (unless MM joins a hypothetical quarter star system).

I still see no reason why breaking functionality is necessary. Showing a non-full and non-half star value as half star value doesn't show any more granularity as you don't know if it is an actual half star value or a near full star rating (that's the exact same argument used to have full star single value). Half and full stars are of equivalent importance in MM even when other software don't use half stars, by setting full star ratings as single value you're saying half star ratings aren't of the same importance.

Value of ID3v2 POPM field and MM's Rating

Post a reply

Expand view Topic review: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Star ratings - what values written to POPM

Star ratings - what values written to POPM

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating

Re: Value of ID3v2 POPM field and MM's Rating