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.
Related
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)
I'm playing around a bit with the HTML5 <audio> tag and I noticed some strange behaviour that has to do with the currentTime attribute.
I wanted to have a local audio file played and let the timeupdate event detect when it finishes by comparing the currentTime attribute to the duration attribute.
This actually works pretty fine if I let the song play from the beginning to the end - the end of the song is determined correctly.
However, changing the currentTime manually (either directly through JavaScript or by using the browser-based audio controls) results in the API not giving back the correct value of the currentTime anymore but seems to set it some seconds ahead of the position that's actually playing.
(These "some seconds" ahead are based on Chrome, Firefox seems to completely going crazy which results in the discrepancy being way bigger.)
A little jsFiddle example about the problem: http://jsfiddle.net/yp3o8cyw/2/
Can anybody tell me why this happens - or did I just not getting right what the API should do?
P.S.: I just noticed this actually only happens with MP3-encoded files, OGG files are totally doing fine.
After hours of battling this mysterious issue, I believe I have figured out what is going on here. This is not a question of .ogg vs .mp3, this is a question of variable vs. constant bitrate encoding on mp3s (and perhaps other file types).
I cannot take the credit for discovering this, only for scouring the interwebs. Terrill Thompson, a gentlemen and scholar, wrote a detailed article about this problem back on February 1st, 2015, which includes the following excerpt:
Variable Bit Rate (VBR) uses an algorithm to efficiently compress the
media, varying between low and high bitrates depending on the
complexity of the data at a given moment. Constant Bit Rate (CBR), in
contrast, compresses the file using the same bit rate throughout. VBR
is more efficient than CBR, and can therefore deliver content of
comparable quality in a smaller file size, which sounds attractive,
yes?
Unfortunately, there’s a tradeoff if the media is being streamed
(including progressive download), especially if timed text is
involved. As I’ve learned, VBR-encoded MP3 files do not play back with
dependable timing if the user scrubs ahead or back.
I'm writing this for anyone else who runs into this syncing problem (which makes precise syncing of audio and text impossible), because if you do, it's a real nightmare to figure out what is going on.
My next step is to do some more testing, and finally to figure out an efficient way to convert all my .mp3s to constant bit rate. I'm thinking FFMPEG may be able to help, but I'll explore that in another thread. Thanks also to Loilo for originally posting about this issue and Brad for the information he shared.
First off, I'm not actually able to reproduce your problem on my machine, but I only have a short MP3 file handy at the moment, so that might be the issue. In any case, I think I can explain what's going on.
MP3 files (MPEG) are very simple streams and do not have absolute positional data within them. It isn't possible from reading the first part of the file to know at what byte offset some arbitrary frame begins. The media player seeks in the file by needle dropping. That is, it knows the size of the entire track and roughly how far into the track your time offset is. It guesses and begins decoding, picking up as soon as it synchronizes to the next frame header. This is an imprecise process.
Ogg is a more robust container and has time offsets built into its frame headers. Seeking in an Ogg file is much more straightforward.
The other issue is that most browsers that support MP3 do so only because the codec is already available on your system. Playing Ogg Vorbis and MP3 are usually completely different libraries with different APIs. While the web standards do a lot to provide a common abstraction, minor implementation details cause quirks like you are seeing.
I want to add video upload support to my small school and after some research i came across sample code:
exec("ffmpeg -i ".$dynamic_path."/".$ moviepath."".$fileName."
-sameq -acodec mp3 -ar 22050 -ab 32 -f flv -s 320x240 ".$dynamic_path."/".$flvpath."myflv.flv");
I understand this will guarantee conversion, but am using shared hosting, so i would like to know what kind of format flash supports and is their any javascript/flash support to play video files without conversion.
thanks
This is what our company does for a living, and we have arrived at mp4 being the standard for nearly every highschool/college/university in the country - the definitive list can be seen here:
http://helpx.adobe.com/flash/kb/supported-codecs-flash-player.html
The video player that they all seem to prefer is the JW Player, and it can be found at http://www.longtailvideo.com/players/jw-flv-player/. Another is Flowplayer, though my experience on this one is limited. The only difference between JWPlayer paid/free is the watermark, so you can experiment with this and Flowplayer before you buy one.
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.
My application is written in Adobe Air & JavaScript and doesn't use Flash/Flex.
Air.Sound() is used to play (shoutcast) audio streams.
I'm looking for a solution (without using external Flash/Flex players, coz) that can preload (buffer) a few second of audio stream to avoid playback lags and keeping memory usage low.
As far as I know Air 2.5 added Audio and Video html5 tags.
For shoutcast and html 5 audio see this question
Edit: Apparently AIR left out the audio/video tags (because they are an alternative to flash and you get flash on AIR - the way adobe looks at it). So I think the answer is you can't do it without flash. Even if it had the audio tag you'd most probably need to tweak the output streams from the server.