Page 4 of 5

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

Posted: Tue Jun 24, 2014 3:45 pm
by MrSinatra
Lowlander wrote:That would break rounding (and thus some Addons) as everything is rounded to half stars instead of as it should to the nearest star (as mipi suggests).
as it should? why should it?

the Add-ons can change.

the point I am trying to make is that there should be only ONE value for full/whole stars, while all other values are gradients above or below a whole star value. (any gradient value would equal a fractional star, which in this case means a half star as that is the only fractional icon representation for display).

for an app that ONLY displays WHOLE stars, (which is almost all of them), it makes sense to map gradient values up or down. in this way, winamp e.g. can approximate what MM writes for half star values.

but for an app that displays FRACTIONAL stars, even if it's only halves, it makes sense for all gradient raw values to be represented by fractional stars. this is the only way for the user to know if their raw value number is a number that is not 1,64,128,196 or 255. to me, 4.5 IS everything from 197 to 254. and it lets me know that the number is not 196 or 255, but something inbetween.

why should any value under 255 = 5 stars anyway? what is the point of having raw values of 249 or 253 = 5 stars? why have gradient raw values = the same max whole 5 star display?

and finally consider that we are dealing with de facto standards and interoperability issues here. there are many many apps to consider! who is to say that all these apps would read the ranges the same way and have cutoffs at the same spots? hell, its only just now that 1,64,128,196 and 255 is becoming more or less universal, as MM did not use those itself!

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

Posted: Tue Jun 24, 2014 4:42 pm
by Peke
Locic behind MMW 252 Rating -> 5 stars can be easily solved using plain Mathematical Decimal point rounding where 0.57 is rounded to 0.6.

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

Posted: Tue Jun 24, 2014 4:59 pm
by MrSinatra
Peke wrote:Locic behind MMW 252 Rating -> 5 stars can be easily solved using plain Mathematical Decimal point rounding where 0.57 is rounded to 0.6.
what is the W in MMW?

and this isn't a math problem. there is no math component. this is strictly about table matching/mapping raw numbers to display UI, and I stand by what I said above, to which u did not respond.

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

Posted: Tue Jun 24, 2014 5:33 pm
by Lowlander
It doesn't make sense at all, half star is an actual value just like a full star. 1 1/2 star means 1.5 stars not > 1 to < 2. It makes sense that each star value (half stars included) have the same value range. Note that this is on reading the value and translating it to a star display value. Writing stars by MM (not Addons) to value should be a fixed value for all star values (values chosen being the most interoperable one). This way existing Addons, which can't be fixed as they rely on each star value having a range, can operate as expected.

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

Posted: Tue Jun 24, 2014 6:25 pm
by MrSinatra
Lowlander wrote:It doesn't make sense at all, half star is an actual value just like a full star. 1 1/2 star means 1.5 stars
obviously. but that doesn't speak to the raw numbers.

tell me, how is one supposed to know the "range," in raw numbers, one should have? how do you determine the cutoffs? 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. that mangling makes it impossible to do correctly.

consider the following scenario:

say iTunes decides to write POPM values to tags, and they support not only full stars and half stars, but ALSO quarter stars! now what are you going to do? redefine your writes? your reading ranges? change your display or not?

if another app writes 249 and doesn't show 5 stars, (which makes sense as the raw number is less than the max value), then why should MM?
Lowlander wrote:not > 1 to < 2. It makes sense that each star value (half stars included) have the same value range. Note that this is on reading the value and translating it to a star display value. Writing stars by MM (not Addons) to value should be a fixed value for all star values (values chosen being the most interoperable one). This way existing Addons, which can't be fixed as they rely on each star value having a range, can operate as expected.
and how does what I said violate that? the reading range for 4 stars is 196 to 196. for 4.5 stars its 197 to 254. a range of one or many is valid.

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? and what would MM do should someone else implement quarter stars?

how can any value under 255 be equal to 5 full stars? its like saying the glass is full when its actually 7/255ths from full. why is that full, and not 8/255ths?

personally, I think the values that MM writes and reads for half stars is arbitrary, and it makes no sense to me to have a "range" for whole stars, when there is now near universal agreement on what to write for those 5 values. what I tried to do was come up with the best, most common sense system to accommodate the insanity of MS, which we all have to live with.

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

Posted: Tue Jun 24, 2014 6:34 pm
by aax
Actually, I see MrSinatra's point, since most apps now write those same five values for full stars. We can safely assume that everything apart from them is some kind of granularity.

Now, if you keep in mind that only a handful of players even offer half-star ratings, of which MM and MusicBee use the same numbers for halves (and fulls), it's not very likely that you'll actually find files with any other in-between numbers (besides, I don't think even OCD users rate in finer increments :lol:).
Having said that, if you had a file with arbitrary value between any two stars, and used same ranges for display of both full- and half-stars as Lowlander suggests, the player would actually tell you about that granularity only in a fraction of cases (e.g. for files with values 0.25-0.75 between stars). And, to me, it seems better if you're aware that the intended rating is more or less than a full star.

So, I agree with Sinatra's proposal – it is better than mine. But it still leaves us two problems:
  • Users who have ratings from older MM versions where 1★ = 23 and 5★ = 252. I know that developers weren't too keen on updating them automatically earlier in the thread, although that would be in the best interest of those users.
  • Full-star players will both round-up and -down what to MM would be half-stars with arbitrary values. Granted, it's really unlikely that anyone actually has files with granular ratings set at arbitrary values.

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

Posted: Tue Jun 24, 2014 7:56 pm
by Lowlander
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.

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

Posted: Sun Jun 29, 2014 8:20 am
by Aff
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?

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

Posted: Tue Nov 10, 2015 2:41 pm
by MrSinatra
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.

Star ratings - what values written to POPM

Posted: Sat Nov 05, 2016 4:43 am
by Blake888
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.

Re: Star ratings - what values written to POPM

Posted: Thu Oct 18, 2018 4:06 pm
by MrSinatra
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.

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

Posted: Thu Oct 18, 2018 7:04 pm
by MrSinatra
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?

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

Posted: Fri Oct 19, 2018 2:04 am
by jiri
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

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

Posted: Fri Oct 19, 2018 3:39 pm
by MrSinatra
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!

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

Posted: Mon Oct 22, 2018 4:56 am
by jiri
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