Re: Fast Fourier Transform Queries



<alanglloyd@xxxxxxx> wrote in message
news:1137309700.621468.135260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "Hans-Peter Diettrich" <DrDiettrich@xxxxxxxxxxx> wrote in message
news:42u7b2F1jtb11U2@xxxxxxxxxxxxxxxxx
>> Maarten Wiltink schrieb:

>>>>> The file is in GSM format of 65 bytes/block, 320 samples/block.

>>>> 320 samples in 65 bytes? ;-)

>>> Of course. Start with 320 physical, time-domain samples. Transform
>>> to frequency domain. Throw away precision (low-order bits), phase
>>> information, and accuracy (higher harmonics) until you have 65 bytes
>>> left. Transmit, transform back, be annoyed at poor audio quality.
>>> It's not magic, it's compression.

>> I.e. the file does already contain kind of "FFT" data?

> [...] I had already tried doing FFT on the unconverted GSM audio,
> and there was no significant difference between correct and
> corrupted blocks. And there was a fair amount of level in higher
> harmonics, with a fairly smooth envelope. So I would suppose the
> compression algorithm is more complex than Maarten's simple
> description.


It _is_ a simple description of course, more a statement of intent
than a fullfledged algorithm.

The devil is in the details. It might be a DCT instead of an FFT, or
something else still, and anyway if you don't know the exact format,
you can't expect to make anything out of it. The above description
is not that far from JPEG - but it skips differential encoding and
Huffman compression. There may be pre- and postprocessing.

Higher harmonics have a tendency to creep back in. Bandpass filters
aren't perfect and everything that is done in the time domain has
repercussions throughout the frequency spectrum.

Groetjes,
Maarten Wiltink


.