Інтеграція AI-розділення аудіо: Source Separation для бізнесу

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Інтеграція AI-розділення аудіо: Source Separation для бізнесу
Середній
~2-3 дні
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

Уявіть: у вас запис концерту, де вокал зливається з гітарою та ударними. Зробити чисту фонограму для караоке — без AI неможливо. Старі методи (ICA, NMF) дають артефакти, а ручна обробка займає години. Ми вирішуємо це завдання за допомогою сучасних нейромереж. Наш досвід — понад 5 років в аудіообробці, більше 30 проєктів із впровадження source separation у медіа та музичний продакшн. Гарантуємо якість розділення та відповідність вашим термінам.

Source separation — виділення окремих джерел звуку зі змішаного сигналу. Це застосовується в музичному продакшні (стеми), обробці мовлення (видалення фонової музики), відеопостпродакшні та ремастерингу архівних записів.

Які проблеми вирішуємо?

Низька якість розділення. Старі методи (ICA, NMF) дають сильні артефакти. Сучасні моделі на основі глибокого навчання — Demucs, Spleeter, MDX-Net — досягають SDR > 9 dB, що означає чисте розділення без помітних сторонніх шумів.

Швидкість обробки. Для пакетної обробки сотень треків критична продуктивність. Spleeter працює в 100 разів швидше реального часу на GPU, Demucs — в 1.5 раза. Ми оптимізуємо пайплайни під ваше обладнання.

Інтеграція в існуючі процеси. API на FastAPI, пакетна обробка через черги, підтримка популярних форматів — усе це реалізуємо під ключ.

Як обрати модель для розділення аудіо?

Вибір залежить від трьох факторів: цільові стеми, необхідна якість та швидкість. У таблиці — порівняння основних моделей:

Модель Тип розділення Якість (SDR) Швидкість
Demucs v4 (htdemucs) Вокал/барабани/бас/інше 9.0 dB 1.5× realtime на GPU
Spleeter (Deezer) 2/4/5 стемів 6.8 dB 100× realtime
Open-Unmix (UMX) 4 стеми 7.2 dB 10× realtime
MDX-Net Конкурсний (MDX Challenge) 9.5 dB 2× realtime
BS-RoFormer SOTA 10.1 dB 0.8× realtime

SDR (Signal-to-Distortion Ratio) — основна метрика: вище = чистіше розділення.

Чому Demucs v4 — найкращий вибір для продакшену?

Demucs v4 (htdemucs) дає найкращий баланс якості та швидкості серед open-source рішень. Він навчений на великих датасетах і стабільно працює на будь-яких жанрах. Нижче — порівняння моделей за latency (час обробки 1 хвилини аудіо на GPU A100):

Модель Latency (сек) Споживання VRAM
Demucs v4 0.8 2.1 ГБ
MDX-Net 1.2 3.8 ГБ
Spleeter 0.1 1.0 ГБ

Для production ми рекомендуємо Demucs v4 або його полегшену версію htdemucs_ft.

Що дає інтеграція Demucs в конвеєр обробки?

Ми використовуємо Demucs v4 у продакшені. Нижче — приклад класу для інференсу:

import torch
from demucs.pretrained import get_model
from demucs.apply import apply_model
from demucs.audio import AudioFile, save_audio
import torchaudio

class AudioSourceSeparator:
    def __init__(self, model_name: str = "htdemucs"):
        self.model = get_model(model_name)
        self.model.eval()
        if torch.cuda.is_available():
            self.model.cuda()

    def separate(
        self,
        audio_path: str,
        output_dir: str,
        stems: list[str] = None  # None = всі стеми
    ) -> dict[str, str]:
        """Розділяємо трек на стеми, повертаємо шляхи до файлів"""
        wav = AudioFile(audio_path).read(
            streams=0,
            samplerate=self.model.samplerate,
            channels=self.model.audio_channels
        )
        ref = wav.mean(0)
        wav = (wav - ref.mean()) / ref.std()

        sources = apply_model(
            self.model,
            wav[None],
            device="cuda" if torch.cuda.is_available() else "cpu",
            progress=True,
            num_workers=2
        )[0]
        sources = sources * ref.std() + ref.mean()

        result = {}
        available_stems = self.model.sources  # ['drums', 'bass', 'other', 'vocals']
        target_stems = stems or available_stems

        for stem, source in zip(available_stems, sources):
            if stem in target_stems:
                output_path = f"{output_dir}/{stem}.wav"
                save_audio(source, output_path, samplerate=self.model.samplerate)
                result[stem] = output_path

        return result

Розділення мовлення від фонової музики

Для контент-обробки ми використовуємо модель htdemucs_ft (fine-tuned на вокал). Приклад:

from demucs.pretrained import get_model

class SpeechFromMusicExtractor:
    """Виділення мовлення з відео"""

    def __init__(self):
        self.model = get_model("htdemucs_ft")

    async def process_video_audio(
        self,
        video_path: str,
        output_speech: str,
        output_music: str
    ) -> dict:
        import subprocess
        audio_path = video_path.replace(".mp4", "_audio.wav")
        subprocess.run([
            "ffmpeg", "-i", video_path,
            "-ac", "2", "-ar", "44100",
            "-vn", audio_path
        ], check=True)
        stems = self.separate(audio_path, output_dir="/tmp/stems")
        speech_stems = ["vocals"]
        music_stems = ["drums", "bass", "other"]
        return {
            "speech": stems.get("vocals"),
            "music_components": {k: stems[k] for k in music_stems if k in stems}
        }

