5

Think about a program where it is mission critical to sync audio playback with text being displayed on the screen. And timing of this sync must be perfect.

Currently, I am having all sorts of trouble with this as browsers are not accurately representing the playback position within mp3 files, specifically for long .mp3 files (nor .ogg), perhaps with variable bit rates (as opposed to constant bit rates)... still experimenting with all the combinations. They are often up to a half-second or more off time, especially when "scrubbing" through the long track.

I have been led to believe that these inaccuracies are the result of the compression techniques used to shrink files and that I may be able to completely sidestep this issue by making use of .wav files within my application (not ideal, but the timing MUST be accurate). I still need to do more testing on this, but I want to ask here to get the opinion of people who understand audio compression/codecs, etc. better than I do.

This applications makes use of thousands of mp3's. If a file is already an mp3, is it feasible that converting to wav after the fact could address these timing issues? Or is it a situation more like with the quality of the audio itself that once it is downsized to mp3, the information is lost and converting back to wav will not "get that lost data back?"

Thanks for your insight.

**EDIT - as it turns out, variable bit rate encodings on your mp3 files are indeed the problem here. If you need accurate timing, make sure you use FIXED/CONSTANT bitrate encoding.

Improve this question
13
  • 2
    Well, I think it falls somewhere in the middle. I have already posted over there but my take is that most developers (such as myself) may not have a solid enough understanding of audio compression/codecs etc to really know what all may be going on here, specifically how different types of files/codecs/bitrates/sample rates/etc. might relate to inaccurate time reporting by the browser... :( stackoverflow.com/questions/25468063/…
    – Brian FitzGerald
    Commented Jun 14, 2016 at 17:21
  • 1
    That thread is not comprehensive as it doesn't solve the problem, so I have to go deeper... to the source (audio knowledge). Anyhow, I understand your point. I will ask another question that gets more directly to what I want to know regarding the audio. Thanks!
    – Brian FitzGerald
    Commented Jun 15, 2016 at 14:20
  • 4
    Is it a lot of work to just try it? You already have the system built that tries to follow MP3s, can you adjust it to run on wave files instead? In terms of audio nerds being able to answer your question, one challenge is we don't know why the MP3s could not sync. If the sync is trying to track the position in the audio file by "counting" words or bits, then wave should work better than MP3 because word length and sample rate are fixed in wave files, but not always fixed in MP3s. You might also look for formats that can include position/clock metadata.
    – Todd Wilcox
    Commented Jun 15, 2016 at 23:06
  • 1
    Could you say a bit more about the timing of the images/words, how that is being run? I'm having trouble visualizing what you are doing. How are you playing back the sound file and what exactly has to correspond with what? Why are you not paying back video files where the images and sounds are fixed in position rather than having two separate entities?
    – Phil Freihofner
    Commented Jun 16, 2016 at 1:33
  • 6
    The problem is not one of 'reliability' as you say, but a simple matter of how the format works. The mp3 stream is divided into frames, and each frame holds exactly the same length (time) of audio.. approx 26 milliseconds. But the size (bytes) of each frame will vary based on the bitrate of that frame. In a VBR file, the bitrate thus the frame size varies, so there's no way, by looking at the number of bytes of data consumed/left, to know exactly where you are in terms of time past/remaining. You can only approximate. With CBR and WAV, the relationship between bytes and time is linear.
    – little_birdie
    Commented Jun 22, 2016 at 21:26

1 Answer 1

Reset to default
1

It does not make sense. You get a lot bigger filesizes, precisely 620 MB per hour of audio (which translates to 20 3-minute-long songs). For thousands, you're looking at about 60 GB of music. A minute of uncompressed audio is 31 MB. For an average American (source), that's 13 seconds of loading a single minute of audio. Not to mention 31 MB of data from a mobile plan if your users happen to use a phone, where the situation would get worse.

VBR (variable bitrate) seems to be a common issue as seen here and here. There are some bug reports like this 2-year old bug in Firefox which got marked as works for me. There are also a similar questions on StackOverflow (see HTML5 audio starts from the wrong position in Firefox and Inconsistent seeking in HTML5 Audio player). You might have better luck with Web Audio or a library that uses it, such as SoundJS.

You also need to properly configure your server to send X-Content-Duration headers

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.