Franchise Record Pool: AI-библиотека треков и Shazam для диджеев — гайд по разработке (2026)

Почему Фора Софт написала этот гайд

Фора Софт выпускает продукты для аудио и видео в реальном времени с 2005 года — более 625 готовых решений, 21 год опыта и 100% успешных проектов из тех, что мы берём в работу. Franchise Record Pool — один из аудиопроектов, которыми мы особенно гордимся. Именно потому что почти каждая его подсистема — это то, что заказчику обычно говорят: «без большой команды такое не построить».

Мы выпустили всё семейство продуктов FRP — веб-консоль, десктопное приложение на Electron, нативные клиенты для iOS и Android, движок распознавания по аудиоотпечаткам, голосового ассистента на базе LLM и синхронизацию с Serato — для живого каталога из 720 000 лицензированных треков от Sony, Universal и Virgin. Эта статья — тот самый гайд, который мы хотели бы вручить каждому основателю music-tech-стартапа ещё до того, как он напишет своё первое техзадание. Читайте её как рабочую оценку того, что нужно, чтобы выпустить современную диджейскую платформу, а не как маркетинговый текст.

Если вы решаете, строить ли музыкальную библиотеку с нуля или использовать готовое решение, переходите сразу к разделам обзор рынка диджейских пулов и модель затрат. Если оцениваете объём разработки, то эталонная архитектура и подводные камни — это те места, где реально экономят деньги.

Бриф FRP в одном абзаце

Franchise Record Pool — это подписочная платформа для профессиональных диджеев. Один аккаунт даёт сразу три вещи: лицензированный каталог из 720 000 треков, где для каждого указаны BPM, тональность, ремиксы и информация об источнике; движок распознавания — «Shazam для диджеев», который подсказывает, какой трек только что сыграл другой диджей, и автоматически добавляет его в вашу подборку; и голосовой ИИ-ассистент, который создаёт тематические плейлисты по одной фразе. На основе этих трёх функций работают веб-интерфейс, десктопное приложение на Electron, мобильные клиенты на React Native для iOS и Android, синхронизация с Serato и WebRTC-связь для аудиообмена между диджеем и фанатами.

FRP — это не копия Spotify. Это рабочий инструмент для тех, кто выступает четыре часа подряд, и это влияет на каждое решение в продукте: от скорости загрузки волновой формы до того, как поиск ранжирует версии Clean и Dirty.

Что профессиональным диджеям на самом деле нужно от трек-пула

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

1. Clean и Dirty — быстро. Работающему диджею нужно одним касанием переключаться между explicit-версией и radio-редакцией одного и того же трека. Поиск, который прячет «Clean» за тремя фильтрами, теряет пользователей уже через неделю.

2. BPM и тональность в каждой строке. Гармоничное сведение работает по колесу Камелот (12 тональностей × мажор/минор = 24 ячейки). Если данные о тональности отсутствуют или ошибочны у более чем 2% треков, диджеи сразу это замечают на первом же выступлении и меняют провайдера.

3. Ремиксы в той же панели, что и оригинал. Редактированные версии, redrum-версии, треки с интро/аутро и акапеллы должны быть доступны одним кликом от исходного трека — с указанием автора ремикса, разницы в BPM и длительности.

4. Распознавание «что они поставили?». Диджеи следят друг за другом. Они записывают фрагмент на телефон, открывают ваше приложение и ждут, что трек определится за секунду — а потом добавляют его в свою подборку одним касанием.

5. Синхронизация с их диджейским ПО. Если музыка не попадает в Serato, rekordbox или Traktor, платформа становится просто брошюрой «только для чтения». Именно эта возможность отличает диджейские пулы от любого другого музыкального сервиса.

6. Надёжная работа офлайн на площадках. WiFi в клубах ужасен. Десктопные и мобильные клиенты должны кэшировать очереди загрузок, возобновлять их после переподключения и не падать без предупреждения при обрыве передачи.

Внутри платформы FRP — функции, которые важны

FRP несёт плотный набор функций. Те, что ниже, — это то, за что мы бы боролись, оставляя их даже в более скромном MVP, если бы бюджет урезали вдвое.

Лицензированный каталог из 720 000 треков с полными метаданными

