Hello, I am new to this group, and I have a question on the Sun forums that it seems this group would be able to help with. The question is posted at: http://forums.sun.com/thread.jspa?messageID=10391494 If you use that forum, I am awarding Duke points to anyone that answers/helps. For people who may be able to help here, this is my question: I am trying to compute the power (in db) of byte[] that represents audio data. It is my understanding that I need to take the RMS value of the bytes, and then perform a 10 log operation on it to do so, but my results don't seem to make sense to me. Here's my code for it. My actual implementation has more to it than this, but for the sake of dealing with this specific problem I am condensing it: // for the sake of brevity, assume I am properly getting the byte[] from the mic. // I know I am because I can write that array to a SourceDataLine and it sounds right. byte[] audioData = getByteArray(); long sumOfSquares = 0; for (int i = 0;i<audioData.length;i++){ // unsign the bytes, square them, and add them to the sumOfSquares int byteSquared = (audioData[i] & 0xFF)*(audioData[i] & 0xFF); sumOfSquares+=byteSquared; } // now divide the sumOfSquares by the number of elements long sqSumAvg = sumOfSquares/audioData.length; // and the square root of the sum of squares is the RMS value double rms = Math.sqrt(sqSumAvg); // then, to find the dB, do a 10 log operation on the value (rms/max) double db = 10 * (Math.log10(rms/0xFF)); All of my values are -2.xxxxx, no matter how much noise I make. To aid my understanding of this, I am drawing a graphical representation of the waveform, so I can visually ensure that I am getting a signal, and that it looks like it "should". And I most definitely am; when I feed what is basically a pure sine wave in, it looks like, well, a sine wave! I feel like I am really close to having this licked. The purpose of this is to find the power level of an audio signal. I have tried to use the built-in method getLevel() that TargetDataLine and SourceDataLine implement from DataLine, but I ALWAYS get -1 as a result, no matter what audio hardware I use. While trying that (with failure), I read that getLevel() isn't actually implemented, even though the javadoc would lead you to believe otherwise. If anyone can help with this, it would be much obliged.
Computing the power level of 8 bit mono audio byte data
Started by ●August 21, 2008
Reply by ●August 21, 20082008-08-21
power in dB is computed with 20*log10(signal_rms) rgds bharat pathak Arithos Designs www.Arithos.com
Reply by ●August 21, 20082008-08-21
On Aug 21, 9:57�am, "bharat pathak" <bha...@arithos.com> wrote:> power in dB is computed with 20*log10(signal_rms) > > rgds > bharat pathak > > Arithos Designswww.Arithos.comThank you Bharat, I tried what you are suggesting, but doing that doesn't seem to help, all of my values are between 42.0 and 43.0 now. Why wouldn't I want to do the 20 * log10 operation on (rms) instead of (rms/maxValue)? Don't I need some kind of reference for the dB value to be meaningful? I am pretty sure my RMS calculation is correct, that seems like a trivial algorithm. I have a feeling that my error may have something to do with signing/unsigning the byte values, but I am not really sure...
Reply by ●August 21, 20082008-08-21
"J_Y_C" <4chen500@gmail.com> wrote in message news:09dc50d2-f07c-4cd8-b242-9537c565e030@34g2000hsh.googlegroups.com...> > If anyone can help with this, it would be much obliged.LOL! This has to be the cream of the crop this week! WELL DONE! ROFLMAO Hah hah hah
Reply by ●August 21, 20082008-08-21
On Aug 21, 12:10�pm, "Icky Thwacket" <i...@it.it> wrote:> "J_Y_C" <4chen...@gmail.com> wrote in message > > news:09dc50d2-f07c-4cd8-b242-9537c565e030@34g2000hsh.googlegroups.com... > > > > > If anyone can help with this, it would be much obliged. > > LOL! �This has to be the cream of the crop this week! > > WELL DONE! > > ROFLMAO > > Hah hah hahSo no, I'm not a DSP engineer or anything. I guess this is an elite newsgroup, and basic questions like this are not welcome?
Reply by ●August 21, 20082008-08-21
J_Y_C wrote:> On Aug 21, 12:10 pm, "Icky Thwacket" <i...@it.it> wrote: >> "J_Y_C" <4chen...@gmail.com> wrote in message >> >> news:09dc50d2-f07c-4cd8-b242-9537c565e030@34g2000hsh.googlegroups.com... >> >> >> >>> If anyone can help with this, it would be much obliged. >> LOL! This has to be the cream of the crop this week! >> >> WELL DONE! >> >> ROFLMAO >> >> Hah hah hah > > So no, I'm not a DSP engineer or anything. > > I guess this is an elite newsgroup, and basic questions like this are > not welcome?There will be jerks wherever you go. Don't mind this one. He doesn't come here often. (I'm guessing that he doesn't know what "thwacket" means or what language it's from.) What on Earth are Duke points? It's rare that audio data are represented by individual bytes. (Octets, really. In come usages, the size of a byte is not necessarily eight bits.) You need to know the size of your data before you can manipulate them. A common reference for "power" of digital numbers is zero dB = full scale, making all other values negative. If your sound samples are 16-bit words, full scale is 2^15. the other bit is the sign bit and can be ignored when squaring. Don't just manipulate numbers. Those numbers stand for something and to deal with them you need to know what. If you're mistaken about *what* to do, *how* to do it doesn't matter. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●August 21, 20082008-08-21
On Aug 21, 11:08 am, J_Y_C <4chen...@gmail.com> wrote:> I am pretty sure my RMS calculation is correct, that seems like a > trivial algorithm. I have a feeling that my error may have something > to do with signing/unsigning the byte values, but I am not really > sure...I recommend you feed your program test data (sinusoid of adjustable value) and single step through it with all relevant variables displayed, checking for example that the square of an individual sample is as expected. Also test that your square root and log functions as expected. Sometimes if you omit a header file it will compile but the answers will be 'wrong' due to mixups in data types. BTW, you can eliminate the square root operation by passing it through the log operator where it becomes division by two. The reverse of this (power being amplitude squared due to ohm's law) is why you were suggested to do 20 log10() instead of 10log10(). Since you want power anyway, the square root and squaring cancel and you are left with power = 10log10(mag^2)
Reply by ●August 21, 20082008-08-21
On Aug 21, 12:46�pm, Jerry Avins <j...@ieee.org> wrote:> J_Y_C wrote: > > On Aug 21, 12:10 pm, "Icky Thwacket" <i...@it.it> wrote: > >> "J_Y_C" <4chen...@gmail.com> wrote in message > > >>news:09dc50d2-f07c-4cd8-b242-9537c565e030@34g2000hsh.googlegroups.com... > > >>> If anyone can help with this, it would be much obliged. > >> LOL! �This has to be the cream of the crop this week! > > >> WELL DONE! > > >> ROFLMAO > > >> Hah hah hah > > > So no, I'm not a DSP engineer or anything. > > > I guess this is an elite newsgroup, and basic questions like this are > > not welcome? > > There will be jerks wherever you go. Don't mind this one. He doesn't > come here often. (I'm guessing that he doesn't know what "thwacket" > means or what language it's from.) > > What on Earth are Duke points? > > It's rare that audio data are represented by individual bytes. (Octets, > really. In come usages, the size of a byte is not necessarily eight > bits.) You need to know the size of your data before you can manipulate > them. > > A common reference for "power" of digital numbers is zero dB = full > scale, making all other values negative. If your sound samples are > 16-bit words, full scale is 2^15. the other bit is the sign bit and can > be ignored when squaring. > > Don't just manipulate numbers. Those numbers stand for something and to > deal with them you need to know what. If you're mistaken about *what* to > do, *how* to do it doesn't matter. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > �����������������������������������������������������������������������Thanks Jerry. My samples are 8 bit, and the values range from -128 to 127, and I am analyzing 4096 at a time at a rate of 44.1k. So, I set my reference value to my current max value, which would be 0xFF (255), and shifting all of my values up by 128.... OMG.... I am shifting up by 0xFF, not 0x80 (128). I just changed that, but I am still not getting the values I would expect... In regards to using 0 as my reference, wouldn't that cause me to divide by zero when I perform the log operation?
Reply by ●August 21, 20082008-08-21
On Aug 21, 12:58�pm, cs_post...@hotmail.com wrote:> On Aug 21, 11:08 am, J_Y_C <4chen...@gmail.com> wrote: > > > I am pretty sure my RMS calculation is correct, that seems like a > > trivial algorithm. I have a feeling that my error may have something > > to do with signing/unsigning the byte values, but I am not really > > sure... > > I recommend you feed your program test data (sinusoid of adjustable > value) and single step through it with all relevant variables > displayed, checking for example that the square of an individual > sample is as expected. > > Also test that your square root and log functions as expected. > Sometimes if you �omit a header file it will compile but the answers > will be 'wrong' due to mixups in data types. >Good idea.> BTW, you can eliminate the square root operation by passing it through > the log operator where it becomes division by two. �The reverse of > this (power being amplitude squared due to ohm's law) is why you were > suggested to do 20 log10() instead of 10log10(). �Since you want power > anyway, the square root and squaring cancel and you are left with > power = 10log10(mag^2)But how can this be? I am performing the log operation on the RMS value, which is the sum of square divided by the number of samples, and not just the sum of squares.
Reply by ●August 21, 20082008-08-21
"Jerry Avins" <jya@ieee.org> wrote in message news:ffGdnYmuAqtqBjDVnZ2dnUVZ_jqdnZ2d@rcn.net...> > There will be jerks wherever you go. Don't mind this one. He doesn't come > here often. (I'm guessing that he doesn't know what "thwacket" means or > what language it's from.) > > What on Earth are Duke points? > > It's rare that audio data are represented by individual bytes. (Octets, > really. In come usages, the size of a byte is not necessarily eight bits.) > You need to know the size of your data before you can manipulate them. > > A common reference for "power" of digital numbers is zero dB = full scale, > making all other values negative. If your sound samples are 16-bit words, > full scale is 2^15. the other bit is the sign bit and can be ignored when > squaring. > > Don't just manipulate numbers. Those numbers stand for something and to > deal with them you need to know what. If you're mistaken about *what* to > do, *how* to do it doesn't matter. > > Jerry > -- > Engineering is the art of making what you want from things you can get. >����������������������������������������������������������������������� You cannot calculate the "power level" of 8 bit data, it is meaningless. If in you own way you are asking "what is the dynamic range of an 8 bit data stream?" then that can be answered. For each additional bit of a digital word you are doubling the resolution, or dynamic range. A doubling of range infers a ratio of 2:1, thus equivalent to 20log2 or 6dB. Thus the dynamic range of a 4 bit signal in crude terms is 4 x 6dB = 24dB. For an 8 bit signal this becomes 8 x 6dB = 48dB For 12 bit becomes 12 x 6dB = 72db And for good old 16 bit = 16 x 6dB = 96dB. etc etc etc There you go. Icky Engineering is the art of making the impossible from the unobtainable. The impossible can be done at once, miracles take a little longer.
