Audio and Visual Analysis - ML in Data Science

Audio and Visual Analysis - ML in Data Science

이미지와 소리를 데이터로 읽고, 다시 창작의 언어로 바꾸기

대학원에서 데이터 사이언스를 공부하며 가장 크게 달라진 점은, 이미지와 오디오를 더 이상 “보이는 것”과 “들리는 것”으로만 다루지 않게 되었다는 것이다.

이미지는 픽셀의 배열이고, 오디오는 시간에 따라 변하는 진폭과 주파수의 신호다. 둘 다 감각적으로 경험하는 매체이지만, 머신러닝 프로젝트 안에서는 먼저 다음과 같은 질문으로 바뀐다.

• 무엇이 입력 데이터인가?
• 어떤 노이즈와 결측을 제거해야 하는가?
• 사람이 이해할 수 있는 특징으로 어떻게 변환할 것인가?
• 어떤 모델이 이 데이터 규모와 목적에 맞는가?
• 모델의 결과를 어떤 방식으로 검증할 것인가?
• 결과를 실제 사용 가능한 이미지·오디오·콘텐츠로 어떻게 되돌릴 것인가?

이 글은 앞서 작성한 KR-audio-analysis-mix-mastering-to-MIR-creative-pipeline에서 다룬 오디오 여정을, 대학원 프로젝트의 분석 리포트 관점에서 더 세부적으로 풀어낸 후속 기록이다.

내가 진행한 프로젝트는 크게 두 방향으로 나뉜다.

1. 이미지 분석: 줄노트 이미지에서 반복되는 가로선을 감지·제거하고, 남은 드로잉과 텍스트를 분석하기
2. 오디오 분석: 드럼 원샷 사운드의 음향 특징을 추출하고, 킥·스네어·탐·심벌을 분류하기

두 프로젝트는 서로 다른 데이터를 다뤘지만, 내부 구조는 놀랍도록 비슷했다.

Raw data
    ↓
Preprocessing
    ↓
Feature representation
    ↓
Model / rule-based analysis
    ↓
Evaluation
    ↓
Human review
    ↓
Usable creative or analytical output

1. 프로젝트가 시작되기 전 필요한 기반 지식

분석 프로젝트는 모델을 고르는 일에서 시작하지 않았다. 오히려 모델을 사용하기 전에 데이터를 어떤 형태로 만들고, 무엇을 정답으로 정의하며, 결과를 어떻게 신뢰할 것인지부터 정해야 했다.

1.1 Python과 데이터 처리

공통 기반은 Python이었다. 파일을 읽고, 배열을 다루고, 반복 처리를 자동화하고, 결과를 CSV나 이미지로 저장해야 했다.

• Python 기본 문법과 함수화
• NumPy 배열 연산
• Pandas DataFrame
• 파일·폴더 배치 처리
• Jupyter Notebook과 Google Colab
• Matplotlib 기반 결과 시각화
• 예외 처리와 로그 기록

Folder of files
    ↓ Python batch loop
Loaded arrays / metadata
    ↓ Pandas / NumPy
Feature table
    ↓
Model input + visual report

1.2 선형대수와 통계

이미지와 오디오는 결국 숫자 배열이다. 따라서 벡터, 행렬, 거리, 분산, 공분산을 이해해야 했다.

• 벡터와 행렬
• 평균·분산·표준편차
• 공분산과 상관관계
• 거리와 유사도
• 차원 축소
• 확률 분포
• 가설 검정과 ANOVA
• bias·variance trade-off

PCA를 이용해 고차원 feature를 저차원 공간에 투영하거나, ANOVA F-score로 어떤 특징이 클래스 분리에 기여하는지 확인하는 과정은 단순한 수학 연습이 아니었다. “내가 중요하다고 생각하는 특징이 실제 데이터에서도 유효한가?”를 검증하는 방법이었다.

1.3 신호와 미디어의 구조

이미지 프로젝트에서는 픽셀, 밝기, 경계, 선, 윤곽을 이해해야 했다. 오디오 프로젝트에서는 샘플레이트, 파형, 주파수, 진폭, 시간-주파수 표현을 이해해야 했다.

이 기반 지식이 없으면 라이브러리가 뽑아준 숫자가 무엇을 의미하는지 해석하기 어렵다. 함수가 실행되는 것과 문제를 이해하는 것은 다른 일이었다.

1.4 머신러닝의 기본 구조

모델을 학습시키는 과정은 다음 단계로 분리해서 이해했다.

Problem definition
    ↓
Dataset and labels
    ↓
Train / validation / test split
    ↓
Feature or representation design
    ↓
Model training
    ↓
Hyperparameter tuning
    ↓
Evaluation
    ↓
Error analysis

특히 작은 데이터셋에서는 train accuracy만 보고 성공했다고 판단하면 안 된다. 데이터 누수, 클래스 불균형, 과적합, 잘못된 split, 의미 없는 feature가 결과를 왜곡할 수 있다.

