First, I apologize as I'm essentially new to working with audio.
The web application I currently work on, designed using asp.net/vb.net, allows users to record and play back audio using the Nanogong applet (http://nanogong.ust.hk/doc_faq.html). We are shifting over to HTML5 audio as support for the NPAPI plugin has been removed from most browsers (except Firefox until the end of this year).
Nanogong uses 4-bit IMA ADPCM to encode wav files. I'm able to convert the Nanogong wav file into 16-bit PCM using sox, and then using that wav file create an ogg version using oggenc2 and an mp3 version using lame. We need the ogg files for Firefox and Chrome, and the mp3 for Safari.
What I would like to learn is why browsers do not seem to be able to play the 4-bit IMA ADPCM format? Can they only play PCM format in 8-bit or 16-bit? In Firefox, firebug indicates the IMA ADPCM wav file cannot be decoded; Chrome and Opera don't mention anything in the developer console, but I'm guessing it's the same as Firefox since the file won't play in those browsers.
I've tried searching the web but there doesn't seem to be a whole lot about HTML5 audio, or most of it seems to be older information. I also see more articles about converting from PCM to ADPCM.
Any guidance or resources would be greatly appreciated. Thanks!!
Browser vendors are not required to support any particular audio format. There are issues such as licensing, although perhaps not so relevant in this case, which make vendors only support the most basic (such as uncompressed PCM) and common formats (MP3, OGG etc.), and in some cases would rely on the underlying system to decode audio (or video). Size of code base relative to gain could be another factor.
4-bit IMA ADPCM would fall into the category "not so common" as of today which is likely why there is no support to find in the browsers.
It's possible to get around this though by supporting the format manually using Audio API (which eliminates IE) and binary parsing/decoding. I am doing this is my audio-reader-js library but currently I have no support for IMA encoded data. It can be used as a basis though to implement support for this as well.
Related
Because I dislike Youtube and Vimeo is too expensive, I chose to upload my videos directly to the server at my web host and embed the videos on my site using the HTML5 tag (see photos for the code). The videos play fine on all browsers except for Firefox and I can't figure out why. https://memoriaelinguagrumentina.org/english/saponareseCuisine.html
I've seen several other posts on here asking about very similar problems; however, nearly all are at least 8 years old. I've gone through them as part of my troubleshooting process, but without any luck.
I've seen it recommended here to use multiple video formats (.mp4 AND .ogv) because there is no universal format supported by all browsers. Firefox did not always support mp4, but I believe it does now. So I don't believe this is the root of the problem.
I checked with my web host to see if they have the correct MIME types (see photo).
I cleared the cache on my browser, set the privacy settings to normal, and checked hardware acceleration.
What am I missing?
*note: To save disk space, I'd like to not have to upload duplicate videos in different video formats to the server, ideally. Since Firefox now claims to support mp4, I was hoping to get away with using only mp4.
Firefox doesn't support all video files. They generally support MP3, WebM, Ogg, and Wave containers, and if you are using an MP4 container then it usually depends on the platform decoders for AAC and H.264 audio and video streams. The video encoder format that you are using isn't supported by firefox. You should use supported encoders for your video.
You can find more information here:
https://support.mozilla.org/en-US/kb/html5-audio-and-video-firefox
Your MP4 videos are using H.265 video codec.
You need to have them encoded as H.264 to work in most browsers.
Solution: This means you must re-save your videos as a new format.
The problem is not just Firefox, even Windows Chrome does not play H.265 encoded video.
Things to fix:
Re-encode as H.264 (use High or Main profile for better compression-vs-quality output).
Re-size your videos (when doing re-encode). 720p should be okay for demos/intros. You don't need a large 3840 x 2160 pixels video showing inside a small 672 x 398 pixels box.
Your file size is not good. 286 mb is too much data loading for just a mere 6 minute video.
I am trying to make a simple node-webkit app that lets you play .avi videos (which should work both on windows and mac). Is there a way to do this with node-webkit?
It is unlikely you will be able to just do this with Node-Webkit. Especially since the official webkit does not support AVI. Your best bet is to use an external application like libav (avplay) or use node to serve a webpage that has a player capable of playing the content and just let the users browser do the work. (Flash is likely still the best way to go, video.js is a good choice)
The alternative is to convert the video to one of the supported formats. I would recommend mp4. (Once again libav (avconv) comes in handy here.) This still assumes that Node-Webkit has implemented full HTML5 support. (I am not sure what they have completed but I am guessing it supports the video element)
Is AVI supported in Chrome (not Chromium) ?
If it is you have to change the libffmpegsumo.so in nw for the one in Chrome (try to use the same version).
libffmpegsumo.so is called ffmpegsumo.dll in Windows
The file file is in the same folder of the nw executable
to get the file download google chrome and go to %USER%/Google Chrome/ (or something like that) and you'll find the file in the same folder of the google-chrome executable
You can wcjs-player to play any format video which supported by VLC. It plays any video without any lags as in-built player.
To support my above claim, I have following points:
Building NW (by compiling source code) with various FFMPEG codec flags given at nw github site, doesn't help, in getting ffmpegsumo.dll which can play avi file format.
wcjs-player uses VLC libraries, which support all video played by VLC does.
Its better than using any nw plugin, as internally wcjs-player using VLC does similar job as HTML native video support .
Even if you suceed playing avi files, sometimes supported videos file format may not get played like most ironically mp4 file itself.
Apart from this, Teewe Theatre, Popcorn Time , Butter are among NW based media player using wcjs-player. It hardly increased 30 MB size of overall app size.
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 am planning on video upload capability on a public website.
I am not going with Flash instead going with HTML5 using MediaElement.js
My goal is to make sure that processed videos play on browser and all smart devices
I used to convert uploaded videos to flv file to play using flash.
I will use FFMPEG to convert uploaded videos to the target format.
My question is how many different format do I need to process\convert the uploaded files?
You will need at least 2 for the HTML5 video element. You need to supply a H264 and either Ogg or WebM. See Wikipedia for the supported codexs.
I have never used MediaElement.js but it look like they can work with either of the two formats in browsers that don't support the element.
if you want to play everything via HTML5 then YES, you do need 2 video-files for each video, as explained by Maurice.
BUT: You could use the Flash-fallback and only use mp4 videos (MEJS will take care of Flash). That way it plays on iOS, many Android devices and chrome, safari and IE9 via HTML5 - Firefox and Opera users will see the Flash-player.
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.