I am working with audio files where in I upload and each time the audio file is fetched from the server it is represented in the UI with functionality to play/pause etc. I am working with.wav/.mp3 files of duration close to about an hour.
The library I am using for displaying the waveform loads the entire audio file at once into an audioBuffer
so streaming is out of option.
I am trying to find a way to cache the audioBuffer
in order to skip the decodeAudioData()
step entirely.
What I am currently doing is store the Float32Array
representation using audioBuffer.getChannelData(0)
method and convert back to audioBuffer
(which almost takes the same amount of time) and using localforage
to use indexedDB to set and get, but it has it's limitations and cannot store the Float32Array
for large mp3 files (1hr ~ file size of about 86-100mb)
I cannot direclty store audioBuffers
in indexedDB due to incompatibility of indexedDB to store such formats.
I need a way to skip the decodeAudioData()
step and directly consume the audioBuffer
of the files already loaded once.
As an alternative, it may be worth caching the visual waveform once it's generated (or pre-rendering on the server). Perhaps the visualization can be rasterized and stored as a png/jpg locally or sent from the server. Or if it's SVG, those elements could be saved. Or if it's canvas, perhaps the pixel matrix could be saved, which would probably use less memory than decoded audio.
One thing the <audio>
element is good for is streaming and seeking. The browsers do a lot of that heavy lifting for you and should balance performance optimizations without needing to fetch and decode the entire 1hr audio file. If you could leverage the native platform features while using visual component caching, this may be a way around local cache size limitations.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.