foo_DAR: auto rating

Topic: foo_DAR: auto rating (Read 126627 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

foo_DAR: auto rating

Reply #75 – 2008-05-12 05:08:22

I've been thinking about a possible workaround to the system date time issue. I don't know if this is possible, but can foobar return the time/date value of the last played song "globally"?

So let's say that song X is played, ALL songs pull the last played value of song X, then song Y is played and ALL songs pull the last played value of song Y. i.e. foobar uses its %last_played% track (whatever it is) as a kind internal stop watch.

Or would this still cause the problems Peter highlighted?

Thoughts anyone?

C.

foo_DAR: auto rating

Reply #76 – 2008-05-12 08:29:46

[Purely speculation]
I have two scenarios:
Peter implementing a good enough automatic rating algorithm for everyone and provide it through a field. It should have mechanism to announce that it has changed so other display components can refresh themself (I guess it's possible as it's just like refreshing changed tag). I wonder why this hasn't been implemented for so long (IIRC it had been requested a bunch of times). It's kind of limited but it should work well without the aforementioned problem.

Another scenario is a developer (either first party or third party) releasing a component that does the same of what I said above and might provide ability for users to script (with whatever suitable as a scripting language) their own rating algorithms and provides the result through a field through the new API mentioned in the first post here http://www.hydrogenaudio.org/forums/index....c=62286&hl=.

Your scenario seems a little patched up to me. And again it also relies on alteration of another field which is again the same as a time field IMHO.
[/Purely speculation]
Of all the previously mentioned scenarios, I like the 2nd option the best. Hope it will happen some day.

Currently I did encounter Peter mentioned problem once or twice (maybe I'm not even sure it's the problem) which my set up (using the first mod code not the one with functions from 0.9.5.3b1) making NG Playlist with Artwork blinking when %_system_hour% changes. But for some time now, I haven't encountered it again, so I didn't report it to MM.

EDIT: just encountered the blinking problem again, guess I will report it later.

foo_DAR: auto rating

Reply #77 – 2008-05-13 17:28:56

Hey!
I want to use CODE foo_DAR_noskip but not using foo_playcount only foo_playback_custom.dll (because you can yourself qualify when the statistics has update).
So can I use CODE for foo_DAR_noskip but I must to change %play_count% on %play_counter% and it will be OK?

foo_DAR: auto rating

Reply #78 – 2008-05-13 18:23:54

Hi Pasta

To answer your question I need to know what it is in foo_DAR_noskip that appeals to you over foo_DAR_full, or what is it about foo_DAR_full that is less appealing than foo_DAR_noskip.

Ultimately I can only think of 2 possible reasons:
1) not using %skip%
2) you prefer the duration "flattening" in foo_DAR_noskip

Let me know and I'll explain whether you may need additional steps beyond just changing %play_count% to %play_counter%.

Also, you should be (and probably are) aware that this formula (and foo_custom_info) will only work with foobar versions prior to 0.9.5.3.

C.

foo_DAR: auto rating

Reply #79 – 2008-05-17 10:07:11

Hey!
I use foo_DAR already since the week and has all the time raking 10000

foo_DAR: auto rating

Reply #80 – 2008-05-17 10:08:25

Did you put the wrong code in for foo_DAR_noskip in your post, Carpman? I see %skip% in it.

foo_DAR: auto rating

Reply #81 – 2008-05-17 13:51:35

Quote from: pasta on 2008-05-17 10:07:11

Hey!
I use foo_DAR already since the week and has all the time raking 10000

All that means is that %added% is < 8 days old.

Pasta have a look here and here and also this post will show you how to test this to see if foo_DAR is working.

If you are getting 10000 for everything, that actually means it's working - you need to check your %added% date. It will likely be very less than 8 days old.

@Thuan:

