handling WAV file
I want to retrieve information out of a Wav file - for a Fourier transfrom.
I am using AudioInputStream. The problem is that I would prefer it to be in float(s), because the bytes affect my analysis.
Alterantivley, if you could provide me with a link to an FT of a wave file, that works well*, I'd be very greatful.
*By works well, I mean - The FT I have now computes for a certain frequency, a certain amplitude. When I change the wave file to be quieter, the fourier transfrom doesn't always show a change in amplitude (sometimes increase).
I printed the array of bytes produced by AudioInputStream, and it looks something like this:
and on the more quiet one, it looks like this:
So you see - 1,6 and 32 were all mapped to the value 1, once the sample was of lower volume. I think this is affecting my analysis, and would prefer to retrieve float information out of WAV files.
Could you help?
Thank you all.
I'm no expert in math or acoustics, but the information stored in a sound file isn't floating point data to begin with.
The degree of accuracy is determined by the sample rate, and the size of the sample (22Khz @ 8bit) for example. So, there are no magic hidden floating point values stored in the file, just lots of rounded integers.
If you need a greater degree of accuracy in your transformations, then I suggest converting all of the bytes read (which can be read as ints or longs depending on the bit size) into floats or doubles and then performing transformations.
However, if you then intend to play the sound again, you're going to loose any trailing decimal information since everything will have to go back to a non-floating point value.
I suspect you're having trouble with the conversion of the bytes to something else in your transform. When I spent a very brief time playing with sound analysis, the sounds I was working with were stored in 2 byte chunks, and transformations had to be applied to the two bytes together, not each individually (16 bit) because the two bytes needed to be treated as one number i.e.
10110101 10010011 is 46483 (unsigned), not
181 and 147
Not realizing this at first, I was performing transformations byte by byte which let to garbage results.
I wasn't doing anything fancy however, just pitch shifting, playing backwards, etc...