Waveform creation: mono AudioStreamWAV has double the expected number of samples?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By yhilanko

I have a local wav file, 16 bit mono with a sample rate of 44100. It’s opened with a file chooser dialog, but can also be called from within res://. Doesn’t make a difference for this problem. Here’s the issue, after some code:

	var audio_stream = ResourceLoader.load(path) as AudioStreamWAV
if audio_stream.stereo == true:
	audio_stream = audio_stream.resample(audio_stream.get_mix_rate(), 1)

I set a few variables just to keep track of things, included here just to confirm that I’ve looked at these options.

var bit_depth: int = (audio_stream.format + 1) * 8
var is_stereo: bool = audio_stream.stereo
var sample_rate: int = audio_stream.mix_rate
duration = audio_stream.get_length()

These all return the correct values. I’ve checked and triple checked everything in other software. It’s 16 bit, mono, 44100, 10 seconds.

Here’s the problem: audio_stream.data.size(), which should be the total number of samples, gives a number which is exactly double the result of audio_stream.get_length() * audio_stream.mix_rate, and I can’t work out why.

Other than the obvious things like it actually being stereo (it’s not), what would be a cause of this?

I’m trying to make a waveform image drawn on a control node, which works just fine for that bit, but the data in the PackedVector2Array which comes from the waveform simply doesn’t match the actual audio file.

I’ve messed with chunking samples, shifting resolution, checking for outlier samples like clicks that might mess things up, but when comparing to the waveform in Audacity as well as directly with another waveform I made in a Python script from the same audio, only the one coming from this GDScript is wrong. And I suspect it has to do with the double sample lengths.

What is the cause of this?

Note that the exact equivalent python code with the same audio gets the right results, as touched on above. So it’s not to do with how I’ve written the loops.

:bust_in_silhouette: Reply From: yhilanko

I have figured out a workaround, which is to just start the index at 1 and skip every other sample, so it’s not a question of bad data through some stage of the import. I’ve got something I’m happy with for the time being, then, but would still be interested to hear why there are twice as many to begin with.