Процес роботи

  1. Аналіз завдання — визначаємо цільові стеми, вимоги до якості та швидкості.
  2. Вибір моделі — підбираємо оптимальну архітектуру (Demucs, MDX-Net, Spleeter).
  3. Інтеграція — вбудовуємо модель у ваш пайплайн (API, batch, реальний час).
  4. Тестування — оцінюємо метрики (SDR, WER) на ваших даних.
  5. Деплой — розгортаємо на GPU/CPU, налаштовуємо моніторинг.

Що входить в роботу

  • Вибір та адаптація моделі.
  • Реалізація API або пакетного обробника.
  • Документація з експлуатації.
  • Навчання команди (1-2 години).
  • Технічна підтримка 1 місяць.

Типові застосування

Музичний продакшн: remixing — ізолюємо барабани або бас для переробки; karaoke — видаляємо вокал, залишаємо інструментал; mastering стемів — обробляємо кожен шар незалежно.

Контент і медіа: видалення фонової музики перед STT — WER знижується з 18% до 4%; ремастер архівних записів — розділення + денойз кожного стема; локалізація відео — ізолюємо мовлення, замінюємо дубляжем.

Постпродакшн: ADR (Automated Dialogue Replacement) — чистий вокал для заміни реплік; музичне оформлення — витяг музики для повторного використання.

Обмеження та нюанси

Demucs працює гірше при:

  • Дуже гучній перкусії поверх мовлення (SDR падає на 2–3 dB).
  • Монозаписах низької якості (< 22 kHz).
  • Складних поліфонічних накладеннях (4+ джерела одночасно).

Для максимальної якості вокалу — mdx_extra або htdemucs_ft. Для швидкості в batch-режимі — Spleeter (в 10–15 разів швидше Demucs на CPU).

Терміни: інтеграція Demucs в пайплайн обробки медіафайлів — 1–2 тижні. Повноцінний сервіс з чергою та веб-інтерфейсом — 3–4 тижні. Вартість розраховується індивідуально, економія часу на обробці знижує витрати до 70% порівняно з ручною працею. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з впровадження AI-розділення — ми допоможемо підібрати рішення під ваші завдання.

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний ASR (Google Speech-to-Text) видає WER 28% на галузевій лексиці, а ціна при таких обсягах стає непідйомною. Завдання — знизити WER нижче 10% і перейти на self-hosted інференс. Така ситуація повторюється в кожному другому проєкті, і ми маємо напрацьований патерн рішення.

Типові технічні проблеми та їх усунення

WER не сходиться до потрібної метрики. Найчастіше винна не архітектура, а дані: шумні аудіо без нормалізації рівня (–23 LUFS замість стандарту), змішані мови в одному каналі, акцент, специфічна доменна лексика. Whisper large-v3 з коробки дає WER 8–12% на чистій українській і провалюється до 25–35% на записах з PSTN-артефактами та вузькосмуговим кодеком G.711.

Діаризація ламається при більш ніж двох спікерах. pyannote/speaker-diarization-3.1 працює стабільно при 2–3 мовцях, але DER (Diarization Error Rate) зростає з 6% до 18–22% при 5+ учасниках конференції. Проблема посилюється перехресними репліками: за замовчуванням min_duration_on=0.1 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

Модель WER (українська, чистий запис) WER (PSTN, кодек G.711) Швидкість інференсу (фактор real-time) Вартість інференсу (1 год аудіо, A10G)
Whisper large-v3 8–10% 25–35% ~0.1x (55 с на 40 хв) ~$0.50
Whisper medium 12–15% 30–40% ~0.3x ~$0.15
Wav2Vec2 XLSR-53 15–18% 28–35% ~0.8x ~$0.08
Whisper large-v3 + fine-tune 4–7% 10–15% ~0.1x ~$0.50

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 12 000 дзвінків/день. Початковий WER на українській з банківською лексикою — 22% (Google STT). Після fine-tuning whisper-medium на 200 годинах розмічених записів через Hugging Face transformers + Seq2SeqTrainer з learning_rate=1e-5, warmup_steps=500 — WER впав до 7.3%. Інференс на одній A10G через faster-whisper з compute_type=float16 обробляє 40-хвилинний дзвінок за 55 секунд. Підсумкова вартість інференсу — $0.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити Whisper на доменних даних?

Коли загальна модель не справляється, fine-tuning — перший інструмент. Мінімальний датасет для помітного покращення — 20–30 годин розміченого аудіо в цільовому домені. Розмітку можна отримати через ітеративний процес: прогнати через базову модель → вручну виправити 10–15% помилок → перенавчити → повторити.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

При fine-tuning обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Модель Латентність (TTFB) Натуральність MOS Клонування Мови
XTTS v2 1.2–2.0 с 4.1–4.3 Так, 3 с референсу 17
StyleTTS2 0.3–0.6 с 4.0–4.2 Так, вимагає адаптації en, + fine-tune
Kokoro-82M 0.08–0.15 с 3.7–3.9 Ні en, ja
Silero TTS 0.05–0.1 с 3.4–3.6 Ні ru, en, de, та ін.
Edge-TTS ~0.4 с (cloud) 4.0 Ні 100+

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

  • Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
  • Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
  • Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
  • Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

  1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
  2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
  3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
  4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
  5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

  • Базова інтеграція готової моделі – 1–2 тижні.
  • Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
  • Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.