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.