>>>>>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) > > CheersInteresting 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
soundcard buffer format
Started by ●December 21, 2004
Reply by ●December 22, 20042004-12-22
Reply by ●December 22, 20042004-12-22
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
Reply by ●December 22, 20042004-12-22
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. �����������������������������������������������������������������������
Reply by ●December 22, 20042004-12-22
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
Reply by ●December 23, 20042004-12-23
On Wed, 22 Dec 2004 10:48:57 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> 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.
Reply by ●December 23, 20042004-12-23
On Wed, 22 Dec 2004 09:47:48 -0500, Jerry Avins <jya@ieee.org> 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 <bla.abla@telenet.be> 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
Reply by ●December 23, 20042004-12-23
You quite succinctly summarized my frustrations with dealing with sales/marketing people! Such loose language one never did hear. It's often like pulling teeth to get a clear, concise description of a problem or requested feature. On the other hand, I've been told to cut them some slack because if they were capable of concise technical descriptions, they would have become engineers instead! :-) "Jerry Avins" <jya@ieee.org> wrote in message news:32tvf2F3phgatU1@individual.net...> 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.
Reply by ●December 23, 20042004-12-23
>>...>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 <canonical.disclaimer> // only my own opinions, etc.
Reply by ●December 23, 20042004-12-23
"Jerry Avins" <jya@ieee.org> 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. > > JerryImagine 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
Reply by ●December 23, 20042004-12-23
RV wrote:> On Wed, 22 Dec 2004 09:47:48 -0500, Jerry Avins <jya@ieee.org> 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 <bla.abla@telenet.be> 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 encodingNo. 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.)...> CheersCheers to you too! Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