%skip% stayed in the foo_DAR_noskip code to make it easier to switch (i.e it doesn't matter if %skip% is in the code if you don't have any %skip% data, which you shouldn't). If you do have %skip% data but don't want it to affect the rating then that's a different issue.

This is why I asked Pasta these questions.

C.

foo_DAR: auto rating

Reply #82 – 2008-05-21 03:18:20

Okay, this is a kind of pre-proposal for a foo_DAR ratings component.

This has come about for a number of reasons:
a) I totally see where Peter is coming from in regards to Title Formatting and the various components that have mis-used it (see here for why).
b) I recently asked a question in the General HA forum regarding the treatment of SKIPPING and it led to an interesting discussion on the problems of interpreting a %SKIP% (It doesn't get any more profound than the meaning of hitting NEXT ).

However, it solved a number of issues:

1) You can ignore %skip% and %play_count% entirely if you record Total Playing Time (TPT) (thanks to Roseval for this).
Additionally if you divide TPT by %track_length% you get a perfectly accurate Play Count. Furthermore, this solves the problem raised by Martel regarding Techno Mixes etc..
2) A database is required and there are a number of issues that will need to be resolved regarding the frequency of Read/Write. Lyx has been helpful in this regard and there are technical issues that will have to be resolved; examples here and here.
3) The component would have to handle the following variables:

DAD = Days Since Added (to Library)
DLP = Days Since Last Played
DFP = Days Since First Played
TPT = Total Playing Time (total recorded playing time in seconds)
TL = Track Length (in seconds)

Notice that the smallest date unit required would be DAYS. However, there is a need to record System Date, so the component would have to do this by itself outside of foobar's core. What I would like is for the component to gather data, store it, run calculations and return a rating value which foobar2000 would pick up as though it was just another piece of meta data. This, I think, would bypass any issues relating to repainting glitches.

I won't go into how this can be done, because I don't know. However, below I'll outline what I would like such a component to do, and also suggest how the interface would allow the tuning of the ratings algorithm very easily and effectively so it's aligned with how the user listens to their music (especially the "Individual Track" vs. "Album" listeners - Yes, I know it doesn't split down the middle like that, but that's the point of tuning).

Below is the ratings formula and some graphs to show the potential effect of user controlled variables in foo_DAR:

DATA REQUIRED

DAD = Days Since Added (to Library)
DLP = Days Since Last Played
DFP = Days Since First Played
TPT = Total Playing Time (total recorded playing time in seconds)
TL = Track Length (in seconds)

The values in red are one's which would be controlled by sliders:

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

R0 (Rating Stage 0: This is the foundation of the Rating, without any date adjustments + penalties etc) =

(((((TL + 60) x 0.75) x (TPT / TL)) / 100)) + 1000) x 10

Note: ((TL + 60) x 0.75) smooths the Track Length around the point of 3 minutes (so everything < 3 mins gets increased and everything > 3 mins gets decreased.

The slider works with the following:

0. (TL + 0) x 1/1
1. (TL + 30) x 6/7
2. (TL + 60) x 3/4 (Default)
3. (TL + 90) x 2/3
4 (TL + 180) x 1/2
5. (TL + 540) x 1/4
6. (TL + 1620) x 1/10
7. (TL + 3420) x 1/20
8. (TL + 86220) x 1/480

As you can see if you purely listened to albums then you wouldn't necessarily consider a 10 minute track more important than the 3 minute track that precedes it (Levels 6 to 8 would be suitable). However, if you listen to individual tracks and shuffle things around much more, then you may want to weigh a track that takes up 40x more of your life/attention higher than a 1 minute ditty.

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

DD (Date Difference Multiplier) =

((DAD - DLP) + 50) / 10

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

PP (Play Per Period Multiplier) =

((TPT / TL) x 10000) / DAD

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

PEN1 (Age Penalty) =

DAD x 1.25

If a track has been in the library for 2 years, it is likely to have been played far more than a track that has been in the library for 1 week. This is the purpose of the Age Advantage suppression slider:

Level
1. 0.50
2. 0.75
3. 1.00
4. 1.10
5. 1.20
6. 1.25 (Default)
7. 1.30
8. 1.40
9. 1.50

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

PEN2 (Penalty for Not Getting Around to Playing a New Track) =

((DAD - DFP) x 5) / (TPT / TL)

Slider would select a number between 1 and 10 with 5 being the default.

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

TPEN: Total Penalty

PEN1 + PEN2

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

R1 (Rating Stage 1)

R0 + ((PP x DD) / 100)

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

R2 (Rating Stage 2)

(R1 - TPEN) + (PP / 40)

This suppresses the advantage of new tracks (e.g. if you add a new track and play it twice and then extrapolate that behaviour you'd listen to it 730 times a year). This suppresses that advantage.

Slider scale from:
1. 20
2. 30
3. 40 (Default)
4. 50
5. 60
6. 70
7. 80
8. 90
9. 100

This is what happens when both the New Track (Play Per Period) Suppression and the Age Advantage Suppression variables are applied together, first in tandem (i.e. both from low to high):

then inverted, Age Advantage (low to high); New Track Advantage (high to low):

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

R3 (Rating Stage 3: Set Rating Floor at 1)

IF R2 > 0 THEN R2 OTHERWISE 1

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

R4 (Rating Stage 4: Set Pseudo Rating for New Tracks < 8 days old)

IF DAD > 7 THEN R3 OTHERWISE 10000

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

OUTPUT RATING:

IF TPT > TL THEN R4 (padded from left with 0s) OTHERWISE DISPLAY "------"

i.e. rating 2 songs, one rated 8500 the other not rated looks like:

SONG1 08500
SONG2 -----

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

Additionally I would like the user to have an option as to whether to display symbols or a numeric value. Personally I prefer the latter, but I think many would like "something easier on the eyes", like a star rating system. I'd like the user to have that option.

That's it for now.

I'd be very interested in people's view as to how this could be implimented (in a way that avoids the pitfalls of older components that have now found themselves defunct).

Lyx has already been extremely helpful and I hope to have addressed a number of issues he raised in this thread.

The questions are, a) technically how can this be done? and b) is it worth it?
I'll answer (b). YES, IMHO.

