Hi

I am developing on an app that records sound from the soundcard and
then perform some dsp on the accuired sound. So far I've been working
with 44100 Hz sampling frequency, but need to change to 22050 Hz.
I use the win32 sdk multimedia functions to communicate with the
soundcard.

When I use 44100 Hz I know that the recorded buffer I receive from the
soundcard contains values that should be interpreted as type short
(programming in c). But what happens if I change sample frequency to
22050? Should I still expect the values to be of type short?
Are there any standards that manufacturers of soundcard implements or
is the data manufacturer dependant?

I use a HP laptop and I can't find any information about the soundcard
on HP's homepage.

Thank you.

From:	RV
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 03:31:40 +1100

On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
wrote:

>Hi
>
>I am developing on an app that records sound from the soundcard and
>then perform some dsp on the accuired sound. So far I've been working
>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>I use the win32 sdk multimedia functions to communicate with the
>soundcard.
>
>When I use 44100 Hz I know that the recorded buffer I receive from the
>soundcard contains values that should be interpreted as type short
>(programming in c). But what happens if I change sample frequency to
>22050? Should I still expect the values to be of type short?
>Are there any standards that manufacturers of soundcard implements or
>is the data manufacturer dependant?
>

The sampling rates doesnt change the max scale - to +
The bit rate does.
8 bit, 16 bit

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Tue, 21 Dec 2004 14:56:01 -0500

RV wrote:

> On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
> wrote:
>
>
>>Hi
>>
>>I am developing on an app that records sound from the soundcard and
>>then perform some dsp on the accuired sound. So far I've been working
>>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>>I use the win32 sdk multimedia functions to communicate with the
>>soundcard.
>>
>>When I use 44100 Hz I know that the recorded buffer I receive from the
>>soundcard contains values that should be interpreted as type short
>>(programming in c). But what happens if I change sample frequency to
>>22050? Should I still expect the values to be of type short?
>>Are there any standards that manufacturers of soundcard implements or
>>is the data manufacturer dependant?
>>
>
>
> The sampling rates doesnt change the max scale - to +

That's what I thought too.

> The bit rate does.

How? What does "bit rate" mean in this context, anyway?

> 8 bit, 16 bit

??

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Randy Yates
Subject:	Re: soundcard buffer format
Date:	Sat, 25 Dec 2004 11:15:24 GMT

RV writes:

> On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins wrote:
>
>>RV wrote:
>>
>> ...
>>
>>> At some point do you guys thinkl you can stick to windows multimedia
>>> API's and forget the lesson on a whole lotta "stuff" that means
>>> nothing to the guy whio is trying to worte to code in win mm API code.
>>
>>Simplifying is appropriate. Misinforming is not.
>
> Uh huh
> So
> Do you know the code used in Win32 mm API to do what the OP needs to
> do or not?

I responded with exactly this information a few days ago but no one seemed to care:

http://groups-beta.google.com/group/comp.multimedia/msg/0a87318d38ea41eb?dmode=source

--RY

--
% Randy Yates % "The dreamer, the unwoken fool -
%% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..."
%%% 919-577-9882 %
%%%% % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

From:	RV
Subject:	Re: soundcard buffer format
Date:	Mon, 27 Dec 2004 01:51:07 +1100

On Sat, 25 Dec 2004 11:15:24 GMT, Randy Yates wrote:

>RV writes:
>
>> On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins wrote:
>>
>>>RV wrote:
>>>
>>> ...
>>>
>>>> At some point do you guys thinkl you can stick to windows multimedia
>>>> API's and forget the lesson on a whole lotta "stuff" that means
>>>> nothing to the guy whio is trying to worte to code in win mm API code.
>>>
>>>Simplifying is appropriate. Misinforming is not.
>>
>> Uh huh
>> So
>> Do you know the code used in Win32 mm API to do what the OP needs to
>> do or not?
>
>I responded with exactly this information a few days ago but no one seemed to care:
>
>http://groups-beta.google.com/group/comp.multimedia/msg/0a87318d38ea41eb?dmode=source
>

I noted that Randy and was going to respond but we got way side
tracked sorting out the Win API code from the abstract.

To the code you posted
waveOutGetDevCaps covers the output capabilities of the sound card.
Unfortunately.
While you can get the value of an output meter from callback, many
sound cards do not have the meter to get a callback from with the
levels.

I agree it is handy if you are using only one machine that does have a
meter to look at in the mixer caps.
Short and sweet to use.
But you run out road with that code on many other machines.

The other thing is you can look at the data off a meter value but you
cant do much with it.

Using WAVEINCAPS
Stop record in silence in an inaccurate sort of way perhaps or other
simple functions, thats its limit.

What the OP needs to use is

(open input and start recording. note recording does not mean
recording to file as yet, it just means recording to buffers)

waveInOpen
waveInPrepareHeader
waveInAddBuffer
waveInStart

(Read buffer and process, display, edit values)

(After read then clear it with)
waveInUnprepareHeader

(and send back empty use again)
waveInPrepareHeader

(to stop)
waveInReset
waveInStop
waveInClose

(read errors with)
waveInGetErrorText

(structures)
WAVEHDR
WAVEFORMATEX

(memory shuffling stuff)
GlobalAlloc
GlobalFree
RtlMoveMemory

(To select device to use with waveInOpen)
waveInGetNumDevs
WAVEINCAPS

In perspective

waveOutOpen is for the sound card output
waveInOpen is for the sound card input

mmio, ascend and descend is used to read a file then send it out of
the sound card using waveOutOpen
Likewse
mmio, ascend and descend is used to take data from waveInOpen and
write it to file.

The method I use only uses waveInOpen and then shoves it into bytes to
process and read and dump to a file as is
I dont use mmio to write.

WAVE CAPS being the hardware level attributes of the sound card
controls In and Out to choose the right one, turn it on and off and
set and get slider volumes. (and input or output meter levels where
they exist as the code you provide does)

That should give him enough to search with to find the source code
ready to use somewhere with C++
I dont do C++, if I did he could have mine.

Cheers

From:	Ronald H. Nicholson Jr.
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 18:45:19 +0000 (UTC)

>>
....
>That's what I thought too.
>
>> The bit rate does.

The bit rate is dependant on several parameters: frames per second,
(96k, 44100, 8k, etc.), samples per frame, (1 for mono, 2 for stereo,
5, etc.), and bits per sample (32, 16, 8, 1, etc.).

The bit rate would be identical for 16 bit mono samples at 22050 and
8 bit mono samples at 44100 (both 352800 bps, exclusive of encoding
and formatting (e.g. parity, sync, RLL, etc.)).