Каждый трек в FRP лицензирован у крупных лейблов (Sony Music, Universal, Virgin Records) и независимых дистрибьюторов. В каждой строке указаны тональность, BPM, жанр, поджанр, дата релиза, семейство ремиксов или эдитов и короткая превью-волна. Ни один другой диджейский пул из нашего исследования не отображает всю эту информацию в одной строке.

Распознавание музыки («Shazam для диджеев»)

Загрузите или запишите аудио длительностью 5–10 секунд — и FRP подберёт подходящий трек с оценкой уверенности. Также сервис найдёт ближайшие ремиксы из каталога FRP — именно эта функция превращает распознавание из «забавного демо» в «добавляет треки в мою подборку».

Голосовой ИИ-сборщик плейлистов

Одна кнопка микрофона запускает диалог. «Собери плейлист с итальянской поп-музыкой из 90-х, около 140 BPM, без explicit». Ассистент подтверждает, создаёт плейлист и озвучивает название и первые пять треков.

Нативная синхронизация библиотеки с Serato

Треки, скачанные из FRP, появляются в Serato с сохранёнными метаданными FRP — без повторной разметки, без повторного импорта, без ручного управления папками. Это первая функция, которую профессионалы проверяют перед оформлением подписки.

Веб и десктоп на Electron, мобильные приложения на React Native

Одна общая кодовая база, три интерфейса. Десктопное приложение на Electron — там, где основная работа с библиотекой; мобильное приложение — то, что используют в диджейской будке или на улице, чтобы быстро найти трек; веб-приложение — для биллинга и администрирования.

Канал связи с фанатами (только в мобильном приложении)

В мобильном приложении диджеи могут отправлять короткие аудиосообщения и превью подписчикам через канал на базе WebRTC. Именно эта функция удерживает приложение на главном экране в перерывах между выступлениями.

Движок распознавания музыки — как работает «Shazam для диджеев»

Современное распознавание музыки использует алгоритм «созвездий» (constellation algorithm): берётся короткий фрагмент, вычисляется его спектрограмма, находятся пиковые точки по осям «время — частота», пары этих пиков хэшируются, а полученные хэши сравниваются с заранее подготовленной базой хэшей, рассчитанных для каждого трека в каталоге. Эйвери Ванг впервые подробно описал этот метод на конференции ISMIR в 2003 году; с тех пор все системы вроде Shazam строятся на его основе.

Движок справляется с фоновым шумом, потому что игнорирует амплитуду и анализирует только паттерн пиков — те пики, что остаются после шума толпы, звона бокалов и плохого звука, всё ещё совпадают с пиками оригинального трека. Для базы из нескольких миллионов треков достаточно 5-секундного фрагмента.

Построить, лицензировать или гибрид — три реалистичных пути

1. Сделать своё. Dejavu (open-source на Python), audfprint (Дэн Эллис, Колумбийский университет) или конвейер на Chromaprint/AcoustID. Бесплатно по лицензии, но вы сами платите за вычисления отпечатков (GPU-часы) и хостинг базы хэшей. Подходит для каталогов до ~500 тыс. треков при наличии собственной команды по машинному обучению.

2. Коммерческий API. ACRCloud, AudibleMagic или Gracenote. Оплата — либо за каждое распознавание, либо по фиксированному enterprise-тарифу. Быстрее запустить; стоимость растёт пропорционально нагрузке; вы зависите от их стабильности работы.

3. Гибрид. Используйте open-source-фингерпринтер для треков из своего каталога, а для тех, что вне каталога, переключайтесь на коммерческий API. Именно так работает FRP — это заметно дешевле в масштабах и позволяет держать задержку распознавания в заданных пределах.

Голосовой ИИ-ассистент для тематических плейлистов

Голосовой ассистент FRP намеренно узкий. Он делает одну вещь хорошо: превращает произнесённый бриф в запрос к каталогу, а затем в плейлист. У конвейера четыре подвижные части.

1. Whisper расшифровывает речь. OpenAI Whisper стоит 0,45 ₽ за минуту, работает с аудио в браузере с частотой 16 кГц. Язык определяется автоматически — в нашей аудитории диджеи говорят на четырёх-пяти языках, и Whisper отлично справляется с переключением между ними.

2. GPT-4o извлекает фильтр. Системный промпт требует от модели вернуть строгий JSON-объект: массив жанров, диапазон BPM, набор тональностей, временной диапазон, флаг explicit, настроение и язык. В поисковую систему отправляется только JSON — мы никогда не даём LLM генерировать SQL напрямую.

