i'm using wavesurfer.js for a tool i wrote. I used it to display a certain mp3 file. The problem i have is that if i load the mp3 file in both browsers the one in chrome gets chopped off in the beginning. I started debugging the problem and it seems that a call to audioContext.decodeAudioData from the AudioAPI results in the mp3 getting chopped off in chrome, the input in both cases is consistent (a 2781 bytearray goes in).
From firefox I get 121248 samples back and the layout looks good, from chrome I get 114330 and it's chopped off in the beginning.
I tested another file which is longer and it also gave me a difference of 6918 samples missing.
The same problem occurred under linux with FF where the samples returned are 124416. (gstreamer plugin)
(btw these are all comparable since the systems all use 48kHz output)
The plugin to decode mp3 under windows for firefox is the vlc plugin since ff itself is not capable to decode mp3 due to licensing issues.
the file is encoded as:
Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v2.5, 24 kbps, 8 kHz, Monaural
originally it was a PCM 32kHz mono file
I can imagine that mp3 is not sample consistent due to different implementations of the decoders. (kinda answered my own question here)
What would be a consistent codec over multiple browsers that produces sampleconsistency? I know that Wav should produce comparable results, right?
How about ogg? can I assume consistency in the amount of samples since the codebase should be the same, or does these differences in samples stem from the fact that the audioAPI is built up differently in the different browsers (a bit counter intuitive from an API i would say)
Related
I have a web page which allows users to select multiple .wav files using the file select button of a form. Each .wav is then displayed using the following markup:
<audio src="blob:f3xyz808-1a65-440e-8e5f-b5djfht4ad1a" controls=""></audio>
This works fine in Chrome and Firefox. In Safari, however, if I try to load too many .wavs at once it stops loading. Using the javascript console I can see that the memory that Safari is using grows with each .wav and can reach upwards of 2GB. With Chrome, memory usage does not increase significantly. So it seems like Chrome and FF stream the files from disk. Is it possible to do this with Safari?
EDIT: It looks like a possible solution to this first problem is to include: preload="none" in the audio tag
On separate but related note: It seems like browsers decode the audio files, at least to some extent, when they are added to an audio tag, because if the file is invalid they complain. Is it possible to access this decoded data without creating an audio buffer in memory. Specifically, I want to create a graph of the files' volume level vs. time. Currently, I do this by decoding the arrayBuffer using the web audio api. This uses a lot of memory. Is it possible to get volume level info from the .wav's raw binary data?
I realize this question has some shortcomings. I am a little vague on some of the concepts.
Any tips or suggestions would be a great help. Thank you.
I would like to see if it's possible to have direct access to Opus using getUserMedia or anything similar from the latest browsers.
I've been researching on it a lot but with no Good results.
I'm aware that either Opus or Speex are actually used in webkitSpeechRecognition API. I would like to do speech recognition but using my own server rather than Google's.
So there are a lot of suggestions about Emscripten but nobody did, so I ported the encoder opus-tools to JavaScript using Emscripten. Dependent on what one has in mind, there are now the following opportunities:
Encoding FLAC, WAVE, AIFF, RAW files || demo || Web Worker size: 1.3 MiB
Encoding raw stuff for immediately processing or sending without container || demo || Web Worker size: 0.6 MiB
Encoding to Ogg-Opus and WAV from getUserMedia stream
When using Mozilla Firefox, it's possible to use a MediaRecorder, which would also allow to convert arbitrary sound files into Opus format on supported platforms together with AudioContext.decodeAudioData()
We're using emscripten for encoding and decoding using gsm610 with getUserMedia, and it works incredibly well, even on mobile devices. These days javascript gives almost native performance, so emscripten is viable for compiling codecs. The only issue is potentially very large .js files, so you want to only compile the parts you are using.
Unfortunately, it isn't currently possible to access browser codecs directly from JavaScript for encoding. The only way to do it would be to utilize WebRTC and set up recording on the server. I've tried this by compiling libjingle with some other code out of Chromium to get it to run on a Node.js server... it's almost impossible.
The only thing you can do currently is send raw PCM data to your server. This takes up quite a bit of bandwidth, but you can minimize that by converting the float32 samples down to 16 bit (or 8 bit if your speech recognition can handle it).
Hopefully the media recorder API will show up soon so we can use browser codecs.
This is not a complete solution, #Brad's answer is actually the correct one at this time.
One way to do it is to compile Opus to Emscripten and hope that your PC can handle encoding using JavaScript. Another alternative is to use speex.js.
I was planning on using wavesurfer.js in a project of mine so I checked out the demo on http://wavesurfer-js.org
I dropped a large mp3 file (around 2 hours) onto the middle of the page that asks for a file. It seems to want to load it but after a while Chrome comes up with an error. It doesnt crash, just the tab fails.
With smaller files, single songs, it seems to work ok.
So there seems to be either some limitations with html5 web audio or the websurfer.js library but im not sure. Does anyone have any ideas?
wavesurfer.js GitHub: Large MP3 files cause DOM Exception 12
Sorry that it takes so long to resolve this. From what I managed to google, Safari and Chrome can't decode a large binary due to memory limits.
It looks like it can't be fixed right now, perhaps in the future. They're trying other approaches but without success so far.
I have a camera feed coming into a linux machine using a V4l2 interface as the source for a gstreamer pipeline. I'm building an interface to control the camera, and I would like to do so in HTML/javascript, communicating to a local server. The problem is getting a feed from the gst pipeline into the browser. The options for doing so seem to be:
A loopback from gst to a v4l2 device, which is displayed using flash's webcam support
Outputting a MJPEG stream which is displayed in the browser
Outputting a RTSP stream which is displayed by flash
Writing a browser plugin
Overlaying a native X application over the browser
Has anyone had experience solving this problem before? The most important requirement is that the feed be as close to real time as possible. I would like to avoid flash if possible, though it may not be. Any help would be greatly appreciated.
You already thought about multiple solutions. You could also stream in ogg/vorbis/theora or vp8 to an icecast server, see the OLPC GStreamer wiki for examples.
Since you are looking for a python solution as well (according to your tags), have you considered using Flumotion? It's a streaming server written on top of GStreamer with Twisted, and you could integrate it with your own solution. It can stream over HTTP, so you don't need an icecast server.
Depending on the codecs, there are various tweaks to allow low-latency. Typically, with Flumotion, locally, you could get a few seconds latency, and that can be lowered I believe (x264enc can be tweaked to reach less than a second latency, iirc). Typically, you have to reduce the keyframe distance, and also limit the motion-vector estimation to a few nearby frames: that will probably reduce the quality and raise the bitrate though.
What browsers are you targeting? If you ignore Internet Explorer, you should be able to stream OGG/Theora video and/or WebM video direct to the browser using the tag. If you need to support IE as well though you're probably reduced to a flash applet. I just set up a web stream using Flumotion and the free version of Flowplayer http://flowplayer.org/ and it's working very well. Flowplayer has a lot of advanced functionality that I have barely even begun to explore.
I am using a embeddable Flash based MP3 player (The standalone Version of Wordpress Audio Player, to be exact) to play audio on the web page of a client. Given the nature of Flash based players - AFAIK they all use Flash's audio/video decoding libraries - the exact player product might not matter, though.
She complains that some specific audio files sometimes tend to play slowly, as if on a tape deck that doesn't run at full speed. Her machine is a 5 year old Sony Vaio with a 1.5 GhZ Pentium M Processor, so it's not top of the line anymore but it should not have trouble decoding anything, let alone a MP3 audio stream.
I can't verify the problem because we can't set up an audio connection (slow Internet on a remote island), nor can I reproduce it on my 3.3 GhZ dual-code Workstation, but this is a person whose error reports have seldom turned out unfounded in the past, so I tend to take them seriously.
I see differences between the encodings of the MP3 files (see below).
My question: Has anybody ever experienced something like this?
If yes, what was the reason?
If it's something in the encoding (which I suspect), could somebody give me pointers towards which setting(s) to change?
This is what Winamp tells me about a file that is sometimes slow:
MPEG-1 Layer 3
128 Kbit, approx. 966 frames
48000Hz Stereo
CRC: Yes, Copyright: No
This is what Winamp tells me about a file that is never slow:
Encoder delay: 576, Zero Padding: 1584
MPEG-1 Layer 3
151 Kbit (VBR), 12405 Frames
44100Hz Joint Stereo
CRC: No, Copyright: No
I think this is a bug with certain versions of the Flash player. I have a Flash-based MP3 audio player that I made with the same problem. The solution is to make sure it is a 44,100 kHz MP3 file... or make your users upgrade their player.
Here is my site with the details:
http://web.archive.org/web/20111227184112/http://www.quickmediasolutions.com/sandbox/audio_player/
This is likely because the sample rate info in the header file does not match the sample rate the file was encoded with. Try fixing the problematic file with one of the MP# fixer utilities: google search.
It is also possible that this is a driver issue on their pc, and reinstalling/updating their audio driver may solve the problem.