northwall, this may help explain:

Example 1:
Played for the first time 1 day ago (Last Played)
Was added 2 days ago (Age)
Thus the difference between when it was Added and when it was First Played is 1 (A:FP).
However because it has not been in the Library for more than a week (Age = 2) it gets a "pseudo rating" of 10000.



Example 2:
Played twice.
Was Added 53 days ago.
Was First Played 16 days after it was added.
Because it has been in the Library for more than a week (Age = 53) it gets a proper rating* (see below).
Furthermore, because it was First Played 16 days after it was Added. It is penalised to the tune of 40 ratings points (Pen):

((First Played - Added) x 5) / Play Count

or:

(16 x 5) / 2 = 40.

* "In the first few days the rating is "vulnerable" to skewing caused by the "plays per time period" problem. Obviously if you add a new track and play it twice (the 2nd track in the list is a good example of this) and then extropolate that behaviour you'd listen to it 730 times a year. The formula's pretty good at smoothing this out after 4 or 5 days. Thus the pseudo rating is there to prevent brand new tracks from jumping straight to the top of the ratings"

Hope that's helpful.

C.

Hello Carpman,

yes you're right i'm using foo_DAR_full v.3
Now i have tried to set the systemdate at the end of may. The rating i'm getting now is higher 10000. So i think everything is working fine. My Problem was that the ADDED-date is today and the first tests of foo_DAR is also today. So the rating is 10000.

I would like to use foo_DAR for rating automatically. In an Autoplaylist i can see the songs with the highest rating. So i can sometimes play the "Highest Rating Autoplaylist". But i think it is important, that the rating is done automatically. Do you think this is possible ?

Why i like the code is, that skipping a song does not take effect to the rating.


Northwall

1) I don't quite know what you are doing, but the rating is done automatically. The image above is from an autoplaylist, the ratings are calculated and displayed in real-time and in order.
(However, I've just noticed that the code in post 2 does not paste well into DUI's custom columns setup. I'll change the code format to work around this.)
Are you using foo_autoplaylist? If so simply copy and paste the code for the autoplaylist in post no.2 and that should work. That's what it's there for.


Skipping a song does effect the rating (if you have foo_playback_custom and foo_custominfo and foo_DAR_full). But only after it is skipped more than once. The reason for this is:
a) the relevant section of the formula is: played - (skipped / 2) and foobar rounds down so that 1 / 2 = 0, or 3 / 2 = 1.
b) Skipping a song is only registered if you hit next (not if you double click on another song) - i.e. by hitting next you are saying on Default Play: "I don't like this song enough to wait for it to finish, I'd rather listen to the next one now"; on Shuffle Play: "I'd rather listen to anything but this", either way this should affect the rating of the song.

Thanks for making me re-look at the DUI custom columns code entry boxes. I'll sort that out very soon.

C.

Updated Post #2

Now the codeboxes are formatted (one long line) so that you can paste easily into either Columns UI or 0.9.5's DUI's custom columns setup.

I've also updated the Setup Instructions for foo_DAR full to cover the Default UI (also useful for people not too familiar with foobar2k installing foo_DAR_noskip).

Contents:
1) TESTING WITH THE foo_DAR FORMULA TEST SHEET
2) SETUP INTRO
3) COMPONENTS SETUP
4) SETTING UP A FOO_DAR RATINGS COLUMN (in DUI and Columns UI)
5) RATINGS BENCHMARK USING CUSTOM INFO & FOO_DAR
6) RATINGS AUTOPLAYLIST

It's now a non-formatted .txt file so relevant formulas can be pasted directly into AutoPlaylist, Default UI and/or Columns UI. You can download it from Post #2 or the link above.

C.

Why it's offline?

The requested URL /stuff/foo_DAR/foo_DAR_full_setup_info.zip was not found on this server.

Which link are you clicking on?
Just tested all the links and they point here:
http://www.giantpygmy.net/stuff/foo_DAR/fo...tup_info_v3.zip

C.

Hello Carpman,

great work. Now it works as you descriped here. The fields DAR and DARSET are updated automatically.
I don't know what was wrong. All you described in your new foo_DAR_full_v3_setup_info.txt i have done before too.

It is right, your code is taking effect by skipped titles. I have done a experiment with Auto-Rating on my own in my first foobar (0.9.4.4). My formula looked like this: %playcount% / (%cwb_systemdatetime% - %firstplayed%). After trying it for a few weeks, i promised, that this was not a good way to rate songs. So i test your code.


Thanks a lot

Northwall

Hi Northwall

Glad you got it working. I think the explanation in the new setup file is a little better (especially re. DUI). Hope so anyway.

Just out of interest what code do you have in your "DARSET" column?
[I just added that as an optional benchmarking extra, courtesy of foo_custom_info really. I was using it initially in testing to measure the rate of ratings decay, and thought it might be nice for others if they were interested.]

C.

Hello Carpman,

in my DARSET-column i have the following code: %darset%

if you meant the DARSET in the Custom-Info Plugin:
$puts(ra,$mul($add(1000,$div($mul(%length_seconds%,$sub(%play_counter%,$div(%skip%,2))),100)),10))
$puts(dd,$div($add($cwb_datediff(%added%,%last_played%),50),10))
$puts(pp,$div($mul(%play_counter%,10000),$cwb_datediff(%added%,%cwb_systemdatetime%)))
$puts(pd,$mul($get(dd),$get(pp)))
$puts(pd2,$div($get(pd),100))
$puts(pd3,$div($mul($cwb_datediff(%added%,%cwb_systemdatetime%),125),100))
$puts(pd4,$div($get(pp),40))
$puts(pd5,$div($mul($cwb_datediff(%added%,%first_played%),5),%play_counter%))
$puts(pd6,$add($get(pd3),$get(pd5)))
$puts(r1,$add($get(pd2),$get(ra)))
$puts(r2,$add($get(pd4),$sub($get(r1),$get(pd6))))
$puts(r3,$ifgreater($get(r2),0,$get(r2),1))
$puts(r4,$ifgreater($cwb_datediff(%added%,%cwb_systemdatetime%),7,$get(r3),10000))
$ifgreater(%play_counter%,0,$num($get(r4),5),-----)