1.5 도메인 지식

결국 가장 중요한 기반 지식은 도메인 자체였다.

• 줄노트의 수평선은 어떤 방향과 길이를 갖는가?
• 드럼의 킥과 스네어는 시간·주파수상 어떤 차이를 보이는가?
• 이미지의 선과 실제 드로잉 획을 어떻게 구분할 것인가?
• 소리의 크기와 음색은 같은 개념인가?

모델은 문제의 의미를 자동으로 이해하지 않는다. 사람이 문제를 올바르게 정의할수록 모델의 입력과 평가 기준도 좋아진다.

2. 프로젝트 A — 줄노트 이미지에서 구조를 분리하기

문제의 시작

2024년 이미지 분석 작업은 줄노트에 그린 낙서와 스케치에서 시작했다. 노트의 수평선은 드로잉과 겹쳐 있었고, 스캔 이미지에는 그림자·노이즈·기울기·불균일한 밝기가 함께 들어왔다.

목표는 단순히 이미지를 깨끗하게 만드는 것이 아니었다.

1. 줄노트의 반복적인 선을 감지한다.
2. 선과 그림을 분리한다.
3. 선을 제거한 이미지 또는 mask를 만든다.
4. 남은 이미지의 윤곽과 밀도를 분석한다.
5. 드로잉과 텍스트를 구분할 수 있는 기반 데이터를 만든다.

Notebook scan
    ├── ruled lines
    ├── drawing strokes
    ├── handwritten text
    ├── shadows / noise
    └── background texture

기술 방식

• OpenCV
• grayscale 변환
• Gaussian blur와 denoising
• Canny edge detection
• Hough Line Transform
• contour detection
• morphology: dilation / erosion
• thresholding
• inpainting
• CNN / U-Net 탐색
• 이미지 분류 모델 비교
• Matplotlib 시각화

도입 방식 1 — 규칙 기반 선 검출

줄노트의 가장 강한 사전 지식은 “대부분의 줄이 수평으로 반복된다”는 것이었다. 따라서 처음부터 무거운 딥러닝 모델을 적용하기보다, 이미지 처리 규칙을 사용해 선 후보를 만들었다.

import cv2
import numpy as np

def detect_ruled_lines(image_path):
    image = cv2.imread(image_path, cv2.IMREAD_GRAYSCALE)
    edges = cv2.Canny(image, 50, 150, apertureSize=3)

    lines = cv2.HoughLinesP(
        edges,
        1,
        np.pi / 180,
        threshold=100,
        minLineLength=100,
        maxLineGap=10
    )

    mask = np.zeros_like(image)

    if lines is not None:
        for line in lines:
            x1, y1, x2, y2 = line[0]
            angle = np.degrees(np.arctan2(y2 - y1, x2 - x1))
            length = np.hypot(x2 - x1, y2 - y1)

            if (abs(angle) < 5 or abs(angle) > 175) and length > 100:
                cv2.line(mask, (x1, y1), (x2, y2), 255, 2)

    return image, edges, mask

이 방식은 데이터가 가진 구조적 규칙을 직접 사용하는 접근이다.

Grayscale image
    ↓
Edge detection
    ↓
Line candidates
    ↓
Angle / length filtering
    ↓
Ruled-line mask

도입 방식 2 — 마스크와 Inpainting

감지한 선을 바로 검은색으로 지우면 이미지가 부자연스러워질 수 있다. 그래서 선 영역을 mask로 만들고 주변 픽셀을 참고해 빈 공간을 채우는 inpainting을 시도했다.

def remove_lines(image, line_mask):
    return cv2.inpaint(
        image,
        line_mask,
        inpaintRadius=3,
        flags=cv2.INPAINT_TELEA
    )

이 단계의 핵심은 “선 제거” 자체보다 결과를 확인할 수 있는 중간 산출물을 남기는 것이었다.

• 원본 이미지
• edge image
• line mask
• inpainted image
• 제거 전후 비교

Original
  ├── edges
  ├── detected line mask
  └── inpainted result

도입 방식 3 — Contour와 형태 분석

선 검출 이후에는 윤곽을 분석했다. 각 contour의 길이, bounding box, aspect ratio, 방향을 기준으로 선과 그림을 구분할 수 있는지 확인했다.

Contour
    ├── arc length
    ├── bounding box
    ├── width / height
    ├── aspect ratio
    ├── orientation
    └── pixel density

이 과정은 이후 드럼 사운드에서 특징을 추출하는 작업과 구조가 같았다. 원본을 바로 분류하지 않고, 문제를 설명할 수 있는 중간 특징을 만든다.

도입 방식 4 — CNN과 U-Net 탐색