Other important characteristics of the bit stream include number format
(float, signed or unsigned, biased, binary 2's complement, etc.)
and endianess (little, big, or network bit order).

IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include // only my own opinions, etc.

From:	Emile
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 01:56:30 GMT

Jerry Avins wrote:
> RV wrote:
>
>
>>On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
>>wrote:
>>
>>
>>
>>>Hi
>>>
>>>I am developing on an app that records sound from the soundcard and
>>>then perform some dsp on the accuired sound. So far I've been working
>>>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>>>I use the win32 sdk multimedia functions to communicate with the
>>>soundcard.
>>>
>>>When I use 44100 Hz I know that the recorded buffer I receive from the
>>>soundcard contains values that should be interpreted as type short
>>>(programming in c). But what happens if I change sample frequency to
>>>22050? Should I still expect the values to be of type short?
>>>Are there any standards that manufacturers of soundcard implements or
>>>is the data manufacturer dependant?
>>>
>>
>>
>>The sampling rates doesnt change the max scale - to +
>
>
> That's what I thought too.
>
>
>>The bit rate does.
>
>
> How? What does "bit rate" mean in this context, anyway?
>

i think it means how many bits are used to encode one sample in computer
memory, thus with 2^8 or with 2^16 possible values for the amplitude of
that sample.

>
>>8 bit, 16 bit
>
>
> ??
>
> Jerry

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Tue, 21 Dec 2004 23:42:04 -0500

Emile wrote:

...

>> How? What does "bit rate" mean in this context, anyway?
>>
>
> i think it means how many bits are used to encode one sample in computer
> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
> that sample.

Most people I know would call that size, not rate. Is rate commonly used
that way among some groups?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Stephan M. Bernsee
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 07:44:54 +0100

On 2004-12-22 05:42:04 +0100, Jerry Avins said:

> Emile wrote:
>
> ...
>
>>> How? What does "bit rate" mean in this context, anyway?
>>>
>>
>> i think it means how many bits are used to encode one sample in computer
>> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>> that sample.
>
> Most people I know would call that size, not rate. Is rate commonly used
> that way among some groups?
>
> Jerry

I hope not!

Bit rate generally means the number of bits/sec. Of course, for a
change in sample rate this number changes, too.

The word length (for the "short int" data type this is usually 16 bits)
does not change with sample rate.
--
Stephan M. Bernsee
http://www.dspdimension.com

From:	RV
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 00:36:51 +1100

On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
wrote:

>On 2004-12-22 05:42:04 +0100, Jerry Avins said:
>
>> Emile wrote:
>>
>> ...
>>
>>>> How? What does "bit rate" mean in this context, anyway?
>>>>
>>>
>>> i think it means how many bits are used to encode one sample in computer
>>> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>> that sample.
>>
>> Most people I know would call that size, not rate. Is rate commonly used
>> that way among some groups?
>>
>> Jerry
>
>I hope not!
>
>Bit rate generally means the number of bits/sec. Of course, for a
>change in sample rate this number changes, too.

Not quite, bit rate is the "rate" of bits over time.
"16 bit" or "8 bit" simply represents the block size in bits of each
sample, it doesn't describe time.

For bit per sec I suggest it's best to refer to wave as samples per
sec.

Not to be confused with compression encoded files where you would
count the bit rate of the encoded frames per sec to determine time,
not the just sample rate of the input samples per sec alone to
determine time as with a wave.

As in more or less compression = more or less bit rate, but at the
same sample rate from the input stream sample rate, the sample rate is
stored in the header of the frame in the case of mpeg audio.

So if you use samples per sec in non compression encoded files it
defines the two seperately.

>
>The word length (for the "short int" data type this is usually 16 bits)
>does not change with sample rate.

Yep, thats one channel maximum scale.
So
16 bit audio is 4 byte per sample, 16 bit per channel stereo.
giving scale range of 65534 per channel of which the centre point of
the scale at 32767 is 0 level sound.

OR for working purposes
16 bit using signed values -32767 max to +32767 max audio levels and
then 0 is 0 audio level.

8 bit audio is 2 byte per sample, 8 bit per channel.
giving 256 scale range per channel of which the centre point of that
scale at 128 is 0 level sound.

OR for working purposes
8 bit using signed values so - 128 max to +128 max audio levels and
then 0 is 0 audio level.

HTH
Cheers

From:	Stephan M. Bernsee
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 20:33:54 +0100

On 2004-12-22 14:36:51 +0100, RV said:

> On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
> wrote:
>
>> I hope not!
>>
>> Bit rate generally means the number of bits/sec. Of course, for a
>> change in sample rate this number changes, too.
>
> Not quite, bit rate is the "rate" of bits over time.

That's what I said, is it not?

> "16 bit" or "8 bit" simply represents the block size in bits of each
> sample, it doesn't describe time.

Yes - again that's what I said.

> For bit per sec I suggest it's best to refer to wave as samples per
> sec.

Samples per sec doesn't say anything about the word length of the
samples, this is something different. IOW: "samples per sec" does not
define "bits per sec" without knowing the word length.

Again, to recap:

You store your data points (your SAMPLES) as numbers of a certain WORD
LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE
RATE (typically specified as samples/sec). Also, you are usually
dealing with FRAMES which contain a certain number of samples per
channel. For a stereo recording, each frame contains 2 samples, left
and right.

The BIT RATE would then be the total number of bits shuffled to the D/A
converters (or any other device in the signal chain) in each second
that passes. This rate would consequently be the product of the word
length of the samples, the sample rate and the frame size (ie. number
of channels) over one second.

Now it is immediately clear why changing the sample rate will change
this number. Changing the sample rate does, however, NOT change the
word length of the individual samples because it's just a number
describing how many measurements are taken at each second, but not how
many amplitude levels they can distinguish (ie. how many bits each of
them contains).

> So if you use samples per sec in non compression encoded files it
> defines the two seperately.

I'm sorry but I don't know what you're getting at. I never mentioned
compression and this has nothing to do with it - I was referring to raw
PCM data.

>> The word length (for the "short int" data type this is usually 16 bits)
>> does not change with sample rate.
>
> Yep, thats one channel maximum scale.
> So
> 16 bit audio is 4 byte per sample, 16 bit per channel stereo.

One sample of a 16 bit audio recording is 2 bytes (= 16 bit) per
sample, with two samples per frame for stereo (left and right). This
equals 4 bytes in total.

> giving scale range of 65534 per channel of which the centre point of
> the scale at 32767 is 0 level sound.

Nope. The correct number for the *range* is 65536 levels (0-65535) if
we're dealing with 16 bit unsigned data.

> OR for working purposes
> 16 bit using signed values -32767 max to +32767 max audio levels and
> then 0 is 0 audio level.

Nope, the minimum level for signed 16 bit data is -32768, not -32767.

> 8 bit audio is 2 byte per sample, 8 bit per channel.
> giving 256 scale range per channel of which the centre point of that
> scale at 128 is 0 level sound.
>
> OR for working purposes
> 8 bit using signed values so - 128 max to +128 max audio levels and
> then 0 is 0 audio level.

Nope again. It's -128 to +127 for 8 bit signed integers.

Hope this clears things up.
--
Stephan M. Bernsee
http://www.dspdimension.com

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 01:59:48 +1100

On Wed, 22 Dec 2004 20:33:54 +0100, Stephan M. Bernsee
wrote:

>On 2004-12-22 14:36:51 +0100, RV said:
>
>> On Wed, 22 Dec 2004 07:44:54 +0100, Stephan M. Bernsee
>> wrote:
>>
>>> I hope not!
>>>
>>> Bit rate generally means the number of bits/sec. Of course, for a
>>> change in sample rate this number changes, too.
>>
>> Not quite, bit rate is the "rate" of bits over time.
>
>That's what I said, is it not?

As far as I know this is what was said
~~~~~~~
>> Most people I know would call that size, not rate. Is rate commonly used
>> that way among some groups?
>>
>> Jerry

>I hope not!

>Bit rate generally means the number of bits/sec. Of course, for a
>change in sample rate this number changes, too.
~~~~~~~~~

Jerry was right
16 bit describes the size, not the rate

I used bit rate in the begining and I was wrong, he was right.
16 bit means the is Bit "size".
8 bit means the Bit "size".

You corrected him by saying that is the Bit rate.?

bit per sec describes the "rate"
16 bit and 8 bit refers only othe the size as he said.

"bit rate" is used in compressed audio not PCM wave and was used by me
to begin with incorrectly.
Last time I make that mistake on Usenet..

>
>> "16 bit" or "8 bit" simply represents the block size in bits of each
>> sample, it doesn't describe time.
>
>Yes - again that's what I said.
>
>> For bit per sec I suggest it's best to refer to wave as samples per
>> sec.
>
>Samples per sec doesn't say anything about the word length of the
>samples, this is something different. IOW: "samples per sec" does not
>define "bits per sec" without knowing the word length.

When I wrote use samples per sec I mean use samples per sec in
preference to bit per sec when specifying rate for a PCM wave file
becuase thats what is used in PCM wave code.
Not bit per sec.

>
>Again, to recap:
>
>You store your data points (your SAMPLES) as numbers of a certain WORD
>LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE
>RATE (typically specified as samples/sec). Also, you are usually
>dealing with FRAMES which contain a certain number of samples per
>channel. For a stereo recording, each frame contains 2 samples, left
>and right.

You might refer to them as frames but the WAVE structure doesnt so to
call a stereo pair of samples a frame doesnt equate to what the OP is
trying to do, which is write the code for WAVE.
So if he uses samples and blocks for wave it might make more sense
looking at the structure in code..

This is the WAVEFORMATstructure, Im sure youve seen it before.

FormatTag
Channels
SamplesPerSec
AvgBytesPerSec
BlockAlign
BitsPerSample

no frames

Blocks and Samples
BitsPerSample describes block size in bits.
And a Block is the BitsPerSample multiplied by number of channels

For rate, which none of the above describe
Samples per sec

AvgByte per sec comes close to "bit per sec" being it describes the
rate and bits via bytes, but "bit per sec" isnt use in PCM wave code.

"bit per sec" is used in code for compression encoded audio like MPEG

And no frames anywhere in the code for PCM wave.

Not in WAVEHDR, WAVEINCAPS or WAVEOUTCAPS

If you want to use "frames" see the description for any compression
encoded audio like MPEG, where you will find your "frames" in the
terminology of the code used.

See MPEGLAYER3WAVEFORMAT

FramesPerBlock

So there are your Frames in MPEG compression encoded files.

But "Frames" isnt used in the PCM wave code anywhere.

So to be of most help to the OP with his code lets not put "Frames"
where "Frames" are not used or needed.

Me mentioning "bit rate" to begin with has caused enough confusion
already I think.

>
>The BIT RATE would then be the total number of bits shuffled to the D/A
>converters (or any other device in the signal chain) in each second
>that passes.

True but we are refering to the levels of each sample, or thats what
the Jerry pointed out and in fact the OP did ask.

Wanting to know the scale or "bit size" that applies to audio level
incoming.
For a change in sample rate.

> This rate would consequently be the product of the word
>length of the samples, the sample rate and the frame size (ie. number
>of channels) over one second.

Yeah but Block size for PCM wave.

Or BlockAlign
number of channels multiplied by bytes per sample.

What you called the BIT RATE is called BytesPerSec in PCM wave audio
code.
samples per sec multiplied by block size.

>
>Now it is immediately clear why changing the sample rate will change
>this number. Changing the sample rate does, however, NOT change the
>word length of the individual samples because it's just a number
>describing how many measurements are taken at each second, but not how
>many amplitude levels they can distinguish (ie. how many bits each of
>them contains).
>
>> So if you use samples per sec in non compression encoded files it
>> defines the two seperately.
>
>I'm sorry but I don't know what you're getting at. I never mentioned
>compression and this has nothing to do with it - I was referring to raw
>PCM data.
>

My point was, there is no need to express the rate as "bit per sec"
for a wave file, it doesnt mean anything in code for WAVE functions
and structures
"samples per sec" does.

"bit per sec" is only going to be of any value in code terms for
compression audio.

>>> The word length (for the "short int" data type this is usually 16 bits)
>>> does not change with sample rate.
>>
>> Yep, thats one channel maximum scale.
>> So
>> 16 bit audio is 4 byte per sample, 16 bit per channel stereo.
>
>One sample of a 16 bit audio recording is 2 bytes (= 16 bit) per
>sample, with two samples per frame for stereo (left and right). This
>equals 4 bytes in total.
>

Yeah I left out "block" size
read "block" not "frame" in a PCM wave.

16 bits
4 bytes
When he adds up 16 bits over 4 bytes for stereo L and R Im sure he
will sort that one out in code.

Stereo
16 bit per sample in 4 bytes
or
16 bit per samples in 4 byte block size for stereo

>> giving scale range of 65534 per channel of which the centre point of
>> the scale at 32767 is 0 level sound.
>
>Nope. The correct number for the *range* is 65536 levels (0-65535) if
>we're dealing with 16 bit unsigned data.
>
>> OR for working purposes
>> 16 bit using signed values -32767 max to +32767 max audio levels and
>> then 0 is 0 audio level.
>
>Nope, the minimum level for signed 16 bit data is -32768, not -32767.

-32768 might be the "minimum" level of a signed integer.
(do you mean, the minimum "value" for a signed integer ?)

Im refering to the number of audio "levels" each side of 0 to show
that 0 is the lowest audio level.
and the audio level increases with the value each side of 0
32767 levels in the - direction for maximum audio level, and 32767 in
the plus direction for maximum audio level

But if it your wish it, make that.

The range is
0 -32768
and
0 +32768

From:	Stephan M. Bernsee
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 18:10:08 +0100

On 2004-12-23 15:59:48 +0100, RV said:

> Jerry was right
> 16 bit describes the size, not the rate

Yes. And I was adding that for one channel, sample size * sample rate =
bit rate.

> I used bit rate in the begining and I was wrong, he was right.
> 16 bit means the is Bit "size".
> 8 bit means the Bit "size".

No, it doesn't. A bit has always a size of exactly 1.
16 bit or 8 bit is the word length for your samples.

> You corrected him by saying that is the Bit rate.?

No. The bit rate is the number of bits that go to the D/A per second.
That's what I wrote in my last post.

> bit per sec describes the "rate"
> 16 bit and 8 bit refers only othe the size as he said.

See my last posting - that's exactly what I said, too!

> "bit rate" is used in compressed audio not PCM wave and was used by me
> to begin with incorrectly.

"Bit rate" can be used for non-compressed audio as well. Like I said,
it just describes the number of bits that pass through your buffer per
second.

> Last time I make that mistake on Usenet..

Don't worry - making mistakes is a good thing! I do it all the time.
:-)