What about (a)?

C.

foo_DAR: auto rating

Reply #83 – 2008-05-21 05:18:38

Erh, I have missed out on the discussion due to I only lurk in this sub forum here. Anyway, after a quick look through your post and the other thread (I'm working now), it seems like I don't have anything more to add to the "way" you had come up with to calculate rating (well I'm the kind of guy normally just let foobar in the taskbar and listen album after album, so custom ratings by me is more important). Also, to top it off, there's no such thing as an omnipotent algorithm to satisfy every cases for this kind of calculation, in the end you have to dumb it down and make compromises.

As far as I have seen, it's definite enough (I can't be sure I might miss some thing) to be called an algorithm and with the way foobar now, I think it's possible to create a component that will provide this value just like any normal metadata fields as you and I have said in one of our respective posts. So to me a YES for question A.

For B, unfortunately for me it might not worth it . As I have said, with the way I listen to music, even your old method or this seems to be redundant to me. But yes for others who have more sophisticated listening habits and want an objective value to judge how they feel about each song, it is worth it.

OT, it is always nice to read posts by Lyx, he always manages to create deep and mind bogging posts. I nearly had to pull out my English dictionary .

foo_DAR: auto rating

Reply #84 – 2008-05-23 02:13:23

Quote from: thuan on 2008-05-21 05:18:38

OT, it is always nice to read posts by Lyx, he always manages to create deep and mind bogging posts. I nearly had to pull out my English dictionary .

I did have to get out my English dictionary; but it didn't help me.

C.

foo_DAR: auto rating

Reply #85 – 2008-05-27 17:40:53

hi,

is it possible to create a autoplaylist from DAR - but only with ratings of (for example) 10001 and above? that would be really great.

sorry, if it's not the right place here with a autoplaylist-question.

greets

foo_DAR: auto rating

Reply #86 – 2008-05-27 19:18:18

Hi Bollerkopp

I don't think it is possible; which is a shame.
It's one of the reasons I suggested this because with such an autorating component it would operate outside the foobar2k core and would supply the ratings result as a %meta_field%. That way making an auto-rating auto-playlist would be very easy:

%foo_DAR_rating% GREATER 10001, or
%topdownjimmys_hotness_rating% GREATER 5 or whatever

That's what I'd like to see, but I think it requires:
a) enough people interested in a user friendly multi auto-ratings component
b) someone with the technical skill and interest to put it together

Easier said than done.

C.

foo_DAR: auto rating

Reply #87 – 2008-05-27 19:48:46

ok, thank you for the answer. yes, it's really sad.
the methode in your link would be really great.
maybe someone will do the difficult job - It is much to be hoped.

