MusicDigger: A tool for Music Discovery

M. Adil Yalc. ın, Preeti Bhargava, Sravanthi Bondugula, Varun K. Nagaraja and Marcelo VellosoDept. of Computer Science

University of Maryland, College Parkyalcin@cs.umd.edu, pretsbhargava@gmail.com, sravanthi.bondugula@gmail.com, mvelloso@umd.edu, varun@cs.umd.edu

Abstract—There are currently many information visualizationapplications present for various fields that deal with largeamounts of data but one such area that has often gone over-looked is the area of music. Musicians are a very collaborativegroup and they will very quickly generate complex networks ofcollaborations with other musicians and a large set of releases,also known as discographies. In conjunction with our facultycollaborator, Robert Gibson (Director, University of MarylandSchool of Music), we have worked to create our own informationvisualization tool to browse music data called MusicDigger.

MusicDigger is an visualization application that allows usersto discover discographies and browse the collaborative networksof artists using the Discogs database. Discogs is a web site thatcontains information on artists and their releases contributed bythe many users who support the web site. Our tool focuses onmusic discovery rather than music recommendation.

I. INTRODUCTION

The current musical world we live in is a vast collectionof data that is not readily available to everyone. Many pro-fessional musicians do not know exactly what is out therebecause what is made more readily available are those artistswho work with major labels and their major releases. Thereare many talented individuals who often perform under theradar and there are also many interesting collaborations majorartists make that are not as well advertised. These are the sortsof questions professional musicians would like to answer butonly with the dawn of the Internet has it been possible toaccess so much music data.

We make extensive use of a web site called Discogs1 toaccess user-submitted data regarding the releases of musicians.To contribute to this site users must first find a release thatdoes not already exist in the database and create a new entry.The users of the community then rate how correct the data isthrough a voting system and as long as the data is determinedto be incomplete it is color coded red in the database. Throughthis system of community vigilance the data is determined tobe correct according to the masses, much like how web sitessuch as wikipedia work. MusicDigger, our solution, uses theDiscogs database of user-submitted data in the backgroundand adds functionality to visualize the information. We have

1http://www.discogs.com/

Fig. 1. MusicDigger Logo

two major visualizations to accomplish this: a timeline visual-ization to view the releases of an artist/label over time and anetwork visualization to view the connections of a particularartist/label to other artists/labels.

Section 2 discusses previous work that has been done invisualizing music data and how our application differs fromthese other solutions. Section 3 discusses our application indetail, the design issues we faced, and how we implementedthe application. Finally, section 4 describes the user evaluationstudy that was conducted and section 5 presents the conclu-sions we gained from this study and the future work for thisproject.

II. RELATED WORK

There has been extensive work done in the area of visual-izing music data but much of it can be tailored to two maintypes of tools: music recommendation systems and tools forexploring personal music collections. The tools are discussedbelow.

A. Music Recommendation Systems

Music recommendation systems arose because there was amarket for users who were interested in listening to new musicsimilar to artists they already liked. There are two popular websites that do music recommendation: Last.fm2 and Pandora3.

Last.fm is a web site that uses a social networking approachto music recommendation. When a user creates their accounton Last.fm they are asked to import the data of the music(scrobbling) they listen to from their computer or on internetradio and Last.fm will then find other users who listen tothe same music. Once Last.fm encounters users who listento a lot of the same songs Last.fm will recommend songs theuser has not listened to yet from the play-lists of these otherusers. Last.fm plays these songs using the same format as radiostations, it does not allow the user to pause a song but userscan skip songs they do not like.

Pandora is a web site that uses the data in the Music GenomeProject to make its recommendations. The Music GenomeProject has isolated over 400 different musical attributes andit tags songs and artists with these attributes. The user is thengiven the option to create radio stations based on a particularsong/artist. Pandora finds other artists/songs that are similarto a particular song/artist and plays its recommendations tothe user like a music radio. This method of recommendationdiffers from Last.fm because the Music Genome Project has

2http://www.last.fm/3http://www.pandora.com/

come up with musical attributes and classified songs/artistsusing experts in the field of music as opposed to a socialnetworking approach.

B. Tools for Exploring Personal Music Collections

Tools such as MuVis [4] and MusicBox [5] allow the userto explore their personal music collections in different ways.MuVis focuses on visualizing a large collection of music usingtreemaps. The ordering of the treemap is based on a pivot artistselected by the user that gets displayed in the top-left corner.Other artists in the music collection are mapped according totheir similarity to the pivot artist. The user is allowed to controlother variables such as the size and color of each node in thetreemap and the user can filter results by the duration of thetrack, the release year, the genre, the beat, and the mood.