> When I wrote use samples per sec I mean use samples per sec in
> preference to bit per sec when specifying rate for a PCM wave file
> becuase thats what is used in PCM wave code.
> Not bit per sec.

That's a matter of naming convention. You can use both units, but they
mean different things.

>> You store your data points (your SAMPLES) as numbers of a certain WORD
>> LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE
>> RATE (typically specified as samples/sec). Also, you are usually
>> dealing with FRAMES which contain a certain number of samples per
>> channel. For a stereo recording, each frame contains 2 samples, left
>> and right.
>
> You might refer to them as frames but the WAVE structure doesnt so to
> call a stereo pair of samples a frame doesnt equate to what the OP is
> trying to do, which is write the code for WAVE.

Yes I agree. Now I see our problem: you were talking about that WAVE
structure and how things are called therein. You should be aware that
M$ never actually cared a great deal about correct naming or sensible
units, obviously. Maybe that's part of the confusion here.

>> Nope, the minimum level for signed 16 bit data is -32768, not -32767.
>
> -32768 might be the "minimum" level of a signed integer.
> (do you mean, the minimum "value" for a signed integer ?)

Sure. The minimum value, or the most negative value, or the audio level
corresponding to the most negative value.

> Im refering to the number of audio "levels" each side of 0 to show
> that 0 is the lowest audio level.

Right, zero is zero. No doubt about it. ;-)

> But if it your wish it, make that.
>
> The range is
> 0 -32768
> and
> 0 +32768

No again, a value of +32768 would wrap around. Either you are talking
about values, in which case your values go from -32768 to +32767 or
you're talking about a *range*, which is always a positive number. The
range for both signed and unsigned 16 bit integers is 65536 different
numeric values, or possible amplitude levels.

It's not that this is my wish, it's just how things are.
--
Stephan M. Bernsee
http://www.dspdimension.com

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 15:18:02 +1100

On Thu, 23 Dec 2004 18:10:08 +0100, Stephan M. Bernsee
wrote:

>On 2004-12-23 15:59:48 +0100, RV said:
>
>> Jerry was right
>> 16 bit describes the size, not the rate
>
>Yes. And I was adding that for one channel, sample size * sample rate = bit rate.

Not used in Win API audio coding.

>
>> I used bit rate in the begining and I was wrong, he was right.
>> 16 bit means the is Bit "size".
>> 8 bit means the Bit "size".
>
>No, it doesn't. A bit has always a size of exactly 1.
>16 bit or 8 bit is the word length for your samples.

Un huh

Well for you then Ill shuffle it again.

16 bit means the is "size" in bits.
8 bit means the "size" in bits.

Let me know if that still not self evident Ill try holding my toungue
in the other direction when I post the reply.

>
>> You corrected him by saying that is the Bit rate.?
>
>No. The bit rate is the number of bits that go to the D/A per second.
>That's what I wrote in my last post.

Uh huh
But how does that answer the question

"You corrected him by saying that is the Bit "rate".?"

>
>> bit per sec describes the "rate"
>> 16 bit and 8 bit refers only othe the size as he said.
>
>See my last posting - that's exactly what I said, too!

He said
~~~~~
> Most people I know would call that size, not rate. Is rate commonly used
> that way among some groups?
>
> Jerry

~~~~~~

To which you said

~~~~~~
I hope not!

Bit rate generally means the number of bits/sec. Of course, for a
change in sample rate this number changes, too.

~~~~~

rate was wrong
size was right.

>
>> "bit rate" is used in compressed audio not PCM wave and was used by me
>> to begin with incorrectly.
>
>"Bit rate" can be used for non-compressed audio as well. Like I said,
>it just describes the number of bits that pass through your buffer per
>second.

Not in Win API audio code.
Thats what the OP is using.

>
>> Last time I make that mistake on Usenet..
>
>Don't worry - making mistakes is a good thing! I do it all the time.
>:-)
>
>> When I wrote use samples per sec I mean use samples per sec in
>> preference to bit per sec when specifying rate for a PCM wave file
>> becuase thats what is used in PCM wave code.
>> Not bit per sec.
>
>That's a matter of naming convention. You can use both units, but they
>mean different things.

Not in Win API audio code
Apples aint oranges.
The API code for PCM wave is the API code for PCM wave

>
>>> You store your data points (your SAMPLES) as numbers of a certain WORD
>>> LENGTH (typically 8, 16, 24, 32 BITS each) collected a certain SAMPLE
>>> RATE (typically specified as samples/sec). Also, you are usually
>>> dealing with FRAMES which contain a certain number of samples per
>>> channel. For a stereo recording, each frame contains 2 samples, left
>>> and right.
>>
>> You might refer to them as frames but the WAVE structure doesnt so to
>> call a stereo pair of samples a frame doesnt equate to what the OP is
>> trying to do, which is write the code for WAVE.
>
>Yes I agree. Now I see our problem: you were talking about that WAVE
>structure and how things are called therein. You should be aware that
>M$ never actually cared a great deal about correct naming or sensible
>units, obviously. Maybe that's part of the confusion here.

The only confustion is when some people use terms not used in the code
that is to be wrritten by the OP.
Thats Win32 MM API code.

