Lossless Audio Comression, Необходимо реализовать Опции

[Iouri]

господа,

Стоит задача взять данные с 8 аудиокодеков 16bit 48KHZ sampling rate сжать без потерь
и передать, на другом конце принять и разжать. Требования:
1. Compression/Decomression должно быть сделано на FPGA
2. Максимальная задержка 1mS
3. Среда передачи Ethernet

Подскажите какой алгоритм лучше использвать, что почитать по теме и все замечания предложения с удовольствием выслушаю
спасибо всем откликнувшимся

всем приятных выходных

[Relayer]

Подскажите какой алгоритм лучше использвать, что почитать по теме и все замечания предложения с удовольствием выслушаю

очень рекомендую посмотреть на TTA codec http://en.wikipedia.org/wiki/TTA_%28codec%29
полностью доступен в сырках. работает быстро и хорошо. мое мнение - это один из лучших открытых алгоритмов lossless audio compression

PS боже упаси вас послушать нашего "теоретика" - lpc прост в теории но имеет свои подводные камни. лучше возьмите какойто готовый алгоритм и реализуйте его - сэкономите массу времени

до 50% - не так уж и плохо для Lossless Audio

50% - это очень даже хорошо. обычно 30-40%

[Stanislav]

очень рекомендую посмотреть на TTA codec http://en.wikipedia.org/wiki/TTA_%28codec%29
полностью доступен в сырках. работает быстро и хорошо. мое мнение - это один из лучших открытых алгоритмов lossless audio compression

Интересно, каким боком данный алгоритм соответствует условиям задачи?

For audio data compression TTA compressor uses a frames with a duration about 1 sec.

PS боже упаси вас послушать нашего "теоретика" - lpc прост в теории но имеет свои подводные камни. лучше возьмите какойто готовый алгоритм и реализуйте его - сэкономите массу времени

1. Вы переходите рамки дозволенного при общении на форуме. Рекомендую перечитать ещё раз его правила.

2. Ваши знания совершенно недостаточны для того, чтобы отличить LPC от не-LPC.
Читаем описание алгоритма TTA:

Below we give the main of methods which have been tested in the TTA compressor constructing activity:

1. Signal approximation with a set of polynomial predictors;
2. Signal modeling by linear prediction method (LPC);
3. Signal modeling with adaptive filters.

The best results have been received by method of signal modeling with adaptive filters.

This method uses IIR (Infinite Impulse Response model) filters, which parameters are changing adoptively during the work process. The base system element is the p-dimensional nonrecursive filter, which in general case is described by the following expression:

(1)

where x'[n] - is a predicted value of the new sample x[n]; v[n,k] - next value of the filter weight coefficients; r - signal delay. Filter weight coefficients are defined by the formulae:

(2)

where m - is an coefficient which defines the filter's adaptation speed; e[n] - next value of output signal (error signal); sgn - sign of the signal [.];

The minimization of the residue e[n] = x[n] − x'[n] can be achieved with a help of various algorithms, such as Widrow-Hoff's least mean square error algorithm (LMS) which is based on statistical approach or recursive least squares algorithm (RLS)

Довожу до Вашего сведения, что сжатие в данном кодеке достигается именно методами линейного предсказания (LPC), о чём явно поведано в описании (см. Формулу 1). Правда, в этом может удостовериться только умеющий читать техническую литературу по-английски.

Сообщение отредактировал vetal - Apr 13 2008, 22:44

[Relayer]

Читаем описание алгоритма TTA

так вот 1сек размер фрейма связан с тем, что формат файлово-ориентированный (что впрочем не мешает его модифицировать в потоковый) и основное требование - возможность позиционирования в произвольное место файла. если мы заглянем в исходники то мы увидим след (я буду комментировать происходящее по версии 3.0 - разница с последними версиями незначительна а код читается лучше):

Код

int compress(FILE *fdin, FILE *fdout) {
    while (fframes--) {
        read_wave(data, byte_size, framelen * (num_chan >> is_float), fdin);
        encoder_init(tta, num_chan, byte_size);
        for (p = data, prev = 0; p < data + framelen * num_chan; p++) {
            // compress stage 1: fixed order 1 prediction
            case 2:    *p -= PREDICTOR1(*last, 5);    break;    // bps 16
            // compress stage 2: adaptive hybrid filter
            hybrid_filter(fst, p, 1);
            value = ENC(*p);
            // encode Rice unsigned
            put_unary(unary);
        }
    }
    // update the seek table

это очень поскипанный код. но суть будет понятна. для каждого фрейма читаем его, инициализируем таблицы накапливающие статистики Rice кодера, для каждого семпла вызываем тривиальный PREDICTOR1:

Код

#define PREDICTOR1(x, k)    ((long)((((uint64)x << k) - x) >> k))

после чего прогоняем через т.н. гибридный фильтр, после чего кодируем райсом и обновляем статистики этого самого райса.
легко заметить следующее:
1. семпл попадает на выход без всяких задержек! т.е. для его кодирования нам необходима только информация о предыдущих семплах, но не о будущих.
2. требование позиционирования = возможность декодировать любой произвольный блок из потока в случайном порядке (radnom access) приводит к тому что мы вынуждены сбрасывать статистики Rice и гибридного фильтра в начале каждого блока. если с фильтром не все так критично, то сброс статистик Rice естественно приводит к ухудшению сжатия. именно поэтому разработчики определили размер фрейма в 1 сек как компромис между ухудшением сжатия и точностью позиционирования при random access
3. никакой допинформации кроме как маркера для позиционирования в файле с фреймом не связывается. для статистик Rice используется backward adaptation - т.е. декодер накапливает эти статистики в процессе декодирования и параметры кода в явном виде передавать не надо.

TTA элементарно преобразовывается в потоковый алгоритм. никаких задержек в 1 сек естественно не будет. понятие фрема зависит от того как мы будем принимать поток. если мы принимаем поток от начала и до конца и канал гарантирует доставку пакетов клиенту без пропусков - тогда можно все передать одним фреймом не сбрасывая статистики. это благоприятно скажется на сжатии. если у нас броадкастинг - т.е. клиент может подключиться в произвольный момент времени - тоже ничего страшного. делаем маркеры с интервалом одна сек, по ним обнуляем статистику. клиент ждет маркера и после его получения (макс 1 сек ожидания) начинает синхронно декодировать поток.

почему это все так важно? дело в том что TTA использует те самые техники в которых наш знайка ни в зуб ногой. а именно Rice и backward adaptation. т.е. декодер синхронно с процессом декодирования набирает статистику которая позволяет ему правильно декодировать коды Rice

Сообщение отредактировал vetal - Apr 17 2008, 20:54