MusicBox, on the other hand, maps a music collection onto2D space by applying principal components analysis (PCA)to contextual and content-based features. After projecting thesongs in a collection onto 2D space, the MusicBox applicationthen plots a scatter diagram of the songs. The guiding intuitionin navigating this visualization is that similar songs are closertogether.

C. How MusicDigger is Different

Our tool is different from the others out there in thatit is not a recommendation system or a tool for exploringpersonal music collections. Our tool focuses on allowing usersto discover music through the connections of artists. In thatsense our tool allows users to explore the music collection ofthe Discogs database.

III. DATA DESCRIPTION

As mentioned earlier, we have made extensive use of datafound on the Discogs web site. Discogs identifies the dataunder three main categories - Artists, Labels and Releases.Artists can be individuals (Ex: Eric Clapton) or groups ofartists (Ex: Beatles, Pink Floyd) who have a set of releaseswhich is referred to as discographies. Each recording canbe released on many formats: Vinyl, CD, DVD, etc. Otherinformation included with the release is the date of production,the country of production, the genre and styles, the credits, andthe track list. The genre and style determine what category themusic falls under: rock, pop, jazz, etc. The track list showsthe number of songs recorded for a particular release and thecredits show who contributed what to each song.

Record Labels (Ex: Sony Music) are the companies that dealwith marketing releases, they can be used to categorize musicinto styles and artist communities, especially for independentlabels. A label also has a list of albums released within it, andalso can include sub / parent labels.

Discogs allows users to access monthly data dumps of theentire Discogs database4. The data includes all the releasesusers have contributed to the database when the dump wasmade and it is provided in the XML format specified by theDiscogs API. The Discogs API allows users to write code to

4http://www.discogs.com/data/

remotely request the data of certain releases if the release idof the Discogs database is known. We have made use of datafrom the latest database dump made on April 2011.

IV. MUSICDIGGER - DESIGN AND IMPLEMENTATION

MusicDigger is an application written in C++ that allowsusers to discover discographies and browse the networksof artists using the Discogs database. Our code has manymoving parts but the main two visualizations are the timelinevisualization and the network visualization.

1) Timeline visualization: The releases of an artist or a labelare displayed on a timeline making it easier to visualizealong with various other filtering and view controls.

2) Network visualization: Connections are identified be-tween a artist of choice to other artists based on col-laborations in releases, links through other artists/labelsetc.

In order to feed the data to these two visualizations werequired code to parse XML files, populate our own databaseusing Discogs data, write interfacing functions to query thedatabase and parse the retrieved information, and code amodule to make release and image requests in the backgroundso we would not have to store all that data on a users machine.

A. XML Parser

The XML data available at discogs is required to be parsedto extract necessary fields used in the application. These fieldsare mentioned in Appendix A. We use a stream based parser,Expat to parse the XML sequentially as the huge size ofthe data disallows the use of a traditional tree based parser.Chunks of data is sent to the parser that stores the state ofthe parse elements. This state preserved by the parser enablesthe parsing of sequential buffered data. The data stream isencoded in UTF-8 format and any illegal character is skippedby the parser. Different schema’s present with the label, artistand release data has been incorporated into the parser. Theparser is analogous to a plug-in service. It can be used byany application which provides an XML and the type of thedata. As each structure is parsed, the database populates thecorresponding tables. Also, the release data loaded in thememory by the DataMiner uses the Parser to extract releasetrack information.

Fig. 2. Search Window

2

B. Database and Interface

The database was designed to consist a sufficient numberof tables which would support easy data retrieval for variousfeatures implemented in the application. The database schemaused for the application can be found in Appendix A. The dataparsed from the XMLs was populated in an SQL databaseusing the SQlite tool which provided versatile features tohandle the large amount of data in a relatively small amountof time. We have tried to strike a balance between locallystored data on the computer and the data retrieved from theweb while using the application. Information such as album artimages, track names are not stored locally since they consumea huge amount of space, and are hence retrieved from webusing the DataMiner while running the application. Howeverthe application is still functional using only the local databasewithout any connection to the web. The current databasetakes around 1.5GB of space which can be easily shared ortransferred in a smaller zipped format which is around 400MB.

The information retrieval module has been coded in C++and uses the sqlite3 external libraries and API for connectingto the database and retrieving the data. There are mainly threetypes of retrieval functions:

1) Search - The main search functionality is invoked whenthe user searches for a term in the search field. Allartists/labels which match the term exactly (limited tothe first 10 exact matches) and which are most similarto the search term (limited to the first 40 matches forlabels and artists each) are retrieved.

2) Attribute queries - These include queries about an artistsname, releases, aliases (different names of the sameartist), bands, band members, releases, styles, genres,labels that the artist has released music under, and otherinformation associated with an artist. For a release,these are queries about the release title, complete releaseinformation (masterID, styles, genres, year in whichit was released, the labels it was released under). Fora label, this information includes the releases releasedunder that label, the styles and genres of those releases,the artists who released their music under that label etc.

