Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualcr88192

Posted 14 March 2013 - 01:20 AM

some audio programs put some data after the "data" lump (note: lump==chunk).
(a common example here are lumps that indicate the audio program used and/or contain data similar to that found in an ID3 tag).

the reader code appears as if it will just read all the way to the end of the file, so if anything follows the main data lump, it may result in noise and/or pops, due to this data being treated as audio.

better could be taking the lump-size into account (for the "data" lump), then use this to know how many audio samples are present (rather than how much data was read).


secondary notes:
not all WAV files will have exactly the same length for the "fmt " lump (mostly N/A for PCM WAV files);
theoretically, other lumps may appear between "fmt " and "data" lumps (not actually ran into this AFAICT);
thoeretically, audio files may contain a 'LIST'/'wavl' lump instead of a single big 'data' lump (not seen AFAICT);
RIFF does this odd thing of padding lumps up to even (multiple of 2) sizes (N/A in this case);
...

the most likely scenario is here being data following 'data', because most of the other scenarios would likely result in the decoder rejecting the file (by not seeing 'data' where it is expected).


ADD, maybe try something like (trivial edit):
/* decode the length for "data" (32 bit little-endian DWORD) */
len = buffer[4] | (buffer[5]<<8) | (buffer[6]<<16) | (buffer[7]<<24);

/* Now read in the data section of this wav file */
ret = fread( buffer, 1, len, file );

#1cr88192

Posted 14 March 2013 - 01:08 AM

some audio programs put some data after the "data" lump (note: lump==chunk).
(a common example here are lumps that indicate the audio program used and/or contain data similar to that found in an ID3 tag).

the reader code appears as if it will just read all the way to the end of the file, so if anything follows the main data lump, it may result in noise and/or pops, due to this data being treated as audio.

better could be taking the lump-size into account (for the "data" lump), then use this to know how many audio samples are present (rather than how much data was read).


secondary notes:
not all WAV files will have exactly the same length for the "fmt " lump (mostly N/A for PCM WAV files);
theoretically, other lumps may appear between "fmt " and "data" lumps (not actually ran into this AFAICT);
thoeretically, audio files may contain a 'LIST'/'wavl' lump instead of a single big 'data' lump;
RIFF does this odd thing of padding lumps up to even (multiple of 2) sizes (N/A in this case);
...

the most likely scenario is here being data following 'data', because most of the other scenarios would likely result in the decoder rejecting the file (by not seeing 'data' where it is expected).

PARTNERS