2

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.

Gagan Ganapathy Ajjikuttira
  • 217
  • 1
  • 9

1 Answers1

0

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.

anthumchris
  • 8,245
  • 2
  • 28
  • 53