Peter Siebel - Practical Common Lisp

(defun translated-genre (id3)

(let ((genre (genre id3)))

(if (and genre (char= #\( (char genre 0)))

(translate-v1-genre genre)

genre)))

Since a version 1 genre code is effectively just an index into an array of standard names, the easiest way to implement translate-v1-genreis to extract the number from the genre string and use it as an index into an actual array.

(defun translate-v1-genre (genre)

(aref *id3-v1-genres* (parse-integer genre :start 1 :junk-allowed t)))

Then all you need to do is to define the array of names. The following array of names includes the 80 official version 1 genres plus the genres created by the authors of Winamp:

(defparameter *id3-v1-genres*

#(

;; These are the official ID3v1 genres.

"Blues" "Classic Rock" "Country" "Dance" "Disco" "Funk" "Grunge"

"Hip-Hop" "Jazz" "Metal" "New Age" "Oldies" "Other" "Pop" "R&B" "Rap"

"Reggae" "Rock" "Techno" "Industrial" "Alternative" "Ska"

"Death Metal" "Pranks" "Soundtrack" "Euro-Techno" "Ambient"

"Trip-Hop" "Vocal" "Jazz+Funk" "Fusion" "Trance" "Classical"

"Instrumental" "Acid" "House" "Game" "Sound Clip" "Gospel" "Noise"

"AlternRock" "Bass" "Soul" "Punk" "Space" "Meditative"

"Instrumental Pop" "Instrumental Rock" "Ethnic" "Gothic" "Darkwave"

"Techno-Industrial" "Electronic" "Pop-Folk" "Eurodance" "Dream"

"Southern Rock" "Comedy" "Cult" "Gangsta" "Top 40" "Christian Rap"

"Pop/Funk" "Jungle" "Native American" "Cabaret" "New Wave"

"Psychadelic" "Rave" "Showtunes" "Trailer" "Lo-Fi" "Tribal"

"Acid Punk" "Acid Jazz" "Polka" "Retro" "Musical" "Rock & Roll"

"Hard Rock"

;; These were made up by the authors of Winamp but backported into

;; the ID3 spec.

"Folk" "Folk-Rock" "National Folk" "Swing" "Fast Fusion"

"Bebob" "Latin" "Revival" "Celtic" "Bluegrass" "Avantgarde"

"Gothic Rock" "Progressive Rock" "Psychedelic Rock" "Symphonic Rock"

"Slow Rock" "Big Band" "Chorus" "Easy Listening" "Acoustic" "Humour"

"Speech" "Chanson" "Opera" "Chamber Music" "Sonata" "Symphony"

"Booty Bass" "Primus" "Porn Groove" "Satire" "Slow Jam" "Club"

"Tango" "Samba" "Folklore" "Ballad" "Power Ballad" "Rhythmic Soul"

"Freestyle" "Duet" "Punk Rock" "Drum Solo" "A capella" "Euro-House"

"Dance Hall"

;; These were also invented by the Winamp folks but ignored by the

;; ID3 authors.

"Goa" "Drum & Bass" "Club-House" "Hardcore" "Terror" "Indie"

"BritPop" "Negerpunk" "Polsk Punk" "Beat" "Christian Gangsta Rap"

"Heavy Metal" "Black Metal" "Crossover" "Contemporary Christian"

"Christian Rock" "Merengue" "Salsa" "Thrash Metal" "Anime" "Jpop"

"Synthpop"))

Once again, it probably feels like you wrote a ton of code in this chapter. But if you put it all in a file, or if you download the version from this book's Web site, you'll see it's just not that many lines—most of the pain of writing this library stems from having to understand the intricacies of the ID3 format itself. Anyway, now you have a major piece of what you'll turn into a streaming MP3 server in Chapters 27, 28, and 29. The other major bit of infrastructure you'll need is a way to write server-side Web software, the topic of the next chapter.

In this chapter you'll look at one way to develop Web-based programs in Common Lisp, using the open-source AllegroServe Web server. This isn't meant as a full introduction to AllegroServe. And I'm certainly not going to cover anything more than a tiny corner of the larger topic of Web programming. My goal here is to cover enough of the basics of using AllegroServe that you'll be able, in Chapter 29, to develop an application for browsing a library of MP3 files and streaming them to an MP3 client. Similarly, this chapter will serve as a brief introduction to Web programming for folks new to the topic.

While Web programming today typically involves quite a number of software frameworks and different protocols, the core bits of Web programming haven't changed much since they were invented in the early 1990s. For simple applications, such as the one you'll write in Chapter 29, you need to understand only a few key concepts, so I'll review them quickly here. Experienced Web programmers can skim or skip the rest of this section. [280] Readers new to Web programming will probably need to supplement this introduction with a more in-depth tutorial or two. You can find a good set of online tutorials at http://www.jmarshall.com/easy/ .

To start, you need to understand the roles the Web browser and the Web server play in Web programming. While a modern browser comes with a lot of bells and whistles, the core functionality of a Web browser is to request Web pages from a Web server and then render them. Typically those pages will be written in the Hypertext Markup Language (HTML), which tells the browser how to render the page, including where to insert inline images and links to other Web pages. HTML consists of text marked up with tags that give the text a structure that the browser uses when rendering the page. For instance, a simple HTML document looks like this:

Hello, world!

This is a picture:

This is a link to another page.

Figure 26-1 shows how the browser renders this page.

Figure 26-1. Sample Web page

The browser and server communicate using a protocol called the Hypertext Transfer Protocol (HTTP). While you don't need to worry about the details of the protocol, it's worth understanding that it consists entirely of a sequence of requests initiated by the browser and responses generated by the server. That is, the browser connects to the Web server and sends a request that includes, at the least, the desired URL and the version of HTTP that the browser speaks. The browser can also include data in its request; that's how the browser submits HTML forms to the server.

To reply to a request, the server sends a response made up of a set of headers and a body. The headers contain information about the body, such as what type of data it is (for instance, HTML, plain text, or an image), and the body is the data itself, which is then rendered by the browser. The server can also send an error response telling the browser that its request couldn't be answered for some reason.

And that's pretty much it. Once the browser has received the complete response from the server, there's no communication between the browser and the server until the next time the browser decides to request a page from the server. [281] Loading a single Web page may actually involve multiple requests—to render the HTML of a page containing inline images, the browser must request each image individually and then insert each into the appropriate place in the rendered HTML. This is the main constraint of Web programming—there's no way for code running on the server to affect what the user sees in their browser unless the browser issues a new request to the server. [282] Much of the complexity around Web programming is a result of trying to work around this fundamental limitation in order to provide a user experience that's more like the interactivity provided by desktop applications.