В своё время MP3 совершил революцию в распространении музыки. Больше не нужно было покупать дорогие компакт-диски. Достаточно поставить на ночь загрузку из «Напстера» — и к утру у тебя несколько файлов MP3, которые можно слушать совершенно бесплатно! Любые исполнители и альбомы. Это было невероятно.
Но сейчас времена изменились. Файлы скачиваются за секунды, а место на диске измеряется терабайтами. Нет смысла подвергать музыку калечащему сжатию с потерей информации. Можно спокойно скачивать и хранить её в lossless-форматах, причём со значительным сжатием.
Есть ряд lossless-кодеков, которые эффективнее .FLAC по степени сжатия.
Немного истории lossless-кодеков
До 2000 года большинство lossless-кодеков были асимметричными, то есть увеличивали нагрузку на CPU при увеличении степени сжатия, однако это практически никак не сказывалось на скорости декодирования.
К началу 21 века среди специалистов распространилось мнение, что для максимального сжатия нужно использовать сложный симметричный алгоритм. Такие алгоритмы требуют больших вычислительных ресурсов CPU при декодировании звука. Первым компрессором, который значительно превзошёл FLAC по степени сжатия файлов, стал Monkey's Audio (форматы .APE и .MAC) в 2000 году.
Компрессор Monkey's Audio
Затем вышел ещё более сложный проприетарный кодек OptimFROG, который превосходит остальных в своих самых тяжёлых режимах сжатия.
Симметричный алгоритм реализован и в кодеке WavPack конца 90-х, который позже был доработан и усовершенствован.
Затем появился TAK, который обозначен зелёным цветом на следующей диаграмме.
Сравнение производительности lossless-кодеков на материале CD-качества:
Аудиофайлы PCM с битовой глубиной 16 бит и частотой дискретизации 44,1 кГц, источник
WavPack, а затем OptimFROG реализовали дополнительную обработку кодирования, которая минимально влияет на скорость декодирования. В то же время FLAC был значительно усовершенствован. Эталонный кодер работает с произвольными коэффициентами LPC (линейное предсказательное кодирование) по принципу грубой оценки нескольких альтернатив (например, длины истории), затем выбирает лучшую и вычисляет её до конца.
Сравнение производительности lossless-кодеков на материале высокого качества:
Аудиофайлы PCM с битовой глубиной 16−24 бит и частотой дискретизации 96−352,8 кГц, источник
На высокой частоте дискретизации звуковая информация включает множество странных вещей, включая пустоты. Эталонный FLAC не всегда хорошо справляется с этой задачей. Практически все остальные кодеки используют те же коды Голомба, но пытаются оптимизировать их реализацию.
Сравнение производительности lossless-кодеков на многоканальном звуке:
Аудиофайлы PCM с более чем двумя каналами, преимущественно 5.1, включая один низкочастотный (LFE) и два канала объёмного звучания (surround), источник
Конвертацию любых форматов друг в друга можно осуществлять с помощью программы ffmpeg. Недавно её портировали на wasm, так что конвертацию удобно делать в браузере: локально своём компьютере или на сервере. Вот пример такого сервера:
Проект опенсорсный, то есть его легко захостить у себя.
Быстрый кодек HALAC
Один из новых losless-кодеков — HALAC (High Availability Lossless Audio Compression) от автора кодека изображений с похожим названием HALIC (High Availability Lossless Image Compression).
HALAC обладает примерно теми же качествами, что и его «брат» для изображений: фокусируется в первую очередь на высокой скорости кодирования при сохранении достойного уровня сжатия. Приоритеты расставлены таким образом, потому что в lossless-кодировании коэффициент сжатия обычно ограничен. Тут нельзя уменьшить файл в десятки раз, как в MP3, так что оптимизация по размеру — не самая благодарная задача. А вот оптимизация по скорости — другое дело. Она позволяет ускорить процесс в несколько раз, по сравнению со стандартными кодеками WavPack и FLAC.
В таблицах ниже сравнивается результат кодирования оригинальных аудиофайлов разными кодеками без сжатия: ALAC, WavPack с разными шаблонами кодирования (Fast и Normal), FLAC с разными шаблонами кодирования (Fast (0) и Default (5)) — и HALAC версии 0.1.9, это самая первая версия от декабря 2023 года.
Особого внимания заслуживают две нижних строки в каждой таблице: время кодирования и время декодирования.
Тестовая машина старой конфигурации: процессор Core i7 3770k, 3,9 ГГц, 16 ГБ RAM, 256 ГБ SSD.
Для объективности в бенчмарках подобрали музыку разных жанров. Все кодеки работали на исходном материале .wav, 16 бит, 2 канала, 44100 bps).
За полтора года вышел десяток обновлений, а степень сжатия улучшилась примерно на 2%.
Windows-бинарники:
- HALAC_ENCODE_V.0.3.8_x64.exe (70,5 КБ)
- HALAC_DECODE_V.0.3.8_x64.exe (65,5 КБ)
Linux-бинарники:
- HALAC_ENCODE_V.0.3.8_x64_Linux_Static (2,12 МБ)
- HALAC_DECODE_V.0.3.8_x64_Linux_Static (2,11 МБ)
Их можно скачать — и проверить результаты на своём компьютере. Например, альтернативные бенчмарки версии 0.1.9 с разными настройками FLAC показали следующие результаты.
Кодирование:
10,1 сек для flac -0r0 --no-md5 --totally-silent 10,4 сек для HALAC 11,0 сек для flac -1 --no-md5 14,4 сек для flac -0 16,1 сек для TAK -p0
Декодирование:
13,8 для HALAC 16,6 для flac в режиме <code>-0r0 --no-md5</code> 18,5 для TAK -p0
Коэффициент сжатия тоже достойный, вот сравнение итогового размера файлов:
13 360 205 283 байт для FLAC -0r0 12 772 828 991 для FLAC -1 12 393 304 500 для HALAC 12 032 168 423 для FLAC -5
Здесь HALAC сравнивается с самым быстрым вариантом FLAC без проверки хэшей
--no-md5. По умолчанию flac.exe вычисляет хэш MD5 на всех шаблонах, если не указать эту «недокументированную» опцию. Тестирование проводилось на четырёх музыкальных альбомах, машина Core i5-1135-G7, версия FLAC 1.4.3 win32.Разработана ещё отдельная экспериментальная версия HALAC+ с увеличенной степенью сжатия на уровне FLAC -8, а скорость кодирования примерно вчетверо выше. В этом кодеке реализован алгоритм адаптивных кодов Райса (Adaptive Rice Coding) и простая коррекция ошибок.
Кодеки вроде HALAC привлекают внимание не столько из-за своей практической пользы, сколько их академического интереса: как улучшить показатели сжатия и за счёт каких алгоритмов/методов (об этом ниже).
Теоретически, HALAC можно использовать ещё и как оригинальный способ обфускации/шифрования аудиофайлов в неизвестный формат. Насчёт «неизвестного» не преувеличение: за год с момента официального анонса на форуме HydrogenAudio кодер и декодер скачали 490 и 463 раза, соответственно, а последнюю версию — 198 и 169 раз.
Как видно по бенчмаркам, время кодирования и время декодирования у HALAC в несколько раз меньше, чем у всех остальных форматов lossless-сжатия. Дело в том, что в нём используется энтропийные кодеры Asymmetric Numeral Systems (ANS) и Finite State Entropy (FSE).
Новый метод энтропийного кодирования — ANS
Энтропийное кодирование — это метод lossless-сжатия данных с помощью усреднения вероятностей появления элементов в закодированной последовательности.
Согласно теореме Шеннона об источнике шифрования, существует предел сжатия без потерь, зависящий от энтропии источника. Чем более предсказуемы получаемые данные, тем лучше их можно сжать. Случайная независимая равновероятная последовательность сжатию без потерь не поддаётся.
Два самых популярных метода энтропийного кодирования — код Хаффмана и арифметическое кодирование, они используются практически во всех кодеках, архиваторах и т. д.
Кодирование сообщения «WIKI» с помощью арифметического кодирования:
1. Вычисляется встречаемость букв.источник
2. Интервалразбивается на части в соответствии с соотношением встречаемостей.
3−5. Соответствующий интервал итеративно разбивается для каждой буквы в сообщении.
6. Для представления сообщения выбирается любое значение в конечном интервале.
2*−6*. Пример работы алгоритма для сообщения «KIWI».
Ниже результат арифметического кодирования слов WIKI и KIWI в виде круговой диаграммы. Две красные линии представляют значения, соответствующие этим уникальным последовательностям, всё остальное совпадает:
В отличие от кода Хаффмана, арифметическое кодирование не имеет жёсткого постоянного соответствия входных символов группам битов выходного потока. Это даёт алгоритму большую гибкость в представлении дробных частот встречаемости символов. Таким образом, арифметическое кодирование обычно эффективнее кода Хаффмана, но с ним есть проблема: у некоторых версий патентные ограничения от компании IBM.
ANS — новый метод энтропийного кодирования, который в 2006 году создал польский учёный и программист Ярек Дуда из Ягеллонского университета. ANS по степени сжатия даёт примерно столь же хорошее приближение к оптимальному энтропийному кодированию, как и арифметическое кодирование, но обладает более высоким быстродействием.
Он не уступает по скорости распаковки алгоритмам Хаффмана, не защищён патентами и свободен к использованию. Целью было именно создание свободной альтернативы арифметическому кодированию.
Благодаря свободной лицензии и высокой эффективности примерно с 2014 года ANS нашёл распространение в опенсорсных программных проектах, в том числе:
- компрессор Facebook Zstandard (также используется в ядре Linux),
- браузер Google Chrome (с версии 123, вышла в марте 2024-го года),
- операционная система Android (с версии Android 4.14 в январе 2024-го), опубликован как RFC 8478 для MIME и HTTP,
- компрессор Apple LZFSE,
- библиотека сжатия Google Draco 3D (используется Pixar и др.),
- алгоритм сжатия изображений PIK;
- библиотека высокоскоростного сжатия Nvidia nvCOMP,
- алгоритм сжатия Dropbox DivANS,
- алгоритм сжатия изображений JPEG XL.
ANS показал себя как эффективная альтернатива арифметическому сжатию. Он используется в некоторых современных ОС и браузерах, а также форматах сжатия изображений. В то же время до сих пор ни разу не находил применение в форматах сжатия звука.
Большинство из них использует коды Голомба, известное семейство энтропийных кодов. Но в тестах коды Голомба выполняют кодирование примерно на 30−40% медленнее из-за расчёта адаптивного параметра
, давая лишь мизерную прибавку в степени сжатия (1−2%).Вероятно, HALAC стал первым аудиоформатом, который использует ANS для lossless-кодирования. Результаты бенчмарков показывают, что по производительности он явно превосходит ALAC, WavPack и FLAC, хотя разработчик даже не уверен, что применил ANS наиболее эффективным способом… Кодек HALAC не использует никакие оптимизации для GPU и SIMD, а текущая версия однопоточная. В будущем он в первую очередь планирует добавить параллелизм.
HALAC в 3−5 раз быстрее обычного FLAC. Можно предположить, что другие lossless-кодеки будущих поколений тоже реализуют методы сжатия ANS, за счёт чего смогут кардинально увеличить производительность.
© 2025 ООО «МТ ФИНАНС»
Telegram-канал со скидками, розыгрышами призов и новостями IT 💻
