Open mojolo opened 3 years ago
Just to add, that I see even ratings like 0.6000000000000001 in my library.
The real problem for all these kind of changes is the migration of all user's existing tag values
Perhaps, with help of operon should be no hassle to run a massive update once...
Perhaps, with help of operon should be no hassle to run a massive update once...
The problem is that's a CLI and fairly separate; we have a basic but little-used migrations system, but this would require something a lot slower and scarier for every use (or optional I guess)
One option I realised is QL could probably just write the simplified rating=80
as well.
And then read it (converting to QL internal floating point) if found but no other specific-email rating found - else ignore
And then read it (converting to QL internal floating point) if found but no other specific-email rating found - else ignore
I'm not quite sure I got the second part...
I would like to add that this issue is the only thing preventing me from switching to QL. I love everything else about QL and I want to switch to it, but most of my music consists of flac files and they already have ratings of 0-100, as described above in this issue.
When I try to manage my music via QL, it creates a ratings disaster. All songs are displayed with the maximum (i.e., 10 of 10) stars rating. I am also unable to use QL ratings in a way that is compatible with any other application I use (whether Dolphin file manager, any other music player or any of the tag editors I use, or even just directly examining the tag contents with a library like Mutagen).
If I set QL to save ratings and play counts, it removes the existing ratings and does not add any rating or playcount in any tags that I can find, so I simply lose my existing ratings.
I am reading through the other issues to learn more. If I see that all my issues are not currently reported, I will add a new issue. I am learning Python and I hope to be able to contribute to QL in the future -- assuming I can actually begin using it, which depends on finding some resolution to this particular issue first.
Another (riskier but universal) option perhaps (need to think more) is to consider any FLAC rating <1 as "old" when reading, and multiply by 100, and write all modified files with integer 0..100 scale. Eventually (or with a force write on all library) everyone's libraries are migrated.
I'm starting to see the momentum shift toward the 0.0 to 1.0 scale. It now looks to me like the 0 to 100 scale in FLAC / Vorbis metadata is going to be the "old" way... Obviously, this is just one person's opinion.
Previously I have referenced this specific page (issue) multiple times in support of the 0 to 100 scale, but I'm abandoning support for it now and I'm on board with the 0..1 scale. Also, this issue [https://github.com/quodlibet/quodlibet/issues/3812#issuecomment-932235113], mentions an "advanced config setting" but since I decided to stick with the 0..1 scale, I did not try it.
I would say 0-100 scale is better, why use a decimal when it isn't needed especially given the quirks.
Or just the option to change the modifier for the ratings tag in the config.
Another Ratings issue/request....
Current QL Behavior
Currently, QL stores vorbis comment (FLAC, OGG, etc) ratings on a floating point scale of 0.0 - 1.0 in the
rating:quodlibet@lists.sacredchao.net
tag, eg:The proposed change
While there is no officially defined standard for storing ratings in Vorbis Comments, there is a commonly used informal standard. This request is therefore two-fold:
RATING
tag (without an email), eg:Benefits of this change
This change will increase compatibility with other players and taggers because:
RATING
vorbis comment and are not configurable.For example:
RATING
tag. See this thread.DISCNUMBER
,RATING
... Ratings are usually mapped as 1-5 stars with 20,40,60,80,100 as the actual string values."Any issues this might cause
Similar issue
Strange rating behaviour with imported music library #2921