Greetings

northwall

Yeah that's cool.
So the custom info "snap-shot" code that you provided gives a static outcome as outputted by %darset%, whereas the DAR column is always giving "live" results, which are ranked, if used in conjunction with an autoplaylist, highest to lowest.

Excellent.
Thanks Northwall for the info. Glad you got it all working fine .

C.

Playback Statistics 2.1.3 (foo_playcount) has been updated and now imports the %added% tag (and %rating%) from files. It does not seem to have any adverse effects on foo_DAR that I can see.

hmm, i tried the new version, but for me there is no change.

see here:

http://www.hydrogenaudio.org/forums/index....st&p=563037

Ah, you're right in the post. I only looked at my "top rated tracks" autoplaylist which contain tracks that already had a play count. Tracks that had no play count didn't get their %added% tag imported. Good find.

metal_termite & Bollerkopp

Thanks for the info re. Playback Statistics.

Yes, I tested Playback Statistics 2.1.3 and had the same results as you. It didn't import %added% from tags to db. However, this is not really a foo_DAR matter; it's a GIGO (garbage in [leads to] garbage out) matter and in general, as far as the foo_DAR formula is concerned:

Garbage In: (e.g. where %added% is later than %first_played%) is a matter for the developers of the stats/playcount plugins.
Garbage Out: (where there is no garbage in) is a matter for me as it suggests the foo_DAR formula is not working as well as it might with valid data.

That said, thanks for keeping me informed, appreciate it.

Personally I won't be switching to Playback Statistics until:

1) they sort this %added% issue out
2) they include a skip count (so that at any time someone hits "next" a %skip% is registered).
3) it allows the user to set the % a track is played before it's counted as played (an added bonus would be to have this option for a %skip% count too, as a user could say if the track is skipped after 90% played don't count it as skipped).

C.

First thank you for this auto rating script. It works quite good for me. I modified it a little to suit my need.

Here's a version of foo_DAR_noskip v.3 that doesn't need foo_cwb_hooks for Columns UI. You need to enable "Make date info available" in Columns UI Preferences, Global tab. This does not work with DUI. The result is a little different than the original version due to me rounding off the date and Columns UI does not provide system minute and second.

Hi thuan

Looks interesting.

<edit>
Your code also seems to work with autoplaylist (I'm always surprised just how much code can be stuffed into that box). But as you said not with DUI (even if it did work I couldn't fit all that code into the custom column pattern box). [10/05/08: Doesn't work with Autoplaylist or DUI (as thuan stated below)]
</edit>


Well system minute and second is no big deal - there's a lot of rounding go on in the formula anyway - that's partly the reason for using such large numbers (a kind of replacement for decimal points).

My understanding, and I may well be wrong, is that with the new Playback Statistics users shouldn't need cwb_hooks. [Wrong]

Unfortunately there seem to be issues with exisiting %added% data not being imported into the Playback Statistics db.

It seems to me that Playback Statistics 2+ users need to check their date data is making sense (if foo_DAR is giving strange results this is the first place to look at present).
Ironically, this is where cwb_hooks is useful. e.g. I've been using:
$cwb_datediff(%added%,%first_played%)
to check the integrity of date data, while testing foo_DAR.

I had initially thought that one needed cwb_hooks to date stamp files, but am I right in understanding this is not the case?

Cheers,

C.

Erh I have used official playcount for a really long time, so I don't have such added tag until version 2.1 and the new one will sync added tag to first played as a patched work.

Newly added songs after upgrading to newest version work fine for me.

Thanks thuan

That's useful to know. So as far as Playback Statistics users go:
a) No problem if you're a new user starting from scratch
b) No problem if you're an existing user with no previous added data (as you said, it now creates %added% from %first_played%)

So the only problem is, if you have existing %added% data (whether in custom info db or in tags) and you want Playback Statistics to import that.

Thanks for clearing that up for me.

C.

thuan,
Your code seems to work with autoplaylist (see post below your code post).
Cheers,
C.

Are you sure? AFAIK those system time fields of Columns UI only work in its playlist views. So if it works in any other places really surprise me. And my setup doesn't have the old autoplaylist component currently. So could you double check it to be sure?

Sure, I'm just checking for myself too. I have to wait for play count test data to be > 1 day old.
C.

thuan

You're right and I was premature & wrong.
Your version does give an output in Autoplaylist, somehow (presumably it just omits all date related calculations), but not one that makes sense.

Simply put, your formula won't work, just as you predicted, in Autoplaylist.

I've edited the post above to avoid confusion.

C.

I updated my mod version of foo_DAR_noskip to use new functions in foobar 0.9.5.3 and optimized the code a little, it should be a little faster for ppl with less powerful systems or already complicated Columns UI scripts.

So does 0.9.5.3 also add %_system_year% etc? I was under the impression that it wouldn't.

As Peter said somewhere, no (it has been repetitively quoted) . But I use Columns UI so no problem for me.

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.

[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.

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?

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.

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

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

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.

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.

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 .

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

C.

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

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.

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.

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.

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?

Doesn't columnsui provide system time?

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

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.

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...".

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.

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

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


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.

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 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.


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.