2016-10-05, 20:04
While people have problems with their music tagging quality, it is so much easier to deal with if scraping (NFO or olnine) doesn't happen automatically. Hence I have argued for the default installation to have "Fetch online info on update" disabled. However this does mean that the users have to remember to query the info. An aim for v18 would be for automatic scraping by default, let's see how v17 goes once it is released. 
Back to ratings....
Let's take your first album "The Original Soundtrack" by 10CC. It has a rating of 1.5 loaded from NFO which I expect reads <rating>1.5</rating>, and userrating of -1 with no <userrating> xml tag present (but I would have expected 0). The songs from this album all have a rating of 0.0 and various userratings, integers from 1 to 10, mostly 3, derrived from the values scanned from the POPM tag in the music files.
As I said before POPM data is actually 0-255 internally, and historically different players encode/decode this into what they display in different ways. There is a note in the code that
Windows Media Player 9 Series ratings:
1 = 1, 2 = 64, 3=128, 4=196 (not 192), 5=255
MediaMonkey:
0.5=26, 1=51, 1.5=76, 2=102, 2.5=128, 3=153, 3.5=178, 4=204, 4.5=230, 5=255
From minimal experiments it seems that Mp3tag does some kind of conversion like that too e.g. 2=64, 4=196 etc. it does the rounding of your tag values not Kodi. Or maybe it is Taglib when it reads the tag values? I'm not sure, but it isn't Kodi code that I can see. It is all about what are POPM compatible rating values.
You are saying that have the album show as a 1.5 (rating) but songs as 3 (userrating) is off putting.
And that because you also want to run Jarvis, or other players, you don't want to change your files.
You would probably like me to undo the Kodi changes as a solution, but I don't think other team members would support that. Instead can I suggest a work around.
My suggestion is that you modify your NFO files adding <userrating max=5>N</userrating> for every <rating>N</rating> entry. Jarvis will ignore the <userrating> tag, still has the rating values as it expects, and the "max=5" tells Krypton that the value N is out of 5 when loaded. All that is needed is a nice batch editor that adds that line to your NFO files.
The end result would be more consistent album userrating and song userrating values. Both show now as integer numbers out of 10, but a skin could then turn these into starts and half stars that you would like.
Meanwhile if you scrape album rating values from Allmusic you will never get a value above 5.0. I would hope that the scraper could allow for the max value of the data it is loading, but that is not my bit of Kodi.
Back to ratings....
Let's take your first album "The Original Soundtrack" by 10CC. It has a rating of 1.5 loaded from NFO which I expect reads <rating>1.5</rating>, and userrating of -1 with no <userrating> xml tag present (but I would have expected 0). The songs from this album all have a rating of 0.0 and various userratings, integers from 1 to 10, mostly 3, derrived from the values scanned from the POPM tag in the music files.
As I said before POPM data is actually 0-255 internally, and historically different players encode/decode this into what they display in different ways. There is a note in the code that
Windows Media Player 9 Series ratings:
1 = 1, 2 = 64, 3=128, 4=196 (not 192), 5=255
MediaMonkey:
0.5=26, 1=51, 1.5=76, 2=102, 2.5=128, 3=153, 3.5=178, 4=204, 4.5=230, 5=255
From minimal experiments it seems that Mp3tag does some kind of conversion like that too e.g. 2=64, 4=196 etc. it does the rounding of your tag values not Kodi. Or maybe it is Taglib when it reads the tag values? I'm not sure, but it isn't Kodi code that I can see. It is all about what are POPM compatible rating values.
You are saying that have the album show as a 1.5 (rating) but songs as 3 (userrating) is off putting.
And that because you also want to run Jarvis, or other players, you don't want to change your files.
You would probably like me to undo the Kodi changes as a solution, but I don't think other team members would support that. Instead can I suggest a work around.
My suggestion is that you modify your NFO files adding <userrating max=5>N</userrating> for every <rating>N</rating> entry. Jarvis will ignore the <userrating> tag, still has the rating values as it expects, and the "max=5" tells Krypton that the value N is out of 5 when loaded. All that is needed is a nice batch editor that adds that line to your NFO files.
The end result would be more consistent album userrating and song userrating values. Both show now as integer numbers out of 10, but a skin could then turn these into starts and half stars that you would like.
Meanwhile if you scrape album rating values from Allmusic you will never get a value above 5.0. I would hope that the scraper could allow for the max value of the data it is loading, but that is not my bit of Kodi.
