DADA Auto-Rating (DAR) for foobar2000, Date and duration adjusted auto-rating algorithm Options

[carpman]

DADA Auto-Rating (DAR) for foobar2000

Date and duration adjusted auto-rating algorithm

The DAR page: http://www.giantpygmy.net/sections/pause/a...g_dar_v162.html

LATEST VERSION: 1.6.4 (released 12/11/10)

*********************

CONTENTS:

1. Intro
2. Requirements
3. Setup instructions
4. The DAR Code
5. The DAR Indexed Rating (with Dots)
6. Making an Autoplaylist ranked by DAR
7. A note regarding issues raised on the old foo_DAR thread
8. Changelog

*********************

1. INTRO

A good auto-rating algorithm will simply tell you what your favourite (and conversely, least favourite) music is, and the rating will be derived from and reflect actual listening behaviour. This is quite different from manual ratings (e.g. 1 - 5 stars set by the user), since there's very often a disparity between what we'd like ourselves to like, and what we actually like. For those interested in uncovering their actual musical tastes, a good auto-rating formula can be quite illuminating.


(obviously this data would normally accompany Track Title & Artist info etc...)


The DADA Auto-Rating algorithm (DAR) addresses the following issues:

a) THE PLAY PER PERIOD PROBLEM
"Total Playcount" / "No. Days in Library" will give an unfair advantage to new tracks.

b) THE TOTAL PLAYCOUNT PROBLEM
Total playcount will give an unfair advantage to old tracks.

c) THE TRACK DURATION & PLAYCOUNT PROBLEM
Song A = 30 mins, Song B = 3 mins, the opportunity cost of listening to Song A is listening to Song B 10 times. If playcount is at the root of the rating (and it has to be), somehow duration has to be factored in, because we are physically limited by time (lifetime/listening time). No matter how much one likes Song A you simply cannot fit as many plays of that track into a lifetime as you can with Song B. So all other things being equal, Song B has an advantage (due to its duration) and this has to be adjusted for.

There are other factors, but they are the principle ones the DAR algorithm is interested in solving. DAR attempts to negate these issues so that regardless of the above, all tracks are rated on a level playing field.


2. REQUIREMENTS:

foobar2000 v.1+
foo_playcount.dll (the offical Playback Statistics plugin)
foo_dynfil.dll (the host for the DAR algorithm) [Warning! Read this post before installing]


3. SETUP INSTRUCTIONS:

The latest code and setup instructions are here:
http://www.giantpygmy.net/sections/pause/a...est_version.txt


4. DAR CODE:

CODE

$puts(pc,%play_count%)
$puts(x,$add($date_diff(%added%),2))
$puts(y,$date_diff(%added%,%last_played%))
$puts(z,$sub($get(x),$get(y),2))
$puts(l,%length_seconds%)
$puts(lib0,$date_diff(2000))
$puts(lib1,$div($add($mul($sub(100,$div($date_diff(%added%),$div($get(lib0),100))),15),2600),30))
$puts(d0,$ifgreater($get(l),3599,$muldiv(9000,$get(l),3600),9000))
$puts(d1,$muldiv($add($get(l),540),1,4))
$puts(d2,$muldiv($get(l),$get(l),$get(d0)))
$puts(d3,$add($get(d1),$get(d2)))
$puts(r0,$mul($add(1000,$muldiv($get(d3),$get(pc),100)),10))
$puts(dd,$div($add($get(y),50),10))
$puts(pp,$muldiv($get(pc),10000,$get(x)))
$puts(2,$muldiv($get(dd),$get(pp),100))
$puts(3,$muldiv($get(x),$get(lib1),100))
$puts(4,$div($get(pp),50))
$puts(5,$div($muldiv($add($date_diff(%added%,%first_played%),2000),500,$add($div($get(d3),6),70)),$add($mul($get(pc),$get(pc)),1)))
$puts(6,$muldiv($get(pc),625,$get(x)))
$puts(7,$add($get(3),$get(5),$get(6)))
$puts(r1,$add($get(2),$get(r0)))
$puts(r2,$add($get(4),$sub($get(r1),$get(7))))
$puts(r3,$sub($get(r2),$div($mul($get(r2),$get(l),$get(z),$get(pc)),500000000)))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$ifgreater($get(pc),0,$num($get(r4),5),-----)

5. DAR INDEXED RATING (WITH DOTS)

If you want a visual reprentation of the DAR results (i.e. dots) similar to the above screenshot:
Then create a custom column in foobar2000 and enter this code:

