HTML5 Audio - Status. Part 1

(Written in May 2012 by a front-end specialist, and especially by media formats, the developer of several open-source projects and happyworm.com, and reflects the current state of affairs with browser support for new media tags and formats. - approx. Transl.)

This is a continuation of my (author, Mark Boas) 2009 article " Native Audio in the browser " (English, and updated in October 2010) , which explains the basics of HTML5 audio. Perhaps you should read it first, if you want to feel the work of the <audio> tag and its associated API. ( There is a Russian translation , but in the version from 2009.)

Now, after 2.5 years, it's time to see how things are going. With the fact that many advanced audio APIs are being actively developed, the native browser-based sound support that inspires us is improving - it's time to return to the fascinating world of the <audio> tag.

A good way to understand how things are going is to see a few examples of uses that we will see later.
')
How do we get started? There are several concepts that you need to master to prepare. Let's first understand the MIME types.

■ MIME Types

● Server part

They are also called Internet media types - this is one of the ways to make your system know how to work with media data.

First of all, the server must be configured to properly support MIME types. In the case of Apache, this means that there are lines in .htaccess :

# AddType TYPE/SUBTYPE EXTENSION AddType audio/mpeg mp3 AddType audio/mp4 m4a AddType audio/ogg ogg AddType audio/ogg oga AddType audio/webm webma AddType audio/wav wav 

Tip : Do not do gzip compression of media files on the server. Most formats are already compressed, and there is some support for the rest. In addition, in a backup solution with a flash, it does not support compression of media data.

● Client part

When describing data sources in code or markup, you can specify a MIME type that allows the browser to determine the data correctly.

The surest way to describe HTML5 audio is something like this:

 <audio> <source src="elvis.mp3" type='audio/mpeg; codecs="mp3"'> <source src="elvis.oga" type='audio/ogg; codecs="vorbis"'> <!--  -     --> </audio> 

This defines the tag and data sources used. The browser will select only one - it will not lose two or more of them. This code also contains backup processing options.

Along with the data address in the src attribute, the type attribute is specified. It is optional, but it helps the browser recognize the MIME type and codecs for the file being sent before it loads it. If not, the browser tries to find out the type of the file in possible ways.

Note : you can omit the name of the codec in the attribute, but for reliability and efficiency, I recommend helping the browser, giving the maximum possible information.

Fine. Now we know how to determine the address of the file, and the browser will calmly select the first format it supports. Can we file a file dynamically?

● Know the type of audio in advance .canPlayType will help (probably)

Fortunately, the API shows whether this file format is supported in the browser. But first, a brief description of how we manage the <audio> tag.

If the Audio object is described in HTML, the object can be accessed via the DOM:

 var audio = document.getElementsByTagName('audio')[index]; 

or, if id is defined,

 var audio = document.getElementById('my-audio-id'); 

As an option, the object is created entirely in Javascript.

 var audio = new Audio(); 

If there is an Audio object, then there is access to its methods and properties. To check the support of formats, the canPlayType method is used with a parameter - a text value of a MIME type.

 audio.canPlayType('audio/ogg'); 

You can even explicitly specify the codec:

 audio.canPlayType('audio/ogg; codecs="vorbis"'); 

canPlayType returns one of 3 values:
1) probably
2) maybe , or
3) "" (empty string).
The meaning of obtaining these strange types expires from the general strangeness of the situation in which the codecs are located, while we judge them by type. Without a real attempt to play the browser can only guess about the applicability of the codec.

Total, to test support do:

 var audio = new Audio(); var canPlayOgg = !!audio.canPlayType && audio.canPlayType('audio/ogg; codecs="vorbis"') != ""; 

Here it is checked that canPlayType is supported ("!!" simply turns the string object into a logical type) and then it is checked that our format canPlayType is not an empty string. (It is somehow illogical with the first part. Probably, the author forgot to mention that he can return undefined ? - comment. Transl.)

■ Support for various codecs in the browser

Let's see how codecs are supported in modern browsers.
Desktop Browser Codecs:

Desktop versions	room	Codec support
Internet Explorer	9.0+	MP3, AAC
Chrome	6.0+	Ogg Vorbis, MP3, WAV (starting with Chrome 9)
Firefox	3.6+	Ogg Vorbis, WAV
Safari	5.0+	MP3, AAC, WAV
Opera	10.0+	Ogg Vorbis, WAV

Mobile codecs:

Mobile browsers	Version	Codec support
Opera Mobile	11.0+	Device-dependent
Android	2.3+	Device-dependent
Mobile Safari	(iPhone, iPad, iPod Touch) iOS 3.0+	MP3, AAC
Blackberry	6.0+	MP3, AAC

The good news is that at the time of this writing, about 80% of browsers support HTML5 Audio.

The bad news is that there is still no agreement on universal support for any codec, so the server must support both MP3 and Ogg Vorbis in order to fully support HTML5 Audio in browsers.

Funny : Android 2.2 supports <video>, but not <audio>. To play audio, you need to use the <video> tag.

● Containers, formats and file extensions (and again these MIME types)

