Pull to refresh

Подсчёт md5-хэша для mp3-файла

Reading time 4 min
Views 12K
Итак, нам нужно подсчитать хэш-сумму для файла MP3. Простой прогон файла через md5.exe не годится, так как файл содержит метаинформацию — теги, которые имеют тенденцию со временем меняться. Таким образом, всего лишь обновив теги в файле, мы получаем уже другую хэш-сумму, что не годится совершенно.

Кстати, для форматов FLAC и APE данная проблема практически отсутствует, так как они обычно изначально содержат хэш-сумму аудио-данных, прописываемую кодировщиком. Для FLAC’а значение можно получить командой metaflac --show-md5sum.

Далее — достаточно надёжный способ подсчёта (не перцептивного) хэша на основе бинарных данных, хранимых в MP3.

1) Подход №1
2) Подход №2
3) Теги Xing и Lame
4) Resync
5) Надёжность подсчёта



Подход №1. Убираем ненужное


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

Структура mp3-файла:
— тег ID3v2
— mpeg-фреймы — собственно аудио-данные
— тег Lyrics
— тег APE
— тег ID3v1 (завершающий)

(Все теги опциональны.)

ID3v2, в отличии от своего предшественника, находится в начале файла, что даёт возможность клиенту сразу же прочитать мета-информацию если файл предаётся по сети, например. Начинается он с трёх ASCII-символов «ID3», затем идёт закодированная длина тега:

if buf[0:3] == 'ID3':
    id3_v2_len = 20 if ord(buf[5]) & 0x10 else 10
    id3_v2_len += ((ord(buf[6]) * 128 + ord(buf[7])) * 128 + ord(buf[8])) * 128 + ord(buf[9])
    audio_start = id3_v2_len


Дальше идут аудио-фреймы. Их начало можно визуально заметить если открыть файл в кодировке 1251 и найти символы «яы».

Теперь пойдём с конца. ID3v1 распознаётся как 128-байтный блок в конце файла, начинающийся с ASCII-строки «TAG». Если потом поискать с конца же «LYRICSBEGIN», то можно найти тег Lyrics3. А если «APETAGEX» — тег APEv2.

Если всё это вырезать, должны будут остаться только аудио-данные. Такой подход исповедует программа mp3tag.de, куча частных скриптов и tagging-библиотеки, значительная часть из которых ориентирована только на ID3, что, понятное дело, мешает.

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

В итоге программу написанную на такой манер мне пришлось выкинуть после столкновения с реальностью.

Подход №2. Оставляем нужное


MP3-плееры действуют наоборот — вычленяют то что им интересно — mpeg-фреймы, пропуская всё что на фреймы не похоже, причём делают это весьма успешно — «всхлипов» на «плохих» файлах обычно не услышишь. Разумно поступать так же.

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

MPlayer должен бы поступать так же, но сомнения возникают из-за того что по факту он иногда спотыкается на некорректных тегах, оставляя их. Команда очистки файла для него такая: mplayer in.mp3 -dumpaudio -dumpfile out.mp3.

Ещё есть медийные библиотеки — декодеры mp3. Это mad, gstreamer и libmpg123, которыми невозбранно пользуются разные пригрыватели. Первые два не пробовал, а вот libmpg123 пошла на ура — этот код проверен годами и множеством проектов, и качественный по результатам моих собственных исследований и сравнений. Там, в doc/examples есть исходный код микро-программы с говорящим названием extract_frames.c. Программа принимает на вход оригинальный mp3-файл и отправляет на выход чистые аудио-фреймы.

libmpg123 без проблем компилируется под cygwin и mingw (правда mingw-версия почему-то глючит с stdin/stdout, так что пришлось исправить исходник, открывая файл в бинарном режиме самому). Я слегка изменил программу чтобы вместо фреймов она сразу выдавала md5 и внёс пару изменений описанных ниже. Исходный код, кому интересно:

dl.dropbox.com/u/1883230/my/habr/mp3hash.zip

Теги Xing и Lame


Но в аудио-фреймах тоже может храниться мета-информация, от которой мы так хотим избавиться — это теги xing и lame, где закодирована лишняя для нас информация используемая для оптимизации перемещения по vbr-потоку, а также параметры использованные при кодировании. Вобщем-то ксинг с леймом можно и оставить так как мало кто умеет и будет их менять, но если вдруг в foobar2000 выполнить операцию «utilities / fix vbr mp3 header», то хэш-сумма для файла поменяется. Так что лучше будет выкинуть эту мету. Перестать учитывать данные теги при хэшировании можно передав libmpg123 следующий параметр:

// "remove ignore" несколько смущает, но это работает
ret = mpg123_param(m, MPG123_REMOVE_FLAGS, MPG123_IGNORE_INFOFRAME, 0.);


Resync


Также полезным оказалось убрать ограничение на resync limit. Если этого не сделать, программа «споткнётся» когда долго (4КБ) не встретит аудио-фреймов, что случается с файлами в которых, например, внутри ID3v2 содержится большое изображение. В моей версии программы хэш-сумма вычисляется та же, но появляющийся флаг ошибки всё портит и уже нельзя быть уверенным что результат получен без ошибок. А с этим параметром всё хорошо:

mpg123_param(m, MPG123_RESYNC_LIMIT, -1, 0.0);


Надёжность подсчёта


На мой ограниченный взгляд foobar2000 работает (избавляется от мета-информации) идеально. Патченная программа extract_frames.c не справляется с редкими файлами, но после операции «rebuild stream» в фубаре 95 пофейленых случаев из 100 уже обсчитываются верно (совместимо с фубаром). Далее и несколько хуже идёт mplayer — он почти всегда совместим с extract_frames (в режиме учёта lame/xing, понятное дело), но, как я уже писал, порой валится на мусорных тегах. Ещё далее идут различные теггеры, которые требуют достаточно корректных тегов, и вряд ли могут быть применимы задачи хэширования при наличии более стабильных альтернатив.

Вобщем после одной крупной неудачи и борьбы с парой аспектов, я лично остался доволен этим алгоритмом, проверив его на куче файлов.
Tags:
Hubs:
+21
Comments 13
Comments Comments 13

Articles