3) Network link information queries - These queries formthe basic framework for the network visualization. Theseserve to establish links like artist-artist, group - artist -group, artist - release - label, artist - release - artist, artist- track - artist, label - release - label, label - artists andso on.

4) Filtering query - We allow users to filter the releasesbased on various attributes like Genres, Styles, Formats,Item types etc. The state of selected variables is capturedevery time the filter button is pressed and a nested queryis constructed to retrieve the filtered releases from thedatabase.

C. DataMiner

This section of the code makes use of the libcurl libraryto access the Discogs web site while the user is exploring

(a) Default View

(b) Release Details

Fig. 3. Pink Floyd’s Discography

releases. The code gets run as soon as the user double-clicks on a release to view its information in more detail.The information that gets displayed is the track and creditsinformation.

The Discogs API limits us to 5000 release requests daily soa lot of the code in DataMiner keeps track of how many releaserequests have been made to ensure that an error is returnedonce we pass the maximum daily limit. In addition to this wehave optimized the code to save the release requests made toa cache so that if a user decides to return to a release he/shelooked at earlier we can pull it up more efficiently from thefile system.

D. Timeline Visualization

The timeline visualization allows the user to view thereleases of artists or record labels in chronological order ofrelease date or alphabetical order of release title. The usercontrols the step size of the timeline so that each dot on thetimeline will represent a certain span of years or grouping ofletters. Releases that fall in the same span of years or groupingof letters will be stacked on top of each other. The releasesdisplayed can be shown with the album art or as pins (smallcircles). Pins allow the user to view more releases at a time.Other options in the view control window allow the user to turnon the circular or fish-eye effects of the timeline. The circulareffect gives the timeline a 3D look and the fish-eye effectzooms into whatever the user is currently focusing on whilescrolling the timeline. There is also an artist info overview

3

(a) Filtering releases to view only Pop genres

(b) Modified View Filters

Fig. 4. Timeline Visualization of Pink Floyd’s Discography

window that shows the current artist with an image and abutton to switch into the network visualization view. Finally,the user can filter the releases displayed by style, genre,members, formats, descriptions, and item type in the filteringwindow. Once a user finds an album he/she is interested inhe/she can click it to find more in-depth information, such asthe description, the genre, the style, the year, format of therelease, and the record label. A figure shown below displaysthis feature.

E. Network Visualization

The network visualization allows the user to view the con-nections of an artist. Once an artist is entered the visualizationwill show a node representing the artist and once that nodeis clicked a context menu will appear. This menu allows theuser to explore the network of an artist in various ways: otheraliases the artist goes by, releases that artist has, groups theartist is a part of, labels the artist has produced releases with,tracks the artist has contributed to, and compilations the artisthas contributed to. In addition to this there is a button in theartist info overview window that allows the user to expandthe connections graph to artists who share the same band asthe artist we are currently viewing. The view control windowdisplays the legend. We distinguish between artists, labels,releases, compilations and tracks.

V. EVALUATION

The effectiveness of MusicDigger was evaluated using ausability test of around five people. The form we came upwith had three sections: A pre-evaluation questionnaire, a setof tasks to complete, and a post-evaluation questionnaire.

The pre-evaluation questionnaire was used to split usersinto three groups: music experts, music hobbyists, and casuallisteners. Our application is targeted towards the music expertswho make use of the discogs database but we realized thatmany other users could make interesting insights and enjoythe experience of discovering music as well. We also thoughtthat these less experienced users could give us good insightsinto what works with our application and what does not.

The tasks of the user evaluation were laid out in such away that each user was required to use all of the functionalitywithin our application to complete all of the tasks. If any taskwas too difficult the user could skip it and he/she was encour-aged to write about it in the post-evaluation questionnaire.

The post-evaluation questionnaire had three open-endedquestions in which the user was asked to tell us what featuresof the application worked well, which features did not workso well, and what features they would like to be added in thenext iteration of the application. Then there were a series ofquestions in which users were asked to rate the features of theapplication, the speed and responsiveness of the application,how aesthetically pleasing the application was, and how easyit was to view and understand the data being presented.

(a) Context Menu

(b) A sample network

Fig. 5. Network Visualization

4

VI. FUTURE WORK/CONCLUSIONS

Our usability test gave us many interesting results. We foundthat most of the users did play instruments and so had somebackground in music. We found that the music experts werefamiliar with all the music web sites in our questionnaire(Discogs, Pandora, and Last.fm) and that the other groups,music hobbyists and casual listeners, were familiar with less.

