Дистрибьютор получает треки от артистов и передает их на стриминговые сервисы. Большинство заявок соответствуют действительности. Некоторые — нет: повторная загрузка коммерческой записи под именем нового артиста, трек, который уже был выпущен через вас под другим названием, или мэшап, созданный на основе чужой мастер-копии. Этот рецепт позволяет проверять каждую заявку с помощью AudD перед доставкой и формировать CSV-файл очереди на проверку, который подскажет сотруднику, какие треки нужно изучить и почему.
Существует две проверки:
- По публичной базе данных. Распознайте заявку и сравните найденную запись (исполнитель, лейбл, ISRC) с тем, что заявил загрузчик.
- По вашему собственному каталогу. Выявляйте одну и ту же запись, доставленную дважды под разными названиями, именами артистов или ISRC, используя пользовательский каталог мастер-копий, которые вы уже доставили.
Что означает совпадение, а что нет. AudD сообщает вам, с какой записью в своей базе данных совпадает аудио, предоставляя метаданные, с которыми эта запись была выпущена. Сервис не может подтвердить право собственности или сказать, кто владеет правами. Поле «лейбл» — это выпускающий лейбл в метаданных релиза, что не обязательно означает владельца прав: каталоги продаются, лицензируются и перемещаются между дистрибьюторами. Совпадение с другим артистом — это повод для проверки человеком, а не доказательство нарушения. Решение о проверке остается за вами. Эта страница не является юридической консультацией.
Что означает совпадение, а что нет. AudD сообщает вам, с какой записью в своей базе данных совпадает аудио, предоставляя метаданные, с которыми эта запись была выпущена. Сервис не может подтвердить право собственности или сказать, кто владеет правами. Поле «лейбл» — это выпускающий лейбл в метаданных релиза, что не обязательно означает владельца прав: каталоги продаются, лицензируются и перемещаются между дистрибьюторами. Совпадение с другим артистом — это повод для проверки человеком, а не доказательство нарушения. Решение о проверке остается за вами. Эта страница не является юридической консультацией.
Что вы создадите
Python-скрипт, который принимает пакет заявок и создает review_queue.csv, по одной строке на каждую заявку для каждой найденной записи, со столбцом действия:
no_match не означает «одобрено». AudD сопоставляет записи, поэтому он не обнаруживает каверы, перезаписи, интерполяции или созданные ИИ имитации голоса артиста, и может сопоставлять только то, что есть в его базе данных из примерно 160 миллионов коммерчески выпущенных песен.
Предварительные требования
- API-токен. Получите свой токен на dashboard.audd.io. Для получения ISRC, UPC и оценки (score) в результатах требуется план Startup или выше. Без ISRC проверка own_release опирается только на артиста и название, что гораздо менее эффективно.
- Python 3.10+ с SDK: pip install audd
- ffmpeg и ffprobe в вашем PATH для нарезки фрагментов и чтения длительности.
- Ваши собственные записи о доставке: для каждой учетной записи — ISRC, которые вы доставили, и имена артистов, которые вы для нее подтвердили. Скрипт считывает их из любого хранилища, которое вы уже используете.
- Для проверки по каталогу (Часть 2): доступ к пользовательскому каталогу. По умолчанию он не включен; напишите на [[email protected]] для запроса доступа.
Стандартный фрагмент или корпоративное сканирование
Вы можете проверить заявку двумя способами, и выбор зависит от баланса стоимости и охвата.
Стандартная конечная точка для фрагмента из середины трека. Стандартная конечная точка (https://api.audd.io/) анализирует первые 12 секунд того, что вы отправляете, и возвращает одно лучшее совпадение. Многие треки начинаются с тишины, отсчета или эмбиент-интро, поэтому вырежьте 12-секундный фрагмент из середины трека и отправьте его. Один запрос на трек.
Корпоративная конечная точка для всего трека. Корпоративная конечная точка (https://enterprise.audd.io/) разбивает файл на 12-секундные фрагменты и возвращает каждое совпадение с его позицией. Она обнаружит сэмпл на 2:40, который пропустил бы фрагмент, и сообщит, какая часть трека совпала. Оплата производится за один запрос на каждые 12 секунд обработанного аудио.
Для трека длительностью 3:30 (210 секунд, 18 фрагментов):
Обычная настройка — запускать проверку фрагмента для каждой заявки, а полное корпоративное сканирование — для подмножества: новых аккаунтов, аккаунтов с предыдущими пометками, жанров, где часто используется сэмплирование, или всего, что было помечено проверкой фрагмента.
Часть 1: Проверка заявок по публичной базе данных
Шаг 1: Опишите заявку и ваши записи
Загрузите AccountHistory для каждой учетной записи из вашей базы данных. ISRC — это те, которые вы доставили для этой учетной записи; имена артистов — те, которые вы подтвердили как разрешенные для доставки этой учетной записью.
Шаг 2: Вырежьте фрагмент и распознайте его
recognize возвращает None, если ничего не найдено. Это нормальный результат, а не ошибка. Чтобы попробовать ту же проверку вручную, CLI отправляет клип из любой точки файла: audd recognize track.wav --at 1:20.
Шаг 3: Классифицируйте совпадение относительно заявки
same_artist намеренно сделано гибким («Artist feat. Guest» содержит «Artist»), потому что результат лишь направляет трек человеку. Два разных артиста могут иметь одинаковое имя, поэтому совпадения имени артиста никогда не достаточно для одобрения трека; именно поэтому только ISRC из ваших собственных записей о доставке создает own_release.
Шаг 4: Полное корпоративное сканирование с частичными совпадениями
Для треков, которые проходят полное сканирование, сгруппируйте совпадения по записям и определите, какую часть трека покрывает каждая запись.
start_seconds и end_seconds — это позиции в отправленном файле в секундах. SDK по умолчанию запрашивает точные смещения и вычисляет их из позиции фрагмента плюс смещение внутри 12-секундного фрагмента, поэтому вам не нужно делать это вручную (см. Enterprise response и поля совпадений, если вы вызываете HTTP API напрямую).
Лимит установлен на количество фрагментов в треке с верхним пределом. Заявка, которая оказывается двухчасовым DJ-миксом, загруженным как «сингл», останавливается на 60 фрагментах вместо обработки всего файла.
Файл, который совпадает с несколькими записями или с одной записью на небольшой части своей длины, попадает в категорию partial. Сэмплирование, DJ-эдит, ремикс, созданный на основе выпущенных стемов, и трек, цитирующий известное интро, выглядят именно так. Некоторые из них одобрены, некоторые нет; AudD не может определить, какие именно.
Публичная база данных знает только то, что уже было выпущено. Трек, который вы доставили на прошлой неделе, может еще не быть в ней, и публичная база данных не скажет вам, что две ваши собственные доставки — это одно и то же аудио. Для этого создайте «отпечатки» (fingerprints) мастер-копий, которые вы доставляете, в пользовательский каталог: вашу частную базу данных отпечатков. Как только мастер-копия попадает туда, обычные вызовы распознавания могут вернуть audio_id этой мастер-копии.
Шаг 5: Добавьте мастер-копии в каталог без повторных попыток
Используйте ваш внутренний ID мастер-копии (целое число) в качестве audio_id и храните метаданные на своей стороне. Пользовательское совпадение возвращает audio_id; его исполнитель и название могут быть null.
Загрузки тарифицируются, и повторная загрузка, которая на самом деле прошла успешно с первого раза, заставит вас платить дважды. SDK не повторяет custom_catalog.add; не оборачивайте это в свой цикл повторных попыток. Записывайте состояние до и после каждой загрузки и отправляйте все, что осталось в неизвестном состоянии, на проверку человеку.
Загружая аудио в каталог, вы подтверждаете, что имеете на это права; условия находятся на странице конечной точки загрузки. Эквивалент CLI для разовой операции: audd catalog add master.wav --id 81234.
Шаг 6: Проверяйте перед добавлением
Чтобы найти дубликаты, распознавайте каждую новую заявку до того, как мастер-запись попадет в каталог. Если она совпадает с уже имеющейся мастер-записью, значит, у вас одна и та же запись в двух экземплярах. Такой порядок действий также подходит для заполнения базы: проходите по своим существующим мастер-записям, начиная с самых старых, проверяйте каждую из них, а затем добавляйте.
Стандартный вызов возвращает одно лучшее совпадение, которое может быть найдено как в вашем каталоге (установлен audio_id), так и в публичной базе данных. Мастер-запись, которую вы доставили несколько месяцев назад, скорее всего, уже есть в публичной базе данных, поэтому проверяйте оба источника: audio_id по вашему каталогу и ISRC по вашим записям о доставке.
Пустое поле claimed_isrc для мастер-записи, у которой оно уже заполнено, намеренно отображается как конфликт: это означает, что кто-то собирается присвоить второй ISRC записи, у которой он уже есть.
Шаг 7: Создание очереди на проверку
Выполняйте обе проверки для каждой заявки и записывайте по одной строке CSV для каждого результата, предоставляя достаточно доказательств, чтобы проверяющему не пришлось ничего перепроверять.
Функция catalog_check уже выполнила вызов для получения фрагмента, поэтому при стандартном сценарии вы можете повторно использовать этот результат вместо повторного распознавания; здесь это разделено для удобства чтения. Записывайте строки с помощью csv.DictWriter(f, fieldnames=FIELDS, restval="").
Готовая очередь выглядит следующим образом:
Проверка очереди
Задача проверяющего — определить, что означают представленные доказательства. Некоторые часто встречающиеся закономерности:
- different_artist с лейблом крупного издателя. Запросите у загрузившего пользователя лицензию или договор, покрывающий этот случай. Конкурс ремиксов или лицензированный сэмпл — это законно; необъяснимая полная повторная загрузка — обычно нет.
- same_artist_no_history. Часто встречается, когда артист переносит свой каталог от другого дистрибьютора; ISRC обычно переносятся вместе с записями. Прежде чем доставлять контент, подтвердите, что аккаунт действительно принадлежит этому артисту.
- partial. Прослушайте диапазон first_seen_s–last_seen_s в заявке рядом с song_link найденной записи.
- metadata_conflict. Решите, какие метаданные верны, и является ли заявка новым релизом существующей записи или ошибкой.
Храните строки CSV и решение проверяющего вместе. Если решение будет оспорено позже, у вас будут данные о том, что было найдено, когда и почему запись была задержана.
Обработка ошибок
- AudDAuthenticationError: неверный токен. Остановите пакетную обработку.
- AudDQuotaError, AudDSubscriptionError: закончились запросы или функция (enterprise, ISRC) недоступна в рамках вашего тарифного плана. Остановите процесс и исправьте настройки аккаунта; повторные попытки не помогут.
- AudDCustomCatalogAccessError: доступ к каталогу еще не включен. Напишите на [email protected].
- AudDInvalidAudioError: файл заявки не является аудио, которое можно декодировать. Верните его загрузившему пользователю.
- AudDConnectionError при вызове распознавания: можно безопасно повторить с задержкой. При загрузке в каталог: не повторяйте; реестр помечает запись как needs_check.
Отмена запроса на распознавание в процессе выполнения может привести к списанию запросов.
Дальнейшие шаги
- Сохраняйте каждый результат, используя ID заявки и хеш файла в качестве ключа, чтобы повторно загруженный идентичный файл не сканировался снова.
- Повторно проверяйте заявки со статусом no_match после доставки, если хотите выявить материал, который попал в публичную базу данных позже.
- Оценивайте совпадение перед маршрутизацией: см. «Интерпретация оценки распознавания».
- AudD для музыкальных дистрибьюторов
- Обнаружение сэмплов и повторное использование ваших собственных треков
- Публичная база данных против вашего пользовательского каталога
- Контроль расходов на enterprise-эндпоинт
- Поля ответа и совпадения в Enterprise
- Документация Python SDK
