Создание доказательств для DMCA-запроса на удаление

Когда вам нужно подать запрос на удаление из-за использования защищенной авторским правом музыки в чужом контенте, жалоба будет настолько весомой, насколько весомы доказательства: какая именно запись, кто ее выпустил и где именно она звучит. Этот рецепт пропускает спорный контент через корпоративный эндпоинт AudD, затем собирает запись доказательств по каждому совпадению — идентификацию трека плюс точные временные метки начала и конца в файле — и представляет их как в формате JSON (для ваших записей и инструментов), так и в виде краткого изложения, понятного человеку (для вставки в жалобу).

Что вы создадите

Функцию, которая принимает URL или файл с нарушающим авторские права контентом и возвращает пакет доказательств: по одной записи на каждый распознанный трек, каждая из которых содержит идентификацию записи (исполнитель, название, альбом, лейбл, ISRC, UPC, song_link, оценка) и ее расположение в контенте (абсолютные временные метки начала и конца в файле), а также ссылку на источник. Вы представите пакет в двух видах — структурированный JSON и краткое изложение в виде простого текста.

Корпоративный эндпоинт — это подходящий инструмент: он обрабатывает контент произвольной длины и находит каждый трек, а не только один. В жалобе необходимо указать, когда звучит запись, и каждое совпадение отвечает на это с помощью start_seconds и end_seconds — абсолютной позиции песни в файле контента. Запросы recognize_enterprise по умолчанию запрашивают точные смещения, поэтому эти позиции точны; не нужно выполнять вычисления смещения фрагментов.

AudD предоставляет данные для идентификации, а не юридическую подачу. Этот рецепт создает доказательства — что было распознано и где. Решение о подаче жалобы, ее составление и подтверждение прав собственности остаются за вами. Выходные данные являются входными для этого процесса, а не юридической консультацией.

AudD предоставляет данные для идентификации, а не юридическую подачу. Этот рецепт создает доказательства — что было распознано и где. Решение о подаче жалобы, ее составление и подтверждение прав собственности остаются за вами. Выходные данные являются входными для этого процесса, а не юридической консультацией.

Предварительные требования

• API-токен с dashboard.audd.io. Получите свой токен там; корпоративный эндпоинт должен быть включен для него. ISRC и UPC в ответах требуют план Startup или выше; они возвращаются при корпоративных вызовах.
• Python 3.10+ с SDK: pip install audd
• Нарушающий контент в виде URL или файла. AudD анализирует социальные URL на стороне сервера, поэтому вы можете передать ссылку на контент в реальном времени напрямую. https://audd.tech/example.mp3 работает для успешного запуска.

Пошаговое руководство

Шаг 1: Распознавание контента

Пропустите контент через recognize_enterprise — передайте URL, байты файла или путь. Он обрабатывает любую длину и возвращает плоский список list[EnterpriseMatch]: по одной записи на каждый распознанный фрагмент, в хронологическом порядке, каждая из которых содержит точные start_seconds / end_seconds, на которых строятся доказательства (точные смещения запрашиваются по умолчанию).

Запуск этого выводит по одной строке на каждый распознанный фрагмент. Запись, которая звучит несколько минут, создает последовательность совпадений, называющих ее — Шаг 4 сворачивает эту последовательность в один диапазон доказательств. Чистый контент возвращает пустой список, а не ошибку.

Всегда устанавливайте limit во время разработки. Корпоративный эндпоинт тарифицируется за каждые 12 секунд обработанного аудио. Неограниченный вызов для длинного видео может создать сотни тарифицируемых фрагментов. Начните с limit=25 и увеличивайте его только тогда, когда поймете стоимость на ваших реальных входных данных.

Всегда устанавливайте limit во время разработки. Корпоративный эндпоинт тарифицируется за каждые 12 секунд обработанного аудио. Неограниченный вызов для длинного видео может создать сотни тарифицируемых фрагментов. Начните с limit=25 и увеличивайте его только тогда, когда поймете стоимость на ваших реальных входных данных.

Шаг 2: Временные метки, на которые ссылаются доказательства

Временные метки, которые проверяющий сверяет с контентом, — это start_seconds / end_seconds: где эта песня звучит в файле контента, в секундах (например, от 246.78 до 251.64). Они являются абсолютными для файла и попадают в запись доказательств как есть. Они имеют значение None только тогда, когда фрагмент поступил без пригодной позиции — пропустите такие.

Два других поля легко спутать с ними. start_offset / end_offset — это необработанные смещения, из которых выводятся секунды: миллисекунды внутри внутреннего 12-секундного фрагмента сканирования AudD (0–~12000), а не секунды файла; они вам редко нужны. А timecode — это позиция внутри распознанной записи, а не файла контента — он говорит вам, какая часть песни звучала, поэтому никогда не используйте его для определения нарушения.

Шаг 3: Форматирование позиции внутри файла в HH:MM:SS

Для жалобы нужно время, а не сырые секунды. Отформатируйте абсолютную позицию файла:

Это всегда дает HH:MM:SS с ведущими нулями, что легко читается в жалобе, даже если контент длится более часа.