CODE

$puts(maxdar,11000)
$puts(mindar,8000)
$puts(maxsub,$sub($get(maxdar),0))
$puts(r3,$ifgreater(%_dynamic_rating%,$get(maxsub),$get(maxsub),%_dynamic_rating%))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$puts(minmax,$sub($get(maxdar),$get(mindar)))
$puts(darind1,$sub($get(r4),$get(mindar)))
$puts(darind2,$div($mul($get(darind1),10),$get(minmax)))
$puts(darind3,$ifgreater($get(darind2),1,$get(darind2),1))
$puts(display,$rgb(100,100,100)$repeat($char(9679),$get(darind3))$rgb(220,220,220)$repeat($char(9679),$sub(10,$get(darind3))))
$puts(notplayed,$rgb(200,200,200)- n/a -)
$ifgreater(%_dynamic_rating%,0,$get(display),$get(notplayed))

For alternatives (i.e. for DUI or other CUI options) see the setup instructions file.


6. MAKING AN AUTOPLAYLIST RANKED BY DAR

To create an autoplaylist ranked according to the DAR algorithm see instructions:

Query pattern:

CODE

%_dynamic_rating% GREATER 0

Sort pattern:

CODE

$sub(99999,%_dynamic_rating%)

7. A NOTE REGARDING ISSUES RAISED ON THE OLD FOO_DAR THREAD

When the first DAR formula was released (then inappropriately named foo_DAR -- it's NOT a component!) a number of issues were raised, along with other substantial improvements, all of these have been remedied:

• The Probation Period: SOLVED (no longer required, instead DAR has a mechanism that subdues the distorting "play per period effect" of very new tracks)
• The %SKIP% Issue: SOLVED (abandoned the use of %skip% as a measure of listening behaviour)
• The First Played Penalty: SOLVED (this has been greatly reduced and is now part of a general low playcount penalty - see DAR page for details)

8. CHANGELOG (v.1.6.2 - onward)

• DAR 1.6.4 (12/11/10)
  Changed the old track suppression multiplier from a static to a dynamic variable. This reduces the "performance burden" of older tracks with each additional year in the collection. The lib0 variable can be altered for those with very large or small collections. For a library of less than 5000 tracks I'd recommend setting it to 1900 (which will be close to the DAR 1.6.3 default) or 1950. For most the default (2000) will work very well. If you have a large 30k+ library AND you are seeing newer tracks dominating the ratings, try increasing the lib0 to 2001, then 2002 etc... but do not go beyond the age of your oldest track. So, if your stats begin in 2007, the max for the lib0 variable will be 2007. I would suggest that to go to the maximum (i.e. in this example, 2007) would only be appropriate for users with a very large music collection (say, in the 50k+ region).
  
  Relevant line to edit: $puts(lib0,$date_diff(2000))
  
  
• DAR 1.6.3 (11/10/10)
  Introduced Super Long Track duration suppression (this only affects songs > 60 mins). The original DAR didn't foresee tracks longer than the duration of a CD. Though rare, such tracks do exist. This update ensures their ratings are not artificially high. See this post.
  

*********************

That's it.
Enjoy!

Feedback and suggestions welcome.

C.

ps. Special thanks to Yirkha for making foo_dynfil and solving the %now% problem.

This post has been edited by carpman: Feb 20 2011, 23:42

[q-stankovic]

Thank you, carpman!

Can you describe in simple words how the formula works? How do added, first_played, last_played and playcount determine the dynamic rating?

[carpman]

It's hard because the variables are used in a number of different ways to carry out different functions. These functions are then combined in a number of ways to achieve the final result.

I'll explain roughly how it goes.

On the DAR page linked to under the title (in the first post) you can see what it does, in how I've laid out the problem.

Firstly it addresses the duration issue:
See: http://www.giantpygmy.net/sections/pause/a...calibration.png
and: http://www.giantpygmy.net/sections/pause/a...s_playcount.png

((%length_seconds% + 540) * 0.25)
Notice if you put 180 into that you get 180, if you put anything less it will gain and anything more will lose. So all track durations move to some degree toward 180 secs.

We add to that (%length_seconds%^2 ) / 9000

What this does is add a little duration back for extremely long tracks (+30 mins)

Then after "recalibrating" (perhaps, "weighting" the duration) it performs a simple calculation which creates the basis of the rating:

$puts(r0,$mul($add(1000,$muldiv($get(d3),$get(pc),100)),10))

The adjusted duration (d3) as per above is multiplied by the %play_count%.
Then divided by 100.
This is then added to 1000 and multiplied by 10.

Why all the big numbers? It's kind of a floating point-ish issue since %titleformatting% rounds down, so that 1.9 gets rounded to 1.

I won't go further, except to say that after that, TIME (or rather age) is allowed to impact the rating. So a number of date based calculations (along with delayed playing, low-playcount penalties, and increased fall rates etc) are made and this erodes the earlier "duration-based" rating (r0).

See the graphs and explanations here for more:
http://www.giantpygmy.net/sections/pause/a...g_dar_v162.html

Hope that helps,

C.

This post has been edited by carpman: Sep 29 2010, 23:13

[スラッシュ]

This is cool! How often does it get recalculated? Or do you have to press the button when you want it to recalculate?

[carpman]

From here: http://www.hydrogenaudio.org/forums/index....st&p=724796

While experimenting with carpmans script i noticed that another type of automatic updating would be senseful. When a currently playing track increases its playcount and therefore changes its first played time then its and only its dynamic rating could be updated to reflect immediately the change of the value.

Indeed, seems reasonable. I'll add that to the component, so that when any metadata changes, the dynamic values of the relevant track(s) will be also recalculated.

And I'll make it do the same for any newly added tracks too. Currently the only action taken was to remove information for tracks removed from the Media Library.

This is up to Yirkha's component. But it sounds like it's in hand. At present it's like this:

Refreshes asynchronously at startup, when you press a button and using bindable main menu command Library > Recalculate dynamic rating.

C.

[shakey_snake]

Neato. Thank you.

[DustMagnet]

Fascinating. The results I've looked at seem sane and realistic. Clearly you've put a lot of thought into this. Bravo.

[romor]

Hi carpman,
great project and fabulous documentation which I did not absorb whole, but have question about max value of DAR Index: I'm getting very high value - 181 (it's one of my favourites tracks, but not as much )

