I've just asked a question about audio, and people suggest that this is a question about html5-audio instead of web audio.
So i wonder what's the difference?
These two concepts are different.
For example, the Introduction paragraph of the W3C proposed standard for Web Audio makes statements like
The introduction of the audio element in HTML5 is very important, allowing for basic streaming audio playback. But, it is not powerful enough to handle more complex audio applications.
Hence hinting at the difference between these two concepts:
HTML5 Audio element = basic playback by embedding audio data in HTML.
Web Audio API = An ECMA Script (JavaScript) based API to support audio capabilities comparable to these of a modern stand-alone PC, such as:
mixing
processing and filtering (e.g. cave or cathedral effects etc., distance attenuation, doppler shift etc...
tasks related to audio production applications
capabilities found in modern game audio engines
A word of caution: As of late October 2012, this API is still relatively new and not supported on all browsers and mobile devices. caniuse.com site may be useful to determine the amount of support found for HTML5 and various related technologies on different platforms. The fact that W3C drafts standards for Web Audio is a strong indication that this API will, in time, receive universal acceptance and broad support, but this is not yet the case.
Related
I saw this question asked but didn't see an answer to the question directly. I was wondering if the HTML5 Audio tag is still accessing a web api? If so, is it different from the Web Audio API?
I am just trying to understand the difference between the 2.
These two concepts are different.
For example, the Introduction of the W3C proposal sed standard for Web Audio makes statements like The introduction of the audio element in HTML5 is very important,
allowing for basic stream audio playback back. But, it is not powerful enough to handle more complex audio applications
Hence hinting at the difference between these two concepts:
HTML5 Audio element = basic playback by embedding audio data in HTML.
Web Audio API = An ECMA Script (JavaScript) based API to support audio capabilities comparable to those of a modern stand-alone PC, such as:
mixing
processing and
filtering (e.g. cave or cathedral effects etc., distance attenuation,
Doppler shift etc...
tasks related to audio production applications capabilities found in modern game audio engines
A word of caution: this API is still relatively not supported on all browsers
and mobile devices.
caniuse.com site may be useful to determine the amount of support found for HTML5 and various related technologies on different platforms. The fact that W3C drafts standards for Web Audio are a strong the indication that this API will, in time, receive universal acceptance and broad support, but this is not yet the case.
Refer this Url For Better Understanding,
https://developers.google.com/web/updates/2012/02/HTML5-audio-and-the-Web-Audio-API-are-BFFs
They can be used completely independently.
An HTML page can use an <audio> tag and the Web Audio API isn't involved.
A JavaScript can use the Web Audio API and the <audio> tag isn't involved.
Here's how you would use Web Audio API:
var context = new AudioContext();
var osc = context.createOscillator();
osc.connect(context.destination);
osc.frequency.value = 440;
osc.start();
This will make a loud sound so get ready to close your browser. Here an oscillator is the source of sound.
The only cross over between the two is that the Web Audio API can use an <audio> tag on the page as a source of sound.
See: createMediaElementSource
This is useful for adding audio effects to a <audio> or <video> tag, among other audio processing things.
In short, I want to record presentation audio, create time markers for that audio in a database, and then provide marker-navigation of that audio content from a web page. What technology (e.g. HTML5 Audio, RTMP) can support this?
My requirements in more detail:
quickly navigate to server-side marked points in server-stored audio, from the browser.
avoid any proprietary client-side software, such as Silverlight; although due to penetration Flash is acceptable, and future-looking standards like HTML5 media are acceptable, provided it ships with the latest browsers.
prefer to leave the 30-50 minute audio files un-split rather than pre-splitting on the selected markers; so that the markers can be seamlessly changed later.
like to keep licensing cost minimal; although single-purchase licensed server-side technologies are fine.
prefer to do most of this from IIS, where I have most experience. however, a parallel streaming server such as Adobe with Windows APIs is acceptable.
Here are my best guesses on a solution so-far:
the presentations will be compressed and stored in mp3 files (but really, any advice on an easily seekable format for speech recording is welcome).
the client will play a unicast stream rather than download file chunks (although TBR, below, challenges this assumption)
HTML5 is not ready, so flash will be required at the client
IIS Media Services is no-go as it requires Silverlight for seekable audio
The leading products in this space, such as Adobe Media Server 5, are probably large kits with their focus on video media. I can probably find a more focused tool like Icecast to reliably do what I need.
OK, I'll bite. I went and looked for how people actually address this, and it's how I said it is in my comment.
Setting HTML5 audio position (it's so close it almost makes this question a dupe)
I've also found this nice blog post from 2009 that describes the further technical possibilities and options. The latter part revolves around advanced video use cases and Ogg, but the first part should apply just fine to <audio>.
http://gingertech.net/2009/08/19/jumping-to-time-offsets-in-videos/
It seems clear that officially the html5 audio tag is intended for use with the ogg format.
Does the html5 audio tag encompass .mid (MIDI) unofficially?
Updates:
This is a somewhat old question but it is still highly ranked on Google so here are some updates to the answers above - standards and tools that may have not been available when the question was asked but may be useful to people who find this question today:
Web MIDI API (this is currently a W3C Editor's Draft from December 26, 2012 - ie. today - so it may change)
MIDI.js - playing MIDI with JavaScript
jasmid - MIDI synthesis with JavaScript
See also those questions:
Generate live MIDI from Javascript
generating MIDI in javascript
In spite of the MIME type "audio/midi" a MIDI file is not audio ... it is a musical performance only, there is no sound. In other words, a MIDI file stores which keys a piano player hit, when he or she hit them, and how hard he or she hit them, but no actual piano sounds. You have to put the musical performance through a sampler that has a piano sound in it, just like you have to put a piano roll through a player piano. Apple QuickTime 7 has such a sampler built-in, but I don't know if QuickTime X does. Anyway, you would have to use an embed tag, it doesn't work through the audio tag.
It seems clear that officially the html5 audio tag is intended
for use with the ogg format.
No. HTML5 is a markup standard. It doesn't address audio standardization at all. In other words, it tells you how to encode markup, not how to encode audio. Audio standardization is done by ISO's Moving Picture Experts Group for the past 20 years now. The current audio standard is MPEG-4 AAC (audio/mp4), and the previous standard is MPEG-2 MP3 (audio/mp3). If you are standardizing your markup to the W3C HTML5 specification, then you should standardize your audio to the ISO MPEG-4 specification. Otherwise, just ignore all standards and use whatever markup and audio you like, and make content that only you can see. All PC's and mobiles support both HTML5 and MPEG-4 out-of-the-box. It is only the alternate browsers that block access to the user's hardware MPEG-4 player, so you should work around those by offering the MP4 audio file to those users as a simple link they can click and open in a helper app, like iTunes (which is on about 90% of all PC's). Or you can invoke a FlashPlayer in those alternate browsers and load the same standard MP4 in there.
As for Ogg, it plays in some alternate browsers, but it doesn't play in the user's RSS reader, Podcast reader, native apps that offer Web views, and in many other contexts that the user may see your web page. Standardized audio plays in all of those contexts. So if you are offering Ogg, you have to offer it as a second choice after MP4, because the Ogg is only going to be needed a small minority of the time.
It doesn't appear to to support raw MIDI files, in Chrome 10 at least.
However, the W3C says it supports XMF which can have MIDI embedded. Not sure about browser support though.
To quote from the official Web MIDI API page (http://www.w3.org/TR/webmidi):
To some users, "MIDI" has become synonymous with Standard MIDI Files and General MIDI. That is not the intent of this API; the use case of simply playing back a .SMF file is not within the purview of this specification (it could be considered a different format to be supported by the HTML5 <audio> element, for example).
In other words, W3 Org says browser support for simple MIDI files should be through the HTML5 tag. Sadly, as far as I know, no browser yet supports MIDI via the <audio> tg. But I'll bet that the first one which does is going to get a huge chunk of market share. For example, the site at http://www.hymntime.com/tch has thousands of MIDI files that still have to use the old <object> tag to play. And even then, it still requires a plugin. Try explaining to a non-technical user what a "plugin" is or how to install one!
Browsers are not required to support any specific codecs or encodings by the HTML5 spec. There is some discussion around supporting MIDI-like sound behaviour in the future, but not much - these two posts on the mailing list last year didn't get any direct responses.
I know that QuickTime does (or used to?) support MIDI, and Safari will play any audio that QuickTime supports, so it may work already in Safari but I haven't tried it.
I notice that there are many libraries out there for playing HTML5 audio, but ain't the whole idea of HTML5 audio that we don't need a library for this to work properly?
If I don't need Flash fallback, but a simple solution for streaming music (my own) that can also play each track after each other, do I then need a library like jPlayer or Soundmanager2?
I know I need different audio formats, but that's not a problem as I won't have many tracks online.
The "whole idea" of HTML5 audio is that end users and web page authors shouldn't need to rely on a browser plugin to play audio - the functionality should be included in the browser, and controllable directly from standardised HTML/JavaScript.
I haven't used an HTML5 audio library, but looking at the jPlayer and Soundmanager2 home pages, it looks like the main functionality they offer is fallbacks for browsers that don't support HTML5 audio.
I suspect they might also have some built-in custom UI for playing audio though, in case you don't like the native audio controls that browsers provide.
You could use straight-up HTML5, but you'd soon realize that has a whole host of problems.
Library's like jPlayer (which is great by the way) account for many common issues like browser support, optimization and fall-backs etc.
If you want to code all that yourself you can, but a popular library will be leaps ahead and it's the wise choice to take.
The truth is, HTML5 offers very powerful features, but its support is thin at this current moment in time. It's all to make your life easier!
HTML-5 audio actually encompasses two distinct factions at this point. One is the audio tag and the other is the Web Audio API. The former is a quick mechanism for playing an embedding audio files, the latter is a way to play,process and manipulate audio in a low-latency manner acceptable for game development and more professional environments where features like reverb effects,filters,"3D" sound and other characteristics are needed. But to answer your question, the only real reason to use a library for the HTML 5 audio tag is (in my opinion) for backward compatibility between browsers as well as ease of use for things like multi-shot file triggering and event handling.
I keep hearing all about HTML5 and how great it is, but if I don't really care about audio and video, is there anything it really changes for me? I've read up on the new tags it supports and they just don't seem to be all that revolutionary beyond its video and audio capabilities.
Shamelessly copy-pasted from wikipedia:
The canvas element for immediate mode 2D drawing.
Timed media playback (possibly not interesting for you)
Offline storage database (offline web applications). See Web Storage[21]
Document editing (via DOM API and user interface)
Drag-and-drop
Cross-document messaging
Browser history management
MIME type and protocol handler registration.
Microdata
Browser-based SQL databases
Oh, and WebSockets to replace AJAX and Comet.
http://en.wikipedia.org/wiki/HTML5#New_APIs
DOM storage
Canvas
Drag'n'drop
Semantic microformats support
One of the biggest deals about HTML5 which is under reported is that HTML4 never defined error handing, but this is well defined in HTML5. All browser vendors are building HTML5 parsers that conform to this spec. While this is not sexy, the end result will be that browsers will become more interoperable with each other (especially in cases where the author makes an error). In the long run this should mean you'll spend less time trying to get all browsers to work correctly, and users will benefit from less broken sites in their browser of choice.
HTML5 also allows you to make more application quality sites, using many of the technologies mentioned in the other answers. Opera Dragonfly (the project I'm involved with) is a complex web app which doesn't use audio or video but takes advantage of a large number of HTML5 technologies. We use AppCache to make sure it still works when you are offline, Web Storage to save user preferences and history (we can store a lot more information than cookies allowed) and will likely use Web Workers to allow the app to use more than one process at once (will speed up performance on mult-core machines).
If you are doing anything with graphics then the Canvas API gives you a lot of drawing options, while SVG (an open vector format) can be used within your HTML pages now. Previously pages had to be served as XML for SVG to be included inside them.