как хранить и искать mp3 по его содержимому

Question

Я хочу хранить несколько mp3-файлов и искать их, задавая часть песни, чтобы определить, какая это песня.

Я думаю о сохранении всего двоичного содержимого в mysql, и когда я хочу найти конкретную песню по содержимому, я возьму некоторую среднюю часть песни и сопоставлю ее с двоичными данными в MySQL.

Мои вопросы:

1. Это разумный способ найти песни по их содержанию?
2. Правильно ли хранить содержимое песен в базе данных или мне следует использовать файловую систему?

Answer 1

Это не сработает. MP3 - это формат с потерями. Это означает, что он постоянно изменяет тонкие нюансы музыки при кодировании, создавая, таким образом, совершенно разные побайтные данные почти для каждой кодировки для одной и той же песни .

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

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

Сравнение музыки не является тривиальным вопросом, существует несколько подходов, но, насколько мне известно, ни один из них не может быть использован в PHP.

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

Answer 2

Это правильный способ найти песни по содержанию песни.

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

Правильно ли будет хранить контент песен в базе данных или хранилище файлов будет нормально работать?

Если вы выполняете простое двоичное сопоставление, нет смысла использовать базу данных. Если у вас есть более сложная техника индексирования (например, аудио-отпечатки пальцев), использование базы данных может иметь смысл.

Answer 3

Как уже отмечали другие, сравнение MP3-файлов с помощью просмотра двоичного содержимого файлов не будет работать.

Я написал что-то вроде этого на Java, когда учился в университете на мой последний год обучения. Я был бы более чем счастлив выслать вам исходный код. Он имел дело с относительным сходством: «песня X больше похожа на песню Y, чем на песню Z», а не соответствует, но это может быть шагом в правильном направлении.

И пожалуйста, что бы вы ни делали, не пытайтесь делать это на PHP. Алгоритм, который я использовал, требовал, чтобы я вычислил (если я правильно помню - я работал над этим около 3 лет назад) 30 матриц 30х30 для каждого проанализированного MP3. Каждой песне требовалось около 30 секунд, чтобы обработать набор матриц на моем неуклюжем старом компьютере (я уверен, что мой новый ПК мог выполнить работу значительно быстрее). Когда у меня были эти матрицы для n песен, второй шаг вычислял различия между каждой парой песен, а третий шаг уменьшал эти различия до m-мерного пространства. Каждый из этих 3-х этапов требует достаточного количества лошадиных сил, и PHP определенно не подходит для этой работы.

Для PHP может работать внешний интерфейс - в итоге я запустил веб-приложение с поддержкой запросов, написанное на Ruby on Rails, где у меня был простой бэкэнд, в котором координаты каждой песни сохранялись в m-мерном пространстве (я случайно выбрать m = 6) - для конкретной песни или фрагмента X вы можете затем вычислить песни на определенном «расстоянии» от X.

NB. Я, вероятно, должен отметить, что весь код, который я написал, был в основном оберткой вокруг библиотек, которые написали другие - которые были сделаны некоторыми умными людьми в университете в Австрии - эти библиотеки взяли две песни и сгенерировали матрицы - все, что я делал, это вычислял расстояния и отобразить расстояния множества песен в м-мерном пространстве. Хотел бы я быть достаточно умным, чтобы сделать первый бит тоже!

Answer 4

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

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

Однако одна идея, указывающая на ваше направление, и я не уверен, насколько это возможно, состоит в том, чтобы проиндексировать некоторые паттерны песен, которые могут однозначно идентифицировать его. Например Что общего у всех песен Джонни Кэша? Громкость, тон, их сочетание? И когда вы получаете часть контента, вы можете извлечь тот же шаблон из него и сопоставить. Это было бы интересной концепцией.

Answer 5

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

Проблема в том, что байты не дают вам никакого представления о СОДЕРЖАНИИ файла, то есть о музыке в нем. Даже если вы вырезаете метаданные из байтов для сравнения (чтобы избавиться от шума, такого как изменения в написании / использовании метаданных с большой буквы), вы знаете только кое-что о самом уникальном файле. Таким образом, вы можете сравнить два одинаковых файла (то есть точные дубликаты) на равенство, но вы не можете сравнить любые два случайных файла на предмет сходства.