Hi!
I've written a Visual Studio 2008 project in VB.Net based off the
Concatenating Wave Files Using C# 2005[
^] project. I wanted to re-write it so that I could understand what's going on and because I wanted to join more than two wave files.
My project has an issue I wondered if you could help with? When I join files, in the resulting merged file, the first file plays fine, but next one is corrupted. That's the pattern: good file/bad file/good file/bad file...
Here's the code that produces the merged file:
For Each strFile In strFiles
fsInput = New FileStream(strFile, FileMode.Open, FileAccess.Read)
Dim byteWaveData(fsInput.Length - 44) As Byte
fsInput.Position = 44
fsInput.Read(byteWaveData, 0, byteWaveData.Length)
fsInput.Close()
fsInput = Nothing
fsOutput = New FileStream(strNewFileName, FileMode.Append, FileAccess.Write)
bwOutput = New BinaryWriter(fsOutput)
bwOutput.Write(byteWaveData)
bwOutput.Close()
fsOutput.Close()
bwOutput = Nothing
fsOutput = Nothing
byteWaveData = Nothing
Next
If I load all the input into the byte array and then issue a single write to the output, each of the joined segments in the merged file play correctly.
Can you see what might be causing the problem?
Thanks!
Phil Jones
>>Having only one header for the merged files also implies that the sample rate and other important parameters
>>of the files must much. Since you didn't elaborate what kind of corruption you encountered I take it
>>that the corruption could very well come from this.
>>If you want serious help with you problem please feel free to edit your question and add the relevant
>>details.
I did read the article carefully, along with several other articles on the web, including 3 pages that describe the file format for WAVE files.
The term "one header" is somewhat misleading. RIFF specification WAVE (PCM) file formats are arranged in chunks and sub-chunks. Each file has one "RIFF" chunk, one "fmt" sub-chunk, and usually only one "data" sub-chunk (though it can have more than one "data" sub-chunk).
If my "RIFF" chunk had incorrect data in it, the entire file would not play at all. That's not the case. The 1st joined file portion of the "data" sub-chunk plays correctly, the 2nd only produces hissing noise, the 3rd play correctly, the 4th produces hissing noise, etc.
As I noted in the original post, if I change my code to load all the "data" sub-chunk inputs into a single byte array and then perform a single BinaryWrite operation to the merged file, the entire file plays without any error whatsoever. I only get the problem if I perform a BinaryWrite operation after each file input, which is what I would prefer doing as WAVE files can be as large as 4 GBs.
Loading 4 GBs into a single ByteArray would be a serious memory intensive operation. I know because I tested that scenario using a single BinaryWrite operation (the merged file played correctly, by the way). After the test, I had to reboot my PC (which has 4 GBs of ram) because it was sluggish after the test.
Having looked over the previous web pages on WAVE file formats again, the only thought I have at the moment relates to the information that WAVE file chunks and sub-chunks are supposed to end on full Word boundaries. If they do not, they are supposed to be padded with binary zeroes. I'm not coding for that, but then again, Ehab Mohamed Essa's original project (which is excellent, by the way... thank you Mr. Essa if you're reading this), does not code for that either, and his project does not result in my problem; I've tested it.
So unless there's some difference between C# (which I know little about) and VB, then the Word boundary issue may not be the problem.
To be clear, every WAVE file I'm testing with has exactly the same encoding (the same channels, audio format, sample rate, sample size and bit rate).
As a test, I ran the same two WAVE files through Mr. Essa's project and mine. In the separate merged files, the "RIFF" chunks and the "fmt" sub-chunks are exactly the same. The only difference between the two merged files is that my file is longer. Eacy BinaryWrite operation apparently adds 1 byte to the file's length, and I can't account for it.