%play_count% = 44
%added% = 2010-05-22 03:04:55
%first_played% = 2010-05-22 03:17:52
%last_played% = 2010-09-12 00:03:30
%length% = 2:35:00.033 (it's that long, and it is one of 3 tracks released on this DVD: http://www.discogs.com/release/728911)

Issue is with length of course, and play_count considers played track after 1min of playback

This post has been edited by romor: Sep 30 2010, 08:41

[carpman]

Hi rumor,

Sounds like a classical example of this:
http://www.hydrogenaudio.org/forums/index....st&p=724804

Simple answer is that you've already hit the nail on the head, it's a foo_playcount issue, and I've already made my point numerous times regarding how I feel about this. The insanity is that according to foo_playcount over a period of almost 5 months (assuming you sleep for 8 hours a day) you've spent 5.5% of you're waking life listening to one song. I'm sure that's not the case.

The ideal situation is to have a playcount based on "total track listening time" / track length.

Have you done the following:

You may need to adjust the two variables.
The "maxdar" should be about 200 points greater than your current maximum rating.
The "mindar" is harder to approximate, if unsure leave it where it is, otherwise give it a value of 2000 to 3000 above the lowest rating, if that doesn't satify, just play around with it until you're happy.

$puts(maxdar,10800)
$puts(mindar,7800)

from: http://www.giantpygmy.net/sections/pause/a...est_version.txt

I'm guessing you're getting a DAR of something like 63000 !

1) Is this track a complete anomaly or are there a load of tracks like this in you collection?
2) How do you listen to music, mainly shuffle, or mainly album by album in default/ "linear" mode?

C.

EDIT: Basically I'd assumed that no individual track could be longer than a CD and I left plenty of headroom.
It's very possible to do a work around because my feeling is that even with foo_playcount's count if played > 1 min, that this is a very extreme case, so I'll look at building in some kind of track length cap.

In the meantime, let me know the answers to those 2 questions.

Thanks.

This post has been edited by carpman: Sep 30 2010, 12:06

[romor]

Hey, thanks for your reply, but I'm not rumor but romor: it's roughly translated as stream bubbling or sparkling

You ideal solution about play_count is perfect solution if someone asks me. I hope developer would consider this as at least making personal preference about play_count trigger is reasonable wish by many if I may say. I know there are components providing this feature, but I also want to take advantage of this fast binary solution over sqlite sloppiness. And again I would prefer your play_count formula as ideal.

I'll check with your quoted text later, in the meantime:

1. It seems like anomaly, here are my top 20:

CODE

