смотрю в сторону 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:

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