규칙 기반 방법만으로 모든 이미지를 처리하기 어려웠기 때문에, 줄과 드로잉의 mask를 학습하는 U-Net 계열 접근도 탐색했다.

Input image
    ↓ encoder
Latent representation
    ↓ decoder + skip connections
Pixel-level line mask
    ↓ threshold
Cleaned / restored image

하지만 U-Net이나 CNN이 자동으로 더 좋은 결과를 보장하지는 않았다. 학습용 mask가 충분하지 않으면 모델은 선이 아니라 스캔 이미지의 배경 특성을 외울 수 있다. 작은 데이터셋에서는 데이터 준비와 라벨 품질이 아키텍처보다 먼저였다.

이미지 분석 아키텍처

graph TD
    A[Notebook image] --> B[Preprocessing]
    B --> C[Grayscale / denoise / threshold]
    C --> D[Edge detection]
    D --> E[Line detection]
    E --> F[Ruled-line mask]
    F --> G[Inpainting]
    C --> H[Contour extraction]
    H --> I[Shape features]
    G --> J[Clean image]
    I --> K[Drawing / text analysis]
    J --> K

이미지 프로젝트에서 얻은 결과

이 프로젝트를 통해 이미지 분석에서 다음을 배웠다.

1. 반복되는 구조가 명확하면 rule-based preprocessing이 강력하다.
2. 모델 입력보다 mask와 라벨을 만드는 일이 더 어렵다.
3. 시각적 결과를 직접 확인할 수 있는 중간 산출물이 필요하다.
4. 선 제거는 복원 문제이기도 하고, 분류를 위한 전처리 문제이기도 하다.
5. 이미지의 “깨끗함”은 픽셀 수치만으로 판단할 수 없다.

이미지 아카이브 아이템

• 줄노트 원본 스캔
• grayscale 변환 결과
• Canny edge 이미지
• Hough line 검출 결과
• ruled-line mask
• inpainting 전후 비교
• contour overlay
• 드로잉·텍스트 분류용 샘플
• CNN/U-Net 학습 구조도
• validation 이미지와 실패 사례

[이미지: 줄노트 원본과 검출된 수평선]
[이미지: edge map → line mask → inpainted image 4단계 비교]
[이미지: contour bounding box와 aspect ratio 시각화]
[이미지: 모델 예측 mask와 실제 mask의 차이]

3. 프로젝트 B — 드럼 사운드를 특징으로 설명하기

이미지 분석을 진행한 뒤 오디오 분석으로 이동했을 때, 문제는 달라 보였지만 사고방식은 이어졌다. 이미지에서 선·윤곽·밀도를 추출했다면, 오디오에서는 에너지·밝기·거칠기·음색을 추출했다.

문제 정의

작은 규모의 드럼 원샷 데이터셋을 다음 네 가지 클래스로 분류하는 것이 목표였다.

• Cymbal
• Kick
• Snare
• Tom

이 프로젝트는 완성된 곡 전체를 분석하는 것이 아니라, 비교적 통제된 단일 타격 샘플을 대상으로 했다. 문제의 범위를 작게 정의했기 때문에 모델의 결과와 feature의 의미를 비교하기 쉬웠다.

데이터 준비

데이터셋은 공개 샘플과 Logic Pro에서 직접 만든 샘플을 함께 사용해 구성했다. 가장 먼저 한 일은 모델을 학습시키는 것이 아니라 사람이 직접 파일을 듣고 라벨을 확인하는 일이었다.

/drum_samples/
├── cymbals/
├── kicks/
├── snares/
└── toms/

기술 방식

• Python
• Librosa
• NumPy
• Pandas
• SciPy
• Scikit-learn
• TensorFlow / Keras
• Matplotlib
• MFCC
• Chroma
• Spectral contrast
• Spectral centroid
• Spectral bandwidth
• Zero-crossing rate
• RMS energy
• Mel Spectrogram
• PCA
• ANOVA F-score
• SVM
• Random Forest
• Gradient Boosting
• CNN

전처리

각 오디오 파일을 일정한 방식으로 읽고, 필요에 따라 trim·normalise·resample했다. 이 단계가 통일되지 않으면 모델은 드럼 음색이 아니라 파일의 길이·음량·녹음 환경을 학습할 수 있다.

.wav input
    ↓ decode
sample rate alignment
    ↓
trim / silence control
    ↓
normalisation
    ↓
feature extraction

특징 그룹 1 — 시간 영역

RMS Energy

RMS는 신호의 평균적인 에너지와 관련된 지표다. 소리가 얼마나 강한지 파악하는 데 유용하지만, 소리의 정체성을 단독으로 설명하지는 못한다.

Zero-Crossing Rate

파형이 0을 가로지르는 빈도를 계산한다. 노이즈성, 거친 질감, 고주파 성분에 대한 단서가 될 수 있다.

Waveform
    ↓ count sign changes
Zero-crossing rate
    ↓