Шаг 4: Сворачивание удерживаемого трека в один диапазон доказательств

Для доказательств вам нужна одна запись с временным диапазоном — «эта запись звучит с 00:04:06 до 00:06:18» — а не десять почти идентичных записей, по одной на фрагмент. Сверните последовательные совпадения для трека в один диапазон: начало — это start_seconds первого совпадения, конец — end_seconds последнего совпадения. Новый (исполнитель, название) открывает новый диапазон; повторение того, который вы сейчас расширяете, растягивает его конец.

Двухминутное воспроизведение становится одним диапазоном с реальным началом и концом, что именно и хочет проверить рецензент по контенту. Защита start_seconds и резервный вариант end_seconds существуют потому, что SDK анализирует ответы мягко: любое поле может отсутствовать или быть None, и один фрагмент без позиции не должен разрушить весь пакет.

Шаг 5: Оставьте только те диапазоны, на которые стоит ссылаться

Не каждое распознавание является доказательством уровня удаления. Обоснованная запись указывает на коммерческий релиз — тот, у которого есть лейбл и/или ISRC/UPC. Отфильтруйте диапазоны, которые содержат эти идентификаторы, и отбросьте остальные (или направьте их на ручную проверку).

Ненулевой лейбл или наличие isrc/upc — это ваш сигнал о том, что совпадение является выпущенной записью, которую вы можете точно назвать. ISRC и UPC требуют план Startup или выше; если они равны null для всех диапазонов, проверьте свой тарифный план, прежде чем предполагать, что контент невозможно идентифицировать.

Шаг 6: Сбор записи доказательств для каждого диапазона

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

source — это URL или имя файла нарушающего контента — запишите его явно, чтобы каждый пакет был самоописываемым. Временные метки местоположения являются абсолютными для файла: они поступают прямо из start_seconds / end_seconds каждого совпадения, поэтому они указывают на точный момент в контенте, к которому может перейти рецензент.

Шаг 7: Генерация пакета от начала до конца

pack — это структурированные доказательства — сохраните их как JSON вместе с записями вашего дела.

Шаг 8: Создание краткого изложения, понятного человеку

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

Это создает то, что вы можете вставить прямо в форму удаления: каждая запись названа, идентифицирована и локализована по ее позиции в файле.

Что вы получаете в ответ

Каждое совпадение в плоском списке — это один распознанный фрагмент, в хронологическом порядке. Поля, которые используют доказательства:

Для примера файла совпадение может вернуться со значениями start_seconds = 246.78 (00:04:06) и end_seconds = 251.64 (00:04:11) — это временной интервал, на который ссылается запись с доказательствами.

ISRC и UPC заполняются в корпоративных ответах для аккаунтов с тарифным планом Startup и выше. Отсутствие ISRC/UPC (null) не означает, что совпадение недействительно — лейбл в сочетании с исполнителем/названием по-прежнему идентифицируют запись, — но наличие ISRC делает запись наиболее точной.

Обработка ошибок

SDK вызывает типизированные исключения; перехватывайте те, на которые вы можете повлиять.

• Ошибки аутентификации (AudDAuthenticationError) — неверный или отсутствующий токен. Завершайте работу при запуске.
• Ошибки квоты / подписки (AudDSubscriptionError) — достигнут лимит запросов или корпоративная конечная точка не включена для вашего токена. Корпоративная конечная точка и ISRC/UPC зависят от уровня тарифного плана; сообщайте об этом владельцу аккаунта, а не пытайтесь повторить запрос.
• Ошибки недопустимого аудио — URL-адрес контента или файл не являлись декодируемым аудио/видео. Для работы с доказательствами это важно: запись, созданная на основе контента, который API не смог прочитать, бесполезна. Рассматривайте это как критический сбой для данного источника, а не как пустой пакет.
• Ошибки соединения (AudDConnectionError) — временные. Повторите попытку с использованием экспоненциальной задержки.

Пустой список записей (отсутствие цитируемых совпадений) — это допустимый и отдельный результат, отличный от ошибки; он означает, что контент не распознал ничего коммерческого, поэтому подавать жалобу не на что.

Дальнейшие шаги

• Повторный запуск распознавания учитывается в квоте для каждого фрагмента. Создавайте пакет один раз для каждого источника и сохраняйте JSON; создавайте читаемое человеком резюме из сохраненного JSON, а не путем повторного сканирования.
• Чтение полей метаданных, выходящих за рамки указанных выше — включая недокументированные или бета-поля, возвращаемые API, — осуществляется через model_extra каждого совпадения. Если для подачи жалобы требуется поле, не перечисленное здесь, считайте его из m.model_extra в объекте совпадения.
• Чтобы найти нарушающий авторские права контент в первую очередь — сканируя загрузки по мере их поступления, — см. «Создание сканера авторских прав для пользовательского контента».
• Для многочасового контента см. «Оптимизация корпоративных затрат при выборе между охватом и тарифицируемыми фрагментами».
• Создание сканера авторских прав для пользовательского контента
• Оптимизация корпоративных затрат
• Стандартный, корпоративный или потоковый: как выбрать
• Документация Python SDK
• Справочник API