I mentioned above the well-known audio formats, but technically we have to work with their container format. (A container may contain more than one format — for example, MP4 may contain AAC and AAC +.)

Container	Format (s)	File extensions	MIME Type	Codec string
MP3	MP3	.mp3	audio / mpeg	mp3
Mp4	AAC, AAC +	.mp4, .m4a, .aac	audio / mp4	mp4a.40.5
OGA / OGG	Ogg vorbis	.oga, .ogg	audio / ogg	vorbis
Wav	PCM	.wav	audio / wav	one

● We have <audio> and are not afraid to use it!

Okay, we somehow run the audio tags - and it works. What else would you like to do? Now in each browser, the elements work a little differently due to the default settings. I want to slightly adjust them to a single mind. There are several properties of the <audio> element for this.

Some of the most used attributes:

Property	Description	Return value
currentTime	player cursor position	double (seconds)
duration	play time	double (seconds); only reading
muted	is the sound muffled	boolean
paused	whether playback is stopped	boolean
volume	volume level	double (0 to 1)

Using them is extremely simple. For example:

 var audio = new Audio(); var duration = audio.duration; 

The duration variable is assigned the duration value (in seconds) of the audio clip.

■ Buffering, Search and Time Ranges

The situation on this front is improving, browser developers are starting to make the bulk of the specification.

The API gives us buffered and seekable attributes when we want to find out how much of the media file has been buffered or preloaded for playback without delay. They both return a TimeRanges object, which is a list of intervals — the start and end numbers.

● Buffered attribute

Returns the intervals of the fully loaded sections of the file. A small example:

 //   TimeRanges   var buffered = audio.buffered; //        TimeRange var bufferedEnd = audio.buffered.end(); 

● TimeRanges object

There is no need for any information. A TimeRanges object consists of these properties:

It contains data on the parts of the buffered sections of the media file (one or more - how many have been buffered) and has the properties:

length - the number of intervals,
start (index) - the start time of the specified interval,
end (index) - the end time of the specified interval
(counted from the start of playback).

Funny : By default, the time dimension in the JS Audio API is seconds, although the traditional functions in JS use milliseconds.

 ------------------------------------------------------ // |=============| |===========| | ------------------------------------------------------ 0 5 15 19 21 

Thus, in this example:

  audio.buffered.length //returns 2 audio.buffered.start(0) //returns 0 audio.buffered.end(0) //returns 5 audio.buffered.start(1) //returns 15 audio.buffered.end(1) //returns 19 audio.buffered.end() //returns 19 

When can there be more than one buffered interval? The user clicks ahead on the unbuffered scale area on the player block. The object starts a new buffering from the point of the click, and there are 2 buffering intervals.

Tip : Most audio players allow you to move to new file positions at boot time by performing a series of queries to the server. In Apache, multiple file access is allowed by default, but you need to make sure of this for a server with unknown settings.

Note that if the user actively switches the playback point, buffering makes little sense. Some browsers can read the end of the file to set the duration of the recording, almost immediately creating 2 buffer spacing. Therefore, the progress bar in the player is somewhat more complicated than the usual progress bar control with 1 interval.

You can check your browser's TimeRanges with this handy HTML5 Media Event Inspector .

● Attributes seeking and seekable

Search in the context of a media file is peering forward or backward into a media file. This usually happens when the full file buffering is not complete. The seeking attribute is used to indicate that a seeked event has occurred . true means that part of the file has not yet been loaded.

To be continued...

Note on the original site, html5doctor.com :

This article is written by Mark Boas . Mark develops / teaches / describes and promotes new and open web technologies. Co-founder of Happyworm , a small web studio that develops, in particular, jPlayer Media Framework , it expands browser capabilities using HTML5 and JavaScript. Being a generalist in the heart, Mark most of the time deals with web-based media and real-time protocols. A lover of everything related to audio, he is now passionately working on the task of “doing something new” in his experiments in the Hyperaudio project . You can follow Mark's twitter .

The content of the following part:

● Note about preloading
● Successfully played
■ Media events
■ Streaming playback
■ Evolution of specifications (or “Wow, this thing is moving!”)
● Load method
● When will browsers return to official documentation?
● Autoplay and volume
● Simultaneous playback of several audio tags
● Dependence on OS
■ What's new?
● Change pitch
● Media fragments
■ Enhanced audio API: future sound in browsers
■ Conclusion
■ Literature

Local articles and translations related to HTML5 audio tags:
* Visualization of audio in HTML5 , August 7, 2011
* Create a cassette tape recorder using HTML5 Audio , July 13, 2012
* Audio processing via Audio Data API , August 30, 2010
* HTML5 Audio and Game Development: browser bugs, problems and solutions, ideas , August 6, 2010
* Mastering HTML5 audio tag , July 21, 2012
* Problems with HTML5 <Audio> , May 16, 2011
* Using HTML5 audio and video last mod. 13 Jun 2012
Thanks to ShpuntiK for pointing out the usefulness of translating this article.

UPD: Translation of the 2nd part .