noisiness / roughness clue

특징 그룹 2 — 주파수 영역

Spectral Centroid

스펙트럼의 무게중심을 계산해 소리가 얼마나 밝게 들리는지 설명하는 데 사용했다. 스네어와 심벌처럼 고주파 성분이 강한 소리와 킥처럼 저주파 중심인 소리를 구분하는 데 도움이 될 수 있다.

Spectral Bandwidth

주파수 에너지가 얼마나 넓게 분포하는지 나타낸다. 음색의 폭과 복잡성을 비교하는 단서다.

Spectral Contrast

각 주파수 대역의 peak와 valley 차이를 통해 소리의 대비와 구조를 파악한다.

특징 그룹 3 — 음색과 지각

MFCC

MFCC는 사람의 청각적 지각과 관련된 스펙트럼 정보를 압축해 음색을 설명하는 대표적인 feature다. 드럼의 pitch를 직접 알려주는 값이라기보다, 소리의 질감과 timbre를 비교하는 acoustic fingerprint에 가깝게 사용했다.

Chroma

드럼 원샷에서는 tonal feature의 비중이 제한적일 수 있지만, 다른 음악 데이터로 확장할 때 화성·음높이와 관련된 정보를 다룰 수 있는 기반이 된다.

Feature extraction pipeline

graph TD
    A[Drum .wav] --> B[Librosa load]
    B --> C[Time domain]
    B --> D[Frequency domain]
    B --> E[Perceptual / timbral]
    C --> F[RMS / ZCR]
    D --> G[Centroid / bandwidth / contrast]
    E --> H[MFCC / chroma]
    F --> I[Pandas feature table]
    G --> I
    H --> I
    I --> J[EDA / PCA / ANOVA]
    I --> K[Traditional ML]

4. 두 모델의 비교 — Feature Engineering vs CNN

접근 A. 사람이 설계한 특징과 전통적인 모델

첫 번째 파이프라인은 도메인 지식을 사용해 오디오를 수치화하고, 그 표를 전통적인 분류기에 넣는 방식이었다.

Audio
    ↓
Handcrafted acoustic features
    ↓
Feature table
    ↓
SVM / Random Forest / Gradient Boosting
    ↓
Drum class

이 접근은 각 feature가 무엇을 의미하는지 설명하기 쉽다.

• centroid가 높으면 더 밝은 소리일 가능성
• ZCR이 높으면 더 거칠거나 노이즈성일 가능성
• RMS가 높으면 에너지가 큰 소리일 가능성
• MFCC가 다르면 timbre가 다를 가능성

접근 B. Mel Spectrogram과 CNN

두 번째 파이프라인은 오디오를 시간-주파수 이미지인 Mel Spectrogram으로 변환한 뒤 CNN이 패턴을 학습하도록 했다.

Audio waveform
    ↓ STFT / Mel filter bank
Mel Spectrogram image
    ↓ convolution / pooling
Learned representation
    ↓ dense classifier
Drum class

이 방식은 사람이 어떤 feature가 중요한지 명시하지 않아도 된다는 장점이 있다. 하지만 작은 데이터셋에서는 모델의 파라미터 수와 데이터 규모가 맞지 않아 과적합 위험이 커진다.

비교 결과

당시 실험에서는 feature engineering 기반 모델이 CNN보다 훨씬 안정적인 결과를 보였다.

이 결과는 모든 오디오 문제에서 전통적인 모델이 더 낫다는 뜻은 아니다. 작은 데이터셋과 제한된 클래스, 비교적 통제된 원샷 샘플이라는 조건에서 feature engineering이 유리했다는 뜻이다.

CNN 결과를 그대로 믿지 않은 이유

CNN은 약 1.4 million parameters를 사용했고, 대부분이 첫 번째 dense layer에 집중되어 있었다. 데이터가 충분하지 않은 상태에서 모델은 드럼의 일반적인 음향 법칙보다 학습 데이터의 잡음과 특수성을 외울 가능성이 높았다.

따라서 accuracy가 낮다는 사실만으로 CNN이라는 방법 전체를 폐기할 수는 없지만, 다음은 분명해졌다.

• 데이터 규모에 비해 모델이 너무 크지 않은가?
• feature engineering으로 이미 분리 가능한 문제에 복잡한 모델을 쓰고 있지 않은가?
• spectrogram을 이미지로 변환하는 과정에서 중요한 정보가 손실되지 않았는가?
• validation set이 실제 사용 환경을 대표하는가?
• 결과를 사람의 청취로 확인했는가?

평가 아키텍처

graph LR
    A[Curated audio dataset] --> B[Train / validation split]
    B --> C[Feature-engineered pipeline]
    B --> D[Mel spectrogram pipeline]
    C --> E[SVM / RF / Boosting]
    D --> F[CNN]
    E --> G[Accuracy / F1 / confusion matrix]
    F --> G
    G --> H[PCA / feature importance / error analysis]
    H --> I[Listening QA]
    I --> J[Model and dataset revision]

