MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Automatically generated playlist BACHELOR’S THESIS Tomáš Šedoviˇc Brno, fall 2008 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Mgr. Jan Kasprzak ii Acknowledgement I would like to express my thanks to the following people: Mgr. Jan Kasprzak for giving me the opportunity to work on this project, thus making myself to finally dive into “that linux stuff”. Which is a good thing. Michael Grigoriev, the author of the IMMS system, for his wonderful support with more complex areas of his code. Fabien Ninoles, for his positive feedback about IMMSMPD, provived patches and ideas about its future direction. iii Abstract There is a group of people who likes to hear a different set of songs in a different order every time they listen to the music. To satisfy them, most music players support a random playback feature. However, the users would appreciate if the some songs were played more often than the others – ideally without the need to manually tamper with their musical library. The current music players offer this functionality either poorly or not at all. This project attempts to provide a suitable solution. iv Keywords music player, playlist, random playback, MPD, IMMS, unix-like, client/server v Contents 1 Introduction ......................................... 1 2 Investigation ........................................ 3 2.1 Design goals ...................................... 3 2.2 Music Player Daemon ................................ 3 2.2.1 Introduction . 3 2.2.1.1 Features . 3 2.2.2 Architecture . 4 2.2.2.1 Server . 4 2.2.2.2 Client . 5 2.2.3 Protocol Description . 5 2.2.3.1 Establishing Connection . 5 2.2.3.2 Command Arguments . 5 2.2.3.3 Command Lists . 6 2.2.3.4 Server Responses . 6 2.2.3.5 Highlighted Commands . 7 2.3 Getting the Song Ratings ............................... 12 2.3.1 Explicit Rating . 13 2.3.2 Implicit Rating . 13 2.3.3 Conclusion . 14 2.4 Usage Behaviour ................................... 15 2.4.1 Generating the Playlist . 15 2.4.2 On-the-fly Song Selection . 15 2.4.3 Conclusion . 16 2.5 Integration With MPD ................................ 17 2.5.1 Server-side Implementation . 17 2.5.2 Client-side Implementation . 17 2.5.3 Conclusion . 18 2.6 Intelligent Multimedia Management System ................... 19 2.6.1 Features . 19 2.6.2 Architecture . 20 3 Implementation ....................................... 21 3.1 Functional Specification ............................... 21 3.1.1 User Interface . 22 3.1.1.1 Starting IMMSMPD . 22 3.1.1.2 Closing IMMSMPD . 22 3.1.2 Logging . 23 3.1.3 Configuration . 23 3.1.3.1 Description . 23 3.1.3.2 Structure . 23 3.1.3.3 Content . 24 vi 3.2 Architecture ...................................... 24 3.2.1 MPD Interface . 24 3.2.1.1 Playback Queue . 25 3.2.2 Interpreter . 25 3.2.2.1 Flag: Bad .............................. 25 3.2.2.2 Flag: Ended ............................. 26 3.2.2.3 Flag: Jumped ............................ 26 3.2.3 IMMS interface . 26 3.3 Code-related Facts .................................. 27 3.3.1 Language . 27 3.3.2 Used libraries . 27 4 Finalization ......................................... 29 4.1 Next steps ....................................... 29 4.1.1 MPD Playqueue . 29 4.1.2 MPD Get Next Played Song . 30 4.1.3 IMMS Protocol . 30 4.1.4 Lower the dependency on the IMMS code . 30 4.2 Conclusion ....................................... 31 Bibliography . 33 vii Chapter 1 Introduction Music plays important role in our lives. It can serve us as an entertainment, relaxation or an emotional outlet. Being one of the oldest art forms, its diversity is enormous. Every person that listens to a music is different. They like different genres, listen to dif- ferent songs and on different occasions. Some prefer hearing classical music in theatres and operas, others love to lose themselves dancing to a psytrance track in a music bar, while yet others enjoy the rhythm of a hip-hop during their jogging excersise. Even the approach to order of the songs differs greatly: There are people who listen to albums just as the author of the music released them. There are others, who like to build their own mixes or playlists, taking only the songs they like best and putting them into the order they prefer the most. And there are those, who would like to have every listening experience different, to have every playlist fresh, not knowing which song will follow the current one. This text and the program behind it is for this group of people. Nowadays, almost every music player (be it a software or a hardware) provides a way of playing selected songs in a pseudo-random mode. In such case, the order of the played songs is determined by a pseudo-random number generator inside the player. Which basically means that the user has no way of knowing what the next-to-be-played song is going to be. However, the listeners still do have a musical preference. They do prefer some songs over the others. And some tracks (spoken introductions and intermezzos for example) that work greatly in an album, are just not fit for a random playback. The goal of this project is to devise a solution for these users. It is then to be implemented into the MPD1 (Music Player Daemon) program, preferably in a way that could be extended to other music players such as XMMS2 (X Multimedia System). The text is divided into four chapters. After this introduction follows the second part, which consists of the investigation of the current situation and various design approaches. Each considered approach is described in detail along with the final decision and the reason behind it. The final chapter provides the details of the solution’s implementation into the MPD player and the last one concludes what has and has not been accomplished, what should 1. <http://musicpd.org/> 2. <http://www.xmms.org/> 1 1. INTRODUCTION have been done differently and where to move on in the future. 2 Chapter 2 Investigation 2.1 Design goals There are some guidelines I dedided to follow while making choices about various aspects of the final solution. Of course, the ultimate goal lies in the usefulness of the program. If it is being used and the users are happy with it then I have succeeded. Still, I believe in following these guidelines unless there is a good reason not to. Sorted from the most important one to the least important: 1. Don’t break any of the existing MPD clients 2. Easy to use 3. Don’t change users’ listening habits 4. Try to avoid the horrible installation experience typical for unix-like software 2.2 Music Player Daemon 2.2.1 Introduction Music Player Daemon is an open-source program used for listening to music. There is one significant difference between MPD and most other programs for playing music. As its name suggests, the software itself is run as a daemon1. It has no user interface per se, instead, MPD operates on the client/server architecture. 2.2.1.1 Features MPD offers the following features[2]: • Playing the music • Random playback • Playlist shuffling 1. Program, running on background. Its parent is usually the init process and has no controlling terminal.[1] 3 2.2. MUSIC PLAYER DAEMON • Save, load, and manage playlists • Gapless playback • Crossfading support • Playlist versioning • Musical collection as a SQL database • SUPPORTED MUSIC FORMATS: – AudioFile – MP3 – OggFlac – OggVorbis • METADATA: – id3v1 – id3v2 – MP4 – Vorbis • PROTOCOLS: – TCP – IPv6 – Unix Domain Sockets The complete feature list is on the MPD official page[2]. 2.2.2 Architecture 2.2.2.1 Server MPD itself is a server program. It does not depend on the terminal it has been run from, therefore, it will continue to work even if a user logs out or restarts her X Window Server. It handles the task of actually playing the music, reading song metadata and taking care of playlists. However, none of these features is dicectly accessible to a user. Instead, MPD needs a client, communacating with the server via a custom protocol, that transfers the user’s commands and displays the status of the server. 4 2.2. MUSIC PLAYER DAEMON 2.2.2.2 Client One of the most important tasks of the MPD clients is to provide the actual interface to the user. Every graphical or command-line representation of the player is in fact an MPD client. MPD clients come in various shapes and sizes. There are single-purposed tools, designed for a particular task, be it a playback control, playlist managing, remote control or music visualization programs. On the other hand, one may encounter more complex applications, that would support multiple features and rich user interface – for example GMPC 2. The advantage of this approach is, that users can use different programs for different tasks. For example, they might use a command-line interface for their hacking time, while have visualization and better playlist management tools when being in GUI (Graphical User Interface). Additionaly, when no user interface suits someone’s needs, it is much easier to develop a frontend to MPD than to implement a full music player. 2.2.3 Protocol Description The MPD command protocol is built over the TCP network protocol[3]. By default, it runs on the port 6600, although it is possible to use a different one. The protocol uses plain text for transmitting messages.