3. Поиск по каталогу выполняется детерминированно. JSON-фильтр попадает в наш собственный индекс метаданных (MongoDB + денормализованная поисковая проекция). LLM никогда не видит каталог; каталог никогда не видит LLM.

4. Amazon Polly зачитывает результат. Короткое подтверждение («Собрал сет из 23 треков итальянской поп-музыки со средним темпом 138 BPM») проигрывается естественным голосом. Polly Neural стоит 1 200 ₽ за миллион символов — погрешность округления при расчёте на сессию.

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

// System prompt used by FRP (abbreviated)
You are a DJ-assistant router. Return ONLY a JSON object:
{
  "genre": string[],
  "subgenre": string[],
  "bpm_min": number, "bpm_max": number,
  "key_set": string[],              // Camelot notation
  "year_min": number, "year_max": number,
  "explicit_ok": boolean,
  "language": string[],
  "mood": string[]
}
No prose. No track names. No commentary.
If the user is ambiguous, default the bpm range to +/-3 around
the implied style (e.g. "house" -> 120..128).

BPM, тональность и обогащение метаданных

Метаданные лейблов часто бывают неполными, противоречивыми и содержат ошибки. На уровне FRP приходится переанализировать аудио самостоятельно. Мы используем Essentia (библиотеку MTG из Барселоны) для определения BPM, тональности и настроения — она бесплатна, с открытым исходным кодом и при сравнении с Mixed In Key показывает совпадение около 99% на стандартных тестовых наборах MIREX.

Essentia извлекает более 200 аудиодескрипторов на трек — мы храним около 15 из них (BPM, уверенность, тональность по Камелот, энергичность, танцевальность, громкость, спектральная сложность и короткий набор тегов настроения). Анализ запускается один раз при загрузке трека на недорогих CPU-воркерах; четырёхминутный трек обрабатывается за ~12 секунд на скромной виртуальной машине. Для каталога из 720 тыс. треков это примерно 2 400 воркер-часов, распределённых на несколько лет.

Интеграция с Serato, rekordbox и Traktor

Ни один из трёх крупных разработчиков диджейского ПО не предоставляет официальный SDK. Интеграция осуществляется через запись в форматы, которые они поддерживают:

1. Serato хранит подборки как бинарные файлы .crate в папке ~/Music/_Serato_/Subcrates. Точки cue и метки битгрида сохраняются в фреймах ID3 GEOB внутри самих аудиофайлов. Десктопное приложение FRP записывает и то, и другое целиком и сразу при загрузке трека.

2. rekordbox (Pioneer) использует XML-файл библиотеки (rekordbox.xml) и базу данных SQLite в новых версиях. Доступ через XML по-прежнему остаётся надёжным способом для сторонних программ записи.

3. Traktor (Native Instruments) использует коллекционный XML (collection.nml), который сторонние инструменты вроде Lexicon и DJ Conversion Utility уже умеют надёжно обрабатывать.

Серьёзный диджейский пул выпускает сначала синхронизацию с Serato, затем с rekordbox, затем с Traktor. Это порядок долей рынка среди профессиональных диджеев в 2026 году.

Эталонная архитектура (веб, десктоп, мобайл)

FRP построен на понятной четырёхслойной архитектуре, которую мы рекомендуем использовать для любого диджейского продукта с лицензированным каталогом. Границы слоёв можно адаптировать, но не саму структуру.

WebRTC передаёт аудио между диджеем и фанатами и обеспечивает превью с минимальной задержкой, потому что другие технологии слишком медленные. WebRTC держит задержку «от стекла до стекла» на уровне 200–500 мс. RTMP — около 3–5 секунд. Обычный HLS — 10–30 секунд. Для диджея, который работает в реальном времени, только WebRTC воспринимается как «мгновенный» ответ. Подробнее о таком выборе мы рассказываем в нашем гайде про альтернативу Agora.io.

Обзор рынка диджейских пулов — FRP против BPM Supreme, DJcity и Beatport

Если вы сравниваете кастомную разработку с лицензированной подпиской, важно понимать, что предлагают основные игроки рынка. Матрица ниже — наш актуальный обзор по состоянию на апрель 2026 года; перед публикацией цен внутри компании уточните данные у вендора.

