Количество хешей — функция от нескольких параметров прореживания (они приведены в статье).
Опускающееся лезвие (и все остальные приёмы для выбора пиков), на первый взгляд, вполне может работать и для real-time определения — почему нет?
Про среднее число вхождения ключей — давайте тогда уточним, что называть средним. А максимальное — это же просто выброс, как он поможет? Допустим есть один (или даже несколько) ключей, которые встречаются почти во всех треках — но разве это может помочь сделать какой-либо вывод? Кажется, нет.
30% времени вещания распознать не удается
Тогда непонятно, как это соотносится с цифрами 95..99.9% в вашем первоначальном комментарии.
Попробую ответить:
1. Сейчас под рукой нет точной цифры по большому числу треков; по нескольким трекам (первым попавшимся) цифра порядка 60 хешей в секунду.
2. Мы используем пары пиков. Если это и есть двузвёздные созвездия в терминологии Шазама, то ответ «да».
3. В статье есть все исходные для этой цифры: 6 млн / 2^20 ≈ 6 документов на пару. Максимального значения под рукой сейчас нет, а как оно может помочь с вашими вопросами?
Как нам кажется, разница в точности с вашим решением вызвана тремя причинами:
а) вы имеете дело с сильно более чистым сигналом — у вас нет ни посторонних шумов бара/кафе, ни акустики помещения, ни искажений АЧХ микрофона.
б) я правильно понимаю, что у вас база заведомо содержит все треки, которые играются на радио — и отсутствие трека в базе не считается результатом «не найдено»? В нашем случае считается — а наши пользователи спрашивают, вообще говоря, не только треки из нашей базы. Т.е. в наши 20% нераспознанного входят оба случая — и «треки, которых мы не знаем», и «алгоритм не смог найти» (например, из-за шумов).
в) вы сами написали, что ваша база на порядок меньше нашей. В общем случае с ростом базы точность падает (растёт вероятность «зацепить» что-то похожее, но другое)
Просьба действительно совсем не по теме статьи — но в порядке исключения отвечу, цитирую коллегу:
Мы делаем все возможное, чтобы наша база пополнялась новым и актуальным контентом. К сожалению, не все правообладатели готовы сотрудничать с нами, и на некоторые песни нам не удается получить лицензию. В других случаях, правообладателя бывает трудно отыскать, чтобы заключить с ним договор. Чаще всего контент появляется и пропадает на сервисе в том случае, если у рекорд компании, которая лицензировала нам песни, заканчивается срок действия договора с артистом, а новый договор между ними не подписывается. В этом случае контент может появиться в каталоге другой рекорд компании, и тогда контент остается на сервисе или очень быстро снова становится доступен. Или же артист может решить оставить все права у себя, и для получения контента нам потребуется идти договариваться к артисту напрямую, что не всегда удается сделать.
Да, всегда один — самый релевантный. В ремиксах он, скорее всего, не идентичен оригиналу. А если в сборники — какая разница, из какого сборника показать этот трек?
Если совсем на пальцах:
= любую периодическую функцию можно приблизить рядом Фурье
= музыкальную запись можно разрезать на множество временных интервалов, и на каждом интервале приближать её своим рядом Фурье — тогда длину этого интервала можно считать периодом (и тогда слово «периодической» в предыдущем пункте уже не важно)
= быстрое преобразование Фурье — просто вычислительно недорогой алгоритм получения первых N коэффициентов для такого разложения
С классикой — похоже, ключевая причина в том, что даже несколько записей одного и того же произведения, исполненные одним и тем же коллективом — это разные записи. Даже небольшие изменения темпа, тембра — оказываются критичными. Такая проблема гораздо реже случается для популярной музыки, там исполнитель гораздо реже варьируется, да и для одного исполнителя гораздо реже случаются повторные записи одного произведения.
По второй проблеме — скиньте мне пожалуйста ваш email-адрес в личку. Я передал вашу проблему коллегам в поддержку полоьзователей, они свяжутся с уточнениями.
Про первую часть: а можете назвать конкретные треки, которые не удалось распознать? (в идеале — сразу ссылками на треки на Яндекс.Музыке, так будет чуть проще разбираться)
По нашему опыту, с точки зрения алгоритмов распознавания живое исполнение всегда отличается от студийного.
А если речь идёт о нескольких студийных записях, которые совсем неотличимы — то какая разница, какой из нескольких идентичных треков мы отдадим пользователю? :-)
Опускающееся лезвие (и все остальные приёмы для выбора пиков), на первый взгляд, вполне может работать и для real-time определения — почему нет?
Про среднее число вхождения ключей — давайте тогда уточним, что называть средним. А максимальное — это же просто выброс, как он поможет? Допустим есть один (или даже несколько) ключей, которые встречаются почти во всех треках — но разве это может помочь сделать какой-либо вывод? Кажется, нет.
Тогда непонятно, как это соотносится с цифрами 95..99.9% в вашем первоначальном комментарии.
1. Сейчас под рукой нет точной цифры по большому числу треков; по нескольким трекам (первым попавшимся) цифра порядка 60 хешей в секунду.
2. Мы используем пары пиков. Если это и есть двузвёздные созвездия в терминологии Шазама, то ответ «да».
3. В статье есть все исходные для этой цифры: 6 млн / 2^20 ≈ 6 документов на пару. Максимального значения под рукой сейчас нет, а как оно может помочь с вашими вопросами?
Как нам кажется, разница в точности с вашим решением вызвана тремя причинами:
а) вы имеете дело с сильно более чистым сигналом — у вас нет ни посторонних шумов бара/кафе, ни акустики помещения, ни искажений АЧХ микрофона.
б) я правильно понимаю, что у вас база заведомо содержит все треки, которые играются на радио — и отсутствие трека в базе не считается результатом «не найдено»? В нашем случае считается — а наши пользователи спрашивают, вообще говоря, не только треки из нашей базы. Т.е. в наши 20% нераспознанного входят оба случая — и «треки, которых мы не знаем», и «алгоритм не смог найти» (например, из-за шумов).
в) вы сами написали, что ваша база на порядок меньше нашей. В общем случае с ростом базы точность падает (растёт вероятность «зацепить» что-то похожее, но другое)
Shumeet Baluja, Michele Covell: «Audio Fingerprinting: Combining Computer Vision & Data Stream Processing»
Наверняка вам будет любопытно прочесть, если ещё не успели.
= любую периодическую функцию можно приблизить рядом Фурье
= музыкальную запись можно разрезать на множество временных интервалов, и на каждом интервале приближать её своим рядом Фурье — тогда длину этого интервала можно считать периодом (и тогда слово «периодической» в предыдущем пункте уже не важно)
= быстрое преобразование Фурье — просто вычислительно недорогой алгоритм получения первых N коэффициентов для такого разложения
Вы об этом спрашивали?
С классикой — похоже, ключевая причина в том, что даже несколько записей одного и того же произведения, исполненные одним и тем же коллективом — это разные записи. Даже небольшие изменения темпа, тембра — оказываются критичными. Такая проблема гораздо реже случается для популярной музыки, там исполнитель гораздо реже варьируется, да и для одного исполнителя гораздо реже случаются повторные записи одного произведения.
Мы планируем увеличивать полноту поиска — и в этих направлениях, конечно, тоже думаем :-)
А если речь идёт о нескольких студийных записях, которые совсем неотличимы — то какая разница, какой из нескольких идентичных треков мы отдадим пользователю? :-)