A working musician and recording studio owner wondered elsewhere how he could get the highest quality audio samples of his work onto his website. He wanted, if possible, to use a minimum of 24 bit/44.1 kHz audio files…
44.1 24 bit uncompressed audio has a bandwidth of ~2117 kbps (~2.1 Mbps). With a rockin’ server and a very good downstream, that might work much of the time with optimal ‘net circumstances depending on server traffic. But it’s probably not a practical solution.

That means using a perceptual encoding algorithm like mp3, AAC, WMA, or Vorbis. With greatly reduced bandwidth comes potential loss of perceived quality, but, happily, the upper levels of those formats are indistinguishable from the ‘real thing’ by most people, even among trained listeners.

The latter three formats are generally accepted as offering marginally higher quality at a given bitrate — but the problem is that near-universal support only exists for mp3. AAC probably comes closest, but many Windows users would have to install the AAC codec in order to not have the browser throw a WTF? error.

So far, then, the most practical advice is to use a high resolution mp3.

Now we come to the player.

We are, interestingly (as in the ancient Chinese curse form of interesting), in an era of transition.

For most of the www’s history, streaming media has been accomplished via browser plugins like Macromedia’s (now Adobe’s) Flash, MS’s Silverlight (which is the system under Netflix Streaming) — or, far less successfully and gracefully, the Quicktime plugin. Such plugins provided both a software mechanism for receiving the streamed media but, in the case of Flash, allowed developers to create sophisticated user interfaces with a number of advanced features. Unfortunately, those third party developed plugins did not always run with great efficiency (many Flash developers came from the visual design world and did not necessarily have an understanding of programming efficiency). And, of course, you don’t get all that potential sophistication for nothing… the sophisticated Flash system inevitably had some overhead built in.

But with the advent of increased demand for mobile web appliances wiht long battery life, as well as increased strategic rivalries between Apple and Adobe, Apple elected to ‘banish’ Flash from the iOS operating system that runs their Touch, iPhone, and iPad, saying that developers should use native HTML5 support for streaming audio and video.

Great.

Except for one thing. HTML5 was not then and is not now a standard. It will not be a finalized standard for the better part of a decade, as plans now exist.

Support for HTML5′s vague ‘standards’ is spotty and inconsistently implemented across browsers. Web developers are now faced with a situation that — sadly — parallels the troubled times of the late 90s when every browser implemented the (often vaguely stated) CSS standard in frequently fundamentally inconsistent ways.

The number of people who do have browsers that properly support HTML5 is around half to 2/3 (depending on whose statistics you buy). That leaves, what, around a billion people who don’t?

And that means that a prudent web developer will likely need to make sure his streaming audio and video media has both Flash and HTML5 support. Some systems use HTML5 if it’s available, but ‘fall back’ to Flash if it’s not. Others, weighing the sophistication and maturity of Flash players, go the other way around, using a full featured Flash player where that’s supported, but falling ‘forward’ to the much cruder, limited HTML5 native players in HTML5-ready browsers.

Here’s a report on the state of HTML5 video from Long Tail Video, the people who make the popular (but no longer strictly free) JW Player.

The State Of HTML5 Video