5. 분석 결과를 믹싱과 마스터링으로 되돌려 보내기

대학원 리포트가 학업 과제로만 끝나지 않았던 이유는, 분석 결과가 Logic Pro와 Reaper에서 실제로 듣는 방식에 영향을 주었기 때문이다.

5.1 음량과 음색을 분리해서 듣기

RMS가 높다고 해서 소리가 더 좋은 것도, 더 강한 캐릭터를 가진 것도 아니었다. 그래서 믹스에서 단순히 볼륨을 높이는 대신 다음을 분리해서 확인하게 되었다.

• 전체 에너지
• 순간적인 attack
• 주파수 중심
• 잔향과 decay
• 고주파의 거칠기
• 중저역의 밀도

5.2 EQ를 문제 정의로 사용하기

EQ를 무작정 “좋은 소리”로 만드는 도구로 사용하지 않고, 어떤 대역이 다른 요소와 충돌하는지 확인하는 도구로 사용했다.

Listen to conflict
    ↓
Inspect spectrum
    ↓
Define target frequency
    ↓
Cut / boost with gain staging
    ↓
A-B listening

5.3 Compression과 transient

드럼 분류에서 시간 영역 feature를 보며 attack과 decay의 차이를 의식하게 되었다. 이후 Enveloper와 Compressor를 사용할 때에도 소리를 단순히 크게 만드는 것이 아니라 transient와 sustain의 관계를 조절하는 것으로 이해했다.

5.4 공간감과 texture

Spectral feature가 소리의 밝기와 복잡성을 설명하는 단서가 되었다면, reverb와 delay는 그 소리를 어느 공간에 배치할지 결정하는 도구였다.

• 짧은 room: 가까운 source
• 긴 hall: 넓은 공간과 잔향
• stereo delay: 반복과 잔상
• saturation: 배음과 밀도
• clipping: 거친 edge

이 경험은 K-Pop Live Band Rework에서 stem, guitar amp, bass amp, parallel distortion, room simulator를 조정하는 데 직접적인 기준이 되었다.

6. 보컬 분석과 후처리: 데이터가 판단을 대신하지 않게 하기

보컬 녹음에서는 피치와 timing 데이터를 활용했지만, 자동 보정이 항상 자연스러운 결과를 만들지는 않았다. Vocalign과 합성 기반 정렬을 시도하면서 오히려 기계적인 artifact가 생기는 구간도 확인했다.

보컬 분석 파이프라인

Raw vocal takes
    ↓
Noise profile / cleanup
    ↓
Pitch tracking
    ↓
Timing comparison with guide
    ↓
Problem segment marking
    ↓
Manual cut / move / cross-fade
    ↓
EQ / compression / reverb
    ↓
A-B listening

이미지 프로젝트와 같은 점

줄노트에서 선 mask를 만들 때도 모든 이미지를 같은 규칙으로 처리하면 안 되었다. 보컬에서도 모든 문장을 같은 양으로 피치 보정하면 안 되었다.

• 정상적인 vibrato를 오류로 오인하지 않기
• 음절의 자연스러운 길이를 지나치게 압축하지 않기
• 노이즈 제거로 자음과 breath를 삭제하지 않기
• 모델이 높은 confidence를 보인다고 음악적으로 옳다고 판단하지 않기

분석 결과는 수정할 지점을 표시하는 보조 정보였고, 최종적인 자연스러움은 청취와 편집으로 판단했다.

7. 공통 아키텍처: 이미지와 오디오는 같은 연구 루프를 가진다

두 프로젝트를 하나의 관점에서 정리하면 다음과 같다.

공통 데이터 파이프라인

graph TD
    A[Raw media] --> B[Ingestion]
    B --> C[Cleaning and normalisation]
    C --> D[Domain representation]
    D --> E[Feature extraction]
    E --> F[Exploratory analysis]
    F --> G[Model / rule system]
    G --> H[Evaluation]
    H --> I[Human review]
    I --> J[Creative or production output]
    I --> C

이 구조는 나중에 영상과 오디오를 연결할 때도 그대로 사용했다. 오디오에서는 feature table이 나왔고, 영상에서는 timecode와 event table이 나왔다. 둘 다 다음 단계의 컴포넌트나 씬이 사용할 수 있는 정규화된 데이터였다.

8. 이미지 분석에서 모션 분석으로

이미지 프로젝트에서 배운 segmentation과 mask의 개념은 이후 영상 로토스코핑과 VFX 실험으로 이어졌다.

Rotoscoping과 tracking

영상에서 사람이나 물체의 윤곽을 추적하고, 각 프레임의 좌표를 저장하면 다음과 같은 구조가 된다.

Video frames
    ↓
