2010-07-03 3 views
7

В принципе, у меня есть много аудиофайлов, представляющих одну и ту же песню. Однако некоторые из них хуже качества, чем оригиналы, и некоторые из них редактируются там, где они больше не соответствуют оригинальной песне. То, что я хотел бы сделать, это программно сравнить эти аудиофайлы с оригиналом и посмотреть, какие из них соответствуют этой песне, независимо от качества. Прямое сравнение, очевидно, не будет работать, потому что качество файлов меняется.Сравните два аудиофайла

Я считаю, что это может быть сделано путем анализа структуры песен и сравнения с оригиналом, но я ничего не знаю об аудиоинженерии, так что это не очень помогает. Все песни одного формата (MP3). Кроме того, я использую Python, поэтому, если есть привязки для него, это будет фантастично; если нет, то для JVM или даже для родной библиотеки было бы хорошо, если оно работает на Linux, и я могу понять, как его использовать.

+1

Посмотрите, как работает Shazam: http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ – 2010-07-03 21:41:16

+0

+1, классный пост в блоге – BenG

+0

Хм, звучит так не так просто, как Я думал, что так будет. –

ответ

4

Копирование that ответа:

точно такой же вопрос, что люди на старом Audioscrobbler и в настоящее время в MusicBrainz работали на давно. Пока что проект Python, который может помочь в вашем квесте, это Picard, в котором будут помечены аудиофайлы (а не только файлы MPEG 1 Layer 3) с GUID (фактически, несколько из них), и с этого момента, теги довольно просты.

Если вы предпочитаете делать это как собственный проект, может оказаться полезным помочь libofa. Возможно, вам понравится documentation for the Python wrapper.

+0

Я закончил тем, что использовал Пикарда, по крайней мере пока. Благодарю. :) –

6

Во-первых, вам нужно будет изменить свой домен сравнения. Анализ необработанных образцов из несжатых файлов не даст вам нигде. Ваша дистанционная мера будет основана на одной или нескольких функциях, которые вы извлекаете из образцов аудио. Википедия перечисляет следующие функции, как правило, используется для Acoustic Fingerprinting:

Перцепционных характеристики часто эксплуатируемых аудио отпечатков пальцев включают среднюю скорость пересечения нуля, по оценкам, темп, средний спектр, спектральная плоскостность, видные тона по всей совокупности полос, а также ширину полосу частот.

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

13

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

  1. Декодировать mp3 для PCM.
  2. Убедитесь, что данные PCM имеют определенную частоту дискретизации, которую вы выбираете заранее (например, 16 кГц). Вам нужно будет перепрограммировать песни с разной частотой дискретизации. Высокая частота выборки не требуется, так как в любом случае вам нужно нечеткое сравнение, но слишком низкая частота дискретизации потеряет слишком много деталей.
  3. Нормализовать данные PCM (т. Е. Найти максимальное значение выборки и масштабировать все образцы, чтобы образец с наибольшей амплитудой использовал весь динамический диапазон формата данных, например, если формат образца подписан 16 бит, то после нормализации максимальная амплитуда образца должна иметь значение 32767 или -32767).
  4. Разделить аудиоданные на кадры с фиксированным числом выборок (например, 1000 выборок на кадр).
  5. Преобразование каждого кадра в область спектра (FFT).
  6. Рассчитать корреляцию между последовательностями кадров, представляющими две песни. Если корреляция больше определенного порога, предположите, что песни одинаковы.

Python библиотеки:

  • PyMedia (для шага 1)
  • NumPy (для обработки данных) - также см this article для некоторой вводной информации

Дополнительное осложнение. Вначале ваши песни могут иметь разную тишину.Поэтому, чтобы избежать ложных негативов, может потребоваться дополнительный шаг:

3.1. Сканируйте данные PCM с самого начала, пока звуковая энергия не превысит предопределенный порог. (Например, вычислить RMS с скользящим окном из 10 выборок и остановиться, когда он превышает 1% от динамического диапазона). Затем отбросьте все данные до этой точки.

+0

Данные PCM - это байтовый массив? На шаге 3 при нормализации, так как нам нужны амплитуды до 32767, я считаю, что вы преобразовали бы его в целочисленный/двойной массив. Пожалуйста, поправьте меня, если я ошибаюсь. Кроме того, нужно ли вычислять корреляцию на шаге 6? Или что, если мы просто сравним значения fft и посмотрим, попадают ли они в порог? – LINGS

+0

@LINGS (3) предполагает, что данные PCM с этапа (1) представляют собой массив соответствующего типа (например, int16 или float32). Но если декодер выбора возвращает необработанные байты, то да, необходим шаг преобразования. – atzz

+0

@LINGS re step (6): простая разница не будет работать, если ваше решение должно терпеть шум, потому что некоторые шумы, такие как щелчки или claps, вызывают большую разницу в FFT. Интегрированные различия могут работать. Я не уверен, что корреляция - лучший метод сравнения здесь, я не исследовал его, как я, вероятно, должен был, но он работал нормально, когда я реализовал нечто подобное. – atzz

Смежные вопросы