Hi.

I\'ve built a new scoring algorithm, to adapt scoring to my
personal listening preferences. Please note I don\'t claim
this is a better way to do it, it\'s just an experiment.
Maybe it\'s useful and maybe it\'s not. :)

Here\'s the underlying assumptions:
[ol]
[*] The scale\'s neutral point is 50, so new tracks should score
somewhere close to that. Currently, new scores are distributed
among half the scale.

[*] Score should be pretty stable: neither should a \"good\" track
suddenly turn \"bad\" just because the user skipped it, nor the
other way around. The current algorithm provides rather
unstable scores, especially with low playcount.

[*] Corollary to 1) and 2), a score of 85 or higher on a 100
point scale is supposedly one of the user\'s favorites. Once
a song reached this score, it is very unlikely the user suddenly
starts disliking it (even if s/he skips it). Therefore, scores
of 85+ no longer go down. This assumption obviously doesn\'t
hold with the current algorithm.

[*]Skipping a track you don\'t like usually happens within the
first few seconds. Skipping at half is more likely to be
the result of incompatible user mood. Don\'t change the score
in doubt. Thus, tracks are divided into three distinct
partitions:
[ul]
[*] 1- 34% Drain score
[*] 35- 65% Neutral
[*] 66-100% Raise score
[/ul]

[/ol]
The code\'s none too beautiful, but anyway, here is a patch against stock 1.3.1...
[code:1]
--- collectiondb.cpp.orig Wed Sep 7 21:07:20 2005
+++ collectiondb.cpp Wed Sep 7 22:51:29 2005
@@ -1298,30 +1298,71 @@
int
CollectionDB::addSongPercentage( const QString &url, int percentage )
{
- float score;
+ int offset; // score adjustment
+ float score; // new score
+
QStringList values =
query( QString(
\"SELECT playcounter, createdate, percentage FROM statistics \"
\"WHERE url = \'%1\';\" )
.arg( escapeString( url ) ) );

+ enum {
+ THRESHOLD_DRAIN = 35, // We drain below 35,
+ THRESHOLD_RAISE = 65, // raise above 65
+ THRESHOLD_DONTDRAIN = 85 // and never drain above 85.
+ };
+
// check boundaries
if ( percentage > 100 ) percentage = 100;
if ( percentage < 1 ) percentage = 1;

- if ( !values.isEmpty() )
+ // With above values, this yields -10 = THRESHOLD_DONTDRAIN )
+ {
+ // don\'t devalue user\'s favorites
+ if ( offset < 0 ) offset = 0;
+ }
+ else
+ {
+ // quicken the pace for non-favorites.
+ offset*= 2;
+ }
+ playcount+= 1;
+ score = (score_old*playcount + offset) / playcount;
+
+ // Possible at boundaries
+ if ( score > 100 ) score = 100;
+ else if ( score < 1 ) score = 1;
+ }
+ else
+ {
+ // Track has never been played before
+ score = 50 + offset;
+ }
+
+
+ // update playcounter and accesstime
if (m_dbConnPool->getDbConnectionType() == DbConnection::postgresql) {
query( QString( \"UPDATE statistics SET percentage=%1, playcounter=%2, accessdate=%3 WHERE url=\'%4\';\" )
.arg( score )
- .arg( values[0] + \" + 1\" )
+ .arg( playcount )
.arg( QDateTime::currentDateTime().toTime_t() )
.arg( escapeString( url ) ) );
}
@@ -1333,13 +1374,13 @@
.arg( values[1] )
.arg( QDateTime::currentDateTime().toTime_t() )
.arg( score )
- .arg( values[0] + \" + 1\" ) );
+ .arg( playcount ) );
}
}
else
{
// entry didnt exist yet, create a new one
- score = ( ( 50 + percentage ) / 2 );
+ score = 50 + offset;

insert( QString( \"INSERT INTO statistics ( url, createdate, accessdate, percentage, playcounter ) \"
\"VALUES ( \'%1\', %2, %3, %4, 1 );\" )
[/code:1]


Regards,
Mario

Hm, sorry, that looks quite different from the preview. :blush:

Anyway, I hope it\'s still readable enough.

Regards,
Mario

Corollary to 1) and 2), a score of 85 or higher on a 100
point scale is supposedly one of the user\'s favorites. Once
a song reached this score, it is very unlikely the user suddenly
starts disliking it (even if s/he skips it). Therefore, scores
of 85+ no longer go down. This assumption obviously doesn\'t
hold with the current algorithm.

Personally, I don\'t entirely agree with this. I have lots of songs with high scores that I don\'t listen too much anymore, and I think that they should actually decay as time goes by and they haven\'t been played, maybe 1 point for every week no play was made or something like that.

I don\'t think we should change the default scoring algorithm of amaroK at this point either, what I think we should do instead is add the ability to disable the built-in auto-scoring, and then let the community implement all manner of custom scoring algorithms through the scripting interface. It might also help to add a rating, which is user defined. This way the system can score what you really like, but the user can tell the system what s/he thinks they like.

Unfortunately, I think the best way to score a song is a personal preference, and I think it would be much better if the default were kept simple.

oggb4mp3 wrote:

I don\'t think we should change the default scoring algorithm of amaroK at this point either

Didn\'t expect you to. But since I had an alternative version, I thought I could just as well post that.

what I think we should do instead is add the ability to disable the built-in auto-scoring, and then let the community implement all manner of custom scoring algorithms through the scripting interface.

Neat idea. Is anything comparable implemented in the source somewhere?

Unfortunately, I think the best way to score a song is a personal preference, and I think it would be much better if the default were kept simple.

No objections from me.

Regards,
Mario