Hi, I am capturing 16 bit mono sound samples using some Win32 API function calls. These function calls return the sound samples in an array of characters. My assumption is that this array of characters represents pairs of bytes that make up a short integer. I'm using the following code to convert the samples: LPTSTR *lpSaveBuffer; ...... for(j=0;j<nBytes;++J) { BYTE a = lpSaveBuffer[2*j]; // left byte BYTE b = lpSaveBuffer[2*j + 1]; // right byte short sample = (a << 8) | (b & 0xff); } I'm getting garbage as a result of this conversion. Any help would be appreciated. Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/1ce9e9cd/attachment.htm
Is "nBytes" what it says -- the number of bytes in the buffer? If so, you're overshooting the buffer by 2x by multiplying by 2 in your array access. You probably want a variable called "nSamples" that represents the number of 16-bit words. Also, if this is a little-endian (Windows on x86?) machine, you're reassembling the word backwards. Not to mention, shifting a BYTE left by 8 inside those parentheses is probably turning it into 0. If you actually need to swap the bytes, try casting to a short before shifting. -- john for(j=0;j<nBytes;++J) { BYTE a = lpSaveBuffer[2*j]; // left byte BYTE b = lpSaveBuffer[2*j + 1]; // right byte short sample = (a << 8) | (b & 0xff); } I'm getting garbage as a result of this conversion. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/62c5e7a8/attachment.html
Jonas Tärnström
2006-Sep-16 11:53 UTC
SV: [Speex-dev] converting 16-bit samples in LPSTR to short
What kind of crazy old Win32 API is that? I?ve used DirectSound and WinMM and never needed to do something like what you are doing. AFAIK, all existing Win32 APIs for capturing sound returns buffers of 16-bit PCM data, assuming PCM was specified as buffer format. //JT -----Ursprungligt meddelande----- Fr?n: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] F?r Peter Gien Skickat: den 16 september 2006 16:48 Till: speex-dev ?mne: [Speex-dev] converting 16-bit samples in LPSTR to short Hi, I am capturing 16 bit mono sound samples using some Win32 API function calls. These function calls return the sound samples in an array of characters. My assumption is that this array of characters represents pairs of bytes that make up a short integer. I'm using the following code to convert the samples: LPTSTR *lpSaveBuffer; ...... for(j=0;j<nBytes;++J) { BYTE a = lpSaveBuffer[2*j]; // left byte BYTE b = lpSaveBuffer[2*j + 1]; // right byte short sample = (a << 8) | (b & 0xff); } I'm getting garbage as a result of this conversion. Any help would be appreciated. Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060916/60786246/attachment.htm
Thank you John. I simply reversed the order of the bytes and that cleared up everything. But now that you mention it, it does look like I'm overshooting by a factor of two. I should rather do a loop that has j incrementing like this j+=2 and make the j loop run from 0 to nBytes/2. Thanks for the advice. On 9/16/06, John Miles <jmiles@pop.net> wrote:> > Is "nBytes" what it says -- the number of bytes in the buffer? If so, > you're overshooting the buffer by 2x by multiplying by 2 in your array > access. You probably want a variable called "nSamples" that represents the > number of 16-bit words. > > Also, if this is a little-endian (Windows on x86?) machine, you're > reassembling the word backwards. > > Not to mention, shifting a BYTE left by 8 inside those parentheses is > probably turning it into 0. If you actually need to swap the bytes, try > casting to a short before shifting. > > -- john > > for(j=0;j<nBytes;++J) > { > BYTE a = lpSaveBuffer[2*j]; // left byte > BYTE b = lpSaveBuffer[2*j + 1]; // right byte > short sample = (a << 8) | (b & 0xff); > } > > I'm getting garbage as a result of this conversion. Any help would be > appreciated. > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060923/2159dd39/attachment.htm