Motion / pose detection
    ↓
Tracking points
    ↓
Bounding box / centroid / outline
    ↓
Bezier or SVG path
    ↓
Remotion frame renderer

이것은 줄노트에서 contour를 추출하고 mask를 만드는 일과 같은 계열의 문제다. 차이는 이미지 한 장이 아니라 시간에 따라 변하는 여러 프레임을 다룬다는 점이다.

graph LR
    A[Video frame] --> B[Segmentation / tracking]
    B --> C[Keypoints and outline]
    C --> D[Interpolation]
    D --> E[SVG path / mask]
    E --> F[Motion text / VFX]
    F --> G[Remotion render]

창작적 도입

• 로토스코핑된 인물 위에 키네틱 텍스트 배치
• 피사체의 위치에 따라 타이포그래피 이동
• motion confidence에 따른 opacity 조정
• tracking path를 따라 흐르는 텍스트
• 피격·동작 이벤트에 맞춘 VFX asset 생성

이후의 영상 실험에서는 MediaPipe 기반 hit detection, VFX asset manager, SVG path interpolation 같은 구조를 검토했다. 데이터 분석에서 만든 좌표와 confidence가 시각적 연출의 입력이 된 것이다.

관련 기록:

• [[ 2025-07-14-rotoscoping-motion ]]
• KR-100days100UI-challenge-and-design-system-logs

9. 오디오 분석에서 MIR과 오디오-비주얼 시스템으로

오디오 분석은 단순히 “이 소리가 무엇인지 맞히는 것”에서 끝나지 않는다. 음악의 구조를 추출해 검색·편집·믹싱·영상 제작에 사용할 수 있다면, 분석 결과는 창작 인터페이스가 된다.

MIR의 기본 레이어

Audio ingestion
    ↓
Signal processing
    ↓
Musical feature extraction
    ├── tempo / BPM
    ├── beat / onset
    ├── pitch contour
    ├── energy / loudness
    ├── timbre / texture
    ├── section boundary
    └── instrument / stem class
    ↓
Metadata and event model
    ↓
Search / mix assistance / visual composition

MIR을 위한 데이터 모델 예시

interface AudioEvent {
  id: string;
  startTime: number;
  endTime: number;
  startFrame?: number;
  endFrame?: number;
  type: 'beat' | 'onset' | 'vocal' | 'section' | 'instrument';
  intensity?: number;
  pitch?: number;
  confidence?: number;
  source: 'midi' | 'audio-analysis' | 'manual';
}

이런 중간 모델이 있으면 오디오 분석 결과를 서로 다른 출력에 연결할 수 있다.

• DAW의 marker
• MIDI trigger
• Remotion Sequence
• kinetic typography reveal
• shader intensity
• video transition
• YouTube용 분석 그래픽

오디오와 시각 이벤트의 대응

오디오 분석 기반 YouTube 콘텐츠

앞으로는 다음과 같은 콘텐츠로 확장할 수 있다.

1. K-Pop 믹스 A/B 분석

   • 원곡과 live-band rework 비교
   • waveform과 spectral profile 비교
   • EQ·compression·reverb의 변화 설명

2. 드럼 사운드 분류 시각화

   • 킥·스네어·탐·심벌의 feature space
   • PCA cluster와 실제 샘플 청취
   • 전통 모델과 CNN의 결과 비교

3. 보컬 후처리 과정 기록

   • raw take, cleaned take, mixed take 비교
   • pitch contour와 timing correction
   • 자동 보정이 실패한 구간 분석

4. MIR 기반 오디오 반응형 Shorts

   • 비트에 맞춘 pixel transition
   • 보컬 진입에 맞춘 kinetic title
   • 에너지 값에 따른 background shader 변화

5. 데이터 사이언스 프로젝트 해설

   • 대학원 프로젝트의 feature engineering 과정
   • 작은 데이터셋에서 모델을 선택하는 기준
   • AI 결과를 인간의 청취와 어떻게 검증하는지 설명

10. 대학원 프로젝트에서 배운 실패의 구조

10.1 완전 자동화의 환상

이미지에서 줄을 제거하는 것, 오디오에서 드럼을 분류하는 것, 보컬을 자동으로 맞추는 것은 모두 자동화할 수 있는 부분이 있다. 하지만 “완전히 자동으로 사용 가능한 결과”는 다른 문제다.

• line remover는 그림의 선까지 지울 수 있다.
• drum classifier는 녹음 환경의 차이를 클래스 차이로 오인할 수 있다.
• CNN은 작은 데이터셋에서 과적합할 수 있다.
• Vocalign은 피치와 timing을 맞추는 과정에서 artifact를 만들 수 있다.
• RVC는 모델을 만들 수 있지만 자연스러운 연기와 음악적 표현을 보장하지 않는다.

따라서 내가 최종적으로 택한 구조는 다음과 같다.

