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-edit одного и того же трека. Поиск, который прячет «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 с тех пор строится на нём.

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

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

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

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 для всего клиентского UI. Одна библиотека компонентов, три поверхности. Выбраны вместо Svelte/Vue, потому что глубина рынка найма важна, когда у вас три клиента параллельно.
• Electron для десктопного приложения. Синхронизации с Serato, локальному кэшу и офлайн-очереди загрузок нужен доступ к файловой системе, который браузер дать не может.
• React Native для iOS и Android. Мы переиспользуем ~70% логики React-компонентов с веба; нативные модули отвечают за захват аудио и мобильные экспорты по аналогии с Serato.
• Node.js + Express для границы API. Легко нанимать, хорошо подходит для нагрузки, в основном состоящей из CRUD и поиска.
• Python-воркеры для ML и аудиоанализа. 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%. Клубный WiFi не прощает ничего другого.

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

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

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

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

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

Вы правда можете определить трек по шумному клубному фрагменту меньше чем за секунду?

Да — против вашего собственного каталога. Хорошо настроенный фингерпринтер в стиле «созвездий» возвращает ответ top-1 на уровне API меньше чем за 500 мс для 5-секундного фрагмента, с точностью 95%+ при клубном уровне шума. Задержку определяет сеть, а не само сопоставление.

Нам использовать ACRCloud или строить свой фингерпринтер?

Сначала коммерческий, если ваш каталог меньше ~150 тыс. треков, а объём распознавания меньше ~10 тыс. вызовов в день; гибрид, как только вы перешагнёте любой из этих порогов. Точка перехода определяется ценой за распознавание и тем, насколько вам важно распознавать треки вне вашего собственного каталога.

Как вы не даёте LLM выдумывать несуществующие треки?

Никогда не позволяйте ей генерировать результаты напрямую. LLM выдаёт только структурированный JSON-фильтр (жанр, диапазон BPM, набор тональностей, диапазон лет, язык). Этот JSON попадает в детерминированный поиск по каталогу, который контролируете вы. Модель не может выдумать трек, потому что вообще не касается списка треков.

Почему для десктопа Electron, а не нативная сборка?

Десктопное приложение переиспользует ~80% веб-кодовой базы, выпускается быстрее и при этом имеет полный доступ к файловой системе для записи в Serato и для очереди загрузок. Нативная разработка (Swift/C++) дала бы нам меньший размер бинарника и чуть меньший расход RAM ценой двух параллельных команд. Для FRP выбор был очевидно в пользу Electron.

Сколько на самом деле стоит работа ИИ-функций на масштабе?

Голосовой ввод через Whisper стоит 0,45 ₽/мин; типичный диджей произносит меньше 3 минут голоса в месяц, так что расшифровка — это копейки. GPT-4o для разбора намерений — это короткий по контексту вызов (< 500 токенов). Зачитывание ответа через Amazon Polly по 1 200 ₽ за миллион символов пренебрежимо мало. В расчёте на активного диджея закладывайте меньше 18 ₽/мес расходов на ИИ-API.

Можете ли вы поддержать rekordbox и Traktor так же, как Serato?

Да — мы написали Serato первым, потому что это лидер рынка профессиональных диджеев. Интеграция с rekordbox делается через запись в rekordbox.xml; интеграция с Traktor — через запись в collection.nml. Каждая — это дополнение на три-пять недель после того, как Serato работает надёжно.

Какой каталог может удержать эта архитектура?

Форма FRP масштабируется до нескольких миллионов треков без архитектурных изменений. Узкие места, по порядку: память индекса отпечатков (решается шардированием), p95 поиска по метаданным (решается отдельным поисковым движком вроде OpenSearch или Meilisearch) и экономика исходящего трафика CDN (решается вторым CDN-провайдером).

Сколько времени от брифа до первого платящего диджея?

Для минимального MVP (веб + iOS, коммерческое распознавание, без голосового ассистента) 4–5 месяцев — это реалистично с agent-engineered-командой. Полный объём уровня FRP занимает 10–14 месяцев. Честный сдерживающий фактор — это переговоры о лицензировании с лейблами, а не разработка.

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

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

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

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

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