Web-audio-api: decodeAudioData: option to disable automatic resampling to context rate

[olivierthereaux]

Originally reported on W3C Bugzilla ISSUE-21519 Tue, 02 Apr 2013 14:41:41 GMT
Reported by Olivier Thereaux
Assigned to

Per discussion at Audio WG f2f 2013-03-26

Add an optional 4th argument for decodeAudioData that disables automatic sample rate conversion.

[douglasbagnall]

This would be very useful to me for creating visual spectrograms from 8kHz wav files. Currently I parse them explicitly, and would prefer to use the Web audio API, but that will involve either back-resampling or pointlessly huge and costly FFT windows. I want the original PCM samples.

[karlt]

An OfflineAudioContext can be created at any sample rate supported by the implementation, and that buffer can be used in other AudioContexts. However implementations may not support rates below 22050 Hz, and creating the OfflineAudioContext requires knowing the encoded sample rate.

[cwilso]

Actually, perhaps the argument should be the desired sample rate - the default (when it is omitted) should be the audioContext.sampleRate, and "0" means don't resample.

[joeberkovitz]

This issue is very important as otherwise it is not possible to use the built-in codecs to acquire an unmunged version of the data in a decoded file. The desired-rate idea proposed by cwilso seems fancy but maybe is useful.

[karlt]

The only information that decodeAudioData uses from the AudioContext is the sampleRate, which would seem to suggest that a similar decode method that doesn't use the sampleRate would be better not on the AudioContext. Compare issue #370.

[cwilso]

Although I agree with you, in discussion yesterday we specifically agreed that a complete, prescriptive well-rounded decoding API is out of scope for v1. With that in mind, I'd rather just keep this on AudioContext for the moment.

[skratchdot]

I added a comment in #300, but I would really like to have access to the original non-resampled rate (if it's available). I'm not sure if I can squeeze that request into this bug, or if I should log something new.

For instance, assume I have a .wav file that has a sampling rate of 11025. Currently, I call decodeAudioData on that file, and I get an audioBuffer with a sampling rate of 44100. This is fine, but it would be great if there was a 2nd argument to the DecodeSuccessCallback callback that contained some additional information (originalSamplingRate at least- perhaps other info like originalNumberOfChannels, originalMimeType, etc).

I can describe my use-case if needed, but I would guess this info might be useful to other people as well.

[lonce]

Yes, the ability to get the original audio file data would be very useful.
Also, it seems inconsistent that decodeAudioData automatically resamples, but leaves the original NumberOfChannels no matter what the AudioContxt number of channels is!

[rtoy]

Leaving the number of channels as the original makes sense. You can do all kinds of single-channel or multi-channel processing and then mix the result up (or down) for the number of channels in the context.

[rtoy]

This is part of the "current sprint". How do we want to do this? To kind of match the other things we're doing, I propose an optional fourth parameter that is a dictionary with the single option of "disableResampling", which defaults to false to preserve current behavior.

[padenot]

That makes sense. This could be used in the future to specify in-memory compression settings and things like that.

[rtoy]

Also, perhaps we can allow

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, DecodeAudioDataOptions options);

I think this is more natural if want to support promise nicely. It would be a pain to have to specify the optional callbacks if we want to disable resampling and if we were using the promise pattern to handle decode success and failure.

[rtoy]

The proposal in https://github.com/WebAudio/web-audio-api/issues/30#issuecomment-228441793 won't work. IDL does not distinguish between a callback and a dictionary (both are objects), so it can't disambiguate the call to the two methods.

We will have to do something else, like add the optional dictionary after the error callback. Or create a new method for this. Or something.

[joeberkovitz]

Resolved on WG call today that we will move to v.next as part of designing a more thorough decoding API that includes progress callbacks.

[rtoy]

Closing this CL, per https://github.com/WebAudio/web-audio-api/issues/30#issuecomment-235950008

[Pomax]

As this issue is pretty high on Google's list when searching how to get the sampleRate of an audio file _before_ building a context for it, what was the result? Comment #30 mentions it got moved to the next version, but that was almost 4 years ago and as far as I can find online, no way to discover this value short of "knowing the file format, and performing a partial file-format-appropriate byte examination".

Can this be confirmed or refuted, so that others who find this issue hoping to find a solution to their problem won't still be lost?

[padenot]

The consensus is that all this work in now in the hands of the web codec group, where a good solution for this is being designed.

The Web Audio API's scope in V2 explicitly excludes any audio decoding and encoding, and focuses on processing.