FFT of audio, packet sampling and others

Question

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.

Answer 1

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

• Read the sampling rate information from the WAV file header

• 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 F_s. But the sample duration has been reduced to N/(10 * F_s).

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

Answer 2

"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.