Value of ID3v2 POPM field and MM's Rating

This forum is for reporting bugs in MediaMonkey for Windows 4. Note that version 4 is no longer actively maintained as it has been replaced by version 5.

Moderator: Gurus

Peke
Posts: 17446
Joined: Tue Jun 10, 2003 7:21 pm
Location: Earth
Contact:

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

Post by Peke »

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.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
Image
Image
Image
How to attach PICTURE/SCREENSHOTS to forum posts
MrSinatra
Posts: 42
Joined: Fri Dec 14, 2012 9:21 pm

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

Post by MrSinatra »

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!
Lowlander
Posts: 56465
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander »

That would break some scripts as mentioned previously, they depend on the range value for each star value.
MrSinatra
Posts: 42
Joined: Fri Dec 14, 2012 9:21 pm

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

Post by MrSinatra »

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?
Lowlander
Posts: 56465
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander »

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.
MrSinatra
Posts: 42
Joined: Fri Dec 14, 2012 9:21 pm

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

Post by MrSinatra »

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.
Post Reply