господа,

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

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

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

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

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

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



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

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

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

так вот 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

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

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

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

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



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

смотрю в сторону FLAC и ADPCM, если можно скиньте информацию по TTA, а что то не могу найти.
Еще раз всем огромное спасибо

http://www.true-audio.com/TTA_Lossless_Aud...udio_Compressor

Господа,


посмотрел ITA действтельно там сказано, что размер буфера 1sec. К сожелению я не нашел достаточно информации касающейся непосрестено реализации алгоритма. Не могли вы посоветовать литературу, линки где непосредственно описан математический апарат алгоритма.

заранее благодарен

значит невнимательно смотрели. почитайте мой пост по этому вопросу. нет там никаких буферов в 1 сек. и небыло никогда.



щаз пойду стреляться по ссылке из пред поста жмем download вверху страницы и скачиваем исходники кодека на C. ну и анализируем их - делов то. а детального описания всех фаз работы этого кодека мне не попадалось. до некоторого времени его вообще никакого небыло - одни общие слова.

Уважаемый, Вы не ответили на прямо поставленный вопрос. А именно: к чему была написана данная фраза?
Мой опыт не сравним с Вашим; по части знания предмета мы находимся, если можно так выразиться, в разных "весовых категориях". Однако, это не является поводом для самоутверждения и ничем не спровоцированного хамства.

2 Iouri
Вопреки опубликованным здесь пожеланиям, дам Вам свой совет: если хотите сделать действительно стОящую вещь, не пытайтесь с ходу прикрутить к "железу" уже готовое решение, а постарайтесь разобраться в принципах построения таких систем, для чего я и посоветовал хорошенько погуглить. Это позволит получить понимание, что именно Вам нужно, и на какой результат стоит рассчитывать, исходя из текущих достижений других разработчиков. Ну, и сформулировать требования к системе сжатия, или чего-либо другого (насколько я понимаю, с параметрами сжималки вы пока ещё не определились).
Потом всё нужно тщательно отмоделировать, тут уж без Матлаба или чего-нить подобного не обойтись.
Ну, и, наконец, реализация алгоритма "в железе".

ЗЫ. Под алгоритмом я понимаю не картинку с квадратиками и стрелочками, и не "кусок программного кода", а страничку математических формул (желательно, в векторном виде ).
ЗЗЫ. И ещё: универсальные методы не оптимальны. Ни в каком смысле, кроме быстроты реализации и количества горьких разочарований..

ради ужимания на четвёртую часть ставить FPGA смешно - тем более, как правильно уже сказали, скорость сетки позволяет.

тем более, что наиболее вероятно, если дунуть в микрофон кодек может заткнуться.

С чего бы это?

Я могу ошибаться (не разбирался в коде) но алгоритм передачи данных мог бы быть простым. Например в начале сигнала идёт маркер начала несжатых данных. Далее передаются 16-бит сэмплы совсем без сжатия. Потом кодек решает когда уже можно переключиться на сжатый формат и передаёт другой маркер. Как раньше так и теперь новые сэмплы передаются без задержек, только не в 16, а в 10 битном формате например. Собственно разных типов маркеров может быть много и в рилтайме кодек выбирает какой формат данных ему удобнее. Вобщем это моя "отсебятина", то есть как вариант создания кодека, "восстановленный" со слов Relayer-a.

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

to Stanislav:

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