Length     count    IDX    DAR
--------------------------------
2:35:00    46       181    62326
2:24:54    22       81     32272
1:59:57    22       63     26763
55:44      74       61     26307
29:51      85       33     17859
30:00      85       33     17917
30:56      76       33     17799
31:08      74       32     17636
52:24      33       29     16589
57:37      32       29     16775
45:00      43       27     15971
45:30      29       22     14449
55:31      17       19     13776
29:51      39       19     13694
24:45      39       17     13194
42:45      27       17     13155
35:36      28       17     13003
30:30      33       17     13171
32:12      34       17     13049
3:12       111      16     12851

notice the first three tracks which are from the same release

2. I would say mainly albums, and rarely shuffle mode


About edit: that discogs review (about this release) quoted another review where it is said that it's "possibly the longest continuous musical composition ever released on any format". There are limitation releasing your artwork in such format (and in this release even compression was unavoidable, so track 2 was compressed with AC-3), but yeah generally considering max length to CD length is reasonable thought.

Also I'll examine your project more later which would be easy with provided documentation

Cheers

This post has been edited by romor: Sep 30 2010, 14:33

[スラッシュ]

There's the Playcount Statistics Custom, which has an option to tag a song when it's halfway through playing (or some other percentage). It uses tags, or foo_customdb (or both). I don't know if that's a viable alternative for you, but it's what I use anyway since I want playcount tags, and it works with DAR.

One of my songs has over 200 plays, so in order to get a decent rating out of the other tracks, I just let that one be too high... It's my own "fault" for playing that song as an alarm clock for a year.

[carpman]

I'll try again ... hi romor,

((%length_seconds% + 540) * 0.25)
Notice if you put 180 into that you get 180, if you put anything less it will gain and anything more will lose. So all track durations move to some degree toward 180 secs.

We add to that (%length_seconds%^2 ) / 9000

What this does is add a little duration back for extremely long tracks (+30 mins)

This was the problem, I had assumed "extremely long" must be < 80 mins.
So now if the track is > 45 mins the divisor is increased by %length_seconds%/2700 (i.e 45 mins).

Try these two versions and see which one works best for your library:

Default Duration Effect (DAR 1.6.3 SLT beta)

In the default version you should see no difference for tracks < 45 mins.
So I'd like you to make a note of a 3, 5, 10 min track and check that the rating doesn't change.
You should notice a major change in very long tracks. If you feel it's still not enough I'd recommend the 2nd version below.

CODE

$puts(pc,%play_count%)
$puts(x,$add($date_diff(%added%),2))
$puts(y,$date_diff(%added%,%last_played%))
$puts(z,$sub($get(x),$get(y),2))
$puts(l,%length_seconds%)
$puts(d0,$ifgreater($get(l),2699,$muldiv(9000,$get(l),2700),9000))
$puts(d1,$muldiv($add($get(l),540),1,4))
$puts(d2,$muldiv($get(l),$get(l),$get(d0)))
$puts(d3,$add($get(d1),$get(d2)))
$puts(r0,$mul($add(1000,$muldiv($get(d3),$get(pc),100)),10))
$puts(dd,$div($add($get(y),50),10))
$puts(pp,$muldiv($get(pc),10000,$get(x)))
$puts(2,$muldiv($get(dd),$get(pp),100))
$puts(3,$muldiv($get(x),135,100))
$puts(4,$div($get(pp),50))
$puts(5,$div($muldiv($add($date_diff(%added%,%first_played%),2000),500,$add($div($get(d3),6),70)),$add($mul($get(pc),$get(pc)),1)))
$puts(6,$muldiv($get(pc),625,$get(x)))
$puts(7,$add($get(3),$get(5),$get(6)))
$puts(r1,$add($get(2),$get(r0)))
$puts(r2,$add($get(4),$sub($get(r1),$get(7))))
$puts(r3,$sub($get(r2),$div($mul($get(r2),$get(l),$get(z),$get(pc)),500000000)))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$ifgreater($get(pc),0,$num($get(r4),5),-----)

Weak Duration Effect (DAR 1.6.3 SLT beta)

CODE