Many of the users felt that the application was much fasterand responsive than their typical experience searching for dataon the web. All of the users also felt that the feature set wascomplete and had very little suggestions to make in this area.Users also seemed to enjoy the circular menu of the networkvisualization. We are also happy to note that all of the userswere able to complete six of the seven tasks, it was only thefinal task that seemed to give them trouble. This leads usto believe that with a tutorial the application is very usableto answer insightful questions about releases in the Discogsdatabase.

Some of the negative comments we received were thatthe information displayed was at times disorganized andoverwhelming. This seemed to crop up the most in both thetimeline visualization and network visualization with artistswho were very well-known and had contributed a lot to themusic world. Some users also mentioned that the ExpandArtists With Shared Bands button could be moved into thecircular menu instead of being placed in the artist overviewwindow. Other complaints were that the album artwork wasmissing and that sorting releases by title was unintuitive forthe timeline visualization.

There is a lot of room for future work. As it stands weare still making updates to complete all the features we hadplanned in the original iteration but that were unable to makeit in time for the user evaluation. We also got lots of feedbackfrom users who would like to see this as a commercial product.A lot of the discogs users who took our user evaluationexpressed interest in paying a few dollars to use this productto browse the data on the web site. We also hope to helpthe music department integrate this product into some of theirmusic courses.

VII. ACKNOWLEDGEMENTS

We would like to extend a sincere thanks to Robert Gibson,the Director of the University of Maryland School of Music,for being our faculty sponsor on this project and taking thetime to meet with us this semester. His enthusiasm, support,and feedback helped us greatly improve the MusicDiggerapplication. We hope that he will make use of it in some ofhis future music courses.

We would also like to thank Dr. Ben Shneiderman forproviding us with valuable information as we studied thematerial presented in his information visualization course andfor giving us great advice and feedback as we worked tocomplete this project. For the same reasons, we would liketo thank Gleneesha Johnson, the teaching assistant for thiscourse.

Lastly, but certainly not least, we would like to thankall who graciously donated their time to complete our userevaluation form and gave us the feedback we needed tomake this project a success. With their acknowledgement,an incomplete list is as the following: Evren Ulusoy, AhmetGunes, Ferhan Ture, ...

REFERENCES

[1] Piotr D. Adamczyk. Seeing sounds: exploring musical social networks.In Proceedings of the 12th annual ACM international conference onMultimedia, MULTIMEDIA ’04, pages 512–515, New York, NY, USA,2004. ACM.

[2] Dominikus Baur and Andreas Butz. Pulling strings from a tangle:visualizing a personal music listening history. In Proceedings of the 14thinternational conference on Intelligent user interfaces, IUI ’09, pages439–444, New York, NY, USA, 2009. ACM.

[3] Raimund Dachselt and Mathias Frisch. Mambo: a facet-based zoomablemusic browser. In Proceedings of the 6th international conference onMobile and ubiquitous multimedia, MUM ’07, pages 110–117, New York,NY, USA, 2007. ACM.

[4] Ricardo Dias and Manuel J. Fonseca. Muvis: an application for interactiveexploration of large music collections. In Proceedings of the internationalconference on Multimedia, MM ’10, pages 1043–1046, New York, NY,USA, 2010. ACM.

[5] Anita Shen Lillie. Musicbox: Navigating the space of your music.Master’s thesis, Massachusets Institute of Technology, 2008.

[6] Mark Notess. Variations2: Toward visual interfaces for digital musiclibraries. In In Second International Workshop on Visual Interfaces toDigital Libraries, 2002.

[7] Marc Torrens and Josep llus Arcos. Visualizing and exploring personalmusic libraries. In In Proceedings of the 5th International Conference onMusic Information Retrieval (ISMIR), pages 421–424, 2004.

5

APPENDIX

A. Database Schema

Artist Table1) int Artist ID (1 reserved for VARIOUS)2) string Artist Name3) string Image Url4) int parentAliasIDArtist Member table1) int groupID2) int artistIDLabel Info table1) int Label ID2) string Label Name3) string ImageURL4) int Parent IDRelease Main Table1) int Release ID (assigned by DISCOGS)2) string Release name3) string Album Art url4) int Master ID (not an actual release id)5) int yearRelease Genre Table1) int Release ID2) enum Genre IDRelease Styles Table1) int Release ID2) enum Style IDMainArtist Release Table1) int Release ID2) int Artist IDExtraArtist ReleaseTrack Table1) int Release ID2) int Artist ID3) string trackPosition4) string/enum roleCompilations Table1) int ReleaseID2) int ArtistID3) string trackPositionLabel Release table1) int Release ID2) int Label ID3) string Catalog NumberRelease Format table1) int releaseID2) int format3) int quantity4) int description

6