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.

[quote=Lowlander post_id=451093 time=1540405071 user_id=262]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.[/quote]

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.

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.

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.

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?

[quote=Lowlander post_id=451090 time=1540397317 user_id=262]That would break some scripts as mentioned previously, they depend on the range value for each star value.[/quote]

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?

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.

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.

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.

[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.

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.

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

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

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... ;-)

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 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!

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 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!

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

This is the current [i]write[/i] algorithm:

[code] 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;[/code]

[i]value[/i] 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. [i]mp3value[/i], is what's written to ID3v2 tag.

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

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).

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):

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?

[quote=aax post_id=391067 time=1403563846 user_id=73072]

[b]Don't worry, this isn't about the values that are being written; they work as they should.[/b]

However, the [i]representation[/i] of non-standard values (values that aren't [u]0[/u], 13, [u]1[/u], 54, [u]64[/u], 118, [u]128[/u], 186, [u]196[/u], 242, [u]255[/u]) is seriously messed up. I noticed this accidentally, and then did a test to see what's up and here are the results:[url]https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20-%20MediaMonkey%204.1.2.1706.png[/url]

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):[url=https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20-%20Windows%20Media%20Player%2012.png]WMP 12[/url][url=https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20-%20Windows%208.1%20Explorer.png]Win Explorer (8.1)[/url][url=https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20-%20Winamp%20v5.666.png]Winamp v5.666[/url][url=https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20-%20foobar2000%20v1.3.2.png]foobar2000 v1.3.2[/url]

EDIT: Oh, and here's [url=https://dl.dropboxusercontent.com/u/11379791/Forums/Mp3tag/_MP3%20ratings%20test.rar]an archive with the files I used for testing[/url], and the results, if anyone wants to try for themselves.[/quote]

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)

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):

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

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. [b]i would like to know exactly what it writes for bombs and half stars?[/b]

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.

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:

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

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[/quote]

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.

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.

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.

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.

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?

[quote="Aff"][quote="MrSinatra"]its like saying the glass is full when its actually 7/255ths from full. why is that full, and not 8/255ths?[/quote]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?[/quote]

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.

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?

[quote="MrSinatra"]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. [/quote]A mathematical translation would be some sort of comprehensible logic at least.

[quote="MrSinatra"]say iTunes decides to write POPM values to tags, and they support not only full stars and half stars, but ALSO quarter stars![/quote]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.

[quote="MrSinatra"]if another app writes 249 and doesn't show 5 stars[/quote]No such app AFAIK, and I don't think any developer would ever do this.

[quote="MrSinatra"]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?[/quote]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.

[quote="MrSinatra"]its like saying the glass is full when its actually 7/255ths from full. why is that full, and not 8/255ths?[/quote]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?

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.

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.