What place does audio have in the web, anyway? The first attempts to integrate sound into the mix were dire, the graves of a thousand midi files testimony to that fact. Is there any hope?

Clearly, people aren’t happy with having strange noises thrust upon them. Browsers lacked sufficiently convenient UI to circumvent the problem so, because of aggrevated users, the web fell silent. Opt-in is the best policy for web audio or, at the very least, players which make it easy to stop the noise.

Alternatively, audio could be used completely separately from traditional web content. Largely static web pages with varying amounts of content are perhaps not an ideal way to use media. We tend to go to a web page, skim it and then move on. With the exception of short, atmospheric background audio this is at odds with how we listen to music (typically 3-4 minutes of continous use). Incompatible? Perhaps.

We need pure audio websites if being used at all. Podcasting and radio broadcasts are becoming more common online and there is a market, however niche it may be at the moment. This is the only real future I see for web audio, beyond the current standard of listening to one or two tracks by an artist. However, we should always head the words of the audioblogging manifesto. A feature for the features sake is usually worthless.

There are (generically) two player types for web audio, whether embedded or otherwise:

• Single stream – Players which feature a single song or a continous sequence of songs which can’t be control.
• Multi stream – Players which feature multiple songs, which can be flicked through in some way.

The former is not a particularly interesting case; it’s essentially just data (music) down a wire (connection). A reasonably solved problem, but useful for radio and simple repetitive sounds (whether using continual loops is good is not being questioned here).

The latter, however, is not as clear cut as far too many players get it wrong. All mature media players should have a feature set including playlist creation (and manipulation), selection directly from playlist, randomisation (“play a song that has not been played recently, using a random but possibly weighted function”), and continous play (“start the next song when this one finishes, regardless of how next is picked”).

This is one reason why Real player fails. It does allow for playlist playback but not selection or creation, making the feature largely impossible to use seriously.

If players for web audio want to compete seriously then they should take a lesson from established players. Or do at least one usability study. I can’t imagine anyone who thinks many players do half of what they want.

Yesterday, we had a look at Real Player as a way of utilising web audio. Today we look at the main contender (in my eyes): Flash.

This is a very different beast. First, Flash player is everywhere. I have no figures giving the proportion of web users who have the player installed, but I imagine it’s a damn sight higher than Real player. While it is highly unlikely to be for the purpose of enjoying web audio, the possibility is still there. Leading on from this, it is apparent that Macromedia do not suffer from the same trust issues as Real. People are happy to install the Flash plug-in into any browser they happen to be using. From the point of view of content producers this should speak volumes: people have Flash installed and are willing to install it if they don’t. The same cannot be said of Real.

Flash is also incredibly easy to integrate with websites, even if that integration is often abused (but the horrors of unskippable flash splash pages are for elsewhere). Your radio/stream controller will look like whatever you want it to. This has the advantage of seamless embedding, but has the obvious downside of lack of consistency (having to learn a new interface for each and every site you visit). Effort has gone into fixing this with standard and relatively feature-rich players recently, such as Soundblox, but it’ll be a while before they become conventional.

Of course, Real are in the business of streaming media so it should come as no surprise that the failure mechanisms in Flash player are far weaker. It hasn’t had millions of dollars spend on engineering relatively sophisticated buffering and pre-fetch technology. Thus, your mileage may vary on sound quality; an important measure in any audio test.

Pros and cons for both, obviously, but which is best? I’m a lazy person. I don’t need the hassle of configuring Real player to my liking. Windows is bad enough, but Linux is a royal pain. My recommendation has to be for Flash. Once more Flash players appear (such as the marvellous Captains Of Industry Radio), I can see a bright future for Macromedia’s entertainment plug-in. Hassle-free, high installation base, a market waiting to be cornered.

Recently, I’ve been playing with different ways of listening to media over the web (see a recent post on the Flash Radio for more). MP3s are out of the question, as they tend to chew through bandwidth, and I can’t necessarily store them wherever I am.

I can see two reasonable options: Real player and Flash.

First up, Real player pros:

• Established for a long time. This means that there are thousands of files to pick from on the web, covering every genre. This is obviously a big plus.
• The player is a proper application, which gives the UI consistency you would expect between listening to different files, i.e. it doesn’t matter which stream you listen to today, the UI is always the same.
• Live streams are possible, rather than being restricted to prerecorded audio.

Cons:

• The player itself is garbage. The Windows version has long been associated with adware, spyware, bloatedness and other assorted nasties. I’ve heard nothing but disparaging remarks from Mac users, and the Linux version is dreadful (more on that within the next few days).
• Quality varies dramatically. Most modern streams are fine, but some older streams are unlistenably bad (optimised for dialup).
• Trust. Because of aforementioned problems with the player, a lot of users simply do not trust Real and would rather stay away from the software all together.
• Application launching. Although this allows for consistency in the UI, it doesn’t allow for consistency with a website. Whether this is a major hassle or not is up to the web designers (should they choose to take embedding streams seriously at some point). Components to do this are already available, but most sites don’t bother.

This is not an exhaustive list, what other pros and cons exist?

The final pub crawl is one devised by myself and Derek in an entirely immature moment, and the route will be given below. If you want to see the childish humour at work, get a map of glasgow out and figure out the shape. It’s a comparatively mild route for drinking but takes in a fairly wide range of pub. Drink in each one. Pubs (and some of the intermediary route) are listed, but not complete. Visit as many as you can that you pass:

• Solid Rock Cafe on Hope Street (easily accessed by either bus or train, being next to Central).
• Sir John Moore.
• A trip down Roberston St.
• Casino on the Clyde (if you fancy a quick hand).
• Along Clyde Street to Barfly.
• Fat Boab’s.
• Times Square.
• Goose on Union Street (passing the Cathouse, if you wish to start elsewhere and end here).
• Foquets.
• Drum And Monkey
• Edwards.
• Revolution (“for the vodka connoisseur”).
• Flares (the highest point, but it is a nightclub).
• Rufus T. Firefly’s.
• Otis B. Driftwood (no, it’s not cheating).
• Candy Bar.
• Cosmopol.
• Solid Rock Cafe (closing the circuit).

Since the route is closed, you can start and end wherever you like. Depending on your clubbing whims, you may wish to end near Union street (handy for Sub Club and the Cathouse) or Sauchiehall Street (Garage, etc). Although, if you end at Solid Rock Cafe, you can dart along Union Street (taking in 2 more pubs) and get to Union Street in minutes.

I can’t personally verify the quality of all those bars but by the time you’re halfway round I’m sure it won’t matter.