>
>>> Nope, the minimum level for signed 16 bit data is -32768, not -32767.
>>
>> -32768 might be the "minimum" level of a signed integer.
>> (do you mean, the minimum "value" for a signed integer ?)
>
>Sure. The minimum value, or the most negative value, or the audio level
>corresponding to the most negative value.

And that audio level is?

>
>> Im refering to the number of audio "levels" each side of 0 to show
>> that 0 is the lowest audio level.
>
>Right, zero is zero. No doubt about it. ;-)
>
>> But if it your wish it, make that.
>>
>> The range is
>> 0 -32768
>> and
>> 0 +32768
>
>No again, a value of +32768 would wrap around. Either you are talking
>about values, in which case your values go from -32768 to +32767 or
>you're talking about a *range*, which is always a positive number

Uhh huh
Well back to Win API audio coding.

We dont have -32768 and +32767 as the peak values of audio level.

In Win API audio code. we have 2 peak signed values of the same order
of scale, each side of 0

From:	glen herrmannsfeldt
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 10:48:57 -0800

Emile wrote:

(someone wrote)

>>>> When I use 44100 Hz I know that the recorded buffer I receive from the
>>>> soundcard contains values that should be interpreted as type short
>>>> (programming in c). But what happens if I change sample frequency to
>>>> 22050? Should I still expect the values to be of type short?
>>>> Are there any standards that manufacturers of soundcard implements or
>>>> is the data manufacturer dependant?

(snip)

> i think it means how many bits are used to encode one sample in computer
> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
> that sample.

Bit rate should be bits/sample * sample rate * number of channels.

One can then trade off bits/sample and sample rate as appropriate.

That is before any compression. The term 'bit rate' may be more
applicable after compression where bits/sample isn't uniform anymore.

-- glen

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 02:00:03 +1100

On Wed, 22 Dec 2004 10:48:57 -0800, glen herrmannsfeldt
wrote:

>
>
>Emile wrote:
>
>(someone wrote)
>
>>>>> When I use 44100 Hz I know that the recorded buffer I receive from the
>>>>> soundcard contains values that should be interpreted as type short
>>>>> (programming in c). But what happens if I change sample frequency to
>>>>> 22050? Should I still expect the values to be of type short?
>>>>> Are there any standards that manufacturers of soundcard implements or
>>>>> is the data manufacturer dependant?
>
>(snip)
>
>> i think it means how many bits are used to encode one sample in computer
>> memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>> that sample.
>
>Bit rate should be bits/sample * sample rate * number of channels.
>

Wot glen said.

16 bit is size
8 bit is size

bit rate is time

If only someone said,
"You mean size, not rate."
"Oh yes of course its not rate, bit size is right."

>One can then trade off bits/sample and sample rate as appropriate.
>
>That is before any compression. The term 'bit rate' may be more
>applicable after compression where bits/sample isn't uniform anymore.

Yep, bit rate is used in compressed audio
In the same place "frames" live.
That we dont have in PCM wave, but thats a whole other thread.

Thanks glen.

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 14:15:44 -0500

glen herrmannsfeldt wrote:

...

> Bit rate should be bits/sample * sample rate * number of channels.
>
> One can then trade off bits/sample and sample rate as appropriate.
>
> That is before any compression. The term 'bit rate' may be more
> applicable after compression where bits/sample isn't uniform anymore.

Sanity and consistency at last! Thank you, Glen. I'm one of those
tight-ass guys who thinks that words mean something, and that people who
use them should mean what they do. That saves me from having to figure
out what they really mean, which is sometimes too hard for me. But I
usually try to be nice anyway.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	glen herrmannsfeldt
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 11:57:52 -0800

Jerry Avins wrote:

> glen herrmannsfeldt wrote:

(snip)

>>That is before any compression. The term 'bit rate' may be more
>>applicable after compression where bits/sample isn't uniform anymore.

> Sanity and consistency at last! Thank you, Glen. I'm one of those
> tight-ass guys who thinks that words mean something, and that people who
> use them should mean what they do. That saves me from having to figure
> out what they really mean, which is sometimes too hard for me. But I
> usually try to be nice anyway.

I have a DVD player that can display a bar graph and numeric
"bit rate" at the bottom of the screen, of the current bit rate
coming off the disk. It changes pretty fast, and tends to be
distracting while trying to watch a movie, but someone must have
thought users would want to know it.

One can see it increase in scenes with lots of action, and
decrease in quiet scenes, but I usually turn it off.

-- glen

From:	Bhaskar Thiagarajan
Subject:	OT: was Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 11:34:05 -0800

"Jerry Avins" wrote in message
news:32tvf2F3phgatU1@individual.net...
> glen herrmannsfeldt wrote:
>
> ...
>
> > Bit rate should be bits/sample * sample rate * number of channels.
> >
> > One can then trade off bits/sample and sample rate as appropriate.
> >
> > That is before any compression. The term 'bit rate' may be more
> > applicable after compression where bits/sample isn't uniform anymore.
>
> Sanity and consistency at last! Thank you, Glen. I'm one of those
> tight-ass guys who thinks that words mean something, and that people who
> use them should mean what they do. That saves me from having to figure
> out what they really mean, which is sometimes too hard for me. But I
> usually try to be nice anyway.
>
> Jerry

