Спасибо за ссылочку. Хотя, я в принципе представляю влияние джиттера на качество оцифровки. Вот я и хотел обратить внимание человека, на то, что нужно ли ему действительно передавать все 16 бит. Для того чтобы обеспечить такую точность, джиттер должен быть не более 4e-14. Такой генератор, чтобы установить его на PCI плату, и чтобы он при этом правильно работал....

Приветствую!

почитал тему - местами было смешно, местами грустно. советов надавали ... вот разве что толку то от них.
теперь по существу. тык сюда http://www.compression.ru/ - там много вкусного.
забудьте про всякие фурье-шмурье, опенсорсные вавпаки и прочую муру. грубо на пальцах всякие аналоговые сигналы жмутся (без потерь) след образом - строим "предсказатель" который пытается предсказать след значение на основании уже имеющихся, кодируем ошибку предсказания переменным кол-вом бит. все остальное частности и от лукавого. предсказатель может быть какой угодно. к примеру как линейная функция N последних значений.

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

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


я бы даже сказал несоизмеримых с дпф затратах. вообще дпф подходит для lossy compression. т.е. с потерями. а для lossless оно практически не применимо. дето попадалась мне разработка lossless audio компрессора с дпф - ничего особенного в плане прироста сжатия я там не обнаружил. еще как вариант строить вейвлеты и работать с ними, но опять же не подходит по причине недостаточной скорострельности.
а для текущей задачи самое простое - тривиальный линейный предсказатель на основе двух-трех последних отсчетов. в офлайне прогнать через него, посмотреть на результат. построить для распределения полученной ошибки оптимальный хафман. и все сожмется тем более что за заоблачными параметрами никто не гонится
а кому не нравится хафман есть еще коды Golomb, Rice, Элиаса, пунктирный ... вобщем их как собак нерезанных

Сообщение отредактировал Relayer - Apr 10 2008, 15:55

Что? Опять двадцать пять?
Послушайте, но это уже слишком...
Кто Вам сказал, что png вообще способен сжать этот поток данных в реалтайме до нужного уровня?
Кроме того, выбор элементов из некого конечного множества по определённым критериям - это уже адаптация.

Тяжёлый случай... А я-то думал: вот человек хоть что-то понимающий нашёлся. Ан нет - дует в тую же дуду, бездумно и безсмысленно...

Скажите, а Вы поняли, что вообще за сигналы изображены на спектре (спектрограмме)?
Каким образом Вы собираетесь их прогонять в оффлайне?
И много ли Вы напредсказываете с помощью двух-трёх последних отсчётов?
Рекомендую почитать тему с самого начала, на этот раз внимательно.

Да уж...

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

ЗЫ. Жаль не поэкспериментировать без реального сигнала. Поэтому разобраться кто прав, а кто нет не получается.

Я, конечно, понимаю, как страшно Вы далеки от осознания того факта, что построение адаптивного фильтра-предсказателя является ничем иным, как параметрическим представлением сигнала (или его спектрального пакета). Параметрами, в данном случае, выступают коэффициенты такого фильтра.

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

Пожалуйста, прежде, чем писать очередной пост, подумайте об этом.

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


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


сигнал как сигнал. мне приходилось работать и с худшими вариантами


сделать несколько контрольных выборок большого размера (на харде). построить несколько предсказателей. посмотреть на распределение ошибки предсказания. выбрать оптимальное кодирование для ошибки


увеличение "длины" предсказателя не всегда ведет к улучшению предсказания а вот выч.затраты возрастают. с нейросетями в качестве предсказателей не работали? а я вот пробовал.


в теме информативные две первые страницы. остальное я не читал т.к. это "белый шум"


уж да. я обратил внимание на то как вы аккуратно пропустили коды райса и голомба и сразу опустились до поливания меня свеженьким гуаном. если вы не в курсе что это такое - расширьте свой кругозор:
http://en.wikipedia.org/wiki/Universal_cod...ta_compression)
http://technomag.edu.ru/doc/60606.html
http://www.firstpr.com.au/audiocomp/lossless/TechRep137.pdf

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

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

