Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Influence of song duration on probability of hitting NEXT (Read 25354 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Influence of song duration on probability of hitting NEXT

Reply #25 –
Quote from: Big_Berny on
Hi carpman,
this looks quite interesting!  Specially because I'm also developing a AutoRating-Script for MediaMonkey since two years.  Looks very similar by the way...

Are you maybe interested in a little 'joint venture'?

Hi Big Berny

What do you have in mind?

I don't know a great deal about MediaMonkey (aren't there 2 versions?) - I tried it not too long ago but found it too rigid - interface wise (that said it was a pretty brief test).

I'd be impressed if it was capable of recording total played time per track? (i.e. listen to a 2 minute segment one day and a four minute segment another and it records 6 mins played).

What variables does your script use?

Personally I'd really like to get this into some kind of outline (ultimately I'd really like it to work with foobar, as well as any other players that are capable). Results are looking pretty good, the problem is implimentation.

How's things with your script?

I'm working on some user defined variable at present as per what Lyx said:
Quote from: Lyx on
I agree with this that a "balance" between the two extremes is needed. However, the optimal point in-between may also depend on the listener. So in an optimal case, a slider which allows the user to set this balance himself (Score weighting: prefer longterm favorites <-----> prefer current favorites) , and which can update the scores in realtime, without invalidating previous data, would be part of the system.

Worked on this last night; there are 4 sliders that would allow the user a substantial degree of control.
I'd also like a save settings and an easy way to switch back to default settings. This is important for trouble shooting or sharing ratings etc.

Will post results when processed.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)
 

Influence of song duration on probability of hitting NEXT

Reply #26 –
Notice that if you are saving too much data (i.e. one DB-entry per play-stop period), you can reduce the amount of data for the price of less accuracy and a minor performance penalty. For example, you can have one DB-entry per track per day.... and then apply the scaling in realtime when reading the data. That would mean a massive reduction in data, for the price of not being able to differentiate the weighting inside of a day (but who needs that?), slightly higher CPU-use and not being able to merge stats from multiple DBs at finer granularity than a day (this affects syncing DBs).
I am arrogant and I can afford it because I deliver.

Influence of song duration on probability of hitting NEXT

Reply #27 –
Interesting thread.

While I agree that skip is a factor, I also submt that it can not be considered in a vacuum by itself, and that 'all other things being equal' simply does not exist.

Big Berny already has been working long on his auto-rate script, and there is also a different auto-rate script which has since seemingly fallen out of development and does not work with version 3 of MM (Diddeleedoo's auto-rate script).

Both scripts have/had some type of skip detection, which while not a native MM functionality, can be approximated via scripting.

Quote
I'd be impressed if it was capable of recording total played time per track? (i.e. listen to a 2 minute segment one day and a four minute segment another and it records 6 mins played).


Unfortunately, this is not tracked. However MM does keep a played table which tracks all completed play's history which can be used to build various historical views. Bex has an excellent play history script which can provide an enormous amount of info on your play history. It's like having last.fm charts but at a much greater detail.

The threads of the 2 mentioned auto-rate scripts, possibly already have some discussion/opinions on this particular topic (skip factor) and general auto-rating factors you (or others) might be interested in.

Big_Berny's Auto-Rate Accurate
DiddeLeeDoo's Auto Rate and Announcer

Influence of song duration on probability of hitting NEXT

Reply #28 –
Well, no. Only version 3.0 has been developed since the last year. I like it because it's very easy to create scripts which can be quite complex. But it only works with MediaMonkey. That's why I'd also like to create a plugin which is supported by different players. Unfortunately I don't have enough programming knowledge (except for Delphi maybe) to create such a plugin. At least I'd need some help.

At the moment played time is not recorded but I can implement it quite quickly. Because the script is already prepared for that feature due to the SkipCounter I already created and works very similar. I think I'll add that also in a future versions, could indeed be very useful. At the moment I use Played, Skip, DateAdded, DateLastPlayed, DateFirstPlayed.

EDIT: The PlayedTime-counter is implemented.

But the special thing behind the script is IMHO the autocalibration it has. This means that you define in the options how much of songs (in percent) you want to have with which rating. IF you set for example 5 stars to 5%, then always the 5% of songs with the highest point-value (calculated by the formula) will get 5 stars. This way you don't have to modify the ranges by hand after a while when the point-value of each songs increase.

The thing I want to do for the next version is also to create a linear formula which easily can be modified with sliders. Maybe we also could try to find a good formula. One idea I also have and probably would be possible with an external plugin is that formula is based on the ratinglogic of the user. So you rate some songs from your library and the plugin then tries to find out which variables are how important to you. This could easily be done with a multivariate regression analysis.

Big_Berny

Influence of song duration on probability of hitting NEXT

Reply #29 –
Big_Berny

It looks pretty sophisticated. I'm pretty sure that such a scipting language imposes far less constraints than foobar's Titleformatting language which obviously was not meant for such calculations (as the name implies it was mean to format titles); this has led to a departure in foobar2000's recent development, though I have no doubt a far more suitable alternative will replace the dreaded Title Formatting "code".

A couple of interesting things have been raised in this thread:

1) SKIP COUNT
This, as has been pointed out, is pretty ambiguous. So my feeling is that if it is to used it has to be used with caution and should only have a subtle negative influence on the ratings. 
2) TOTAL PLAYED TIME
It seems we both like this as an important ratings variable (perhaps the most important)?
3) RESULT DISPLAY
This is an interesting area raised by your "Auto-Rate Script".
I personally like an accurate numeric value, clearly others like a symbol-based (stars/hearts) display.
An option to show either one or the other or both would be nice.
eg. foo_DAR gives a rating between 00001 and ... well, anything over 10000 is good something around 11000 is the highest I've got so far.

