remotion-dev
getAudioData() returns system sample rate instead of audio file sample rate
The audio context will re-sample an audio file decoded with BaseAudioContext.decodeAudioData().
The decoded AudioBuffer is resampled to the AudioContext's sampling rate, then passed to a callback or promise.
- https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/decodeAudioData
Getting the sample rate from the audio file doesn't seem to be completely trivial (if possible): https://github.com/WebAudio/web-audio-api/issues/30
When does the AudioContext sample rate change?
For me I discovered this when I plugged in my external audio interface. The AudioContext seems to reflect the system sample rate. Without the audio interface my system has a 44.1 khz sample rate, and with the audio interface it by default picks 192 khz.
This varies by device and an audio visualization preview in the browser will look different from the server-side rendered result if the user device and the server have different system audio sample rates.
When is knowing the audio file's sample rate important?
Knowing the sample rate of the recorded audio is important for determining the linear frequency-width of each bin of the FFT response. This lays the foundation of making really good audio visualizations, for example using a tempered scale sampling of the frequencies to make an equalizer that "feels right" according to human non-linear hearing (see this example).
Alternate possible solutions?
I've made some assumptions about the 44.1 khz sample rate in my code, and will need to test things out a little more before suggesting a solution.
I'll circle back to this when I have solutions...
Thanks for that! Should This could be useful to add to the docs, shall I paste this into the getAudioData() docs? I guess we have no option to change the behavior, so there is nothing actionable in the code?
@JonnyBurger I'm not convinced it's completely unactionable. I suggest holding off adding too much in the docs right now. Possibly link to this issue in a foot note?
No advancements on it because I have no idea how this could be fixed unfortunately 🤔 Looks like a browser behavior we inherit right?
If you use Audio API for sure.
If you are interested in getting the right sample rate of an audio file, you can use music-metadata-browser that will return the right sample rate instead of the system one.
A demo is available here
Since it's open source, you could check the code if you are interested in this feature, maybe.
Thanks for the answer anyway :)
Interesting, I think it would be a mistake to include a big dependency to this dependency-free package though just to solve a browser edge case, when the scope of the media utils package is much broader.
So I would suggest to use this package directly instead rather than rely on the Remotion one.
Of course, I was addressing the message in case someone ends here with the same needs as mine.
Thanks for your time.