On November 21, 2009, Maciej Łoziński wrote: > Gordon Haverland pisze: > > On November 20, 2009, drew Roberts wrote:
It seems Drew and Maciej have been busy. :-0 The most obvious use of correlations in the time series of playing music, is to generate new time series. However, if I have a hand compiled playlist, is it not more valuable to know that song A is within N plays of song B? Or for those who don't like algebra, if I always listen to Alice's Restaurant by Arlo Guthrie after I listen to Don't Fear (The Reaper) by Blue Oyster Cult; is not Alice's Restaurant a good suggestion for people who happen to have Don't Fear (The Reaper) in their collection? > Doesn't the playing order is enough information in each case? > User-made playlists are of course the best source of data, but > in case of lists randomly generated by player, user usually > skips song he doesn't like, and playlists from external source > (internet radio) are generated by some person (dj?) using some > rules, which give us some sort of similarity between them. And > also there are reasons why user has selected this station > among lots of others, which makes dj-selected tracks somehow > similar to this user's tracks. > But I have to admit, if we had an information about the souce > of playlist, it would be useful. But not every player has that > information and it's not a part of last.fm API (which libre.fm > implements). Love/hate would be great. I think we can use it > if player supports it. And when we do, more players will > support it :-) Who says that what last.fm has, is the best scrobbling format? Obviously, what last.fm accepts is somewhat tolerant of errors. Can we not extend the protocol in such a way, that this extra information which we think is valuable, appears to be an error to last.fm? > > Me too. I'm starting to notice that people are finding more > > obtuse than usual, which is not a good thing. I don't like > > to be seen that way. > > My dictionary says "obtuse = stupid, dull", which makes me a > little confused about the meaning of these sentences :-S I > hope you don't think I find you obtuse! I spend entirely too much time not interacting with any people in person. The longer this happens, the worse I get at conversation, either in person or simulated in email. > Ok :-) Now I get it. You are talking about the process of > generating lists of recommended tracks and I was thinking > about just about defining what is similar to what. Indeed, > when we connect these two processes, we get recommendation > engine ;-) I believe the two processes are related. Proximity is of value, when the playlist is hand selected. If the playlist is generated by program, one needs to consider how the playlist was generated. > I think at the beginning we should keep things as simple as > possible, and later add options. Therefore I have a sugestion > - let's just get some (for example a half) most recommended > tracks and play them in random order (not putting a card back > to the deck). Same thing could be done for albums - we could > of course play top recommended albums in random order, when > user would like to hear their stories. I can't say I've run across "play half the deck, then reshuffle with replacement". > Maybe we could have a few algorithms to coose from, configured > per user? I think the biggest problem, is adequately describing how the algorithms work. Writing code is less difficult than trying to explain how choice A is different from choice B. > BTW 347446 plays... impressive. I hope you transferred them to > libre.fm ;-) I would like to. However, I still haven't figured out a way to do this with software that is "up to date". The early suggestion was to use an outdated Python library to do things. > > Building things at random is all inherently the same process. > > It doesn't matter whether you are making random integers, > > random float points that are uniform 0-1, or anything else. > > But applications such as random text and random music have > > expectations (correlations) that people may want to use. But > > working with extended correlations does come with a > > computational burden. You need to draw more than one random > > number to find the next song. But time consuming part is > > comparing the other random numbers to complicated probability > > functions in order to decide yes or no (or to pick a song). > > Is it really that complicated? Maybe some example(s) will help? > I think if we stored the similarities in database, instead of > computing them for each song played, it could be quite simple. How does one compare one song to another? What we typically do is think of some statistic of a song, and compare the statistics. An easy statistic, is the playing time. But MusicBrainz has a bit of documentation, and some of it considers such things as finding similar songs. There are lots of proprietary algorithms out there, and there is apparently a lot of value in this kind of data. What MusicBrainz has said (my rewording) is that there isn't a hope in hell of any of these algorithms ever gettting published. They are worth entirely too much money to the groups that developed them. For example, a lot of people talk about beats per minute in a song. How does one determine beats per minute? Let's look at subdividing a song into "random" fractions (greater than some undetermined minimum), and calculating the beats per minute of each fraction. Some songs will have about the same beats per minute regardless of what fraction of the song is chosen (assuming it is long enough). Other songs will see multiple beats per minute figures for certain fractions of the song. > I just hope I havent't messed it up with my English. You seem to be at least as good as the people coming out of high school in Canada. :-) I skipped a bunch here, I think I caught the main parts. But, if I missed something you want answered, by al means ask again. Oh well, time to get back to the other task at hand (trying to come up with a fair cost structure for consulting, if you are Autistic and can't read people). Have a great day! Gord _______________________________________________ Libre-fm mailing list [email protected] http://lists.autonomo.us/mailman/listinfo/libre-fm