foo_DAR: auto rating

Reply #88 – 2008-06-07 19:08:11

Hey!
Someone tested foo_DAR: auto rating, date & duration adjusted ratings formula on foobar2000 v0.9.5.3?

foo_DAR: auto rating

Reply #89 – 2008-06-08 00:01:31

Quote from: pasta on 2008-06-07 19:08:11

Hey!
Someone tested foo_DAR: auto rating, date & duration adjusted ratings formula on foobar2000 v0.9.5.3?

Won't work. Needs system date/time function (which cwb_hooks provides) and this isn't allowed with foobar2000 v0.9.5.3.

See Peter's reasons here and what I think would be a solution here.

C.

foo_DAR: auto rating

Reply #90 – 2008-06-27 13:16:28

Would it be possible to make an alternative version of foo_dar that is compatible with foobar2000 0.9.5.3+ -- A version that doesn't require a system date/time function?

foo_DAR: auto rating

Reply #91 – 2008-06-27 13:26:09

Doesn't columnsui provide system time?

+1 for an integrated component if it's possible to use efficiently.

foo_DAR: auto rating

Reply #92 – 2008-06-27 14:42:55

metal_termite,
simply, no. foo_DAR requires system date function.

odyssey,
yes columnsui does provide system time, and AFAIK someone recently updated topdownjimmy's Hotness code to work with Cols UI, so it probably can be done.

First problem is I'm pretty busy right now.
Second problem is this wouldn't work with an autoplaylist - which kind of defeats the point. The nice thing about foo_DAR with the old setup was that it would fit in an autoplaylist box.

Really what I was after when I wrote it was a playlist that told me what I really liked (long and short term combined) - it's working fine for me, but then I'm using 0.9.4.3.

The real solution (and thanks odyssey for the +1), is a ratings components that does the calculations (and system time functioning) outside of foobar. That way it could simply calculate the data and then return a value as a piece of meta data (i.e. %foo_dar%). Furthemore it could do it very efficiently because it would be using a syntax that was designed for calcs.; foobar's designed to play music not do maths.

If that was done, then all the nice new stuff in 0.9.5 would really work well i.e. facets with %foo_dar% GREATER x etc.

Also as I suggested a ratings component if implemented properly would work as platform for all kind of ratings systems, not just foo_DAR. Requires some will and organisation.

As far as getting it working in 0.9.5.3+, if I find time I'll look into it, but absolutely no promises, and right now it's unlikely.

If anyone else has the time and inclination -- please go ahead.

C.

EDIT: Here's a link to some relevant code should anyone wish to get their hands dirty.

foo_DAR: auto rating

Reply #93 – 2008-06-27 17:12:11

I did make a columns ui column only foo_dar rating in previous page or the page before that. You can try it if you like.

EDIT: Of course, you need to enable "Make date info available...".

foo_DAR: auto rating

Reply #94 – 2008-06-27 17:45:34

Sorry thuan, I'd forgotten you'd done that.
I'll add your mod to the front page - when I get a moment, also I'll set up a new foobar install with 0.9.5.3 and run your code.
I've been using the old version, but testing with some minor modifications.

Thanks for posting your version.

Since I've tested foo_DAR for quite a while now, I've come to the conclusion that I could live without the %skip% element, but one thing stops me from adopting the official foo_playcount and that is the fact that you can't set % played before considered played (and this can really skew foo_DARs results and make them rather meaningless).

thuan's version is here.

C.

foo_DAR: auto rating

Reply #95 – 2008-06-28 09:38:37

Quote from: carpman on 2008-06-27 14:42:55

The real solution (and thanks odyssey for the +1), is a ratings components that does the calculations (and system time functioning) outside of foobar. That way it could simply calculate the data and then return a value as a piece of meta data (i.e. %foo_dar%). Furthemore it could do it very efficiently because it would be using a syntax that was designed for calcs.; foobar's designed to play music not do maths.

If that was done, then all the nice new stuff in 0.9.5 would really work well i.e. facets with %foo_dar% GREATER x etc.

Also as I suggested a ratings component if implemented properly would work as platform for all kind of ratings systems, not just foo_DAR. Requires some will and organisation.

