Why extra zeroes in FMPS_RATING

[gitut2007]

Hi.
(I guess this is of lesser importance that the other issues and proposed patches already here)
It's good that GMB is using the FMPS_RATING standard*, but it's using it in a kind of 'non-standard' way: others are writing to the tag 0.0 0.1 0.2 0.75 ... while GMB uses 0.1000000 ... ; while mathematically it's the same, it could pose displaying (like stars rating) or other (?) issues if read by other programs.

Users shouldn't resort to find posts like https://le-marocain-dailleurs.blogspot.com/2013/07/partager-les-notes-de-ses-mp3-entre.html http://le-marocain-dailleurs.blogspot.com/2014/01/afficher-les-notes-de-ses-mp3-sous.html (here to eliminate the extra zeroes for use in Foobar2000. And anyway others don't have Foobar's flexibility).

So I don't know why the extra zeroes but it would be more elegant /'standard' (as in how eg Amarok, Clementine do it) without them.
(Also (not sure) 'FMPS_RATING' -all in caps- should be usedd for OGG while 'FMPS_Rating' for others?)

So, just a little thing but maybe the 'fix' (if worth it, idk) is very trivial.

*Regarding the FMPS standard, I can't even find what it is; could you or someone reading this who has it copied post it in a wikipedia or archive.org page? the original page where it is supposed to be is not working.
Thank you.

[squentin]

I can't find the specs anywhere sadly. But the "zeroes" were how the standard required the values to be stored. Either that or I misunderstood the specs, which is possible.

I think the idea was that software supporting the specs would not display the raw value. A value between 0 and 1 is clearly not meant to be user visible, but as a compatible way to represent the various values used (0-5 stars 0-100% ...) and I guess the zeroes (though a bit too numerous) ensure that a common way to store the decimals is used and supported.

About "FMPS_RATING" in all in caps in ogg files, it may be from the fmps specs, or I simply followed the examples from the ogg specs (https://xiph.org/vorbis/doc/v-comment.html) that use all caps for the field names, though they do say they should be case insensitive, so it shouldn't matter anyway.

Of course there are the standards and how they are implemented in practice. I'm not opposed to following how all the other softwares are doing it, but I'm out of touch with them, I would have to check the most common ones, and do lots of testing. This is not a priority.

In any case, it's easy to change it yourself by editing the FMPS_rating_prewrite function in gmusicbrowser_songs.pm and change the "%.6f" in the sprintf to "%.2f".