господа,

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

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

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

Прикольно Буферизация не более 48 значений (это в идеале), а в реале наверно 32 в лучшем случае.

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

Дык, требования к сжималке неплохо было бы ещё огласить. Битрейт постоянный/переменный, его величина, и т.д.

Навскидку - адаптивная дельта-модуляция (ADPCM), один из самых простых алгоритмов, работающих при малой длине буфера, но и сжатие получается небольшое. После первого знакомства с ней, можно побить сигнал на полосы, и к каждой попробовать прикрутить "свою" ADPCM, причём битрейт в полосах получится разный. Реализация этого алгоритма также очень проста, а компрессия - побольше.
Далее, что-нибудь вроде LD-LP, типа, как в стандарте G728. Сжималка там с потерями, но принцип построения линейного предсказателя можно взять на вооружение и для lossless компрессора. Этот метод посложнее будет, конечно. Разбивка сигнала на полосы также может оказаться полезной.
Ну, и гугль ещё никто не отменял. " сжатие аудио без потерь " и " "low delay audio" " дают море информации. Выбирайте на любой вкус.



И что же здесь Вы усматриваете прикольного?

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

я бы посмотрел в сторону таких специализированных форматов как FLAC, в основе которых опять же - линейное предсказание + RLE.

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

В любом случае, "степень сжатия" для lossless получится небольшой. Вероятно, гораздо меньшей, чем того бы хотелось автору темы...

А стОит ли сжимать?
Битрейт для ваших 8 аудиокодеков с 16bit 48KHZ sampling rate будет равен 6,144 Мбит/с.
Если стерео, то 12,288 Мбит/с, - вполне проходит через 100Mb Ethernet.

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

Я бы сказал - отлично.
Однако, при столь малой длине буфера получить такой результат весьма сложно (если вообще возможно). Во всяком случае, хорошо проверенными методами линейного предсказания не отделаться... Вероятно, придётся городить компрессор, использующий статистики более высоких порядков, что весьма затруднительно реализовать на FPGA.

Естественно, речь идёт о постоянной битовой скорости.

Приличным результатом при зажержке в 1 мс я бы признал к-т компрессии 0,75; очень хорошим - 0,66 (2/3).
А 0,5 - просто выдающимся.

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

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



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

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

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



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

Пожалуйста, предложите алгоритм, который будет "обычно" жать без потерь на 30-40% при задержке сигнала в 1 мс.
Иначе всё написанное Вами следует воспринимать не иначе, как словесный спам.

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

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



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



после чего прогоняем через т.н. гибридный фильтр, после чего кодируем райсом и обновляем статистики этого самого райса.
легко заметить следующее:
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

Интересно, а какой смысл тогда заключён в этой сентенции:?
Прошу ответить. Настаиваю, чтобы Вы пояснили, что в данной теме мной написано неправильно, и какое моё утверждение Вы опровергли данным заявлением?
Об остальном - после.

Тема почищена. Общайтесь без оскорблений и перехода на личности!

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

так что остального и после - не будет. вначале закончим с ТТА



вы согласны с тем что здесь написали полную чушь? алгоритм вполне соответствует задаче. со структурой алгоритма вы не знакомы, иначе бы такое не написали. а учитывая что ТТА появился в public domain не вчера, а в начале 2000х и то, что открытых lossless audio compression алгоритмов можно по пальцам руки пересчитать мне очень странно что вы о нем не слышали ... профессионалу такое непростительно. хотя конечно если ваши познания о методах сжатия носят ознакомительно-поверхностный характер - я не в претензии. вот только зачем вводить в заблуждение окружающих ?

Сообщение отредактировал Relayer - Apr 14 2008, 20:57