Две ключевые ячейки для позиционирования FRP — «распознавание в приложении» и «голосовой ИИ-поиск». У всех игроков рынка они пока пусты — именно поэтому здесь оправдана кастомная разработка.

Лицензирование 720 000 треков — юридический слой

Разработка — это лёгкая часть диджейского пула. Сложнее — договориться о правах на каталог. Каждому треку нужны две лицензии: на мастер-запись (от лейбла — Sony, Universal, Warner, Virgin, BMG и независимых дистрибьюторов) и на композицию (от издателей — через механические права или от общества по коллективному управлению правами). Диджейские пулы обычно заключают с лейблами фиксированную ежемесячную лицензию на промо-использование, рассчитанную на одного пользователя, с отчётностью по количеству загрузок.

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

Хранилище, CDN и масштаб каталога

Для каталога из 720 тыс. треков в формате FLAC-мастеров, а также транскодов MP3-320 и MP3-128, потребуется примерно 20–28 ТБ объектного хранилища. В 2026 году это небольшая цифра; основная нагрузка ложится на исходящий трафик, а не на хранение.

Мульти-CDN-подход (Cloudflare плюс региональный резервный вариант или AWS CloudFront плюс Fastly) — это способ поддерживать стабильную скорость загрузки во всех регионах. Spotify публично сообщал о снижении исходящего трафика примерно на 35% после перехода на Opus и мульти-CDN — аналогичная арифметика работает на любом серьёзном масштабе каталога. Предварительно подписанные URL с коротким TTL и возобновление по байтовым диапазонам решают проблему «отвалился WiFi в клубе» без необходимости писать кастомный клиентский код.

Что касается хранения отпечатков, сами индексированные хэши занимают мало места — около 1–2 КБ на трек. Индекс для 1 млн треков легко помещается на одной машине с большим объёмом RAM. Именно в этой части системы чаще всего возникают излишние усложнения.

Стек, который мы выбрали (и почему)

Точный стек для FRP — и объяснение, почему каждый его элемент находится именно здесь, а не заменяется на правдоподобную альтернативу.

• React + TypeScript для всего клиентского интерфейса. Одна библиотека компонентов, три поверхности. Выбраны вместо Svelte и Vue, потому что глубина рынка труда важна, когда у вас три клиента одновременно.
• Electron для десктопного приложения. Синхронизация с Serato, локальный кэш и офлайн-очередь загрузок требуют доступа к файловой системе, которого браузер предоставить не может.
• React Native для iOS и Android. Мы используем около 70% логики React-компонентов с веб-версии повторно; нативные модули отвечают за захват аудио и мобильные экспорты, как в Serato.
• Node.js + Express для API-шлюза. Легко найти разработчиков, хорошо справляется с нагрузкой, в основном состоящей из операций CRUD и поиска.
• Python-воркеры для машинного обучения и анализа аудио. Здесь работают Essentia, клиент Whisper и индекс аудиоотпечатков.
• MongoDB для хранения метаданных (схема постоянно меняется, когда лейблы добавляют новые поля). MySQL для транзакционных данных — подписок, прав доступа и биллинга.
• WebRTC для аудиосвязи между диджеем и фанатами и для превью. Задержка меньше 500 мс, без дополнительных плагинов.
• OpenAI Whisper + GPT-4o + Amazon Polly для голосового ассистента. Почему именно эти инструменты — объяснили в статье «7 лучших ИИ-решений для аудиоприложений».

Модель затрат для похожей платформы

Ориентировочные диапазоны на 2026 год для продукта уровня FRP — без учёта лицензирования каталога и отчётности перед лейблами. Это оценки Фора Софт по методу Agent-Engineered, который работает быстрее и точнее, чем классические аутсорсинговые подходы; сверяйтесь со своим вендором, а не делайте экстраполяции самостоятельно.

Текущие эксплуатационные расходы после разработки: закладывайте примерно 2–4% выручки от подписок на ИИ-API (Whisper — 0,45 ₽ за минуту, GPT-4o — по текущему тарифу, Polly — 1 200 ₽ за миллион символов) плюс исходящий трафик CDN, который растёт с количеством загрузок. По части ИИ-API у нас есть полноценный материал: «6 лучших библиотек синтетического голоса для разработки приложений».

Подводные камни, которые мы уже прошли за вас

