WaveFileWriter fails to pad oddly sized chunks of data

[JoeTheJock]

I had an issue where streamed audio of 16 bit sample depth was wrongly being saved to a .WAV file via WaveFileWriter. On inspection using a Hex editor I found that the 16 bit samples were apparently being written with the bytes swapped so e.g. sample 0x0015 would be written 0x1500. The result was a corrupt WAV file that was incomprehensible hissing. I inserted an extra byte at the start of the data and the WAV file was as I would have expected.

After much trawling the Internet I found one description of the WAV file format that mentioned a 'padding' byte to be appended to a chunk where 'n' is odd, 'n' being the chunk length. I added a check and conditional pad byte prior to the Write call into WaveFileWriter and the problem was solved.

Is this a bug in WaveFileWriter.Write or should the caller be responsible for ensuring that the chunk size is always on the sample size boundary (%2 in this case)?

[Crow8644]

From what I can gather from documentation and articles like this the design philosophy in NAudio is that the caller is responsable for lining up data with the bit depth. That's just my best understanding, but it seems to apply across the package, not just to working with writers.

In order to work with this programatically, WaveStream has the BlockAlign property, and WaveFormat has the blockAlign property. You can get the WaveFormat of your WaveFileWriter, so that should help if you need to code checks that work with any bit depth.