AutoRateAccurate 2.4.3 (22/10/2009) - for MM3

[Big_Berny]

@drjboulder: No problem, you did nothing wrong. Theoretically there should be no problem whether you uninstall first or not. Also the bug with you mentioned about opening the Advanced-subsheet first should be fixed. That's why I asked what you did exactly.

The next time I work on it I'll try to fix your problem.

[Big_Berny]

Ahhh! Got it!

Fixed in 2.0.2.1. Thanks for reporting!

Btw nothing else changed from 2.0.2 so you don't have to update.

PS: Just thought that AccurateAutoRate would make more sense thn AutoRateAccurate, right?

[Guest]

I love this script - I never bothered to rate songs myself. So many thanks. But..

(probably my fault) I am having some issues.

I have a library of 1300 songs. In options I go the AutoRateAccurate tab and enable it. The %s that each rating should get look good to me but seem to have no resemblance on what actually happens.
I have 5 stars set to the default 1% but in my library 105 songs have been given 5 stars which is ~8%.
There are many other inconsistencies like no 1, 1.5 or 2 star ratings even though I am using the default percentages. I am on about 350 plays since installing the plugin but 1000s overall.

Some questions, mainly curiousity ones that you don't have to answer coz you likely have much more intelligent ones to deal with

1) I've set the 'Custom Field' to Custom 5 and not changed it. Is that correct? For the points, why do the numbers have to be so big, and are the ranges needed to get each star set/the same?

2) What can you change in the formula without causing an error? Even changing the 1.01^ to 1.02^ won't work.

3) Any idea on user error that causes the %s to not do their job?

Thanks

[Big_Berny]

Hi Guest,
hmm... That's strange. Do you use a really fresh database with low playcounts? Then it happens that the %'s are not correct. It's because too much songs get the same points wih the formula. With the default settings there also won't be any 1-star-songs (as it is set to 0%) and there will be 2% of 5-star-songs (not 1%).

1. Well if you change it to Custom5, the AutoRateAccurate-Informations will get stored into Custom5. Changes nothing with the rating (only if there already were skips in the old customfield).
The points are so high because the formula just calculated this value for the song. I just added "100000*" to the formula so that songs with very low points (when playcount is low) don't get all the same the values are rounded. So it's just to get more variety in the very low range.
This one "and are the ranges needed to get each star set/the same?" I don't understand. The script just sorts all the songs by the points they get with the formula and then it rates the 2% with the highest points with 5-stars, the following 6% get 4.5-stars, and so on.

2. This one doesn't happen here, I just tested what you said... What error appears?

3. See the beginning of the post.

Nice that you like the script! And naturally I like to explain how it works.
Big_Berny

[Tictac]

I'm the guest from above, I didn't realise I was posting without an account

With reference to the "and are the ranges needed to get each star set/the same" my comment was misguided as I was thinking maybe songs within a range of (1 x 10^16) - (1.5 x 10^18) points would be given 5 stars. But this wouldn't be true because the ratings are relative to other points score.

With regards to changing the formula (the one in Tools > Options > AutorateAccurate e.t.c) if I change anything but how many zeros at the beginning of the equation I get this

http://i12.photobucket.com/albums/a231/ ... 13/MM1.jpg

then when I click enter I get this:

http://i12.photobucket.com/albums/a231/ ... 13/MM2.jpg

I get those 2 errors whenever I click to play a song.

Here is my custom 5 column for a selection of my 5-rated songs (should be only 1% of all songs but is actually 7%).

http://i12.photobucket.com/albums/a231/ ... 13/MM3.jpg

I wouldn't call my database fresh - my total playcount is 6815 and I think those points score look further enough apart?

I didn't realise I had changed the %s a little from default but my songs seem not to be arranging as they should?

Thanks for answering, sorry if my posts are a little jumbled

[Big_Berny]

Well 6000 plays isn't soooo much. I have over 20'000 here and it works... Do you have songs which you played very often? How big is your highest playcounter? Because then you get those high points which aren't supported...

Try this formula instead:

Code: Select all

EDIT: Look below!

Does it work?

And no problem! I want my script to be as stable as possible so each report is useful.

[Big_Berny]

Ok, I just released a new version which checks if the values aren't too high. Thanks Tictac for the idea.

I also improved the default formula: (should work for you, Tictac)

Code: Select all

Removed due problem

Since the settings won't be overwritten when updaten the script you have to change the formula by hand. Or you uninstall the old version first.

