peaks.js
peaks.js copied to clipboard
Long audio files encoded with VBR cause desync with waveform
Using CBR mp3 rather than VBR resolves the issue. Just thought I would let you guys know. Fantastic work!
Can confirm in Chrome, .dat files generated from CBR or VBR only work with CBR audio source... if audio source is assigned to a VBR encoded mp3 the playback is out of sync with the drawn waveforms. You can even see the difference looking at the audio controls timer, VBR encoded mp3s end earlier than CBR encoded mp3s.
https://github.com/bbc/audiowaveform/issues/34#issuecomment-508568079
Thanks, Lee. I can also confirm that the same occurs when using the Web Audio API rather than precomputed .dat files, and also in Firefox. There are two cases where the audio and waveform become out of sync:
- on seeking to a different time in the audio
- a gradual drift during playback
So far, I have only confirmed in the seeking case.
Hi @chrisn, is there any fix will be applied to out of sync issue in the next release? Currently, I just using ffmpeg converts audio to 64bit rate to avoid this issue.
It's not clear that this is fixable in Peaks.js (suggestions welcome), so for now converting your MP3 files to CBR is recommended.
Instead of converting MP3 file to CBR is there any other alternatives to get rid of this delay?
Instead of converting MP3 file to CBR is there any other alternatives to get rid of this delay?
It’s not a static delay. The nature of VBR is for the bitrate to constantly change thus the delay will constantly change. The way this plugin works is to have a .dat value that corresponds with each set of grouped samples. To match these we need to know the fixed bitrate.
When I first opened this issue I didn’t understand this. It’s fair to say that without a completely different approach and a complete rewrite, this application won’t support VBR mp3s.
This is the thing... I suspect there's little that can be done in this library, rewrite or otherwise.
Audio playback is handled by the browser, and we use Web Audio decodeAudioData
to produce the waveform from the MP3 - so it's possible we're looking at a browser implementation issue that simply can't be fixed in a JavaScript library.
But I think we need more information on what exactly is happening before coming to that conclusion.