$puts(pc,%play_count%)
$puts(x,$add($date_diff(%added%),2))
$puts(y,$date_diff(%added%,%last_played%))
$puts(z,$sub($get(x),$get(y),2))
$puts(l,%length_seconds%)
$puts(d0,$ifgreater($get(l),2699,$muldiv(10000,$get(l),2700),10000))
$puts(d1,$muldiv($add($get(l),720),1,5))
$puts(d2,$muldiv($get(l),$get(l),$get(d0)))
$puts(d3,$add($get(d1),$get(d2)))
$puts(r0,$mul($add(1000,$muldiv($get(d3),$get(pc),100)),10))
$puts(dd,$div($add($get(y),50),10))
$puts(pp,$muldiv($get(pc),10000,$get(x)))
$puts(2,$muldiv($get(dd),$get(pp),100))
$puts(3,$muldiv($get(x),135,100))
$puts(4,$div($get(pp),50))
$puts(5,$div($muldiv($add($date_diff(%added%,%first_played%),2000),500,$add($div($get(d3),6),70)),
$add($mul($get(pc),$get(pc)),1)))
$puts(6,$muldiv($get(pc),625,$get(x)))
$puts(7,$add($get(3),$get(5),$get(6)))
$puts(r1,$add($get(2),$get(r0)))
$puts(r2,$add($get(4),$sub($get(r1),$get(7))))
$puts(r3,$sub($get(r2),$div($mul($get(r2),$get(l),$get(z),$get(pc)),500000000)))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$ifgreater($get(pc),0,$num($get(r4),5),-----)

Let me know how it goes, and also which version suits you best.

Thanks for bringing this up.

C.

EDIT: Code pasting sloppiness.

This post has been edited by carpman: Sep 30 2010, 19:23

[q-stankovic]

Thank you for the detailed explanation, carpman!

I just expected some information about the relation of dynamic rating to the itemized playback statistics fields.
I assume it works like this:

The higher the playcount the higher the dynamic rating if all other playback statistics fields are the same.
The older the last played timestamp the lower the dynamic rating if all other ...

I have difficulties to see how first played and added timestamp are related.

This post has been edited by q-stankovic: Sep 30 2010, 19:57

[carpman]

I assume it works like this:

The higher the playcount the higher the dynamic rating if all other playback statistics fields are the same.
The older the last played timestamp the lower the dynamic rating if all other ...

Correct.

I have difficulties to see how first played and added timestamp are related.

When tracks have a very low playcount (i.e. < 5) the effects of the low playcount penalty are a dominant factor in the DAR rating scheme. As the playcount increases this effect diminishes quickly (ultimately to zero).

Source: http://www.giantpygmy.net/sections/pause/a...g_dar_v162.html

Part of the low playcount penalty is the delay in first playing.
The greater the difference between first played and added the greater the penalty, the lower the rating.

However, this penalty is temporary since the gap between first played and added never changes yet playcount does (it's divided by playcount^2).

The green arrows below show the effect of delaying first playing the song by 40 weeks:


C.

[carpman]

@ romor

The 2 versions I've given you are marked below in red:



All these versions have the new Super Long Track suppression code (except the grey line which is the old default). As you can see it's identical up to 45 mins, then the new mechanism comes in.

I'm going to sit on it, but it's possible I'll put this in the next release (more likely at about 60 mins). Afterall, it will only effect a few extreme tracks.

Thanks for raising the issue, it's basically a combination of my assumption re. long tracks and the way foo_playcount counts them. As I said before, let me know what you think.

Cheers,

C.

[romor]

Thanks carpman for your replies and solutions
I wish play_count trigger issue to be solved (in our all interest)

I tried your new scripts and decided to go with DDE:

20 samples:


54 samples:


I'll look more into your interesting work in future days, as I just had exam in statistics yesterday and I don't want to look at the subject in following few days

[carpman]

romor, you've probably already done this, but you'll need to change your maxdar, mindar settings in the DAR Index.

The "maxdar" should be about 200 points greater than your current maximum rating.
The "mindar" is harder to approximate, if unsure leave it where it is, otherwise give it a value of 2000 to 3000 above the lowest rating, if that doesn't satify, just play around with it until you're happy.

I'm guessing, but something like:

CODE

$puts(maxdar,20000)
$puts(mindar,7500)

The DAR Index is setup so that it should always be between 1 and 9 dots (with 10 dots suggesting your max needs to be adjusted).

C.

[sebassjee]

Awesome component! Thank you..
There's only one thing i can't get working, How can I create a custom column for the dotted-rating?

seb

Edit: I allready managed it

This post has been edited by sebassjee: Oct 3 2010, 22:55

[carpman]

Awesome component! Thank you..

Thank you. But you mustn't confuse people - it's not a component (I got into trouble with that a while back).
Component credits go to Peter and Yirkha.

Hope you enjoy the results.

C.

[romor]

romor, you've probably already done this, but you'll need to change your maxdar, mindar settings in the DAR Index.

Thanks for interest carpman, I tried that, but got some flat values, like 99% of tracks with value 1 and rest some values till 9
BTW limit values were something like 36000/5000 (according suggestion)
I looked at DAR TF code and extracted formula:



-----------------------------------
where:
P is play_count,
L track length, and
D are various date differences in days (indicated by subscripts)

Result values are more/less same as DAR code, perhaps because of date difference calculation and foobar rounding maybe

I tempered quadratic part (red outlined) and made it linear: $puts(d2,$div($get(l),100)) slightly affecting the next part, but results are fine by me:



About DAR Index I took max/min values and interpolate them on 0-100 scale - it's interesting

Overall, at a first glance results from your idea are not very noticeable, (except my top 20 being my longest tracks on first try) but I expect to tweak it in future when I got more used to it.
Is this work based on your own suggestions/experience or you used some known algorithms?

[carpman]

Result values are more/less same as DAR code, perhaps because of date difference calculation and foobar rounding maybe

Yes, my Excel DAR "modelling" sheet, always has slightly different values due to rounding.

Overall, at a first glance results from your idea are not very noticeable, (except my top 20 being my longest tracks on first try) but I expect to tweak it in future when I got more used to it.
Is this work based on your own suggestions/experience or you used some known algorithms?

The former. I just thought about what I wanted a ratings formula to do. A lot of the decisions are practical ones as I've said before, a) limited to pretty simple maths, b) rounding issues (as you've discovered).

