HT-Demucs FT의 ONNX 익스포트: iOS, Android, 웹을 위한 첫 동작 익스포트 구축기 — 9개의 오픈 Hugging Face 모델과 재현 가능한 MUSDB18-HQ 벤치마크 (2026)

요약(TL;DR). Hugging Face에 10개의 스템 분리 자산을 오픈소스로 공개했으며, 그중에는 MUSDB18-HQ에서 1위를 차지한 오픈소스 보컬 분리기인 HT-Demucs FT의 첫 동작 ONNX 익스포트가 포함됩니다. "demucs onnx"의 모든 기존 시도는 동일한 4가지 블로커에서 멈췄으나, 우리는 이 모두를 해결했습니다. 그 결과물은 onnxruntime에서 CPU/CoreML/CUDA/DirectML 환경으로 추론 시 PyTorch 없이 실행되며, CPU에서 PyTorch보다 1.31배 빠르고, 원본과 수치적으로 동등합니다(4개 스템 전체에 걸친 최대 절대 차이: 0.000163).

아래에서는 이번에 공개한 내용, 그 의미, 그리고 ONNX 익스포트를 실제로 어떻게 완성했는지에 대한 엔지니어링 기록을 다룹니다.

---

이번 주에 공개한 모든 것

모두 MIT 라이선스이며, StemSplitio 조직 페이지에서 확인할 수 있습니다.

헤드라인: 이 ONNX 저장소들은 우리가 아는 한 Hugging Face 상에서 HT-Demucs FT의 첫 동작 ONNX 익스포트입니다. "첫 시도"가 아니라 — 실제로 로드되고, 실행되며, 올바른 값을 내고, 동등성이 검증된 벤치마크와 함께 출시되는 첫 번째입니다.

---

우리가 이걸 한 이유

벤치마킹의 공백

2026년에 스템 분리 모델을 고르려고 시도해 봤다면 혼란스러운 상황을 마주했을 것입니다. 모든 모델 저장소는 자기 모델이 "최첨단(state of the art)"이라고 주장합니다. 재현 가능한 벤치마크를 공개하는 곳은 거의 없습니다. 같은 모델들을 같은 하드웨어에서 같은 지표로 서로 테스트한 사례는 더더욱 적습니다.

우리는 stem-separation-benchmark-2026을 공개하며 이 문제를 해결했습니다 — MUSDB18-HQ에서 htdemucs, htdemucs_ft, htdemucs_6s, mdx_extra_q, mdx_net_inst_hq3에 대한 SDR / ISR / SIR / SAR 점수 850개 행과 전체 평가 파이프라인을 오픈소스로 공개했습니다. 누구나 클론하고, 다시 실행하고, 우리 수치에 도전할 수 있습니다.

핵심 결과: htdemucs_ft가 오픈소스 보컬 분리기 1위(보컬 SDR 중앙값 9.19 dB), mdx_extra_q가 오픈소스 드럼/베이스/기타 분리기 1위(각각 11.49 / 11.42 / 7.67 dB)입니다. 스템마다 최적의 모델은 다릅니다.

ONNX의 공백

더 큰 문제는 다음과 같았습니다. iOS, Android, 또는 브라우저에서 HT-Demucs FT를 사용하고 싶다면, 그럴 수 없었습니다. PyTorch의 모바일 지원은 거칠고, MPS/CUDA는 서버 사이드 전용이며, 명백한 정답인 — ONNX — 는 아직 시도된 적이 없었습니다.

demucs 저장소에는 ONNX 익스포트를 요청하는 GitHub 이슈가 최소 4개 열려 있습니다. 반쯤 망가진 포크가 여러 개 있고, 2023년에 머지되지 않은 PR이 하나 있으며, M1 이상 Mac이 필요한 MLX 실험 몇 개가 있을 뿐입니다. "그냥 동작하는" 것은 없었습니다.

그 이유는 다음과 같습니다. HT-Demucs는 PyTorch에서는 무해해 보이지만, ONNX 익스포터를 비명백한 방식으로 망가뜨리는 아키텍처 선택들을 포함합니다. 우리는 4가지를 모두 부딪치고 해결했으며, 이것이 이 글의 나머지 내용입니다.

---

HT-Demucs FT가 모든 ONNX 익스포터를 망가뜨리는 방식

