-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wishlist: Have the Auto-DJ build IMMS-style "intelligent" playlists #456
Comments
I like this idea and have been considering similar strategies. I'm on the road right now but when I get back home I'll have more to say about this. |
Good to hear that! |
This is something I think about a lot too, and would like to also see implemented. /twocents |
So we're already collecting play count in the DB. I'll start by changing the code to also collect these things ("blue" means Auto DJ chose it):
Anything else we should be collecting? For the algorithm, I think it should be self-balancing. Meaning that if a song gets chosen randomly because the algorithm thinks the song is ranked highly, then having it queued up should not improve its ranking. Otherwise once a song is identified as ranked highly then it will stay that way forever, but that should not be the case. |
I think IMMS does more than that, but I don’t fully understand it. Here’s the source: https://code.google.com/p/imms/source/browse/trunk/imms/ It’s GPL2, maybe you can simply borrow the code? IMMS has two parts, the immsd server that keeps a song database and a client – groovebasin might become a client for immsd. IMMS keeps a score for each song, starting score is 71, each successful play adds a few points (initially 8, number of points lessens if the song has already many points, later its something like 3), each time a song is skipped it loses a bigger number of points (25, I think it’s less if the song has already few points). It also stores the date a song was last played, and avoids playing the same song too often. In addition, IMMS collects how much you like albums and artists, and awards “bonus points” for popular ones during playlist generation. And it does some song analysis to see which songs have a similar mood/tempo. |
No, no no no no no :) We've tried being a client before, and the problem is that every server is Doing It Wrong. And anyway, I disagree about the tempo and frequency analysis being relevant to which songs should be played next. Groove Basin will have its own algorithm for choosing songs, and it can be as inspired by IMMS as we want it to be, or not. And we'll be free to invent new ideas and try them out without having to get them accepted into IMMS's source code. |
I think groovebasin could use the immsd similar to a mail server using a spam filter, a separate demon that is specialized on one specific task. But it’s your project… And I like the tempo and frequency analysis thing, as long as it’s not overdone: I have a wide range of music in my collection. Yesterday Groovebasin gave me a playlist like: one punkrock song, one jazz piece, one electronic piece, two old songs by Marylin Monroe, one Jimi Hendrix song, another Marilyn Monroe song, a hiphop piece (and I don’t have so much Marylin Monroe in my collection). IMMS plays a couple songs of each kind in a row, so that I have a varied playlist, but without frequent clashes . Also, you don’t have to worry much about IMMS upstream, the last official release (-candidate) is from 2010, AFAIK it’s kept alive only by the Debian maintainer of the audacious plugin. |
It's not the tempo that makes them clash, is it? My understanding is that they clash because they are wildly different genres. IMMS is using tempo and frequency analysis as an approximation for genre. But maybe there is even a better way to determine if songs clash than that. Also whether something clashes might be a personal thing. I personally don't think that Techno and Rock clash, but I do think that low energy music and high energy music clash, even by the same artist from the same album. If clashing is subjective, then we either have to decide that detecting clashes is out of scope, or use data points that are relevant to the user, such counting skips and plays. |
I think IMMS looks for something like the tone of the song. It doesn't strictly keep to a genre, but it often manages to play number of songs that are mainly rhythm, and then a number of songs that have a dark mood, and then a number of songs with strong lead guitar/synth etc. -- IMHO thats a good idea. |
That does seem pretty nice. |
It is... I think the IMMS algorithms would be a good starting point. If you don't want a separate daemon for this, maybe you could use the IMMS code as a basis for some sort of library? |
In order to build a playlist automatically, I am successfully using MPD_sima with groovebasin. The topic about identifying similar music is apparently called Music information retrieval. At one time, there was a very handy service called MusicIP.
Everything could be done offline and it was working really well. But sadly because of patents/litigations it seems that everything was stopped. There has been some other attempts to do similar things, mirage for instance. I think that storing the music profile in a fingerprint stored in the tag is a good idea. |
Identifying similar music is only part of what IMMS does. A service like last.fm will try to deliver a continuous playlist of songs similar to the first one. AFAIK mirage does the same. But IMMS instead (usually) plays a few songs like the first song, and then skips (more or less gracefully) to a different style, and plays a few songs in that style, and then it changes again etc., while favoring your favorite songs/artists/albums. |
I have created a small library called compilation that uses a few APIs (lastfm, pandora, spotify currently) to find related artists or tracks, and presents a merged result set sorted by weighted relevance. I might take a stab at integrating this as one factor into the autodj functionality. Personally, I would love to have an easy way to tune the weight of different factors in the settings. Sometimes, similarity is most important, but other times, variety is fun as well. Exposing this information in the UI could be nice as well. The Guayadeque music player does this relatively well. It presents top tracks, related tracks and related artists in a separate tab, and shows which of those are available locally. It also lets the user enqueue tracks from that view. I found myself often enqueuing all top tracks from that view. The presentation is a bit plain (lists with thumbs). In a web environment, a D3 force-directed graph could make for more similarity exploration fun. |
A WIP PR is now available at #486. This is working quite well, but is in need of clean-up and refactoring. The patch is structured to compose a ranking from several inputs:
Each of these produces a score between 0 and 1, and is then integrated into an overall score using weights between 0 and 1. The overall score is then used to sort candidates, and a probabilistic function then picks a candidate. The randomness of this selection can also be parametrized, from "I want to explore" to "only pick really similar tracks". It would be great to expose those knobs in the user preferences eventually, and also surface some of this functionality in other places, such as "enqueue most popular tracks from this artist", and the aforementioned browse mode for similar artists / tracks. |
The best approach for playlist building I have yet found is IMMS, a plugin for XMMS, audacious etc: https://sites.google.com/a/luminal.org/imms/
IMMS builds statistics how often songs are skipped, and how often you jump to a song while in auto mode. Then it favors the more popular songs, while also playing the less popular songs sometimes. IMMS also uses different metrics to determine what songs should be played together.
It would be great if the Auto-DJ could use a similar approach.
The text was updated successfully, but these errors were encountered: