khotckevichПринципиальная разница между АРЕ и МР3, что АРЕ - lossless (без потерь), a MP3 - lossy ( с потерями) , поэтому делать из из МР3 АРЕ, примерно тоже самое, что из
амлета пытаться склеить целое яйцо , оно может и получится, но ципленок из него не вылупится :diablo:
Вот немного теории по теме:
С потерями:
http://websound.ru/index.cgi?articles/theory/earcomprБэз потерь:
Алгоритмы lossy- и lossless-компрессии (с потерей и без потери качества соответственно) принципиально отличаются друг от друга. Если lossy-алгоритмы после FFT работают с привычными для нас звуковыми волнами, то все lossless-кодировщики понятия не имеют о том, что длинный набор чисел на входе может быть представлен в виде волны с амплитудой и периодом. Их задача — исключительно математическими методами упаковать информацию поплотнее так, чтобы она могла быть в точности восстановлена впоследствии. Во многом алгоритмы lossless-сжатия схожи с алгоритмами обычных архиваторов. Но архиваторы ориентированы на сжатие любой информации, lossless-кодеки же обладают некоторой спецификой, которая позволяет им лучше справляться со своей прямой задачей — компрессией звука. Кроме того, при декодировании (проигрывании) сжатого звукового файла требуется возможность быстрой перемотки. Закодированный файл должен быть разделен на сравнительно короткие промежутки, каждый из которых сжимается независимо от остальных. Архиваторы же могут позволить себе работу с непрерывными архивами, дающими лучшее сжатие.
В Сети есть несколько разных форматов хранения звука без потери качества. Самым популярным их них является Monkey’s Audio Compression1 (MAC, www.monkeysaudio.com). Он обеспечивает lossless-сжатие аудиоинформации в среднем в 1,5–2 раза. Этот алгоритм состоит из трех основных этапов кодирования. Только один из них базируется на использовании природных свойств звука, позволяющих представлять закодированный сигнал в более удобной для компрессии форме. На двух оставшихся этапах используются методы сжатия, в принципе применимые для информации любой природы.
Этап первый: замена переменных2
В исходной некомпрессированной записи информация об амплитуде волны левого и правого канала сохраняется с определенной частотой дискретизации и записывается подряд. Вот как выглядит секунда звука обыкновенного Audio CD: LR LR … LR LR (44100 сэмплов LR), где L и R — 16-битные числа, характеризующие амплитуду волны в левом и правом канале соответственно.
Часто в музыке сигналы левого и правого канала очень похожи. Этим грех не воспользоваться. На первом этапе алгоритм MAC преобразует исходную информацию (числа L и R в каждом сэмпле) по такому принципу: X = (L + R)/2 и Y = (L - R), где X и Y — новые переменные, с которыми алгоритм и будет работать в дальнейшем. Легко видеть, что исходные значения L и R легко восстановимы из X и Y преобразованием: R = X - Y/2 и L = X + Y/2.
Один из эффектов этого преобразования очевиден. Если разница между левым и правым каналом незначительна или постоянна или ее нет вовсе, то после преобразования «игреки» будут соответственно или приближены к нулю, или все одинаковы, или равны 03. В любом из этих случаев дальнейшее сжатие «игреков» пойдет веселей.
Информация о звуковом сигнале преобразована в удобный для компрессирования вид, и теперь алгоритм MAC работает с новыми переменными X и Y.
Этап второй: мультипроходный предсказатель
На этом этапе исключается избыточность информации. Именно реализацией этой части алгоритма и отличаются различные алгоритмы lossless-сжатия.
Задача предсказателя — по возможности минимизировать значения «иксов» и «игреков». Проще всего описать работу предсказателя на упрощенном примере. Пусть дана последовательность значений X (8, 24, 45) и некоторая формула, позволяющая рассчитать опорное значение PX по двум предыдущим значениям X: PX = (2 x X-1) - X-2, где X-2 и X-1 — два предыдущих значения Х.
Рассчитаем опорное значение РХ для последнего значения нашей последовательности: PX = (2 x 24) - 8 = 40.
Теперь вместо последнего значения, запишем в нашу последовательность разность между реальным и опорным значением: (8, 24, 45 – 40 = 5) Число 5 ввиду своей более низкой двоичной разрядности на заключительном этапе будет кодироваться лучше, чем 45.
Большая часть хороших кодировщиков адаптивна, то есть может приспосабливаться к кодированию конкретной информации. Для адаптации, естественно, требуется мультипроходное кодирование. При каждом следующем проходе кодек учитывает результаты предыдущего прохода и улучшает адаптацию. Результат компрессии тем выше, чем больше сделано проходов. Вот («на пальцах») как это реализовано в алгоритме MAC. Возьмем параметр m, варьирующийся от 1 до 1024 и по умолчанию равный 512. Он будет служить «адаптатором». Для расчета последнего значения Xf последовательности воспользуемся такой формулой: Xf = X0 - PX х m/1024 = 45 - 40 х 512/1024 = 25.
Результат не очень впечатляет — 25 всего лишь на один двоичный порядок меньше 45. При следующем проходе алгоритм увеличит значение m.
Финальная степень компрессии зависит от того, насколько удачно выбраны изначальные формулы для расчета PX, а также от количества совершенных при компрессии проходов.
Описанный пример ни в коей мере не иллюстрируют реальную работу алгоритма MAC, а лишь описывает принцип его действия. В приведенном тривиальном примере экономия объема от применения преобразований не очень заметна, однако в действительности устройство кодека более сложное и детальное, он оперирует со значительно бо,льшими объемами информации, по сравнению с которыми служебная информация вроде величины m и рамок его изменений становится пренебрежимо мала.
Этап третий: финальное сжатие
На заключительном этапе происходит обыкновенное сжатие данных, похожее на алгоритмы стандартных архиваторов. Предположим, что перед алгоритмом возникла задача сжать последовательно четыре числа: 10, 14, 15 и 46. Так как разрядность оцифрованного звука — 16 бит, в некомпрессированном двоичном виде эти числа будут записаны как 0000000000001010, 0000000000001110, 0000000000001111 и 0000000000101110 и в сумме займут 8 байт, или 64 бита. Удалив лишние нули в начала каждого числа, запишем их подряд: 101011101111101110. В таком виде они занимают 18 бит. Именно так, к сожалению, получившиеся числа хранить нельзя, поскольку потеряна информация о том, где заканчивается одно число и начинается другое. Сохранить ее можно с небольшим увеличением объема.
Из имеющихся четырех чисел минимальная двоичная длина числа составляет четыре бита (в числах 10, 14 и 15). Запомним это число как переменную k. Она обозначает длину числа по умолчанию. С учетом сохраненного значения переменной k первые три числа можно записать подряд: 101011101111. Теперь осталось закодировать только последнее число, 46 (в двоичном коде 101110). Отбросим справа k = 4 бит. Оставшиеся два бита переполнения (10) в десятичной системе исчисления составляют 2. Теперь запишем число 46 в следующей форме: сначала нулями (то есть «одноично») коэффициент переполнения (в нашем случае 2) — 00; затем 1, означающую окончание кодировки переполнения; и в конце те самые четыре бита, которые были отброшены.
Итак, 46 в компрессированном виде записано как 0011110.
Вся последовательность 10, 14, 15, 46 при k = 4 записывается так: 1010111011110011110. Нетрудно проверить, что описанный алгоритм полностью обратим. Объем информации, занимаемый этой последовательностью, составляет 19 бит плюс еще информация о величине k.
Описанный пример, как и в предыдущем случае, достаточно тривиален, при реальном применении алгоритма используются гораздо бо,льшие числа, при кодировании которых информация о величинах k становится пренебрежимо малой.
На этом этапе MAC заканчивает работу, а результаты записывает в файл с расширением .ape.
1 (назад) О странном названии своего детища автор получал так много вопросов, что даже вынес их в FAQ. Q: Why name a lossless compression technology «Monkey’s Audio»? A: Well… who doesn’t love monkeys?
2 (назад) Информация о методе сжатия базируется на авторском описании: www.monkeysaudio.com/theory.
3 (назад) Для проверки этого факта я сжал два 10-секундных файла с шумом — первый моно, а второй стерео. Оба канала стереофайла были копией канала монофайла. В результате стереофайл получился всего лишь на 8 байт (!) больше, чем моно, и это при объеме 559 644 байта. После этого один из каналов стереофайла был сдвинут на 5 мс. На этот раз объем сжатого файла составил 1 107 836 байт.