Good night
Big_Berny

[Big_Berny]

Sorry, but the formula I gave before didn't work in some cases! I'll change it tomorrow.

@tictac: For you this formula should work in the meantime:

Code: Select all

10 * ((Played-2*Skip)^5 / DaysSinceAdded / 1.01^DaysSinceLastPlayed)^0.5

[BerniPi]

Hello!!

I have some ideas for the script:

The last posts have shown, that the formulas that the script uses, are very sensitive to great values. That implies, that the formula has to be adopted from time to time (for example the dayssinceadded increases more and more, and also the fifth power of playcount can be a problem too).

I solution would be, not to use absolute values, but relative ones. For example dayssinceadded/maxdayssinceadded, instead of dayssinceadded and "played/maxplayed" instead of "played".


The second idea has to do with the skipcounter. In my country, there is point count on every driving licence. When you break some traffic regulations you get points, and the more points you have, the harder the punishment.
But these points have an expiration date, and this is also my idea for the skipcounter. The drawback is, that an extra value have to be saved. Let me call it skipdate.
so the script can decrease the counter by one after two months not skipped for example, and sets the skipdate on today, after another two months the counter gets decreased again, if it wasn't played in the meantime.

What do you think about these?

Berni

[Big_Berny]

Hi BerniPi,
thanks for you ideas. The problem is exactly what you said, that's also why I wanted to add the root in the last formula. I'll change the formula for the next version anyway. I want to use a linear formula but have first to do some analysis.

the fifth power of playcount can be a problem too.

Yes, I know that this is a problem. To be honest I just used ^5 instead of ^3 because a lot persons told that PlayedPerDay had too much influence.

I solution would be, not to use absolute values, but relative ones. For example dayssinceadded/maxdayssinceadded, instead of dayssinceadded and "played/maxplayed" instead of "played".

Yes, I had this idea too at the beginning but there are problems:
-To get the max-informations it always had to analyse all songs to rate one song. This would be no problem when autorating the whole library. But since the tracks also get autorated after you listen to them it won't work then. It would need a lot of time to analyze the whole library everytime.
-And also if the maxplayed would get analyzed each time it would get an inaccuracy because songs which have been rated before had another maxplayed...

The second idea has to do with the skipcounter. In my country, there is point count on every driving licence. When you break some traffic regulations you get points, and the more points you have, the harder the punishment.

I know!

But these points have an expiration date, and this is also my idea for the skipcounter. The drawback is, that an extra value have to be saved. Let me call it skipdate.
so the script can decrease the counter by one after two months not skipped for example, and sets the skipdate on today, after another two months the counter gets decreased again, if it wasn't played in the meantime.

Ok, that would work this way! But do you think this work well? Example: We have a song which has been skipped five times you probably don't like it. And then you dont' listen to it anymore. After a year the skip is zero - but do you think that you maybe like it then? I totally understand your idea, it's just a constructive critic to get best results. My idea now is, that the skipcounter just has less influence when you listen to a song a lot. So if you hear the song sometimes in the next year the skip isn't important anymore as its (Played - 2*Skip).

What do you think?

Btw thanks four your ideas! Cool that you think about that!

[BerniPi]

after a song has been playing, the new rating is determined by the script by calculating the points of the song and comparing it with the point-limits saved in the ini (calculated on calibration).
is this right?

a solution could be to calculate the maximum-values only on calibration and save it with the limits, and aren't changed until the next calibration.

Then the "on-the-fly"-rating of a song can get the maximum-values also from the ini-informations. It is fast and the max-vals are in sync with the limits.

about the second idea:
my personal formula i use now, don't use the (Played - 2*Skip), but (Played - Skip^2). because i think, that one time skipped happens sometimes and shouldn't have a great influence. but when i skip it more times, i really don't like it and the rating is therefore very low:

to show the difference:
original:
1 skip absorbs 2 plays
2 skips absorb 4 plays
3 skips absorb 6 plays
...

my formula:
1 skip absorbs 1 play (less then original)
2 skips absorb 4 plays (the same)
3 skips absorb 9 plays (much more)
...

I understand your Example and it isn't good, when a song gets played again, i really dislike and i wanted to never hear again.
but there are also songs, that aren't that bad, but get played at the wrong time. (for example a very fast and agressive song in moments of sadness or tiredness).

