|
|
|
[
Permlink
| « Hide
]
Soft Linden added a comment - 07/Apr/08 09:12 AM
I want to make sure a Linden doesn't take this in without understanding - can you point to an authoritative source that says the header size should be included in the total?
Let me see if I understand you properly. You're saying the header in a WAVE file is 8 bytes long, and it contains the amount of data that will be in the rest of the file. Say there's 512 bytes of actual sound data. You're saying that the .dsf file being written is going to be exactly 512 bytes long, INCLUDING the header? That sounds to me like it'll leave off 8 bytes of data, which is definitely a problem!
This could explain why I sometimes get little pop sounds in looping sound files even when I carefully cut my sound samples at zero-crossings. Soft, if I'm correct in my understanding, Carjay is saying the exact opposite – that the header size shouldn't be included in the data_length in the header, but the current code is essentially treating it as if it is. Ah, no, Soft, you misunderstood. It's pretty simple and the way Lex assumed.
The generated header is correct, it's the amount of data that is written which is wrong. Original code snippet: S32 data_length = mWAVBuffer.size() - WAV_HEADER_SIZE; mFileHandle = LLLFSThread::sLocal->write(mOutFilename, &mWAVBuffer[0], 0, data_length, 1. mWAVBuffer holds all data (the total 44 byte header and the pcm data). 2. data_length is initialized with that size minus WAV_HEADER_SIZE (the 44 bytes) so by now it is the length of the actual pcm sample data. 2. Next, 36 is added (which is the length of the "fmt" section header). This value is now written to the RIFF header. This is correct, too. So all the header data is indeed correct. But we want to write the whole mWAVBuffer and data_length is still missing the 8 bytes from the RIFF header. Either add 8 or just use mWAVBuffer.size() (as I did). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||