먼저 torch.onnx.export를 시도했고, 그 다음 torch.onnx.dynamo_export를 시도했습니다. 둘 다 서로 다른 곳에서 실패했습니다. 다음은 전체 블로커 목록과 각각의 해결 방법입니다.

Blocker 1: complex64 STFT 출력

HT-Demucs는 Short-Time Fourier Transform(spec.py::spectro)으로 시작합니다.

z = torch.stft(x, n_fft=4096, hop_length=1024, window=hann,
               win_length=4096, normalized=True, center=True,
               return_complex=True, pad_mode="reflect")

이 return_complex=True는 complex64 텐서를 반환합니다. CoreML의 MIL에는 복소 dtype이 없습니다. ONNX의 STFT 연산(opset 17+) 역시 복소 출력을 지원하지 않습니다. 그래프의 다운스트림 slice/transpose 연산이 모두 즉시 실패합니다.

해결책. torch.stft를 sin/cos 커널을 사용하는 Conv1d로 대체하여 두 개의 실수 채널을 직접 출력하게 만듭니다.

def _make_stft_kernels(n_fft: int) -> tuple[torch.Tensor, torch.Tensor]:
    n = torch.arange(n_fft, dtype=torch.float64)
    window = torch.hann_window(n_fft, periodic=True, dtype=torch.float64)
    norm = 1.0 / math.sqrt(n_fft)
    k = torch.arange(n_fft // 2 + 1, dtype=torch.float64).unsqueeze(1)
    angles = 2 * math.pi * k * n.unsqueeze(0) / n_fft
    cos = (window * torch.cos(angles)) * norm
    sin = (window * -torch.sin(angles)) * norm   # negative for forward STFT
    return cos.float().unsqueeze(1), sin.float().unsqueeze(1)

class RealSTFT(nn.Module):
    def forward(self, x: torch.Tensor) -> torch.Tensor:
        x = F.pad(x.reshape(-1, 1, x.shape[-1]), (n_fft // 2,) * 2, mode="reflect")
        real = F.conv1d(x, self.cos_kernel, stride=self.hop_length)
        imag = F.conv1d(x, self.sin_kernel, stride=self.hop_length)
        return torch.stack([real, imag], dim=1)   # (..., 2, F, T) real

torch.stft와 비교해 직접 검증한 결과 최대 절대 차이 5 × 10⁻⁶입니다. 역변환의 경우 ConvTranspose1d와 오버랩-애드(overlap-add) 윈도우 제곱 엔벨로프(window-squared envelope)를 사용하여 동일한 방식으로 처리합니다.

이 수정 이후, _magnitude와 _mask의 모든 view_as_real / view_as_complex는 실수 채널 텐서를 전체 forward pass에 통과시키도록 다시 작성됩니다. 그래프 어디에도 복소 텐서가 없습니다.

Blocker 2: model.segment의 fractions.Fraction

사전 학습된 htdemucs_ft는 세그먼트 길이를 Fraction(39, 5)(= 7.8초)로 저장합니다. Dynamo는 Fraction 연산을 추적할 수 없으며 — torch._dynamo.exc.Unsupported: call_function UserDefinedClassVariable(<class 'fractions.Fraction'>)를 발생시킵니다.

해결책. 익스포트 전에 float로 강제 변환합니다.

if isinstance(model.segment, Fraction):
    model.segment = float(model.segment)   # 7.8

간단합니다. 추론 시 수학적으로 동일합니다.

Blocker 3: 크로스 트랜스포머의 random.randrange

CrossTransformerEncoder._get_pos_embedding은 Python의 random.randrange를 호출합니다.

def _get_pos_embedding(self, T, B, C, device):
    if self.emb == "sin":
        shift = random.randrange(self.sin_random_shift + 1)
        return create_sin_embedding(T, C, shift=shift, ...)

추론 시에는 sin_random_shift=0이므로 random.randrange(1)은 항상 0을 반환합니다 — no-op입니다. 하지만 ONNX 익스포터는 여전히 Python의 random 모듈을 들여다볼 수 없어 실패합니다.

해결책. 메서드 자체를 몽키 패치하여 shift=0을 하드코딩합니다.

def _get_pos_embedding_no_random(self_, T, B, C, device):
    if self_.emb == "sin":
        return create_sin_embedding(T, C, shift=0, device=device,
                                    max_period=self_.max_period)
    # ... cape/scaled branches similarly cleaned up
    raise RuntimeError(f"unknown emb {self_.emb}")

for m in model.modules():
    if isinstance(m, CrossTransformerEncoder):
        m._get_pos_embedding = types.MethodType(_get_pos_embedding_no_random, m)

추론 시 수학적으로 동일하며, 익스포트가 가능합니다.

Blocker 4: aten::_native_multi_head_attention

최신 PyTorch의 nn.MultiheadAttention.forward는 사전 조건이 충족되면 융합된 C++ 커널(_native_multi_head_attention)로 단축 경로를 탑니다. 이 커널은 어떤 opset에도 ONNX symbolic이 없으며, 그래서 익스포터가 UnsupportedOperatorError를 던집니다.

해결책. 각 nn.MultiheadAttention 인스턴스의 forward를 안정적인 ONNX symbolic을 가진 일반 연산(Linear, bmm, softmax, transpose)만 사용하는 드롭인 구현으로 대체합니다.

def _onnx_friendly_mha_forward(self_, query, key, value, ...):
    if self_.batch_first:
        query, key, value = (t.transpose(0, 1) for t in (query, key, value))
    tgt_len, bsz, embed_dim = query.shape
    head_dim = embed_dim // self_.num_heads

    if self_._qkv_same_embed_dim and torch.equal(query, key) and torch.equal(key, value):
        q, k, v = F.linear(query, self_.in_proj_weight, self_.in_proj_bias).chunk(3, dim=-1)
    else:
        # cross-attention: three separate matmuls
        ...

    q = q.contiguous().view(tgt_len, bsz * self_.num_heads, head_dim).transpose(0, 1)
    k = k.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)
    v = v.contiguous().view(-1,      bsz * self_.num_heads, head_dim).transpose(0, 1)

    attn_weights = F.softmax(torch.bmm(q * head_dim ** -0.5, k.transpose(1, 2)), dim=-1)
    attn_output  = torch.bmm(attn_weights, v).transpose(0, 1).contiguous().view(tgt_len, bsz, embed_dim)
    return self_.out_proj(attn_output), None

모델의 모든 MHA 인스턴스에 패치를 적용합니다. 동등성 검증 결과: 융합된 빠른 경로 대비 최대 차이 1 × 10⁻⁶.

결과

네 가지 패치를 모두 적용한 뒤, torch.onnx.export(레거시 익스포터, opset 17, dynamo=False)는 6.5초 만에 깔끔한 316MB .onnx 파일을 작성합니다. onnx.checker.check_model을 통과하고, 24,765개의 노드를 포함하며, onnxruntime에서 바로 실행됩니다.

4개 스템 모두 공식 PyTorch htdemucs_ft의 fp32 출력과 수학적으로 동등하며, 부동소수점 누적 드리프트로 설명되는 1e-3 허용오차보다 훨씬 낮습니다.

익스포트된 ONNX 모델은 동일 하드웨어에서 PyTorch 기준 대비 CPU에서 31% 더 빠릅니다 — 7.8초 세그먼트 기준 1.59초 대 2.09초 — ONNX Runtime의 그래프 옵티마이저가 정리된 그래프를 PyTorch의 eager 런타임보다 더 적극적으로 폴드(fold)하고 퓨즈(fuse)할 수 있기 때문입니다.

---

플랫폼별 의미

동일한 .onnx 파일이 onnxruntime이 동작하는 곳이면 어디서나 실행됩니다. 다음은 플랫폼별 빠른 시작 가이드입니다.

Python (모든 OS, CPU 또는 GPU)

import onnxruntime as ort
import soundfile as sf

sess = ort.InferenceSession("htdemucs_ft_vocals.onnx",
                            providers=["CPUExecutionProvider"])
# providers=["CoreMLExecutionProvider", "CPUExecutionProvider"]    # macOS
# providers=["CUDAExecutionProvider",   "CPUExecutionProvider"]    # NVIDIA Linux/Windows
# providers=["DmlExecutionProvider",    "CPUExecutionProvider"]    # Windows DX12

audio, sr = sf.read("song.mp3", dtype="float32", always_2d=True)
stems = sess.run(["stems"], {"mix": audio.T[None].astype("float32")})[0]
sf.write("vocals.wav", stems[0, 3].T, sr)   # row 3 = vocals

해당 저장소: StemSplitio/htdemucs-ft-vocals-onnx.

iOS / Swift

import onnxruntime_objc

let opts = try ORTSessionOptions()
try opts.appendCoreMLExecutionProvider(with: ORTCoreMLExecutionProviderOptions())

let env = try ORTEnv(loggingLevel: .warning)
let session = try ORTSession(
    env: env,
    modelPath: Bundle.main.path(forResource: "htdemucs_ft_vocals", ofType: "onnx")!,
    sessionOptions: opts
)
// audio: 1 × 2 × 343980 Float32 buffer, then session.run(...)

316MB의 .onnx(또는 더 작은 전문 모델)를 앱 번들에 포함시키세요. CoreML 실행 공급자는 가능한 경우 Apple Neural Engine에서 무거운 연산을 처리합니다.

Android / Kotlin

import ai.onnxruntime.OrtEnvironment
import ai.onnxruntime.OrtSession

val env = OrtEnvironment.getEnvironment()
val opts = OrtSession.SessionOptions().apply { addNnapi() }
val session = env.createSession(modelPath, opts)

addNnapi()는 Tensor / Snapdragon / MediaTek NPU에서의 가속 추론을 위한 Android Neural Networks API를 제공합니다.

웹 / onnxruntime-web

import * as ort from "onnxruntime-web";

const session = await ort.InferenceSession.create("htdemucs_ft_vocals.onnx", {
  executionProviders: ["wasm"],
  graphOptimizationLevel: "all",
});
const tensor = new ort.Tensor("float32", audioBuffer, [1, 2, 343980]);
const out = await session.run({ mix: tensor });

네, HT-Demucs FT를 브라우저에서 실행할 수 있습니다. 네, CPU EP보다는 느립니다(WebAssembly 오버헤드). 하지만 사용자에게 설치 없이 동작합니다.

---

성능 수치

Apple M4 Pro(통합 메모리 24GB)에서 3분 길이의 곡을 기준으로 측정했습니다.

단일 전문 ONNX 모델은 동일 스템 기준으로 PyTorch CPU보다 5.7배 빠르며, 품질은 동일합니다. 보컬 제거 앱에 전체 PyTorch 백 대신 htdemucs-ft-vocals-onnx를 출시할 때의 이점은 명확합니다: 더 작은 바이너리, 더 빠른 추론, 동일한 SDR.

---

스템 전문 모델은 어떻게 도출되는가 (재미있는 트릭)

htdemucs_ft "백(bag)"은 사실 4개의 별도 모델로 구성되어 있습니다. 백의 스템별 가중치 행렬은 **원-핫(one-hot)**입니다.

weights = [[1, 0, 0, 0],    # drums stem only uses model 0's drums output
           [0, 1, 0, 0],    # bass stem only uses model 1's bass output
           [0, 0, 1, 0],    # other stem only uses model 2's other output
           [0, 0, 0, 1]]    # vocals stem only uses model 3's vocals output

즉, 백의 드럼 출력은 서브 모델 0의 드럼 출력과 비트 단위로 동일합니다. 따라서 드럼만 필요할 경우, 서브 모델 0만 출시(160MB)해도 640MB 풀 백과 동일한 드럼 품질을 약 1/4의 추론 비용으로 얻을 수 있습니다.

우리는 이를 5개의 별도 Hugging Face 저장소로 노출했습니다: 편의를 위한 풀 백 ONNX 하나(htdemucs-ft-onnx)와, 하나의 스템만 필요한 프로덕션 배포를 위한 4개의 스템별 ONNX 저장소입니다. PyTorch 형제 저장소들에도 같은 트릭이 적용됩니다.

드럼 샘플 추출기를 만든다면 htdemucs-ft-drums-onnx를 출시하세요. 베이스라인 채보기라면 htdemucs-ft-bass-onnx. 보컬 제거기 또는 카라오케 메이커라면 htdemucs-ft-vocals-onnx.

---

다음 단계

이번 작업은 3일간의 ONNX 프로젝트 중 1일차와 2일차에 해당합니다. 3일차 계획은 다음과 같습니다.

1. CoreML 실행 공급자 프로파일링. 우리 테스트에서 24k 노드 그래프의 MLProgram 최초 컴파일이 M4 Pro에서 5분 이상 걸렸습니다. iOS / macOS에서 CoreML EP를 진정으로 빠르게 만들기 위해 MinimumDeploymentTarget, ComputeUnits=CPUAndNeuralEngine, 서브그래프 폴백 규칙을 조사해야 합니다.
2. INT8 동적 양자화. 모델별 onnxruntime.quantization.quantize_dynamic — 일반적으로 파일 크기가 4배 작아지고(각각 약 80MB), 음악 모델의 SDR 하락은 보통 0.3 dB 미만입니다. 이 아키텍처에서 성공한다면 모바일에서의 큰 승리가 될 것입니다.
3. onnxruntime-web 데모 Space Hugging Face 공개. 브라우저 전용 스템 분리, 드래그 앤 드롭, 설치 없음, 서버 없음. 트위터에 공유되고 Awesome-ONNX 리스트에 오를 만한 데모입니다.

해당 작업들이 공개되는 대로 StemSplitio Hugging Face 조직에서 업데이트를 확인하세요.

---

2026년에 PyTorch 실행과 비교해 HT-Demucs ONNX는 어떤가?

런타임을 직접 제어하는 서버 사이드 Python 배포라면 PyTorch도 괜찮습니다 — CPU에서는 ONNX Runtime보다 약간 느리지만, apply_model의 오버랩-애드 헬퍼와 기본적으로 호환됩니다.

그 외 모든 환경 — iOS 앱, Android 앱, 브라우저 도구, 임베디드 장치, 2GB PyTorch 설치를 피하고자 하는 Windows 데스크톱 도구 — 에서는 ONNX가 유일한 길입니다. 이번 주까지 그 길은 막혀 있었습니다. 이제는 아닙니다.

여러분의 제품에 ONNX 저장소와 StemSplit API 중 무엇을 선택할지 결정한다면, 트레이드오프는 다음과 같습니다.

• ONNX 저장소 = 요청당 비용 없음, 인프라 불필요, 그러나 앱에 316MB 이상이 들어가고 사용자 기기의 CPU/배터리를 소모합니다.
• StemSplit API = 초당 과금이지만, 즉시 콜드 스타트, GPU 등급 품질, 모델 번들링 불필요, 버전 관리 불필요.

월 1,000건 이상의 분리를 처리하는 소비자용 앱이라면 보통 총비용과 사용자 경험에서 API가 유리합니다. 일회성 도구나 셀프 호스팅 환경이라면 ONNX 모델이 옳은 선택입니다.

---

StemSplit API 사용해보기 — 동일 모델, 호스팅 제공

316MB 모델을 앱에 출시하거나, GPU 풀을 관리하거나, 오버랩-애드 청킹을 직접 작성하고 싶지 않으신가요? StemSplit API는 이 Hugging Face 저장소들에서 볼 수 있는 동일한 htdemucs_ft 모델을 크레딧, 큐잉, 대시보드와 함께 제공합니다.

• 🌐 stemsplit.io — 제품 홈
• 📘 개발자 문서 — 여기서 시작
• 🔌 API 레퍼런스 — 전체 엔드포인트 목록
• 📚 가이드 & 레시피 — 일반적인 통합 예시

curl -X POST https://stemsplit.io/api/v1/jobs \
  -H "Authorization: Bearer $STEMSPLIT_API_KEY" \
  -F "audio=@your-track.mp3" \
  -F "model=htdemucs_ft"

혹은 동일한 모델 패밀리를 오늘 바로 제공하는 노코드 도구를 사용해보세요.

• 🎤 Vocal Remover — 어떤 곡에서든 몇 초 만에 보컬 제거
• 🎶 Karaoke Maker — 한 번에 인스트루멘탈 + 아카펠라
• 🎙️ Acapella Maker — 깨끗한 보컬 분리
• 📺 YouTube Stem Splitter — URL 붙여넣기, 4 스템 받기
• 🎛️ Stem Splitter — 범용 4 스템 분리

---

FAQ

2026년에 iOS와 Android에서 사용하기 위해 HT-Demucs FT를 ONNX로 익스포트할 수 있나요?

네 — 2026년 5월 기준, StemSplitio/htdemucs-ft-onnx는 4 스템 htdemucs_ft 풀 백의 첫 동작 ONNX 익스포트를 제공합니다. iOS(CoreML EP)와 Android(NNAPI EP)의 onnxruntime-mobile에서 PyTorch 원본과 동일한 수치 출력으로 동작합니다. 이전 시도들은 htdemucs_ft가 복소 텐서, Python fractions.Fraction, random.randrange, 그리고 PyTorch의 융합된 멀티 헤드 어텐션 커널을 사용하기 때문에 실패했습니다 — 모두 표준 ONNX 익스포터가 처리를 거부하는 요소들입니다. 이번 릴리스는 네 가지 블로커를 모두 패치하고 최대 절대 차이 1.63 × 10⁻⁴ 이내로 동등성을 검증합니다.

ONNX 익스포트는 PyTorch HT-Demucs FT 모델 대비 얼마나 정확한가요?

정상적인 부동소수점 누적 드리프트 범위 내에서 fp32 비트 동등 수준입니다. 구체적으로 ONNX Runtime 출력과 PyTorch 출력 사이의 최대 절대 차이는 drums에서 0.000163, bass에서 0.000011, other에서 0.000739, vocals에서 0.000008입니다 — 모두 fp32 재정렬로 일반적으로 설명되는 0.001 허용오차보다 훨씬 낮습니다. stem-separation-benchmark-2026 MUSDB18-HQ 테스트 세트의 SDR 점수는 PyTorch 기준선과 동일합니다.

HT-Demucs FT가 ONNX로 실행될 때 정말 PyTorch보다 빠른가요?

CPU 기준 그렇습니다 — M4 Pro에서 7.8초 세그먼트당 1.59초 대 2.09초로 약 1.31배 빠릅니다. ONNX Runtime의 그래프 옵티마이저가 정리된 그래프를 PyTorch의 eager 런타임보다 더 적극적으로 폴드하고 퓨즈할 수 있기 때문입니다. GPU에서는 PyTorch와 ONNX Runtime + CUDA가 거의 비슷하며, 둘 다 CPU 대비 큰 차이로 앞섭니다. 더 큰 이득은 풀 백 대신 단일 전문 모델(drums/bass/other/vocals)을 출시하는 데서 옵니다 — 이들은 스템별 동일 품질로 풀 백보다 약 4배 빠릅니다.

보컬 제거 웹 앱을 위해 브라우저에서 HT-Demucs FT를 실행하는 가장 좋은 방법은 무엇인가요?

StemSplitio/htdemucs-ft-vocals-onnx를 onnxruntime-web과 함께 사용하세요. WebAssembly 실행 공급자가 전체 모델을 지원합니다. 네이티브보다 지연 시간이 높을 것으로 예상되지만(브라우저 샌드박싱 오버헤드), 설치가 필요 없고 서버 비용이 없습니다. 프로덕션 트래픽이라면 StemSplit API가 보통 더 좋은 경제성과 UX를 제공합니다 — 동일 모델, GPU 가속, 초당 과금.

직접 ONNX HT-Demucs 모델을 처음부터 학습시킬 수 있나요?

네 — 공식 demucs 저장소는 학습 코드를 제공합니다. 학습된 .th 체크포인트를 확보한 후, 우리의 coreml-conversion 스크립트에 있는 패치를 그대로 적용할 수 있습니다. 익스포트 파이프라인을 demucs-onnx Python 패키지로 오픈소스화하는 것도 검토 중입니다 — 유용하다고 생각하시면 StemSplitio 모델 저장소의 아무 곳에서나 디스커션을 열어주세요.

---

3일차 알림 받기

Hugging Face의 StemSplitio 조직을 구독하거나 벤치마크 데이터셋을 워치하세요 — INT8 양자화 변형, CoreML 프로파일링 기록, 브라우저 데모 Space는 그곳에 가장 먼저 공개될 예정입니다.

이 모델들로 무언가를 만들고 있다면, 듣고 싶습니다. 저장소 어디에서든 디스커션을 열거나 stemsplit.io/contact로 연락주세요.

---

이번 릴리스의 모든 결과물은 MIT 라이선스입니다. 원본 HT-Demucs는 Rouard, Massa & Défossez (Meta AI)의 작업이며, 연구에 모델을 사용하실 경우 그분들의 ICASSP 2023 논문을 인용해 주세요.