Sound Design Stack Exchange is a question and answer site for sound engineers, producers, editors, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I'm trying to create audio files to be played by a very picky program. Creating a 32-bit float 22050Hz WAV file in Audacity seems to play fine. However, creating a 32-bit float 22050Hz WAV file with NAudio makes the program crash when I try to play it, even if they both came from the same source. Looking in Audacity, both files seem to have the same sample rate and sample size.
Is there any way I could examine these files to figure out the differences and what's wrong?
To examine difference between files, an hexadecimal editor will be helpful. Most of them allow to display differences between two files. You can find one appropriate to your operating system. A good starting point is to see what are the differences between the two files, especially what is different in the non-playable file.
Now, the point is what to look for. A wav file is composed of two main area : a header and a data chunk. The header itself is composed of several chunks, some of them mandatory, others optional. The issue you are facing might have several reasons :
This page might be helpful to check where the problem is occurring.
Edited after being able to look at sample files.
And this page is helpful too, I will be using it as a reference.
The files produced by the original poster are actually 16 bit, not 32 bit float. Nevertheless :
Here's the header part of the naudio produced file (up to the 'data' chunk)
52 49 46 46 2C 94 00 00 57 41 56 45 66 6D 74 20 12 00 00 00 01 00 01 00 22
56 00 00 44 AC 00 00 02 00 10 00 00 00
And here's the header of the audacity generated file (up to the the 'data' chunk) :
52 49 46 46 A4 94 00 00 57 41 56 45 66 6D 74 20 10 00 00 00 01 00 01 00 22
56 00 00 44 AC 00 00 02 00 10 00
You can notice that the naudio header is 2 bytes longer than the audacity one.
You can also notice that the 'fmt ' subchunk of the audacity file (starting at byte 12) is declared as 16 byte long (0x10 0x00 as int little endian), whereas the 'fmt ' subchunk of the naudio file is declared as 18 bytes long (0x12 0x00). And both respect their declaration (the subchunk is actually 2 bytes longer on the naudio file, that's where the 2 exceeding bytes come from).
But it seems that for a wav file with PCM data, this subchunk has to be 16 bytes long and should not use the 'extra param size' mentionned in 2.
So I think the issue comes from the fact that several players succeed in parsing these extra two bytes where the Source Engine fails, maybe because it is stricly expecting a 16 bytes long 'fmt ' subchunk.
Addon : NAudio's source code is available on github.
So let's dig a little bit more. And have a look at the file WaveFormat.cs.
Line 307, we can see the Serialize method. And we can notice that the size of 18 bytes is hard coded in this method, as well as a place to store the extra size, which can be used in case you are writing a non-pcm wav file, and is set to a value of 0 in case of a pcm file.
So now, who's the culprit ? I cannot say whether the way Naudio writes the file is in conformance with standard, although the header is actually well formed, or if the Source Engine wav parser is buggy. Most wav files writer do not include the extra size when writing pcm audio, but several wav readers parse the naudio files correctly. Maybe you could create a bug report on Naudio's github to see what Naudio developer thinks of it ?
