⚖️

UVR Mel-Band RoFormer vs Demucs — 음원 분리 모델 비교 분석

카라오케 전용 2-스템 vs 범용 4-스템 — 아키텍처, 학습 데이터, 성능, 실전 선택 기준

핵심 차이 한눈에

UVR Mel-Band RoFormer Karaoke Demucs htdemucs
개발 UVR 커뮤니티 (aufr33+viperx) Meta/Facebook AI Research
모델 크기 913 MB ~80 MB
출력 스템 2개 (리드 보컬 / 카라오케 반주) 4개 (보컬 / 드럼 / 베이스 / 기타)
보컬 정의 리드 보컬만 리드 + 백킹 전체
반주에 백킹 보컬 있음 (의도적) 없음 (전부 보컬로 분류)
아키텍처 순수 주파수 도메인 Transformer 시간+주파수 하이브리드 Transformer
Vocal SDR 10.20 dB (리드만) ~9.20 dB (전체 보컬)
추론 프레임워크 PyTorch (native) PyTorch (native)
라이센스 MIT (audio-separator) MIT

아키텍처 비교

UVR Mel-Band RoFormer:

파형 → STFT → 멜 밴드 분해(60밴드, 50%중복)
→ 시간 Transformer ↔ 주파수 Transformer × 6레이어
→ 마스크 추정 → ISTFT → 분리된 파형

순수 주파수 도메인에서 작동한다. STFT로 스펙트로그램을 만들고, 멜 스케일로 주파수를 분해한 다음 Transformer로 처리한다. 시간·주파수 축을 교대로 처리하는 계층적 구조.

Demucs htdemucs:

파형 → (시간 경로) 1D CNN 인코더 → Cross-Domain Transformer → 1D CNN 디코더
     → (주파수 경로) STFT → 2D CNN 인코더 → Cross-Domain Transformer → 2D CNN 디코더 → ISTFT
     → 두 경로 합산 → 분리된 파형

시간 도메인과 주파수 도메인을 병렬로 처리한다. Cross-Domain Transformer에서 두 도메인 간 정보를 교환한다.

학습 데이터의 결정적 차이

이 두 모델의 가장 큰 차이는 아키텍처가 아니라 학습 데이터의 정의다.

UVR Karaoke:

instruments:

  - karaoke    # 반주 + 백킹 보컬 + 코러스

  - other      # 리드 보컬만

"카라오케" 스템을 학습 타겟으로 쓴다. 이 스템에는 백킹 보컬이 포함된다. 모델은 리드 보컬만 빼고 나머지(반주+코러스)를 보존하는 법을 배운다.

Demucs:

sources = ["drums", "bass", "other", "vocals"]
# vocals = 리드 + 백킹 전부

"보컬" = 사람 목소리 전체. 리드든 백킹이든 다 보컬로 분류한다. 모델은 모든 인간 음성을 추출하는 법을 배운다.

왜 UVR이 10배 이상 큰가 (913MB vs 80MB)

파라미터 수 차이가 크다:

  • UVR Mel-Band RoFormer: 84.2M 파라미터 (dim=384, 6레이어, 8헤드, 60밴드)

  • Demucs htdemucs: 26.3M 파라미터

게다가 UVR 체크포인트는 float32로 저장되어 있다 (파라미터당 4바이트). Demucs도 float32지만 파라미터 수가 적어 파일이 작다. 84.2M × 4B ≈ 337MB가 순수 가중치인데, 옵티마이저 상태와 메타데이터가 포함되어 913MB가 된다.

언제 뭘 써야 하나

UVR Karaoke를 쓰는 경우:

  • 노래방 반주를 만들 때 — 백킹 보컬이 남아서 자연스럽다

  • 리드 보컬만 깨끗하게 추출할 때 — WhisperX 전사 입력 등

  • 음질이 최우선일 때 — SDR이 더 높다

Demucs를 쓰는 경우:

  • 드럼, 베이스, 기타를 개별로 필요로 할 때

  • 리믹스나 마쉬업을 만들 때 — 파트별 조작이 가능

  • 악기 연습 — 특정 파트만 제거

  • 모델 크기가 중요할 때 — 80MB vs 913MB

  • 보컬 전체(리드+백킹)를 완전히 제거해야 할 때

Nightingale에서의 선택

Nightingale은 UVR Karaoke를 기본으로 쓰고, Demucs를 대안으로 제공한다.

# 기본: UVR Karaoke
def separate_stems_uvr(audio_path, work_dir, models_dir):
    separator = Separator(...)
    separator.load_model(KARAOKE_MODEL)
    output_files = separator.separate(audio_path)

# 대안: Demucs
def separate_stems(audio_path, ...):
    model = get_model("htdemucs")
    sources = apply_model(model, wav[None], device=device)
    vocals = sources[vocals_idx]
    instrumental = wav - vocals  # 원본 - 보컬 = 반주

노래방 앱이니까 UVR Karaoke가 기본인 게 맞다. Demucs를 쓰면 코러스까지 빠져서 반주가 빈약해진다.

성능 비교

지표 UVR Karaoke Demucs htdemucs
Vocal SDR 10.20 dB ~9.20 dB
처리 속도 (GPU) 곡 길이의 ~0.3배 곡 길이의 ~0.5배
처리 속도 (CPU) 곡 길이의 ~3배 곡 길이의 ~5배
GPU VRAM 사용 ~2-4 GB ~1-2 GB
첫 로드 시간 느림 (913MB) 빠름 (80MB)

UVR이 SDR은 높지만, 리드 보컬만 분리하는 더 쉬운(?) 태스크를 하는 것처럼 보일 수 있다. 실제로는 반대다 — 리드와 백킹을 구분하는 건 전체 보컬을 분리하는 것보다 어렵다. 같은 음역대, 같은 하모닉 구조를 가진 소리를 분리해야 하니까.

둘 다 써보고 비교하기

# UVR Karaoke
pip install audio-separator[gpu]
audio-separator song.mp3 \
  --model_filename mel_band_roformer_karaoke_aufr33_viperx_sdr_10.1956.ckpt

# Demucs
pip install demucs
demucs song.mp3
# → separated/htdemucs/song/{vocals,drums,bass,other}.wav

UVR은 Instrumental과 Vocals 2개, Demucs는 4개 파일을 출력한다. 같은 곡으로 돌려보면 차이를 바로 느낄 수 있다 — 특히 코러스가 있는 곡에서 반주의 자연스러움이 확연히 다르다.

핵심 개념

1

UVR은 2-스템(리드 보컬/카라오케), Demucs는 4-스템(보컬/드럼/베이스/기타)

2

핵심 차이는 학습 데이터: UVR의 "카라오케"에는 백킹 보컬이 포함됨

3

UVR은 913MB(84.2M params), Demucs는 ~80MB(26.3M params)

4

UVR은 순수 주파수 도메인 Transformer, Demucs는 시간+주파수 하이브리드

5

노래방용은 UVR (코러스 유지), 리믹스용은 Demucs (파트별 조작)

사용 사례

모델 선택 가이드 — 노래방 앱 vs 리믹스 도구 vs 악기 연습 앱별 최적 모델 음원 분리 파이프라인 설계 — 두 모델의 아키텍처 트레이드오프 이해 성능 벤치마크 기준 — SDR, 처리 속도, VRAM, 모델 크기 비교