# FFT of audio, packet sampling and others

Hi I am just toying around with compression now that we are learning about Fourier transforms in my class (compression is not a part of the class but I became a bit curious). Trying to do this with a wav file and I have some questions.

Assume I don't know the sampling rate of the signal (.wav) how can I figure out what the FFT frequency range is in Hz? I know that the bins are multiples of the sampling rate ($F_s$) divided by N, or they are factors of Fs, eg 0.1*$F_s$, 0.2*$F_s$ etc... but how does this help me find the sampling frequency in Hz, so I can actually see which frequencies are doing what?

Is there any clever trick in storing the coefficients of a real signal (wav)? They are always complex unless the signal is a pure cosine but what audio is? If I want to store the full range of coefficients I need at least as much storage as the .wav file (exploiting symmetry at the midpoint and having 2 units (real, imag) for every real input). This is of particular importance, if the coefficients are small they can be stored with less bits than the bits needed to represent the .wav datapoints.

Since for the case of functions you can split them in subintervalls and take the Fourier transform and depending on the result get some easier or more compact expression I was wondering if for the sake of compression I could split the audio-signal?

If I have a .wav file with N datapoints then split into ten N/10 segments and then fft on each segment. But this then means that my sampling frequency is essentially reduced to N/10 $F_s$? This seems intuitive, if I "zoom" into a rapidly osciallitaing function then in that window it will look very slow and appear to have a low frequency.

• Do you know the contents of the WAV file? For example, if you know the WAV file is made by recording a single note played constantly, you would be able to figure out the sampling rate from the WAV contents. – The Photon Oct 30 '12 at 21:41
• There is no property of the transform you can use to figure out the sampling rate. For example, there is no way to tell the difference between a 10 Hz signal sampled at 100 Sa/s from a 320 MHz signal sampled at 3.2 GSa/s. – The Photon Oct 30 '12 at 22:40
• @ThePhoton I have seen many cases where you can look for 60hz hum. Crappy recordings can often have a little left and it will just sit there the entire recording, not fool proof, but might help narrow it down to a few options. Otherwise, I agree with you. – Kortuk Oct 30 '12 at 23:30
• If you have a WAV file, you do know the sampling rate. This is in the WAV file header. There is no need to guess. – Olin Lathrop Oct 31 '12 at 0:00
• @Kortuk, Yes, you can look for 60 Hz hum; but OP is asking for a "property of the transform" that will recover the sampling rate. And that simply doesn't exist. 60 Hz hum is not a property of the transform, it's something that might be present in the signal you sampled. – The Photon Oct 31 '12 at 0:16

As some comments have pointed out, there are a couple of practical ways to find out the sampling rate:

• Look for mains hum in the recorded audio, which you'd see as a peak in the FFT response in the frequency bin corresponding to 60 Hz (or maybe 50 Hz).

But it sounds like you're looking for a mathematical property of the FFT that will allow you to back out the sampling frequency. Such a thing doesn't exist.

The only inputs to the FFT are the original sampled data. And this sample data itself has no information about the real sample rate contained in it. So there's no possibility that the spectral result of the FFT can tell you anything about the sample rate.

For example, there is no way to tell the difference between a 10 Hz signal sampled at 100 Sa/s from a 320 MHz signal sampled at 3.2 GSa/s.

In order to know the sample rate you must record it as meta-data, for example in the header of a WAV file.

If I have a .wav file with N datapoints then split into ten N/10 segments and then fft on each segment. But this then means that my sampling frequency is essentially reduced to N/10 Fs?

No, the sample rate is still Fs. But the sample duration has been reduced to N/(10 * Fs).

This means that the spectrum will still cover the same frequency band (0 to Fs*(N-1)/N), but it will cover it in coarser steps. The bins of the DFT will be spaced by 10*Fs/N instead of Fs/N.

"Is there any clever trick in storing the coefficients of a real signal (wav)? "

Yes, there was a variation of the FFT called the Hartley transform that enjoyed modest popularity some years ago, but overall didn't actually save any trouble or clock cycles.

The key was to use a 45-degree shifted sine wave, not cos or sin, in the integral. The shifted sine, if added or subtracted with its mirror image (negative frequency) gave a sine or cosine. This clever fact was exploited to give an all-real spectrum. Another nice property is that the inverse transform was exactly the same as the forward transform, not even a complex conjugate involved.