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!
hi guys,
thx [u]very[/u] 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 [u]any[/u] 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.
[b]aax said:[/b]
[quote]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 [b]reads[/b]:
[code]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)
[/code][/quote]
[i]so is the above still accurate?[/i] b/c if it is, i agree with aax it [b]is[/b] 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.
[b]proposed reading:[/b]
[code]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)
[/code]
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!