Question

I’m going to be processing a lot of audio files, I don’t need to play the files, but I want to be able to get the volume level at a regular interval (e.g. every second), so I can roughly graph the overall volume level throughout the file. I’ve used the java Sound API to read the frames of the file, but I’m not sure how to interpret them (i’m not sure how to deal with the little-endian as well splitting the frame into two channels), and I tried sending the AudioInputStream to a SourceDataLine, and calling getLevel() on the dataline every second, but it always returned 0.

Answer 1

If you have signed PCM, the values decoded from the bytes will have the range of a Java short integer (-32768 to 32767). The nature of a sound wave, though, is to sweep back and forth, so at any single frame, the value could be almost anywhere and thus not particularly well correlated with the volume you hear.

So, I suspect you will have to look at many samples and do some sort of analysis in the aggregate. Perhaps add up all the deviations from 0 as absolute values and divide by the number of frames? How many frames would be needed? Well, if we want to include, say, bass sound waves that cycle at 50 cps, and want to make sure we include an entire cycle, that’s 1/50 of a full second’s worth of frames. If you sample rate is 44100fps, that’s 8805 frames! But perhaps using this rolling average distorts the contributions of other nearby frequency values?

Caveat, I’m mostly self-taught, so there may be a better way to do this.

Following is the code line I use to convert a frame of a little-endian track to a float between -1 and 1 (er, 0.999…), where buffer is a byte array:

float audioVal  = (float)( ( ( buffer[i+1] << 8 )   
    | ( buffer[i] & 0xff ) ) / 32768.0 ); 

If you search, there are other posts that have similar conversions, here on Stack Overflow. The MSB is shifted and retains its sign. The LSB is &’d with an ff hexadecimal to make sure the “sign bit” is interpreted as being part of the numeric value. The MSB & LSB are |’d together and divided by the largest possible short int value to “normalize” the range. I think the four bytes of a frame for little endian 16-bit encoding are ordered as follows: b[0] = left LSB, b[1] = left MSB, b[2] = right LSB, b[3] = right MSB. I can’t recall where I saw this officially defined or posted though. It would be embarressing to have swapped the left & right!

You would want to do an ABS before finding the moving average. Maybe the ABS could be built into the conversion to save a couple cpus.