Possible Misinterpretation of the Popularimeter Tag in v2.54

[Zamiel]

Hello devs. Thanks for all your work; Mp3tag is a great product!

After playing around with a hex editor, I've found that this is how Mp3tag writes a "rating mm" tag, in hex:

Value of 1 (emulating a "1 star rating") = 17 (23 in decimal)
Value of 2 (emulating a "2 star rating") = 40 (64 in decimal)
Value of 3 (emulating a "3 star rating") = 80 (128 in decimal)
Value of 4 (emulating a "4 star rating") = C4 (196 in decimal)
Value of 5 (emulating a "5 star rating") = FC (252 in decimal)

This convention for 1 and 5 seem non-intuitive. For example, MusicBee uses the following convention, which seems more logically consistent:

1 = 01 (1 in decimal)
2 = 40 (64 in decimal)
3 = 80 (128 in decimal)
4 = C4 (196 in decimal)
5 = FF (255 in decimal)

Is there some particular reason why Mp3tag is configured in this manner?

[dano]

rating mm is designed to use the same values as the program Mediamonkey.

[MrSinatra]

its true that thats the way MM writes them, but there is no guarantee that the value for the rating will be one that MM wrote, just b/c the text string is the one MM uses for its email ID. see here:

/t/11847/1

i have yet to do proper WMP tests, but the problem could really exacerbate there, since i believe it uses half stars and further granularity.

mp3tag needs to acknowledge that the raw data for ratings frames should also be accessible, regardless of what app it thinks wrote the data.

[MrSinatra]

btw, future release of MM will do the standard 1,64,128,196,255 values for whole stars, so the current mp3tag interpretation of values for "no@email" will break.

[Florian]

I've missed this one, this was addressed in v2.66

[2014-12-10] FIX: updated RATING MM to use latest mapping of values.