Цитата(Relayer @ Apr 11 2008, 11:33)

будет. но ключевое слово тут "правильно". вы уверены что сможете выбрать предиктор который будет "правилен" в 100% случаев поведения входного сигнала?

))
Ага!
Цитата(Relayer @ Apr 11 2008, 11:33)

...как вы его будете выбирать? из чего?
Поясняешь, поясняешь, и всё как горохом об стенку...
"Выбирать" предиктор из множества кем-то уже за Вас рассчитанных, предлагаете именно Вы. Я же его предлагаю
"строить" адаптивно, что является способом гораздо более точным и удобным как алгоритмически, так и вычислительно. Задаться нужно только структурой такого предиктора, соответствующей априорным сведениям о сигнале, и удобным способом его адаптации.
Впрочем, предсказателями, работающими во временнОй области сигнала, дело не исчерпывается. Можно легко показать, что, вопреки Вашим утверждениям,
можно успешно решить задачу и в фурье-базисе. Однако, реал-тайм ДПФ на таких частотах - весьма напряжённый вычислительно процесс, и поэтому я не стал его здесь рекомендовать.
Цитата(Relayer @ Apr 11 2008, 11:33)

...как говорят у нас в Одессе - "не смешите мои тапочки"

правильно спроектированная система не будет передавать по каналу эти коэффициенты используя технику backward adaptation или будет передавать их крайне редко для больших блоков данных, что однако не исключает backward внутри блока.
У вас в Одессе говорят совершенно правильно.
Backward adaptation даёт хороший результат только в системах, исключающих ошибки при передаче, и поэтому применяется относительно редко. Кроме того я могу предложить Вам вариант предиктора, где "обратная адаптация" не будет работать вовсе.
Для работы с каналом, имеющим ошибки, требуется параметры предсказателя всё-таки передавать, о чём я и писал ранее, и что почему-то у Вас вызвало непонимание. Или реализовывать алгоритм "с забыванием", что ухудшает качество предсказания.
Длина фильтра, как я уже и говорил, ограничивается также точностью представления чисел и вычислительными возможностями системы. Для backward adaptation это такое же препятствие, как и для forward-а.
Однако, это всего лишь
техника адаптации, и не имеет прямого отношения к теме. Речь же идёт о
принципах сжатия сигнала в реал-тайме на основе
конкретных статистических моделей, а размениваться на частности сейчас не хочется.
Цитата(Relayer @ Apr 11 2008, 11:33)

если вам непонятны такие банальные вещи, то у меня создается впечатление что вы мягко говоря "плаваете" в вопросе. идите читайте литературу
Это не ответ на прямо поставленные вопросы, уважаемый.
Для меня они вовсе не банальны, поэтому я их и задал Вам. Более того, перед началом разработки любого реал-тайм компрессора я их задавал и себе также.
Попытка стеба в ответ на корректно заданный вопрос, а также отсылание к некой абстрактной литературе, чаще всего являются признаками не только гипертрофированного самомнения, но также некомпетентности, граничащей со скудоумием.
Цитата(Relayer @ Apr 11 2008, 11:33)

...пока что средство от поноса в голове изобретаете вы. посмотрите тесты архиваторов на различных корпусах. там есть файлы которые жмутся очень хорошо и есть те которые жмутся очень плохо...
Я уже догадался, что беседую с "архивариусом", имеющим весьма поверхностные сведения об обработке сигнала в реалтайме.
Поверьте, эти технологии имеют весьма мало общего, и сравнивать их друг с другом просто некорректно.
Цитата(Relayer @ Apr 11 2008, 11:33)

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

Потому, что о сигнале нам очень многое
априорно известно. В отличие от "файлов", где мы вынуждены оценивать статистику уже в процессе сжатия.
Цитата(Relayer @ Apr 11 2008, 11:33)

...а кто вам сказал что мы потеряем данные? с чего вы себе это выдумали? нам не нужны предикторы на все случаи. они нам нужны на 90-95% случаев. а оставшиеся 5-10% которые мы не описали просто сожмуться хуже. а чтобы небыло потерь - самое простое - буферизация.
М-да...
Хорошо, представьте себе случай, что в сигнале появилась мощная составляющая (напр, помеха), которую Ваш "набор" не способен разрешить (для фильтра 3-4 порядка это просто невозможно).
Ваш буфер будет переполнен за конечное время, и данные в нём будут всё равно потеряны.
Напротив, применив метод, предложенный мной, будем иметь только частичное заполнение буфера, соответствующее времени, необходимому на адаптацию (автоматическую перестройку) предсказателя, после чего эта очередь благополучно рассосётся, без каких-либо потерь информации.
Цитата(Relayer @ Apr 11 2008, 11:33)

...на выходе формировать блоки и сбрасывать их на макс скорости. т.е. максимально эффективно использовать пропускную способность канала.
Способ максимальной эффективности использования пропускной способности канала Вы выбрали прямо-таки революционный, ничего не скажешь.
Цитата(Relayer @ Apr 11 2008, 11:33)

...я то прекрасно понимаю о чем пишу.
Ну, так поясните толком, без кокетства. А то создаётся прямо противоположное ощущение.
Иначе останется только записать очередной "перл" в "цитатник":
Цитата(Relayer @ Apr 11 2008, 01:03)

если он обнаружит аномалию которую мы не учли - он просто ухудшит коэф сжатия. главное тут все разумно спроектировать чтобы это ухудшение не привело к избыточности в выходном потоке.
Цитата(Relayer @ Apr 11 2008, 11:33)

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