От Вас, собственно, это и не требуется - просто воздержитесь от необдуманных советов, и только.
Мне кажется, однако, что Вы не совсем хорошо понимаете термины "стационарность" и "статистика сигнала". Так вот, для данного радиосигнала и для изображения звёздного неба они суть совершенно разные вещи - статистика приведённого сигнала кардинально отличается от статистики сигнала изображения звёздного неба, которое, к тому же, является в высшей степени стационарным, чего не скажешь о сигнале на спектрограмме. Поэтому, методы сжатия без потерь также должны различаться кардинально.
Хвалится своими прошлыми заслугами как-то не принято - лучше писать по существу. Вот если бы Вы пояснили, почему вэйвлет-сжатие без потерь является для данного конкретного сигнала оптимальным (в каком хотите смысле), это было бы действительно интересно.

Что значит "худшими"?

ЗЫ. Скажите, а что Вы вообще знаете о сигнале, с которым работает Автор темы?

1. Зачем лезть на хард, если это легко сделать и в реалтайме, даже не имея большого буфера сигнала?
2. Сигнал Автора темы нестационарен (могу пояснить, почему ). При изменении его статистики, что будете делать? Пока полезете на винт, пока перенастроите фильтр, данные будут безвозвратно потеряны из-за недостаточной пропускной способности канала. Вот таких "решений" и боятся "товарищи учёные".

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

Отчего же, работал.

Ну, и как впечатления?

Какой кошмар...

Сообщение отредактировал Stanislav - Apr 11 2008, 06:13

а какже особенно когда предиктор выбран некорректно и не соответствует поведению сигнала берем полином высокой степени и получаем среднепотолочное от кофейной гущи



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

Ну, это смотря кто будет "выбирать предиктор". На вэйвлетах с дельтами, нейросетях и прочих png, как предлагают тут некоторые безответственные личности, швах получится точно.
Я могу Вам строго доказать, что для реального стохастического сигнала увеличение длины "правильно" выбранного предиктора будет уменьшать мощность ошибки предсказания. Если сигнал не стационарен, предиктор должен быть адаптируемым в "процессе".
На практике, однако, длину адаптивного предсказателя ограничивают - передача его к-тов тоже создаёт трафик, который с определённого момента приводит только к увеличению объёма передаваемых данных. Кроме того, вычисление к-тов очень длинных предсказателей в системах с ограниченной разрядностью данных сопряжено с трудностями, связанными с точностью представления чисел.

ЗЫ. А-а, кажись, понял. Вы предлагаете коэффициенты предикторов выбирать методом проб и ошибок, верно?

1. Скажите, каким именно способом Вы предлагаете строить "простые предикторы"?
2. Каким образом Вы предлагаете оценивать распределение ошибки?
3. Что подразумевается под термином "оптимальное кодирование"?

Что значит "в большинстве случаев"? А гарантии где?
Опять попытка изобрести универсальное средство от головы и от поноса...

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

Простите, Вы хоть сами поняли, что написали?
Имея такие представления, писать о "разумном проектировании" просто смешно...

даааааааааа.......
много слов я ещё в жизни не слышал

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

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



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



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



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



а кто вам сказал что мы потеряем данные? с чего вы себе это выдумали? нам не нужны предикторы на все случаи. они нам нужны на 90-95% случаев. а оставшиеся 5-10% которые мы не описали просто сожмуться хуже. а чтобы небыло потерь - самое простое - буферизация. на выходе формировать блоки и сбрасывать их на макс скорости. т.е. максимально эффективно использовать пропускную способность канала.



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

Ага!

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

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

Это не ответ на прямо поставленные вопросы, уважаемый.
Для меня они вовсе не банальны, поэтому я их и задал Вам. Более того, перед началом разработки любого реал-тайм компрессора я их задавал и себе также.
Попытка стеба в ответ на корректно заданный вопрос, а также отсылание к некой абстрактной литературе, чаще всего являются признаками не только гипертрофированного самомнения, но также некомпетентности, граничащей со скудоумием.

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

Почему же, можем. Потому, что о сигнале нам очень многое априорно известно. В отличие от "файлов", где мы вынуждены оценивать статистику уже в процессе сжатия.

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

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

Ну, так поясните толком, без кокетства. А то создаётся прямо противоположное ощущение.
Иначе останется только записать очередной "перл" в "цитатник":

"С выхлопом" - умри, лучше не придумаешь.

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



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



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



ну насмешили так насмешили у нас канал передачи с потерями? PCI-шина теряет информацию?! это чтото новенькое. backward adaptation применяется сплошь да рядом, а для исправления ошибок в канале прменяются совершенно другие методы



"панты" пожалуйста в другом месте



сомневаюсь



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



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



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