Machine candidate
    ↓
Human inspection
    ↓
Manual correction
    ↓
Validated asset

10.2 데이터 누수와 잘못된 성공

작은 데이터셋에서 accuracy 1.00은 인상적이지만, 다음을 확인하지 않으면 위험하다.

• train과 test에 거의 같은 source가 들어갔는가?
• 같은 녹음 환경의 샘플이 양쪽에 나뉘었는가?
• 클래스 정의가 너무 쉬운가?
• 실제 사용 환경의 변형을 포함하는가?
• cross-validation을 했는가?

수치가 높을수록 오히려 데이터 구성과 평가 조건을 다시 봐야 했다.

10.3 시각화하지 않으면 디버깅하기 어렵다

분석 결과는 표만으로 이해하기 어려웠다. 다음 시각화가 문제를 발견하는 데 도움이 되었다.

• 이미지 edge map
• line mask
• contour overlay
• spectrogram
• PCA scatter plot
• confusion matrix
• waveform marker
• predicted vs actual output

Model result
    ↓ visualise
Pattern / anomaly
    ↓ inspect
Data or pipeline bug
    ↓ revise
Model / preprocessing

10.4 라이브러리보다 문제 정의가 먼저다

Librosa, OpenCV, TensorFlow, Scikit-learn을 많이 사용하는 것이 실력의 증거는 아니었다. 어떤 라이브러리를 쓰기 전에 “내가 지금 해결하려는 문제는 무엇인가?”를 정확하게 정의해야 했다.

• 선 감지인가, 이미지 복원인가, 분류인가?
• 음색 분류인가, onset detection인가, source separation인가?
• 피치 교정인가, 타이밍 정렬인가, 보컬 질감 설계인가?

문제 정의가 달라지면 데이터·feature·모델·평가 지표도 달라진다.

11. 프로젝트별 기술·도입·아키텍처 요약

12. 이미지와 오디오 분석이 크리에이티브 프로젝트로 확장되는 방식

분석 리포트를 작성할 때는 결과표와 모델 성능이 중심이었다. 하지만 프로젝트를 계속 이어가며 분석 결과가 실제 창작의 입력값으로 변환될 수 있다는 사실을 확인했다.

확장 1 — 이미지 분석에서 VFX와 로토스코핑으로

픽셀 mask, contour, bounding box, centroid를 이용해 영상 속 피사체를 추적하고, 그 위에 모션 그래픽스를 배치한다.

Image segmentation
    ↓
Video tracking
    ↓
Motion keyframes
    ↓
SVG / Canvas / Remotion
    ↓
Rotoscoping VFX

확장 2 — 오디오 분석에서 믹스 보조로

음향 특징을 이용해 충돌 가능성이 높은 대역, 에너지가 큰 구간, 피크가 반복되는 구간을 표시한다. 최종 EQ와 compressor 값은 사람이 결정하되, 분석 결과가 검수 범위를 줄여준다.

확장 3 — 오디오 이벤트에서 Lyrics MV로

비트와 가사 타이밍을 event object로 변환해 Remotion의 씬에 전달한다. 텍스트의 등장과 배경 셰이더의 강도, 이미지 전환이 같은 시간축을 공유한다.

확장 4 — 분석 리포트에서 YouTube 콘텐츠로

프로젝트의 최종 결과만 보여주는 대신, 다음 과정을 영상으로 설명한다.

Raw data
    ↓
What went wrong?
    ↓
Which feature mattered?
    ↓
Which model failed?
    ↓
What did human review change?
    ↓
How was it used creatively?

이렇게 하면 대학원 프로젝트는 닫힌 리포트가 아니라, 데이터·음악·영상·UX를 연결하는 콘텐츠가 된다.

13. 앞으로 구성할 MIR 기반 창작 시스템

내가 만들고 싶은 MIR은 거대한 모델 하나로 모든 음악을 자동 해석하는 시스템이 아니다. 내가 다루는 창작 환경에서 반복적인 분석과 정리를 돕고, 사람이 최종 판단할 수 있게 결과를 설명하는 시스템이다.

13.1 데이터 계층

Audio source
    ├── original / stem / vocal / sample
    ├── source and licence
    ├── model and processing version
    └── user annotations

13.2 분석 계층

Feature extraction
    ├── time domain
    ├── frequency domain
    ├── timbre
    ├── pitch
    ├── rhythm
    └── section structure

13.3 변환 계층

Audio features
    ├── search tags
    ├── mix suggestions
    ├── MIDI / trigger events
    ├── visual intensity
    ├── scene boundaries
    └── caption / lyric timing

13.4 출력 계층

Validated events
    ├── DAW markers
    ├── audio asset library
    ├── Remotion scenes
    ├── data visualisation
    └── YouTube / Shorts templates

13.5 Human-in-the-loop 운영

