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)?