Comments 13
В свое время позабавил коментарий в коде libmpg123:
Порой кажется что люди намеренно портят файлы… Кстати, не пробовали включать/выключать SKIP_JUNK при сборке?
ps. Из всех библиотек для декодирования файлов с которыми мне довелось работать, libmpg123 была самой удобной. И разработчики там приветливые.
first attempt of read ahead check to find the real first header; cannot believe what junk is out there!
Порой кажется что люди намеренно портят файлы… Кстати, не пробовали включать/выключать SKIP_JUNK при сборке?
ps. Из всех библиотек для декодирования файлов с которыми мне довелось работать, libmpg123 была самой удобной. И разработчики там приветливые.
А нельзя ли объяснить саму проблему? Зачем подсчитывать md5-хэш от mp3-файла без тегов?
Для проверки аудио на уникальность.
Сомневаюсь, что для этого. Скажем тот-же самый трек рипнутый два раза (другой программой, с другими настройками, под другим знаком зодиака) — дадут разные хеши. Что бы повторы искать, ИМХО, нужно сравнивать аудио-содержимое на похожесть а не на идентичность.
Во-во. В mp3 можно много чего менять, даже если рассматривать только неразрушающие методы, без перепаковки. И определять «уникальность» отбрасывая теги — это как защищаться от воров, поставив дорогой замок на дверь, и открыв все окна на первом этаже.
Всё правильно написал Ocelot — именно для проверки на уникальность. Если вкратце, у меня система автоматического бэкапа аудио-архивов.
Получение хэша — не конечная задача. Через проверку хэша на уникальность можно решить такие задачи:
1) Поиск дубликатов (с последующим уничтожением или симлинкингом)
2) Автоматический бэкап аудио — нужно знать какие файлы уже были забэкаплены, какие нет. А так как файлы беспорядочно перемещаются и теггируются, без такого хэша не обойтись.
3) На основе предыдущего пункта у меня ещё и третья работа делается.
1) Поиск дубликатов (с последующим уничтожением или симлинкингом)
2) Автоматический бэкап аудио — нужно знать какие файлы уже были забэкаплены, какие нет. А так как файлы беспорядочно перемещаются и теггируются, без такого хэша не обойтись.
3) На основе предыдущего пункта у меня ещё и третья работа делается.
Для личного использования подойдёт. А для «боевого» детектирования дублей — нет, ибо достаточно добавить/обрезать 1мс тишины в начале/конце, или добавить один щелчок на грани слышимости в середине — и хэш уже другой.
Есть такое — мпеги не должны обрабатываться. Слава б-гу, этим мало кто занимается.
Кстати, ведь можно отслеживать такие вмешательства на манер rsync/dropbox — делить файл на чанки и искать частичное соответствие, с достоверность от 90%, например. В довесок можно тишину анализаровать, и если её вырежут, то нестрашно. А вот щелчок в середине вставить — это имхо совсем редкий случай, если только какой-то алгоритм даст сбой.
Кстати, ведь можно отслеживать такие вмешательства на манер rsync/dropbox — делить файл на чанки и искать частичное соответствие, с достоверность от 90%, например. В довесок можно тишину анализаровать, и если её вырежут, то нестрашно. А вот щелчок в середине вставить — это имхо совсем редкий случай, если только какой-то алгоритм даст сбой.
Зависит от задачи детектирования. Оптимизация — вполне пойдёт во многих случаях, предотвращение использования по образцу — нет.
Я в свое время занимался поиском мрз-дублей:
Исключая явные копии файлов (по CRC), и отыскивая «похожие» файлы по размеру.
Так же я группировал их по рассчетной длительности и бит-рейту.
И, выдергивал мета-теги (по содержимому которых так же группировал).
Для меня этого было достаточно.
Исключая явные копии файлов (по CRC), и отыскивая «похожие» файлы по размеру.
Так же я группировал их по рассчетной длительности и бит-рейту.
И, выдергивал мета-теги (по содержимому которых так же группировал).
Для меня этого было достаточно.
Sign up to leave a comment.
Подсчёт md5-хэша для mp3-файла