a solution would be to alter the proposed function.
first idea (easier): there is a limit for skipcounts, the function gets in action (the skipcounts aren't dicreased anymore, when the skipcount reached 5 counts)

second idea: the time between the decreases is dependent from the skipcount itself, for example skipcount*2 months or even harder 2*(skipcount)^2,2^skipcount, ....

then an accidental skip is corrected very fast (2 months) and a bad song with 5 skips gets reduced to 4 skips after 10, 50 or 32 months (the examples above, whereby the last value isn't representive for the real agressiveness of 2^x)

what do you think about this? technically it shoud be realizable, but is it worth the effort...


before i forget:
1.01^Dayssinceplayed can also cause an overflow for great values of dayssinceplayed. (i have tested a little bit with it, because i wanted to increase the influence of it)

[Big_Berny]

after a song has been playing, the new rating is determined by the script by calculating the points of the song and comparing it with the point-limits saved in the ini (calculated on calibration).
is this right?

Right!

a solution could be to calculate the maximum-values only on calibration and save it with the limits, and aren't changed until the next calibration.
Then the "on-the-fly"-rating of a song can get the maximum-values also from the ini-informations. It is fast and the max-vals are in sync with the limits.

Yes, that should be possible. But as I said since I want to change the formula to a linear-formula (like Points = a*(x1) + b*(x2) + c*(x3)) I don't know if I'll implement that. The main idea of linear-formula is that I can calculate the correlation between the viarables and the rating and based on that the optimal weight of the values. In a following version I want to implement that for every user a perfect formula will be calculated. To do that you then have to rate some songs and then the script will try to find out what's your logic (which variable is how important for you).

about the second idea:
my personal formula i use now, don't use the (Played - 2*Skip), but (Played - Skip^2). because i think, that one time skipped happens sometimes and shouldn't have a great influence. but when i skip it more times, i really don't like it and the rating is therefore very low

You're completely right! I'll change that in the next version! Thanks!

a solution would be to alter the proposed function.
first idea (easier): there is a limit for skipcounts, the function gets in action (the skipcounts aren't dicreased anymore, when the skipcount reached 5 counts)

second idea: the time between the decreases is dependent from the skipcount itself, for example skipcount*2 months or even harder 2*(skipcount)^2,2^skipcount, ....

The problem here is that I have to add a new feature for that and that it's only useful for some people and for some formulas. For example the limit would be bad depending on which formula you use. You know what I mean?
That's a really basic problem now. Because I want to put the whole algorithm into the formula so that it can easily be changed.
Also the buggy formula works great but the problem was that it can give an error because sometimes there is a root of a negative number. If I would hard-code the formula (like in older versions) I could simply add "if <0 then =0". But as I want that the formula can be modified that's not so easy.

then an accidental skip is corrected very fast (2 months) and a bad song with 5 skips gets reduced to 4 skips after 10, 50 or 32 months (the examples above, whereby the last value isn't representive for the real agressiveness of 2^x)

Well with Skip^2 a accidental skip isn't problematic anyway... and if you skip it in the first 10 seconds it will even not be counted as skip. So I dont think that this is a problem.

1.01^Dayssinceplayed can also cause an overflow for great values of dayssinceplayed. (i have tested a little bit with it, because i wanted to increase the influence of it)

Yes, you're right. That happens after 3471 days which is ten years. I don't think that somebody has MM so long.

But as I said I'll change the formula anyway: from "(x1)^a * (x2)^b * (x3)^b..." to "a*(x1) + b*(x2) + c*(x3)..."

Another idea would be that I'll do some predefined formulas which you can select. Then people like you could also create their functions to calculate points and I'll implement them in the script. Then you also can make more complex things than in formulas.
I wanted to implement such things already in older versions but there was nobody who wanted to create it's own formulas.

[RedX]

Hi!

A little improvement more would be when autorating to check the statusbar for the terminate event so the user can stop the rating at any time.

And see this post as how to avoid having multiple buttons on the toolbar when upgrading.

Regards,
Red

[Big_Berny]

@Redx: Thanks!
About the statusbar: I don't know why it doesn't work in MM3 because in 2.x it worked. Maybe it's because the database transaction I have to use. If you'd just terminate in the transaction it would cause problems I think.

[RedX]

@Redx: Thanks!
About the statusbar: I don't know why it doesn't work in MM3 because in 2.x it worked. Maybe it's because the database transaction I have to use. If you'd just terminate in the transaction it would cause problems I think.

In the function UpdateLibrary i don't see any

Code: Select all

if Progressbar.terminate then
  exit do
end if

sure that it was there in MM2?

Regards,
Red