I tempered quadratic part (red outlined) and made it linear: $puts(d2,$div($get(l),100)) slightly affecting the next part, but results are fine by me

The "d2" part is based on something I was finding regarding tracks whose duration was > 30 mins. I needed a way to benefit tracks 30 mins+ without giving that same benefit to songs <20 mins.

What's worth keeping in mind, is that my test data is based on a playcount that a) only counts after 67% played, and b) where, if I've fallen asleep for example, the playcounts of those unlistened to tracks are subtracted by 1. So my test results are based on very accurate playcount data over a long period (as an example my ratings have never exceeded 10700 -- this is a reflection in part of my own listening behaviour, but has a lot to do with the nature of the playcount data).

I think your modifications are very suitable for your situation and the current limitations of foo_playcount.
Personally, I'd like to see an improved foo_playcount, but your modifications may well be useful for people who find themselves with similarly high DAR results as results of foo_playcount's limitations.

Please keep me informed of your modifications -- very interesting (and I like the formula! ).

C.

[romor]

I do intent to modify it based on my data and foo_playcount limitation on hard-coded 1min counting. Version 3 recently came out and there are no indication on preferred changes happening (or even replies in previous version thread IIRC) so that seems to be the way for users of foo_playcount
However I did not modify nothing special, I guess that removing quadratic part is the first idea that comes to mind when thinking about lowering influence of large tracks, as you've done in DDE and WDE

[carpman]

Absolutely, I understand what you're saying, and I'm all in favour of your modifying and improving DAR where possible. Personally, I have tremendous faith in Peter and the team in their rationality and ability to realise when something simply doesn't make sense.

My view on what you've done is that you could almost get rid of d2 entirely. It's whole purpose is to increase the ratings of very long tracks, precisely because with a proper playcount listening to a song for an hour for example takes a substantial chunk out of your day, and deserves some ratings reward.

Here's what your modification does to duration as against removing d2 entirely (based on % of original track length):



ps. The formula you posted:


Which DAR version is this (I'm assuming it's the original one I posted - L^2 etc ...) but I was a little confused by this:

I looked at DAR TF code and extracted formula

C.

[Yirkha]

"TF code" = simply "title formatting code"?

[Takaji]

Very interesting algorithm! I'm having fun trying to calibrate it properly.
One thing I've noticed is that DAR seems to be more informative when looking at a playlist on the whole; if one uses the "dot" dating system to compare tracks in a single album, they all seem to come out the same, making it hard to tell which tracks on the album are the "best."

For example, I've got an album with playcounts like 24,7,7,9,11,3, etc... and ratings like 3/5,4/5,5/5...
Yet the DAR dot rating shows almost all the tracks as a 5 or 6.

One workaround that I think might satisfy some people (and me) is if instead of using dots, you could just output a more precise rating, like 7.8, 8.2, 3.4, etc... then I think the DAR dot rating may be more helpful when looking at a single album or group of tracks. I would do this myself, but I'm not that familiar with the code/math required.

Could someone provide a simple fix? Obviously the dots would no longer be needed.