Imagine working in cultural enviroments (several of the Asian countries)
where people don't like to be straight forward. So words are used in such a
convoluted fashion (as opposed to correlated - sorry couldn't resist) that
you'd have to be real tuned in to the local culture to make real sense out
of what is being said or written.

Cheers
Bhaskar

From:	Jerry Avins
Subject:	Re: OT: was Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 16:06:48 -0500

Bhaskar Thiagarajan wrote:

> "Jerry Avins" wrote in message
> news:32tvf2F3phgatU1@individual.net...
>
>>glen herrmannsfeldt wrote:
>>
>> ...
>>
>>
>>>Bit rate should be bits/sample * sample rate * number of channels.
>>>
>>>One can then trade off bits/sample and sample rate as appropriate.
>>>
>>>That is before any compression. The term 'bit rate' may be more
>>>applicable after compression where bits/sample isn't uniform anymore.
>>
>>Sanity and consistency at last! Thank you, Glen. I'm one of those
>>tight-ass guys who thinks that words mean something, and that people who
>>use them should mean what they do. That saves me from having to figure
>>out what they really mean, which is sometimes too hard for me. But I
>>usually try to be nice anyway.
>>
>>Jerry
>
>
> Imagine working in cultural enviroments (several of the Asian countries)
> where people don't like to be straight forward. So words are used in such a
> convoluted fashion (as opposed to correlated - sorry couldn't resist) that
> you'd have to be real tuned in to the local culture to make real sense out
> of what is being said or written.
>
> Cheers
> Bhaskar

I'd have been lynched (or sacrificed) long since in such an environment.
To me, "It would be nice if ..." is a statement of preference, a
request, a threat, or a directive, in order of decreasing likelihood.
Call me square!

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	RV
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 17:19:47 +1100

On Wed, 22 Dec 2004 01:56:30 GMT, Emile wrote:

>Jerry Avins wrote:
>> RV wrote:
>>
>>
>>>On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
>>>wrote:
>>>
>>>
>>>
>>>>Hi
>>>>
>>>>I am developing on an app that records sound from the soundcard and
>>>>then perform some dsp on the accuired sound. So far I've been working
>>>>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>>>>I use the win32 sdk multimedia functions to communicate with the
>>>>soundcard.
>>>>
>>>>When I use 44100 Hz I know that the recorded buffer I receive from the
>>>>soundcard contains values that should be interpreted as type short
>>>>(programming in c). But what happens if I change sample frequency to
>>>>22050? Should I still expect the values to be of type short?
>>>>Are there any standards that manufacturers of soundcard implements or
>>>>is the data manufacturer dependant?
>>>>
>>>
>>>
>>>The sampling rates doesnt change the max scale - to +
>>
>>
>> That's what I thought too.
>>
>>
>>>The bit rate does.
>>
>>
>> How? What does "bit rate" mean in this context, anyway?
>>
>
>i think it means how many bits are used to encode one sample in computer
>memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>that sample.
>

Yup thats it
8 bit or 16 bit for each channel L and R per sample.

But not encoded, just recorded as a raw sample for this exercise.
(a typo?)

From:	Emile
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 11:32:14 GMT

RV wrote:
> On Wed, 22 Dec 2004 01:56:30 GMT, Emile wrote:
>
>
>>Jerry Avins wrote:
>>
>>>RV wrote:
>>>
>>>
>>>
>>>>On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
>>>>wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi
>>>>>
>>>>>I am developing on an app that records sound from the soundcard and
>>>>>then perform some dsp on the accuired sound. So far I've been working
>>>>>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>>>>>I use the win32 sdk multimedia functions to communicate with the
>>>>>soundcard.
>>>>>
>>>>>When I use 44100 Hz I know that the recorded buffer I receive from the
>>>>>soundcard contains values that should be interpreted as type short
>>>>>(programming in c). But what happens if I change sample frequency to
>>>>>22050? Should I still expect the values to be of type short?
>>>>>Are there any standards that manufacturers of soundcard implements or
>>>>>is the data manufacturer dependant?
>>>>>
>>>>
>>>>
>>>>The sampling rates doesnt change the max scale - to +
>>>
>>>
>>>That's what I thought too.
>>>
>>>
>>>
>>>>The bit rate does.
>>>
>>>
>>>How? What does "bit rate" mean in this context, anyway?
>>>
>>
>>i think it means how many bits are used to encode one sample in computer
>>memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>that sample.
>>
>
>
> Yup thats it
> 8 bit or 16 bit for each channel L and R per sample.
>
> But not encoded, just recorded as a raw sample for this exercise.
> (a typo?)
>
>

I mean by encoded: in some way expressed as a binary digit (= code
representation of that value). The same way as the decimal 6 can be
encoded as 110 in binary, but it is encoded as 00110110 when following
the ascii convention.

From:	RV
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 01:18:17 +1100

On Wed, 22 Dec 2004 11:32:14 GMT, Emile wrote:

>RV wrote:
>> On Wed, 22 Dec 2004 01:56:30 GMT, Emile wrote:
>>
>>
>>>Jerry Avins wrote:
>>>
>>>>RV wrote:
>>>>
>>>>
>>>>
>>>>>On 21 Dec 2004 07:48:22 -0800, ridpiska@hotmail.com (Jonas Rundberg)
>>>>>wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi
>>>>>>
>>>>>>I am developing on an app that records sound from the soundcard and
>>>>>>then perform some dsp on the accuired sound. So far I've been working
>>>>>>with 44100 Hz sampling frequency, but need to change to 22050 Hz.
>>>>>>I use the win32 sdk multimedia functions to communicate with the
>>>>>>soundcard.
>>>>>>
>>>>>>When I use 44100 Hz I know that the recorded buffer I receive from the
>>>>>>soundcard contains values that should be interpreted as type short
>>>>>>(programming in c). But what happens if I change sample frequency to
>>>>>>22050? Should I still expect the values to be of type short?
>>>>>>Are there any standards that manufacturers of soundcard implements or
>>>>>>is the data manufacturer dependant?
>>>>>>
>>>>>
>>>>>
>>>>>The sampling rates doesnt change the max scale - to +
>>>>
>>>>
>>>>That's what I thought too.
>>>>
>>>>
>>>>
>>>>>The bit rate does.
>>>>
>>>>
>>>>How? What does "bit rate" mean in this context, anyway?
>>>>
>>>
>>>i think it means how many bits are used to encode one sample in computer
>>>memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>>that sample.
>>>
>>
>>
>> Yup thats it
>> 8 bit or 16 bit for each channel L and R per sample.
>>
>> But not encoded, just recorded as a raw sample for this exercise.
>> (a typo?)
>>
>>
>
>I mean by encoded: in some way expressed as a binary digit (= code
>representation of that value). The same way as the decimal 6 can be
>encoded as 110 in binary, but it is encoded as 00110110 when following
>the ascii convention.

I understand whats meant it just that encoding is encoding,
compression is compression, and neither occurs during recording from a
sound car AD(analogue to digital) "converter".

AD converters dont "compress" or "encode", they just "convert".

An encoder uses a table to describe the encoding used so it can decode
it.
audio data values from a sound card line or mic input don't need to be
decoded as the levels represent the same thing as voltage in.
volts = data value on a linear scale.

The values given from the .data structure, are levels that correspond
directly to the AD converter as an actual voltage value at the input.

Just pure scale conversion that occurs from volts to data level
X numer of times a second.

For line in, 1v pp "scaled" to the bit size you use.
16 bit is simply more voltage increments fom the same 1volt pp input
than 8bit.
in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
line input

For a "real world" application
You can read the scale of the audio buffer data value for level and
divide that by 1v pp and you can see the voltage at the sound card
input in precise increments of that.

Encoding such as ASCII isnt linear in size of the binary values bit
for bit.
It uses a table of conversion to decode, the ASCII standard.
Without that you would not be able to encode or decode binary to
ASCII, but the computer has the stadard stuffed in there already to
use.

MPEG encodes and decodes to the standard tables, without the external
table of the standard to data would be un decodable.

No such thing applies ot the sound card.
(ignoring on board mpeg encoders etc that ae secondary to the AD raw
values)

Cheers

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 09:47:48 -0500

You know what you mean; I know what you mean. As explanation, I think
you put some of it poorly.

RV wrote:

> On Wed, 22 Dec 2004 11:32:14 GMT, Emile wrote:
>
...

>>I mean by encoded: in some way expressed as a binary digit (= code
>>representation of that value). The same way as the decimal 6 can be
>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>the ascii convention.
>
>
> I understand whats meant it just that encoding is encoding,
> compression is compression, and neither occurs during recording from a
> sound car AD(analogue to digital) "converter".
>
> AD converters dont "compress" or "encode", they just "convert".

The conversion is from an analog voltage to a bit pattern that
represents it. The bit pattern is construed as a number encoded in some
way, usually two's complement, sometimes offset binary.

>
> An encoder uses a table to describe the encoding used so it can decode
> it.
> audio data values from a sound card line or mic input don't need to be
> decoded as the levels represent the same thing as voltage in.
> volts = data value on a linear scale.

The encoding for numbers of at least one class -- mostly two's
complement, nowadays -- is hard wired into the processor, so no table is
needed.

> The values given from the .data structure, are levels that correspond
> directly to the AD converter as an actual voltage value at the input.
>
> Just pure scale conversion that occurs from volts to data level
> X numer of times a second.
>
> For line in, 1v pp "scaled" to the bit size you use.
> 16 bit is simply more voltage increments fom the same 1volt pp input
> than 8bit.
> in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
> in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
> line input
>
> For a "real world" application
> You can read the scale of the audio buffer data value for level and
> divide that by 1v pp and you can see the voltage at the sound card
> input in precise increments of that.
>
> Encoding such as ASCII isnt linear in size of the binary values bit
> for bit.
> It uses a table of conversion to decode, the ASCII standard.
> Without that you would not be able to encode or decode binary to
> ASCII, but the computer has the stadard stuffed in there already to
> use.

Converting ASCII to signed binary is easily accomplished without a
table. Converting it to signed decimal is even easier.

> MPEG encodes and decodes to the standard tables, without the external
> table of the standard to data would be un decodable.

MPEG compresses. Strictly, an MPEG file is decompressed, not decoded.
It's easy to confuse while trying to explain.

> No such thing applies ot the sound card.
> (ignoring on board mpeg encoders etc that ae secondary to the AD raw
> values)
>
> Cheers

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 03:21:13 +1100

On Wed, 22 Dec 2004 09:47:48 -0500, Jerry Avins wrote:

>You know what you mean; I know what you mean. As explanation, I think
>you put some of it poorly.

Maybe so.

>
>RV wrote:
>
>> On Wed, 22 Dec 2004 11:32:14 GMT, Emile wrote:
>>
> ...
>
>>>I mean by encoded: in some way expressed as a binary digit (= code
>>>representation of that value). The same way as the decimal 6 can be
>>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>>the ascii convention.
>>
>>
>> I understand whats meant it just that encoding is encoding,
>> compression is compression, and neither occurs during recording from a
>> sound car AD(analogue to digital) "converter".
>>
>> AD converters dont "compress" or "encode", they just "convert".
>
>The conversion is from an analog voltage to a bit pattern that
>represents it. The bit pattern is construed as a number encoded in some
>way, usually two's complement, sometimes offset binary.

The data bits are just a "conversion" from one raw value scale to
another that is linear to it and you can assume that one increment of
the converted value out is one increment of the input value in to a
simple converter.

PCM is a simple voltage conversion to byte value created at a given
bit length for each train of bits sent at a given frequency.

Remove the frequency and look at one byte and you just have a scale
conversion from volts to bits.

When we convert Imperial to Metric we dont "encode" Imperial to
Metric, that is not encoding..it is simple conversion of one scale to
another scale linear to it.
The sound card is just a voltage to bit value converter that does the
same, convesrion only from one scale to another.

"Encoding" requires some scheme / table / standard, call it what you
like, to encode by, and the same one to decode by.

There is no linearity between the input and output of the encoded
audiio, the table or scheme is required to describe the coding scheme
used, to decode it as the same as the original, or as close as
possible to the same on lossy compression encoding

The input scale of samples is not longer linear to the encoded data
bits you read, the standard table of mpeg is required to decipher
that.
You cant equate any encoded data with the input data without a table
or scheme to describe the encoding.

In simple conversion like the sound card does with PCM, you can assume
each converted data value is a linear representation of the input
value.
For both amplitude, and time (the computer is generating itself for
PCM.)

>
>>
>> An encoder uses a table to describe the encoding used so it can decode
>> it.
>> audio data values from a sound card line or mic input don't need to be
>> decoded as the levels represent the same thing as voltage in.
>> volts = data value on a linear scale.
>
>The encoding for numbers of at least one class -- mostly two's
>complement, nowadays -- is hard wired into the processor, so no table is
>needed.
>
>> The values given from the .data structure, are levels that correspond
>> directly to the AD converter as an actual voltage value at the input.
>>
>> Just pure scale conversion that occurs from volts to data level
>> X numer of times a second.
>>
>> For line in, 1v pp "scaled" to the bit size you use.
>> 16 bit is simply more voltage increments fom the same 1volt pp input
>> than 8bit.
>> in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
>> in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
>> line input
>>
>> For a "real world" application
>> You can read the scale of the audio buffer data value for level and
>> divide that by 1v pp and you can see the voltage at the sound card
>> input in precise increments of that.
>>
>> Encoding such as ASCII isnt linear in size of the binary values bit
>> for bit.
>> It uses a table of conversion to decode, the ASCII standard.
>> Without that you would not be able to encode or decode binary to
>> ASCII, but the computer has the stadard stuffed in there already to
>> use.
>
>Converting ASCII to signed binary is easily accomplished without a
>table. Converting it to signed decimal is even easier.

ASCII is the table / scheme.
That table lives in the computer.
The ASCII table is the key to the coding done.

Binary bits in, are not linear in value to the ASCII bits out.
ASCII takes up more bits than the binary takes up so we cant call it
compression.

The computer has to read the ASCII table in it that says for a binary
bit values, use xyz ASCII bits to represent the binary bits.
(that wont travel over Email, NNTP etc)

So that is "encoding" binary bits, to a larger number of bits
Or "decoding" ASCII bits to binary bits
Using the ASCII table
Bit to bits
(Meeses to peices)
No conversion there of scale from bits to something else.

>
>> MPEG encodes and decodes to the standard tables, without the external
>> table of the standard to data would be un decodable.
>
>MPEG compresses. Strictly, an MPEG file is decompressed, not decoded.
>It's easy to confuse while trying to explain.

MPEG is compression encoding.
encodes AND compresses.

So named
MPEG encoder
MPEG decoder.

Or "Codec" being both

To encode it requires a table called the MPEG standard.
It also requires the same MPEG standard to decode.

If you dont have the standard then you dont have the key to unlock,
decode, the data bits that went in to the encoder.
The data bits on the compression encoded data are not linear in any
way to the input data bits.

The sound card voltage in is linear to the bits read out from it so
that is just a plain "conversion", the same are imperial to metric or
US dollars to Euros

>
>> No such thing applies ot the sound card.
>> (ignoring on board mpeg encoders etc that ae secondary to the AD raw
>> values)
>>

Cheers

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 14:47:00 -0500

RV wrote:

> On Wed, 22 Dec 2004 09:47:48 -0500, Jerry Avins wrote:
>
>
>>You know what you mean; I know what you mean. As explanation, I think
>>you put some of it poorly.
>
>
> Maybe so.
>
>
>>RV wrote:
>>
>>
>>>On Wed, 22 Dec 2004 11:32:14 GMT, Emile wrote:
>>>
>>
>> ...
>>
>>
>>>>I mean by encoded: in some way expressed as a binary digit (= code
>>>>representation of that value). The same way as the decimal 6 can be
>>>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>>>the ascii convention.
>>>
>>>
>>>I understand whats meant it just that encoding is encoding,
>>>compression is compression, and neither occurs during recording from a
>>>sound car AD(analogue to digital) "converter".
>>>
>>>AD converters dont "compress" or "encode", they just "convert".
>>
>>The conversion is from an analog voltage to a bit pattern that
>>represents it. The bit pattern is construed as a number encoded in some
>>way, usually two's complement, sometimes offset binary.
>
>
> The data bits are just a "conversion" from one raw value scale to
> another that is linear to it and you can assume that one increment of
> the converted value out is one increment of the input value in to a
> simple converter.

The particular arrangement of bits is more than that. The first A-D
converters I used had outputs coded in either unsigned or offset binary.
(The particular coding was set by jumpers.) I often used a hardware
inverter on the MSB to convert offset binary code to two's complement
code, and sometimes a bunch of XOR gates to convert unsigned or offset
binary codes to reflected binary Gray code. No matter how the ADC
outputs are coded, they represent the same number (and voltage). The
mapping from a bit pattern to a number or anything else -- ASCII and
EBCDIC are examples of "else" -- is called a code.

> PCM is a simple voltage conversion to byte value created at a given
> bit length for each train of bits sent at a given frequency.
>
> Remove the frequency and look at one byte and you just have a scale
> conversion from volts to bits.

Sloppy. A converted quantity may be represented by more that one byte,
and the code used in the conversion needs to be specified. Packed BCD is
one option offered by some systems. ASCII suitable for sending to a data
logger is another. It's all just bits with different encodings.

> When we convert Imperial to Metric we dont "encode" Imperial to
> Metric, that is not encoding..it is simple conversion of one scale to
> another scale linear to it.

Quite.

> The sound card is just a voltage to bit value converter that does the
> same, convesrion only from one scale to another.

Provided you know what the bits mean. That's not as self evident as one
might think. Bits on Intel and Motorola machines are in different order.

> "Encoding" requires some scheme / table / standard, call it what you
> like, to encode by, and the same one to decode by.
>
> There is no linearity between the input and output of the encoded
> audiio, the table or scheme is required to describe the coding scheme
> used, to decode it as the same as the original, or as close as
> possible to the same on lossy compression encoding

No. Even early A- and mu-law codecs accomplished conversion without
look-up tables. (Note that the curves are segmented. Consider the
implications.)

> The input scale of samples is not longer linear to the encoded data
> bits you read, the standard table of mpeg is required to decipher
> that.
> You cant equate any encoded data with the input data without a table
> or scheme to describe the encoding.
>
> In simple conversion like the sound card does with PCM, you can assume
> each converted data value is a linear representation of the input
> value.
> For both amplitude, and time (the computer is generating itself for
> PCM.)

...

> Cheers

Cheers to you too!

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 14:31:21 +1100

On Thu, 23 Dec 2004 14:47:00 -0500, Jerry Avins wrote:

>RV wrote:
>
>> On Wed, 22 Dec 2004 09:47:48 -0500, Jerry Avins wrote:
>>
>>
>>>You know what you mean; I know what you mean. As explanation, I think
>>>you put some of it poorly.
>>
>>
>> Maybe so.
>>
>>
>>>RV wrote:
>>>
>>>
>>>>On Wed, 22 Dec 2004 11:32:14 GMT, Emile wrote:
>>>>
>>>
>>> ...
>>>
>>>
>>>>>I mean by encoded: in some way expressed as a binary digit (= code
>>>>>representation of that value). The same way as the decimal 6 can be
>>>>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>>>>the ascii convention.
>>>>
>>>>
>>>>I understand whats meant it just that encoding is encoding,
>>>>compression is compression, and neither occurs during recording from a
>>>>sound car AD(analogue to digital) "converter".
>>>>
>>>>AD converters dont "compress" or "encode", they just "convert".
>>>
>>>The conversion is from an analog voltage to a bit pattern that
>>>represents it. The bit pattern is construed as a number encoded in some
>>>way, usually two's complement, sometimes offset binary.
>>
>>
>> The data bits are just a "conversion" from one raw value scale to
>> another that is linear to it and you can assume that one increment of
>> the converted value out is one increment of the input value in to a
>> simple converter.
>
>The particular arrangement of bits is more than that. The first A-D
>converters I used had outputs coded in either unsigned or offset binary.
>(The particular coding was set by jumpers.) I often used a hardware
>inverter on the MSB to convert offset binary code to two's complement
>code, and sometimes a bunch of XOR gates to convert unsigned or offset
>binary codes to reflected binary Gray code. No matter how the ADC
>outputs are coded, they represent the same number (and voltage). The
>mapping from a bit pattern to a number or anything else -- ASCII and
>EBCDIC are examples of "else" -- is called a code.

Yeah, but this is as sound card.

>
>> PCM is a simple voltage conversion to byte value created at a given
>> bit length for each train of bits sent at a given frequency.
>>
>> Remove the frequency and look at one byte and you just have a scale
>> conversion from volts to bits.
>
>Sloppy. A converted quantity may be represented by more that one byte,
>and the code used in the conversion needs to be specified. Packed BCD is
>one option offered by some systems. ASCII suitable for sending to a data
>logger is another. It's all just bits with different encodings.

thats just obfuscating the simple explanation given for the purpose of
the simple understanding of it, suffice for it to now relate to
nothing in the win 32 mm code.

And this is supposed to help the OP to write win3d mm code, how?

>
>> When we convert Imperial to Metric we dont "encode" Imperial to
>> Metric, that is not encoding..it is simple conversion of one scale to
>> another scale linear to it.
>
>Quite.
>
>> The sound card is just a voltage to bit value converter that does the
>> same, convesrion only from one scale to another.
>
>Provided you know what the bits mean. That's not as self evident as one
>might think. Bits on Intel and Motorola machines are in different order.

What did the OP say he was wirting the code on and with.

At some point do you guys thinkl you can stick to windows multimedia
API's and forget the lesson on a whole lotta "stuff" that means
nothing to the guy whio is trying to worte to code in win mm API code.

>
>> "Encoding" requires some scheme / table / standard, call it what you
>> like, to encode by, and the same one to decode by.
>>
>> There is no linearity between the input and output of the encoded
>> audiio, the table or scheme is required to describe the coding scheme
>> used, to decode it as the same as the original, or as close as
>> possible to the same on lossy compression encoding
>
>No. Even early A- and mu-law codecs accomplished conversion without
>look-up tables. (Note that the curves are segmented. Consider the
>implications.)

mu-law is a standard

scheme / table / standard
Not that complicated so why make it complicated.

Any "encoded" audio uses a standard
PCM wav doesn't refer to a table or standard for volts to bits.
It s simple linear conversion.

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 12:28:55 -0500

RV wrote:

...

> At some point do you guys thinkl you can stick to windows multimedia
> API's and forget the lesson on a whole lotta "stuff" that means
> nothing to the guy whio is trying to worte to code in win mm API code.

Simplifying is appropriate. Misinforming is not.

>>>"Encoding" requires some scheme / table / standard, call it what you
>>>like, to encode by, and the same one to decode by.
>>>
>>>There is no linearity between the input and output of the encoded
>>>audiio, the table or scheme is required to describe the coding scheme
>>>used, to decode it as the same as the original, or as close as
>>>possible to the same on lossy compression encoding
>>
>>No. Even early A- and mu-law codecs accomplished conversion without
>>look-up tables. (Note that the curves are segmented. Consider the
>>implications.)
>
>
> mu-law is a standard

Yes. It is a standard way to encode levels. No look-up table is needed
in the implementation.

> scheme / table / standard
> Not that complicated so why make it complicated.
>
> Any "encoded" audio uses a standard
> PCM wav doesn't refer to a table or standard for volts to bits.
> It s simple linear conversion.

What you call PCM assumes that the LSB has the weight of one unit, that
the next one up has the weight of two units, etc. and that the last one,
if on, means that the number is negative. That assumption is a code.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	RV
Subject:	Re: soundcard buffer format
Date:	Sat, 25 Dec 2004 16:43:30 +1100

On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins wrote:

>RV wrote:
>
> ...
>
>> At some point do you guys thinkl you can stick to windows multimedia
>> API's and forget the lesson on a whole lotta "stuff" that means
>> nothing to the guy whio is trying to worte to code in win mm API code.
>
>Simplifying is appropriate. Misinforming is not.

Uh huh
So
Do you know the code used in Win32 mm API to do what the OP needs to
do or not?

From:	glen herrmannsfeldt
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 12:44:29 -0800

Jerry Avins wrote:

(snip)

> The particular arrangement of bits is more than that. The first A-D
> converters I used had outputs coded in either unsigned or offset binary.
> (The particular coding was set by jumpers.) I often used a hardware
> inverter on the MSB to convert offset binary code to two's complement
> code, and sometimes a bunch of XOR gates to convert unsigned or offset
> binary codes to reflected binary Gray code. No matter how the ADC
> outputs are coded, they represent the same number (and voltage). The
> mapping from a bit pattern to a number or anything else -- ASCII and
> EBCDIC are examples of "else" -- is called a code.

I agree.

So maybe a bar graph representation of a real number would
be uncoded?

(snip)

>>When we convert Imperial to Metric we dont "encode" Imperial to
>>Metric, that is not encoding..it is simple conversion of one scale to
>>another scale linear to it.

> Quite.

A linear conversion from one real number to another.

But could the common Imperial (and US) unit systems that
represent a real number in a combination of different quantities,
feet and inches, pounds and ounces, etc., be considered a code?

>>The sound card is just a voltage to bit value converter that does the
>>same, convesrion only from one scale to another.

> Provided you know what the bits mean. That's not as self evident as one
> might think. Bits on Intel and Motorola machines are in different order.

>>"Encoding" requires some scheme / table / standard, call it what you
>>like, to encode by, and the same one to decode by.

So the binary representation, with power of two bit values,
is not a code? If it is BCD then is it a code?

Maybe not quite as bad as the discussions over what is modulated,
and therefor what is or isn't a modem. Note that both cable and
DSL are definitely modulated, and so require modems.

I would say that some codes are simpler than others, but that
doesn't mean they aren't codes.

-- glen

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 14:46:53 +1100

On Thu, 23 Dec 2004 12:44:29 -0800, glen herrmannsfeldt
wrote:

>
>
>Jerry Avins wrote:
>
>(snip)
>
>> The particular arrangement of bits is more than that. The first A-D
>> converters I used had outputs coded in either unsigned or offset binary.
>> (The particular coding was set by jumpers.) I often used a hardware
>> inverter on the MSB to convert offset binary code to two's complement
>> code, and sometimes a bunch of XOR gates to convert unsigned or offset
>> binary codes to reflected binary Gray code. No matter how the ADC
>> outputs are coded, they represent the same number (and voltage). The
>> mapping from a bit pattern to a number or anything else -- ASCII and
>> EBCDIC are examples of "else" -- is called a code.
>
>I agree.
>
>So maybe a bar graph representation of a real number would
>be uncoded?
>
>(snip)
>
>>>When we convert Imperial to Metric we dont "encode" Imperial to
>>>Metric, that is not encoding..it is simple conversion of one scale to
>>>another scale linear to it.
>
>> Quite.
>
>A linear conversion from one real number to another.
>
>But could the common Imperial (and US) unit systems that
>represent a real number in a combination of different quantities,
>feet and inches, pounds and ounces, etc., be considered a code?

Not if yout want them man down the hardware store totake your
seriouslty

Do you have a Metric encoder.
Ah what?
A Metric encoder that encodes Metric to imperial
Huh?
16yo harward store cash register attendant says
"I think he means a metric converter."

Go down the autoshop
I need a new catalytic encoder.
You need a what?
A catalytic encoder
Huh?
16yo knuckle dragging apprentice says
"I think he means a catalytic converter"

Yeah, you can use code or encode if you are not happy with using the
true descriptive of convert.
But dont be surprised if people of a lower IQ than yourself look at
your as though youve lost the plot..

>
>>>The sound card is just a voltage to bit value converter that does the
>>>same, convesrion only from one scale to another.
>
>> Provided you know what the bits mean. That's not as self evident as one
>> might think. Bits on Intel and Motorola machines are in different order.
>
>>>"Encoding" requires some scheme / table / standard, call it what you
>>>like, to encode by, and the same one to decode by.
>
>So the binary representation, with power of two bit values,
>is not a code? If it is BCD then is it a code?

BCD is a standard.

>
>Maybe not quite as bad as the discussions over what is modulated,
>and therefor what is or isn't a modem. Note that both cable and
>DSL are definitely modulated, and so require modems.
>
>I would say that some codes are simpler than others, but that
>doesn't mean they aren't codes.

Well in a fit of pedanticism you could say that the fact he is using
Win mm API code means he is encoding everything he does.
In fact each time he punches the button in his keyboard he encodes.
And he is using C++ code.

But if you want to be of any use to the OP on Windows MM API's then
dont refer to PCM raw wave as encoded.
Its not.

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 12:32:03 -0500

RV wrote:

...

> BCD is a standard.

BCD is one standard way to encode decimal numbers with bits.
Excess-three code is another.

...

> But if you want to be of any use to the OP on Windows MM API's then
> dont refer to PCM raw wave as encoded.
> Its not.

You evidently think that the meaning of "code" is restricted to a small
subset of its range of meanings. Consider "penal code". "codify", "Morse
code", and other ways the word is used. There are different ways to
encode numbers as bits. Natural binary code -- the base-two analog of
the base-ten representation of positive integers -- is the basis of most
of them. (Arabic numerals and base-ten number encoding is very different
from the ancient Roman encoding.) Two signed variations of binary
encoding and two of decimal encoding of integers have all been used in
computers, with their hardware designed to work directly with those
numbers. For binary, there are two's-complement and sign/magnitude
encodings. Some DACs and ADCs use offset-binary code. (The exponents in
many floating-point encodings are also offset binary.) For decimal
calculations, some computers once used packed-BCD code for
representation and had hardware that worked with that directly. Since
the hardware to manipulate excess-three code is simpler, some computers
used that.

When numbers must be read properly even if some bits might be in
transition, simplicity is sacrificed to achieve an encoding in which
only one bit makes a transition to pass from one state to another. Such
encodings -- there are many of them -- were first investigated and
described by a guy named Gray, hence the name and the capital letter.
There is a simple mapping -- a conversion from unsigned or offset binary
code to reflected-binary Gray code. It is so commonly used that when
"Gray code" is used without modification, reflected-binary Gray code is
implied.

The point is that they are all codes. A bunch of bits only represents a
number or symbol if the encoding is known. That includes the bit order.
If you see 32 bits and are told that they represent a number, you can't
tell what the number is without knowing the endianness and whether the
number is encoded as signed, unsigned, or floating point. Six
possibilities commonly exist today. In the past, there were more.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Thu, 23 Dec 2004 16:00:22 -0500

glen herrmannsfeldt wrote:

...

> So maybe a bar graph representation of a real number would
> be uncoded?

(snip)

The mapping from "height" to magnitude is a code, and the assumption
that different points on a horizontal piece of paper have different
heights also is. As you wrote, some codes are simpler than others.

jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Emile
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 16:26:39 GMT

>>>>>How? What does "bit rate" mean in this context, anyway?
>>>>>
>>>>
>>>>i think it means how many bits are used to encode one sample in computer
>>>>memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>>>that sample.
>>>>
>>>
>>>
>>>Yup thats it
>>>8 bit or 16 bit for each channel L and R per sample.
>>>
>>>But not encoded, just recorded as a raw sample for this exercise.
>>>(a typo?)
>>>
>>>
>>
>>I mean by encoded: in some way expressed as a binary digit (= code
>>representation of that value). The same way as the decimal 6 can be
>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>the ascii convention.
>
>
> I understand whats meant it just that encoding is encoding,
> compression is compression, and neither occurs during recording from a
> sound car AD(analogue to digital) "converter".
>
> AD converters dont "compress" or "encode", they just "convert".
>
> An encoder uses a table to describe the encoding used so it can decode
> it.
> audio data values from a sound card line or mic input don't need to be
> decoded as the levels represent the same thing as voltage in.
> volts = data value on a linear scale.
>
> The values given from the .data structure, are levels that correspond
> directly to the AD converter as an actual voltage value at the input.
>
> Just pure scale conversion that occurs from volts to data level
> X numer of times a second.
>
> For line in, 1v pp "scaled" to the bit size you use.
> 16 bit is simply more voltage increments fom the same 1volt pp input
> than 8bit.
> in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
> in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
> line input
>
> For a "real world" application
> You can read the scale of the audio buffer data value for level and
> divide that by 1v pp and you can see the voltage at the sound card
> input in precise increments of that.
>
> Encoding such as ASCII isnt linear in size of the binary values bit
> for bit.
> It uses a table of conversion to decode, the ASCII standard.
> Without that you would not be able to encode or decode binary to
> ASCII, but the computer has the stadard stuffed in there already to
> use.
>
> MPEG encodes and decodes to the standard tables, without the external
> table of the standard to data would be un decodable.
>
> No such thing applies ot the sound card.
> (ignoring on board mpeg encoders etc that ae secondary to the AD raw
> values)
>
> Cheers

Interesting expanation, some things i didnt know, u clearly know more
about MPEG encoders and stuff than i do.
But the only thing i did was use the verb "to encode" in its literal
meaning: to express/convert something, an idea (in this case a value)
in/into code, nothing more, nothing less. This is also what i read in my
english dictionary (and now even several other english dictionaries to
be sure). I acknowledge that there may be some contexts in wich there is
a convention to use to encode in another meaning.

grtz
Emile

From:	RV
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 15:20:43 +1100

On Wed, 22 Dec 2004 16:26:39 GMT, Emile wrote:

>
>>>>>>How? What does "bit rate" mean in this context, anyway?
>>>>>>
>>>>>
>>>>>i think it means how many bits are used to encode one sample in computer
>>>>>memory, thus with 2^8 or with 2^16 possible values for the amplitude of
>>>>>that sample.
>>>>>
>>>>
>>>>
>>>>Yup thats it
>>>>8 bit or 16 bit for each channel L and R per sample.
>>>>
>>>>But not encoded, just recorded as a raw sample for this exercise.
>>>>(a typo?)
>>>>
>>>>
>>>
>>>I mean by encoded: in some way expressed as a binary digit (= code
>>>representation of that value). The same way as the decimal 6 can be
>>>encoded as 110 in binary, but it is encoded as 00110110 when following
>>>the ascii convention.
>>
>>
>> I understand whats meant it just that encoding is encoding,
>> compression is compression, and neither occurs during recording from a
>> sound car AD(analogue to digital) "converter".
>>
>> AD converters dont "compress" or "encode", they just "convert".
>>
>> An encoder uses a table to describe the encoding used so it can decode
>> it.
>> audio data values from a sound card line or mic input don't need to be
>> decoded as the levels represent the same thing as voltage in.
>> volts = data value on a linear scale.
>>
>> The values given from the .data structure, are levels that correspond
>> directly to the AD converter as an actual voltage value at the input.
>>
>> Just pure scale conversion that occurs from volts to data level
>> X numer of times a second.
>>
>> For line in, 1v pp "scaled" to the bit size you use.
>> 16 bit is simply more voltage increments fom the same 1volt pp input
>> than 8bit.
>> in 8 bit, +128 or -128 is maximum voltage input at 1v pp line input.
>> in 16 bit -32767 or +32767 is the same maximum voltage at the 1v pp
>> line input
>>
>> For a "real world" application
>> You can read the scale of the audio buffer data value for level and
>> divide that by 1v pp and you can see the voltage at the sound card
>> input in precise increments of that.
>>
>> Encoding such as ASCII isnt linear in size of the binary values bit
>> for bit.
>> It uses a table of conversion to decode, the ASCII standard.
>> Without that you would not be able to encode or decode binary to
>> ASCII, but the computer has the stadard stuffed in there already to
>> use.
>>
>> MPEG encodes and decodes to the standard tables, without the external
>> table of the standard to data would be un decodable.
>>
>> No such thing applies ot the sound card.
>> (ignoring on board mpeg encoders etc that ae secondary to the AD raw
>> values)
>>
>> Cheers
>
>Interesting expanation, some things i didnt know, u clearly know more
>about MPEG encoders and stuff than i do.
>But the only thing i did was use the verb "to encode" in its literal
>meaning: to express/convert something, an idea (in this case a value)
>in/into code, nothing more, nothing less. This is also what i read in my
>english dictionary (and now even several other english dictionaries to
>be sure). I acknowledge that there may be some contexts in wich there is
>a convention to use to encode in another meaning.
>

I understand.
The use of the english dictionary is not always a good guide to use
when describing terms like this because the dictoinary has abstract
uses of words, such as you listed, the use of these terms in computers
is more explicit and normally has one meaning only..
Computers are rather anal like that.
But it helps so we know our apples from oranges writing code.

As you can see a slip of the hand from "rate" to "size" can cause an
entire thread breakout on Usenet with code writers.

Where the dictionary could be used to apply both in an abstract way to
much the same thing
As in
"Size" of my repair bill is the same as the "rate" the repairer
charged me.

This is Windows 32 API MM code the OP is using. I simply suggested we
stick to the terminlogy used in it and not replace the terms used in
code for some other abstract.

I can safely say I have regrets about doing that now too.
But I assumed this group was software programmers.
Wrongly it seems.

From:	Jerry Avins
Subject:	Re: soundcard buffer format
Date:	Fri, 24 Dec 2004 12:34:28 -0500

RV wrote:

...

> "Size" of my repair bill is the same as the "rate" the repairer
> charged me.

The size of your bill was probably determined by the repairman's hourly
rate and the length of time he spent on your job.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Randy Yates
Subject:	Re: soundcard buffer format
Date:	Wed, 22 Dec 2004 02:14:27 GMT

ridpiska@hotmail.com (Jonas Rundberg) writes:

> Hi
>
> I am developing on an app that records sound from the soundcard and
> then perform some dsp on the accuired sound. So far I've been working
> with 44100 Hz sampling frequency, but need to change to 22050 Hz.
> I use the win32 sdk multimedia functions to communicate with the
> soundcard.
>
> When I use 44100 Hz I know that the recorded buffer I receive from the
> soundcard contains values that should be interpreted as type short
> (programming in c). But what happens if I change sample frequency to
> 22050? Should I still expect the values to be of type short?
> Are there any standards that manufacturers of soundcard implements or
> is the data manufacturer dependant?
>
> I use a HP laptop and I can't find any information about the soundcard
> on HP's homepage.

See the WAVEOUTCAPS structure and the waveOutGetDevCaps() win32 API function
call.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr