For ratings, 0 to 5 stars seems a very small range, and it means a huge number of tracks are going to have the same rating, making sorting less useful.
Personally I'd like a 0-100 scale (although it should definitely be optional or configurable).

Even better, custom user data fields would be very cool.
Just like ratings, every track could be assigned a value in each data field.

Personally, I'd do something like:
- Loudness (enya < garbage < tool)
- Happiness/Darkness (enya <-> manson)
And a few other ones that are harder to describe.

Does that sound useful to others?

For the record: there are five stars, but the rating goes by half stars, so this is a scale of 10.

Also, you seem not aware of the scoring possibility that goes from 0 to 100 (Se track details -> Statistics) It is automatically incremented when a track is played to more than 50% of its duration, but can of course also be edited by the user. Needless to say you can search by or generate playlist based on the scoring.
As for additional sorting: check out the Labels (Edit track details -> Labels)

Yeah, I see now it goes by half-stars - took a while to notice though as I was just clicking on full stars.

The scoring I had seen, but didn't know it could be set by the user. I still don't see how to do it (except by manually editing the database, of course).

Well, you can edit directly in the track, by right-clicking on it and editing the track details. This can be done by track, by album, or by CD or by artist, whatever you prefer.
No need to edit the database, really. How about just try this out instead of wondering how to do it?

Mamarok wrote:Well, you can edit directly in the track, by right-clicking on it and editing the track details. This can be done by track, by album, or by CD or by artist, whatever you prefer.

Ok, thanks. I did try a few things but missed it, and I did google briefly, but obviously badly.

However, most of what I read focused on the fact that score was controlled by Amarok. So I was also searching to see if there's a way to tell Amarok not to change scores. I couldn't find any way to do this. Is it possible to disable this?

If not then scores are probably not what I'm after.


I still think user-created fields would be the ultimate way to go, and since Amarok already uses a database it shouldn't be a huge amount of work.

Did you check out the labels? You can create whatever label you want, be this text or numbers.
AFAIK you can't disable Amarok to increment the scores.
It would be counterproductive to create more fields, as this would only grow the database, and the current existing fields are most likely sufficient for most user cases. Keep in mind we can't cater for all user specifics, this would be impossible to handle and to maintain.

Mamarok wrote:It would be counterproductive to create more fields, as this would only grow the database, and the current existing fields are most likely sufficient for most user cases. Keep in mind we can't cater for all user specifics, this would be impossible to handle and to maintain.

I wasn't suggesting you create the fields yourself. I was thinking that you could allow each user to create their own fields that only apply to their own files. So nothing in a user's database should actually need to change unless they choose to use this.

Mamarok wrote:Did you check out the labels? You can create whatever label you want, be this text or numbers.

The labels could be somewhat useful I guess, but they'd be boolean values rather than scalars, so instead of "heaviness=97" you'd just use the label "heavy". (That is, unless your searching algorithm was able to intelligently decode and sort numbers in tags).

Also, it seems that (for me at least) using "Edit Track Details" causes Amarok to write to the file, even to change rating (it doesn't write to the file if you change the rating from outside). I'd prefer to not have Amarok make any modifications.

Mamarok wrote:AFAIK you can't disable Amarok to increment the scores.

I did see two other users explicitly asking for the ability to disable it. It would very likely be an extremely simple option to implement. Should I suggest this somewhere else or is it enough to mention it here?