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
soundcard buffer format
Started by ●December 21, 2004
Reply by ●December 23, 20042004-12-23
Reply by ●December 23, 20042004-12-23
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. �����������������������������������������������������������������������
Reply by ●December 23, 20042004-12-23
Bhaskar Thiagarajan wrote:> "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. >> >>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 > BhaskarI'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. �����������������������������������������������������������������������
Reply by ●December 23, 20042004-12-23
On Thu, 23 Dec 2004 14:47:00 -0500, Jerry Avins <jya@ieee.org> wrote:>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.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.
Reply by ●December 23, 20042004-12-23
On Thu, 23 Dec 2004 12:44:29 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> 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.
Reply by ●December 24, 20042004-12-24
On Wed, 22 Dec 2004 16:26:39 GMT, Emile <bla.abla@telenet.be> 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.
Reply by ●December 24, 20042004-12-24
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 standardYes. 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. �����������������������������������������������������������������������
Reply by ●December 24, 20042004-12-24
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. �����������������������������������������������������������������������
Reply by ●December 24, 20042004-12-24
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. �����������������������������������������������������������������������
Reply by ●February 2, 20052005-02-02
On Sat, 25 Dec 2004 11:15:24 GMT, Randy Yates <yates@ieee.org> wrote:>RV <do_not_use@email.com> writes: > >> On Fri, 24 Dec 2004 12:28:55 -0500, Jerry Avins <jya@ieee.org> 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