If it's implemented as a component, I guess it needs to be aware of eigher tags being modified in the current playing file*, or aware that the playcount has changed (dunno if the API allows something like that) for it to be updated properly, otherwise %foo_dar% would be outdated until it's recalculated.

* I would actually very much like to know that

foo_DAR: auto rating

Reply #96 – 2008-06-30 04:03:49

Odyssey, just out of interest have you read my "proposal / question" on this matter?

Quote from: odyssey on 2008-06-28 09:38:37

If it's implemented as a component, I guess it needs to be aware of eigher tags being modified in the current playing file*, or aware that the playcount has changed (dunno if the API allows something like that) for it to be updated properly, otherwise %foo_dar% would be outdated until it's recalculated.

It seems to me that the latter is more important, but perhaps not necessary.
My suggestion was to bypass "play counting" all together, and instead have the component record total time played per filename and store that in a DB, thus "total played time" / "track length" = play count.

It's a good way to eliminate the need for skip counts, and gives you a far more accurate reading than foo_playcount, as I can play first 1 min of a 10 min song 10 times and foo_playcount says I've played it 10 times, "total played time" / "track length" says I've played it once > not entirely accurate but far, far closer to the truth.

Such a component would simply need to know:
a) active filename
b) playing status (i.e. differentiate between paused and playing etc.)
c) the time at each relevant change.

Pretty much the same as someone with a stopwatch who looks at the header for track changes, the status bar to see if the track is actually playing and records and sums the data in a db. Other data required for calculations can be pulled from foo_playcount now that it does %added%, %first_played% and %last_played%.

So the component would need its own database but it would be very light as it's only holding total played time data. Aside from that it would be doing calculations. EDIT: And offering the data back to foobar2k periodically (as a low priority process) in the form of, for example %foo_DAR% or %hotness% or whatever rating scheme the user employs.

C.

foo_DAR: auto rating

Reply #97 – 2008-06-30 04:34:01

Quote from: carpman on 2008-06-30 04:03:49

It's a good way to eliminate the need for skip counts, and gives you a far more accurate reading than foo_playcount, as I can play first 1 min of a 10 min song 10 times and foo_playcount says I've played it 10 times, "total played time" / "track length" says I've played it once > not entirely accurate but far, far closer to the truth.

Bravo! Your solution manages to solve the inadequacies of the current system quite well; Maybe we should request %play_time% or something be made part of the official play count component.

foo_DAR: auto rating

Reply #98 – 2008-06-30 08:21:24

Quote from: carpman on 2008-06-30 04:03:49

My suggestion was to bypass "play counting" all together, and instead have the component record total time played per filename and store that in a DB, thus "total played time" / "track length" = play count.

I wouldn't like that. I don't depend on my filename on anything, since i regularly might change them. However, what prevents you from writing it to a tag?

foo_DAR: auto rating

Reply #99 – 2008-06-30 18:45:34

Quote from: odyssey on 2008-06-30 08:21:24

I wouldn't like that. I don't depend on my filename on anything, since i regularly might change them. However, what prevents you from writing it to a tag?

Nothing. I think that it should be up to the user. But IMO audio files were never designed to be perpetually altered; whereas databases are (this is especially the case regarding dynamic ratings data linked to time, as it changes perpetually). A plus side of storing play stats in a database is backups: with a DB you are backing up all the info in one file. If you want to backup your play stat data held in tags you have to backup gigabytes of data. But that's just my opinion / preference; ultimately I agree with you, it's a user's choice, how they wish to store their data and use their file system.

Quote from: kanak on 2008-06-30 04:34:01

Bravo! Your solution manages to solve the inadequacies of the current system quite well; Maybe we should request %play_time% or something be made part of the official play count component.

I think having that as an option in the official playcount would be excellent. I'd certainly back any request for this. Whether foo_playcount just records total play time or actually creates an alternative play count based on "total played time" / "track length", I'm not too bothered. If it did the latter it would want to always round down to the nearest integer.

Of course, if this was implimented then it would remove the need for the additional DB - which kind of answers Odyssey's point.

C.

ps. What is important, and it's not something I know about, is the ability for 3rd party plugins to access the foo_playcount data.