Новости алгоритмов сжатия

[dil]

Граждане, а как это так получается, что MP3 256 кбит/c VBR сжимаются rar'ом? Причём так заметно сжимаются - compression ratio в районе 70%.

Это какие-то такие специальные mp3, или я пропустил великое открытие?

Comments

[lazylonelion.livejournal.com]

???
%)
круто...

[dil.livejournal.com]

Вот: 6.5 MB (http://dil.pp.ru/mp3/strange.rar)

 Name             Size   Packed Ratio  Date   Time     Attr      CRC   Meth Ver
-------------------------------------------------------------------------------
 strange.mp3   9596928  6782534  70% 15-03-08 04:46 -rw-r--r-- 67D42CF6 m5g 2.9
-------------------------------------------------------------------------------
    1          9596928  6782534  70%

[lazylonelion.livejournal.com]

:))
Скоро будут лосслесс-форматы, которые сжимают МР3 в какой-нить МР7, как когда-то РСМ появился после WAV.

[dil.livejournal.com]

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

[dil.livejournal.com]

там частоты выше 18.5 кГц срезаны. фигня какая-то

[grayw.livejournal.com]

не "скоро будут" а "уже есть". SoundSlimmer тот же.

[dil.livejournal.com]

"Current version of SoundSlimmer losslessly compresses Mp3 and Mp3Pro files averaging 20% less file size"

С одной стороны, если я правильно понял их объяснения, они на последнем этапе сжатия аудиоданных вместо кодирования по Хаффману используют какой-то проприетарный алгоритм, якобы, сильно более эффективный. И обещают, что его можно применить и к другим аналогичным случаям - ogg, wma и т.п.

Но при этом оно works with audio data only utilizing certain specifics of digital sound signals. Какая такая специфика аудио остаётся к этому этапу, я не понимаю. А если б это было эффективный алгоритм общего назначения, то его можно было бы применить и к видео в MPEG2/MPEG4, оно в конце точно так же сжимается.

как-то оно.. не то, чтобы фейком попахивает, но некоторое недоверие вызывает

[alec_v.livejournal.com]

Небось техномузыка хорошо жмется, повторений много. :)

[grayw.livejournal.com]

да не фейк это, автор алгоритма (Женя Шелвин) в среде людей занимающихся сжатием данных человек известный и уважаемый, не с руки ему людей обманывать :)

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

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

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

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

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

кстати, есть и безпотерьные "дожиматели" для zip, pdf и jpeg, подход при их создании аналогичный.

[motto.livejournal.com]

ну, много чего бывает
вспомни, как G.729 устроен. На "шпецифик дата" всякое может быть

[dil.livejournal.com]

но в разных алгоритмах сжатия звука методика разложения в спектр разная. значит, для эффективного дожатия надо учитывать особенности не просто звука, а конкретного алогоритма. для mp3 одно, для ogg другое, для wma третье.. для какого-нибудь MPEG2 video - четвёртое, и не сильно сложнее, чем для аудио.