Introduction

Big data and mining social media trends has done great things for recommendation engines for all sorts of media types, but several of the inherent design features of these systems has lead to flaws in the system. I propose a solution that circumvents many of the issues of a music recommendation system by focusing on ‘little data’. That is: users whose influence is more significant than an average user, whom I call “Tastemakers”. The core concept is to design a service that feels more like a staff wall at a local record store than any “web service”.

View the website at yourmusicfriend.com

Brief/Problem Statement

Music recommendation engines have the following issues:

Internal Feedback Loops

Spotify recommends music based off of the music listening habits of it’s users. The system both influences the listening habits and is driven by them. This leads to a ‘long tail’ where an artist must hit a certain threshold of success to continue success, and is detrimental to more modest artists. last.fm, iTunes, and other recommendation engines that are also listening services suffer from this

Stores or users who play spotify as a radio station all day long have a disproportionate influence over the system, as their 247 number of listens is far greater than any regular listener.

People don’t know what they want to listen to

The average music listener listens to the same cycle of artists, and infrequently is discovering new bands to listen to. Not every user has listened to enough music to form a taste that is worth accounting for in data. Their listening data, in terms of building recommendation engines for new music discovery, is not as useful as a user who is actively searching for and trying out new artists.

Genres are good for talking about music, but not good for music discovery.

Attempting a sort of ‘music genome’ to algorithmically determine similar artists to recommend is hinged on the assumption that a if a user likes one artist, they will like a similar artist. This usually correct assumption leads to an unaccounted for contrapositive, where the the user will not like artists that are not similar to the original artist. This is false, and locks users into listening to only particular styles, genres, time-periods, and other taxonomic categories instead of a diverse spread of music.

New releases are rated too high.

By valuing only the ‘freshest’, ‘hottest’ album drops, recommendation engines disvalue music that is not recently produced. Look at the movie industry, where a movie must be successful in its first few weekends to make any money. This, in my opinion, is an unhealthy model for music listening, particularly as music is not ephemeral to it’s time of production, and that a user can listen to far more music than they can watch movies, and enjoy music repeatedly, coming back to music long after it’s release date. Recommendation engines that value fresh music too much encourage this environment.

One can avoid these issues, if - in the automotive spirit of big data - one embraces ‘small data’ and starts paying attention to specific users to give a service a hand-picked flair.

Approach

I built a music recommendation engine that’s source data is built solely from the personal and intentional recommendation of certain users I call ‘tastemakers’. They not only listen to music, but actively select a track to be included in the database. The engine randomly selects tracks from this curated database, weighted towards the music most recently added. This engine pulls in a spotify iFrame for convenience, but the website is not a listening platform. For discovering new music, it gives the user no input on the matter. They are presented with a track and they are forced to form their own opinion on it.

Process

I wanted to create a music recommendation engine that feels more akin to the ‘staff recommendations’ wall at a local record store than any infinite, algorithmically generated big-data, database.

For creating site, I decided to go with a client-side javascript (and jQuery) solution, as I figured many of the libraries for interacting with services would already exist, and a website makes an easy platform for an audience. Just go to a url, and listen to ‘good’ music. No barriers. After dealing with a lot of API dead-ends and, I ended up pulling music from a curated database through google spreadsheets, and the engine - which now requires human effort to keep updated - was born very quickly after this point. The design and development stage a breeze once I knew which tools I could easily work with. Almost all of the time spent was spent frustratedly trying to decipher various API documentation.

Outcome

I created a website that, on every page load, shows you a random artist from a curated database. View it at listentothis.hdyar.com. It is built with JQuery, Miso Project, and IFTTT. I used Skeleton as a framework for the html and the css.

The algorithm that re-assigns weight based on how recently the track was added has yet to be implemented, although it’s an easy process once I figure out the spreadsheet math. There are a lot of changes I would like to make, eventually removing the random component, so the weighting isn’t a high priority.

Next Steps

My next step is to remove the randomness feature, and just let the website work it’s way through the database (at a generated pace that roughly matches the pace music is being added), theming it feel like a record store’s staff wall of ‘check this music out’ in design and in function. This will force viewers to respect the recommendation, and not just refresh their way through a lot of artists, judging the music by it's album art.

I also would like to remove the ‘effort’ from maintaining the database, which would basically involve rewriting the whole thing - in effect, I made a statement about big data by avoiding big data, but I would like to pull automatically from tastemakers all over the country, then analyze what they are listening to. if I can figure out which users are tastemakers outside of my personal community and follow them (on spotify or last.fm, or music blogs, or wherever). The current implementation is ‘small data’, but I would like the data perhaps being a bit bigger. Not big data big, but a much larger selection of tastemakers.