One thing I quite like about this is that ratings are universal, so, in theory if everyone selected a default setting they would be able to understand each other's ratings. Just a thought.
Quote from: Big_Berny on
This could easily be done with a multivariate regression analysis.

Good, I can leave the complicated stuff to you  .

I'm more than happy to post an outline of how the ratings are calculated in foo_DAR (or rather how they would be if it could calculate total play time). Also you're welcome to have a look at the test spreadsheet and test it out, see if there's any ideas in there you like. Like I say it's not rocket science, but it does a lot with a little and most importantly I've been very pleased with the early "field test" (which mirror "modelled" testing) results.

DAR should really become: DADAR (date and duration adjusted ratings), or DADA Rating.
Quote from: Big_Berny on
The thing I want to do for the next version is also to create a linear formula which easily can be modified with sliders. Maybe we also could try to find a good formula. One idea I also have and probably would be possible with an external plugin is that formula is based on the ratinglogic of the user. So you rate some songs from your library and the plugin then tries to find out which variables are how important to you.

Personally, although I like the slider idea of your's and Lyx's to give a degree of tuning over to the user, I also like the idea that it should just work, and regardless of listening habits, should reflect the user's REAL likes and dislikes. That, IMO is the purpose of an Auto Rating algorithm - to accurately reflect what the user actually likes (rather than what they think they might like - which is what manual star ratings do). 

Quote from: Lyx on
Notice that if you are saving too much data (i.e. one DB-entry per play-stop period), you can reduce the amount of data for the price of less accuracy and a minor performance penalty. For example, you can have one DB-entry per track per day.... and then apply the scaling in realtime when reading the data. That would mean a massive reduction in data, for the price of not being able to differentiate the weighting inside of a day (but who needs that?), slightly higher CPU-use and not being able to merge stats from multiple DBs at finer granularity than a day (this affects syncing DBs).

@ Lyx ---- Didn't understand this bit: "and then apply the scaling in realtime when reading the data".
But overall I'm pretty sure I agree. Certainly there is no need to have date related calculations going any finer than units of days.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

Influence of song duration on probability of hitting NEXT

Reply #30 –
You know, there is one thing that will throw off probably any type of auto-rate add in..

That alot of people simply play on shuffle/random with no weight being made of ratings or other play history.

Of course there are various implementations of 'smart' shuffle for different apps, but really I would expect that the manual selection of tracks is less common than whatever shuffle mode is available to a user of a particular app.

I myself mostly use a shuffle (script) based on last.fm relationships (both directly related tracks and/or related artists's tracks).

Perhaps my use scenario is not common, but what I would expect of any auto-rate based upon my listening is going to be spread between what I specifically choose to play, and popular/related tracks/artist. Depe

Which is fine with me, but this is because I am aware of the skewing this has on auto-rating.

Influence of song duration on probability of hitting NEXT

Reply #31 –
Well IMHO the PlayCounter is more important than Total Played Time. Because I for example always listen to albums, so the PlayCounter of the songs is often the same. But that doesn't mean that I like longer songs more! But since I also want to pay attention to when a song only has been half I replaced the variable PlayCounter with (Total Played Time/Songlength). So I get values like 4.3 when a song has been played a bit more than 4 times.
About SkipCount you're right. That's also why the SkipDetection can easily be disabled in my script. And it only counts a Skip when at minimum 10 seconds and at maximum 80% of the song. Since the formula can be modified very easily you also can disable the influence of Skips.

And my script also is able to store a point-value in a customfield although the values are a bit high and don't look so nice like yours.
The idea behind the ratings is that they are also visible on portable players. For example on my ipod. So I can create a playlist on my ipod where I always find all my moste preffered songs with 5 stars. And the problem with point-values is IMHO that you have very low values at the beginning with a fresh database. But in reality that oesn't mean that you like non of your songs. You know what I mean? That's why my script compares all songs and rates the songs with the highest points with the highest ratings. If the points are only 100 or 100000 doesn't matter.

And compared to you I don't think the ratings are universal. Each person has its own listening habbits. So the formula to get the ratings (or points) isn't the same for all people and has to be adjusted. For example some people skip a lot of songs because they change the song quite often. Other people skip versy seldom and if they really skip it means that the son't like the song at all. So IMHO the formula has to be adjusted to the user to show what he REALLY likes. I also not interested in what the user might like but what he actually likes. Different views here?

@Teknojnky: I also use Auto-DJs but IMHO it doesn't affect the autoratings too much because 1. I also skip a song if I don't like it and 2. I don't use Auto-DJ all the time, mostly I use my ipod. So at least with my listening habbits it has not a big effect. But I understand that this could be a problem for some users...

Big_Berny

Influence of song duration on probability of hitting NEXT

Reply #32 –
Quote from: carpman on
TOTAL PLAYED TIME
It seems we both like this as an important ratings variable

Quote from: Big_Berny on
Total Played Time/Songlength.

Which is using Total Played Time as a variable.
Precisely. Total Played Time/Songlength gives you a more precise Play Count.
So no disagreement there.
Quote from: carpman on
And the problem with point-values is IMHO that you have very low values at the beginning with a fresh database.

Not necessarily - that all depends on the algorithm.
The foo_DAR ratings for example will probably vary (depending on size of collection) betweem 7000 and 11000.
A new 3 minute track played only once after the first 30 days since added (and only played the day it was added to the library) will have a rating of: 10005.
Quote from: Big_Berny on
So IMHO the formula has to be adjusted to the user to show what he REALLY likes. I also not interested in what the user might like but what he actually likes. Different views here?

I'm not sure. It looks to me that the two ratings systems are taking a different approach; probably equally valid. What would be fun is to run them side by side. Equally you might find interesting things happen when you use one to weight the other or simply multiply one by the other.

I quite like the idea of an application / component that allows the user to choose from a variety of ratings schemes. Cleary there's no absolutely right answer to the ratings problem. topdownjimmy wrote a hotness algorithm for foobar2k, again this is doing something completey different but equally valid.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

Influence of song duration on probability of hitting NEXT

Reply #33 –
Quote from: carpman on
Quote
And the problem with point-values is IMHO that you have very low values at the beginning with a fresh database.

Not necessarily - that all depends on the algorithm.
The foo_DAR ratings for example will probably vary (depending on size of collection) betweem 7000 and 11000.

Ok, so your ratings aren't really universal either? If the ratings depend of the size of the library...

Well my gain just is to create a "ratingbot" which is able to rate like the user would. Like AI.  I know that this is not completely possible but I think it could work quite good. And you can calculate the validity (grade of quality of the prediction) quite good.

I also think that your formula easily could be added to my script. You'd like to try? That's the Formula I use at the moment:
Code: [Select]
(10000000 * (7+PlayedTime/SongLength*60-(Skip*0.98^(SongLength/60))^1.7)^3 / (10+DaysSinceFirstPlayed)^0.5) / (1+DaysSinceLastPlayed/365)

Could you translate your formula in similar terms or is it not possible?

Big_Berny

Influence of song duration on probability of hitting NEXT

Reply #34 –
Quote from: Big_Berny on
Quote from: carpman on

Quote
And the problem with point-values is IMHO that you have very low values at the beginning with a fresh database.

Not necessarily - that all depends on the algorithm.
The foo_DAR ratings for example will probably vary (depending on size of collection) betweem 7000 and 11000.

Ok, so your ratings aren't really universal either? If the ratings depend of the size of the library...

No they are. The reason I said it depends on the library is obviously if someone has 100,000 tracks and someone else has 1000 track and they both listen to their music for 2 hours a day. The person with 1000 tracks will generally have higher ratings, purely because he is recycling the same tracks more often. However, if they both added, the same track, at the same time and listened to it the same amount etc ... they would get the same rating.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

Influence of song duration on probability of hitting NEXT

Reply #35 –
Quote from: Big_Berny on
I also think that your formula easily could be added to my script. You'd like to try? That's the Formula I use at the moment:
Code: [Select]
(10000000 * (7+PlayedTime/SongLength*60-(Skip*0.98^(SongLength/60))^1.7)^3 / (10+DaysSinceFirstPlayed)^0.5) / (1+DaysSinceLastPlayed/365)

Could you translate your formula in similar terms or is it not possible?

I've translated the foo_DAR formula, and have included a number of proposals regarding what I'd like it to do as a component, here.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)