graph TD
    A[Audio / image input] --> B[Automated preprocessing]
    B --> C[Feature extraction]
    C --> D[Model prediction]
    D --> E[Confidence and anomaly report]
    E --> F[Human listening / visual review]
    F --> G[Accept / edit / reject]
    G --> H[Creative output]
    F --> I[Corrected label / feedback]
    I --> B

이 구조에서 모델의 역할은 정답을 선언하는 것이 아니라, 사람이 더 빠르게 판단할 수 있도록 후보와 근거를 제공하는 것이다.

14. 최종 교훈

1. 좋은 모델보다 좋은 입력이 먼저다

전처리와 라벨이 엉망이면 복잡한 모델도 엉망인 결과를 낸다. 데이터의 출처와 조건을 먼저 기록해야 한다.

2. Feature engineering은 낡은 기술이 아니다

도메인 지식으로 문제를 작게 만들고, 설명 가능한 특징을 정의하는 것은 여전히 강력하다. 특히 작은 데이터셋에서는 더욱 그렇다.

3. 시각화는 결과 발표가 아니라 디버깅 도구다

mask, contour, spectrogram, PCA, confusion matrix는 보고서 장식이 아니라 파이프라인의 오류를 발견하는 장치다.

4. Accuracy와 실제 사용성은 다르다

모델이 맞혔다고 해서 이미지가 자연스럽게 복원되거나, 드럼 차트가 연주 가능하거나, 보컬이 음악적으로 자연스러운 것은 아니다.

5. 자동화의 목표는 인간을 제거하는 것이 아니다

자동화는 반복적인 파일 처리와 후보 생성을 맡고, 사람은 경계 사례·미감·맥락·권리·최종 품질을 판단한다.

6. 분석은 창작과 분리되지 않는다

이미지 분석에서 얻은 mask는 로토스코핑이 되고, 오디오 feature는 믹싱 기준이 되고, MIDI와 pitch 데이터는 Lyrics MV의 타임라인이 된다.

7. 실패는 다음 시스템의 설계 조건이다

CNN의 과적합, U-Net mask의 불완전성, BPM mismatch, Vocalign artifact, RVC preprocessing 오류는 모두 “다음에는 무엇을 먼저 검증할 것인가”를 알려준다.

에필로그: ML은 내 창작을 대신하지 않았다

대학원 프로젝트를 시작할 때는 이미지와 오디오를 분류하고 복원하는 일 자체가 목표처럼 보였다. 하지만 프로젝트를 끝내고 보니 더 중요한 결과는 모델의 점수가 아니었다.

나는 이미지가 어떻게 mask와 contour로 바뀌는지, 소리가 어떻게 waveform과 feature table로 바뀌는지, 모델의 예측이 어떻게 실제 사용 가능성 앞에서 다시 검수되는지를 배웠다.

그리고 그 지식은 다시 창작으로 돌아왔다.

이미지 분석
    ↓
mask / contour / tracking
    ↓
로토스코핑 / VFX / 모션 그래픽스

오디오 분석
    ↓
feature / pitch / beat / energy
    ↓
믹스 / 보컬 커버 / MIR / Lyrics MV

이제 내가 만들고 싶은 것은 분석만 하는 시스템도, 버튼 하나로 모든 창작을 대신하는 AI도 아니다. 데이터를 읽고, 결과를 설명하고, 사람이 수정하고, 다시 창작의 언어로 내보낼 수 있는 연결 시스템이다.

오디오와 비주얼 분석은 나에게 감각을 숫자로 죽이는 작업이 아니었다. 오히려 막연하게 느끼던 질감과 구조와 어색함을 설명할 수 있게 해주는 새로운 감각 기관에 가까웠다.

대학원의 ML 프로젝트는 끝났지만, 그 과정에서 만든 feature와 실패 로그와 검수 습관은 계속 남아 있다. 그것들은 앞으로의 믹싱과 보컬 커버, 오디오 반응형 영상, Lyrics MV, 그리고 유튜브 콘텐츠를 구성할 작은 레고 블록이 될 것이다.

Related Articles

• KR-audio-analysis-mix-mastering-to-MIR-creative-pipeline
• EN-Feature-Engineering-vs-CNNs-in-audio
• EN-Memo-AudioCategorisingTagging
• KR-Audio-to-Chart Pipeline
• KR-GameToAudioDesign
• [[ 2025-07-14-rotoscoping-motion ]]
• music-to-data-design-kr
• EN-generalist-or-master-of-none-or-A Trans-disciplinary Experience Architect
• EN-Retro-Review-Progress-drumgaming-to-producing-and-data-analysis
• [[ 2025-11-19 ]]
• [[ 2026-01-08-Engineering the Intersection of Sound, Data, and User Experience ]]
• KR-All-experiments-combined-into-making-MVs
• KR-Lyrics-MV-Project-Compound-Convergent-Directing-Retrospective