1. Воспринимать распознавание как ML-проект, а не как проект про индексацию. Команды тратят месяцы на обучение всё более сложных фингерпринтеров. При этом выигрыш почти всегда связан с индексом — кардинальностью, распределением хэшей и скоростью шардирования поиска. Начните с простой схемы хэширования и измеряйте результаты.

2. Пускать LLM напрямую к базе данных. Как только модель начинает генерировать поисковый запрос, она начинает выдумывать треки. Маршрутизируйте через строгий JSON и детерминированный поиск; LLM — это парсер, а не извлекатель данных.

3. Игнорировать Serato с первого дня. Интеграция с Serato после запуска — это аврал на шесть-восемь недель без какой-либо пользы для пользователя. Пишите в папку Serato с самого первого релиза.

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

5. Откладывать DRM «на потом». Если один из ваших контрактов с лейблами требует промо-водяных знаков, конвейер загрузки должен создавать отпечатки для каждого пользователя при каждой загрузке. Подключать это к уже работающему каталогу — самая дорогая ошибка, с которой мы сталкиваемся.

Метрики, которые важны для диджейского пула

Метрики качества. Точность распознавания (цель — не менее 98% по top-1 на 5-секундных фрагментах против собственного каталога), точность определения BPM по эталонным данным (не менее 99%), точность определения тональности (не менее 95%), точность распознавания намерения голосовой команды (не менее 92% на отложенной выборке). Эти показатели важны, потому что диджеи проверяют систему уже в первый день — всё, что ниже, воспринимается как «не работает».

Бизнес-метрики. Доля активных диджеев в месяц (D28 ≥ 55% от платящих пользователей), количество загрузок на одного диджея в неделю (≥ 25 — это здоровый показатель), отток (< 4% в месяц), конверсия из бесплатного в платный тариф (≥ 8% среди пользователей с пробным доступом). Если показатели ниже этих порогов — юнит-экономика почти всегда оказывается в минусе после выплат лейблам.

Метрики надёжности. p95 поиска по каталогу ≤ 250 мс, p95 распознавания ≤ 1,2 с, доля успешных возобновлений загрузок ≥ 99,5%, доля сессий десктопного приложения без сбоев ≥ 99,8%. Клубный Wi-Fi не прощает ничего другого.

Когда НЕ стоит строить это с нуля

Кастомный диджейский пул окупается, только если у вас есть реальное преимущество в каталоге, сообществе или интеграции с ПО. Если такого преимущества нет, вы заплатите за то, чтобы заново создать то, что и так работает лучше.

Не стройте, когда: ваш каталог будет содержать меньше 50 тыс. треков; у вас нет партнёрства с лейблом или дистрибьютором; вы планируете привлечь менее 2 000 платящих диджеев за первый год; или ваше преимущество — только «интерфейс приятнее, чем у BPM Supreme». В этом случае лучше адаптировать лицензированный продукт под свои нужды.

Стройте, когда: вы лейбл или дистрибьютор с эксклюзивными правами на каталог, недоступными другим участникам рынка; у вас есть преимущество в лицензировании в определённых регионах (например, Латинская Америка, Корея, страны MENA — все они недостаточно охвачены); или ваш продукт — это не просто библиотека с плеером, а полноценный инструмент для работы диджея с собственной медиатекой.

Частые вопросы

Что почитать дальше

Готовы построить собственную аудиоплатформу на базе ИИ?

Franchise Record Pool — это доказательство того, что диджейский пул в 2026 году — это три инженерные дисциплины, соединённые воедино: лицензированный каталог, сервис распознавания на основе отпечатков и узкая LLM, обёрнутая вокруг детерминированного поиска. По отдельности ни одна из них не является чем-то необычным; ключевое преимущество — в том, чтобы объединить их в единый продукт, которым профессиональные диджеи реально пользуются во время выступлений.

Если ваш продукт ориентирован на аудио — диджейский пул, music-tech SaaS, караоке-платформа, инструмент для вещания, бэкенд для радио — Фора Софт — это команда, которая уже делала подобное и честно скажет, где объём работ занижен, а где могут возникнуть сложности.

Начните с 30-минутного звонка. Мы вернёмся либо с оценкой объёма по статьям, либо с честной причиной, почему лучше делать это как white-label-сборку. В любом случае вы сэкономите деньги.