Насчет FFT

После выделения сигнала он обрабатывается с помощью FFT. Сказать легко...
На моем сайте помещены статьи Дмитрия Михайлова по цифровой обработке звука, они помогли мне понять суть метода FFT.
Пример. Пусть, например, у нас есть аудио-данные, сэмплированные в 44.1 кГц, и мы, взяв 8 значений (отдельных отсчетов), хотим получить частотное разложение этого участка. В результате у нас получится 5 пар коэффициентов - 4 синусоиды с частотами 22.05 кГц, 16.5 кГц, 11.025 кГц, 5.51 кГц, и синусоида с частотой
0 кГц - то есть константа.
На изменении этих коэффициентов основана работа цифровых эквалайзеров, но это так, к сведению.
Короче, мы получили определенную частотную сетку. Но ведь сигнал после его выделения будет иметь разную длину - значит изменится и шаг частотной сетки.
Михайлов предлагает следующее решение: просто дополнить сигнал нулями до 64 КБ и обработать FFT. В результате получим тот же спектр (амплитуда немного пострадает и фаза будет не очень, но она нам и не нужна). Он говорит, что
искажение амплитуды можно исправить - постараюсь узнать как.

FFT - версия CTA
Надо перевести алгоритм FFT приведенный в журнале CTA (http://www.cta.ru) в целочисленный вид. Это, понятно, ускорит обработку. Но еще в те времена когда я знал только ассемблер (было и такое) я не мог найти описание того, как народ использует 32-х разрядные регистры новых по тем временам процессоров для работы с фиксированной точкой.
Требуется разъяснение...

re: FFT - версия CTA
Фиксированная точка - это сугубо на ваше усмотрение. Сколько хотите знаков после запятой, столько и делаете. Например в 3D рисовалках перевод числа в фиксированный вид делается непосредственно перед операцией ( умножения и т.п.), результат сразу же переводят обратно в нормальный вид.
Перед работой все вещественные числа умножаются допустим на 1000(лучше степень двойки) и делаются целыми. А после - делятся на 1000.И всё. Главное чтобы не возникало потери точности и переполнений.
С ассемблером я поступал так:
Так как ассемблером занимаюсь очень редко, то он в голове не держится. Писал маленькую подпрограмму на C, где расписывал то, что хочу получить. Компиллировал, получал ассемблеровский код, который правил и вставлял в уже оптимизированную подпрограмму или просто весь вставлял в проект.

Убыстрить с сохранением точности не получается.
Появление во внутреннем цикле операций перевода из целых в вещественные или обратно существенно увеличивают время. При лобовой замене операций на целые существенного выигрыша не происходит. Наблюдаемый максимум уменьшения времени всего 2 раза. Да и то, если не беспокоиться о достоверности результата. Исходный код при работе с вещественными числами, при включении оптимизации по скорости, очень удачно использует параллелелизм вещественных и целых операций. На Celeron-300A 16килобайт переваривает за 70-100 мсек. Надо подумать.

Если я правильно понял...
Если ты смотрел сообщение о TWave, то там видно, что я работаю только с short int (в основном).
Если я понял все правильно, то в конструкторах надо сразу переводить все на float.
Например так:
// header
float *Buffer;
// cpp
__fastcall TWave::TWave(short* buf, DWORD size)
{
// size в байтах
Buffer = (float *) GlobalAlloc(GPTR, size);
for (int i=0; i<(size/sizeof(short); i++)
Buffer[i] = (float) buf[i];
}

Лучше иметь дополнительный буфер float.