OBS에서 오디오를 6개로 나눠 보내도, 편집 단계에서 여섯 번째 소리만 꺼낼 수 있다는 보장은 없습니다. 중간 먹서가 일부 트랙만 남기거나, 파일에는 있어도 재생목록에 선택지가 실리지 않을 수 있기 때문입니다. 입력 설정 화면 대신 송출한 트랙이 어디까지 도착했는지 확인해야 했습니다.
저는 PokeClip의 미디어 입력 계약을 정하면서 트랙의 존재와 선택한 소리의 보존을 다른 검증 항목으로 나눴습니다. 초기 스파이크는 AI 협업으로 진행했고, 후속 OBS 플러그인 구현과 테스트 톤 측정은 팀원 jaehwan-space가 맡았습니다. 전체 구조와 통합 검증 범위를 정하고 각 결과가 증명하는 내용을 구분한 것이 제 역할입니다.
첫 실험에서는 트랙의 개수와 선택 경로를 따라갔습니다
2026년 8월 실험은 OBS 32.2.0의 custom FFmpeg output으로 영상 1개·오디오 6개를 SRT 송출하고, MediaMTX 1.19.3에서 받는 조건이었습니다. 녹화 파일, 재생목록, 브라우저 선택, 최종 추출과 색인을 차례로 확인했습니다.
| 단계 | 확인한 질문 | 관측 |
|---|---|---|
| SRT → fMP4 | 녹화하며 트랙이 사라지는가 | 오디오 6개 |
| fMP4 → LL-HLS | 목록에 선택지가 실리는가 | EXT-X-MEDIA 6개 |
| 브라우저 선택 | track 5 선택 뒤 요청이 성립하는가 | HTTP 200, 오류 0 |
| FFmpeg 추출 | 여섯 번째 오디오만 고를 수 있는가 | -map 0:a:5, 결과 오디오 1개 |
| 파일 → DB | 녹화 산출물과 색인이 대응하는가 | 61파일 = 61행 |
FFmpeg 인덱스는 0부터 시작하므로 0:a:5는 첫 입력의 여섯 번째 오디오입니다. 표에는 전체 실행 명령 대신 사용한 선택 표현을 적었습니다. FFmpeg의 스트림 선택 문서와 함께 보면 자동 선택과 명시적 -map의 차이를 확인할 수 있습니다.
검사를 나눈 덕분에 파일에는 6개인데 목록에서 일부가 빠지는 문제와, 목록은 정상인데 플레이어가 전환하지 못하는 문제를 구별할 수 있습니다. 61파일과 61행의 일치도 같은 실행의 저장·색인 대응을 보여 주는 별도의 증거입니다.
무음 입력이 통과해도 음악 분리를 검증한 것은 아니었습니다
첫 실험의 입력은 무음 씬이었습니다. 무음으로도 트랙 수와 순서, 선택 추출을 검사할 수 있지만, 목소리와 음악이 실제로 나뉘어 남는지는 알 수 없습니다. 검증을 더하려면 트랙마다 구별할 수 있는 입력이 필요했습니다.
이 구분은 산출물 설계에도 반영했습니다. 편집 원본에는 여러 오디오를 보존하고, 되감기 재생은 첫 오디오를 사용하도록 했습니다. 모든 재생 요청에 편집용 6트랙을 전달하기보다, 시청과 편집에 필요한 정보를 다르게 남긴 것입니다. OBS 공식 가이드에서도 재생용 믹스와 후편집용 트랙을 구분합니다.
테스트 톤으로 개수 다음의 내용을 확인했습니다
팀의 PR #195에서는 OBS 32.2.2 macOS → SRT → 로컬 MediaMTX 조건에서 440Hz와 1,000Hz 소스를 켰고, 방송 중 2,500Hz 소스를 추가했습니다. ffprobe에는 영상 1개와 AAC 6개, HLS에는 대체 오디오 6개가 나타났습니다. 여기에 트랙별 대역 측정을 더했습니다.
| 대조 항목 | 팀 실측 결과 | 의미 |
|---|---|---|
| 해당 스템의 목표 대역 | −24.1dB | 지정한 테스트 톤 관측 |
| 빈 트랙 | −91.0dB | 무음 패킷이 이어지는 트랙 |
| 다른 대역 | −47~−57dB | 측정 필터 누설; 원음 혼입률로 단정할 수 없음 |
| 본방 트랙 2 | 첫 오디오에 440Hz 보존 | 첫 오디오를 믹서 0으로 고정하지 않고 실제 본방을 따름 |
특히 본방 트랙 2 조건은 개수만 세는 검사에서 드러나지 않는 문제를 다룹니다. 트랙이 여섯 개 있어도 첫 오디오가 본방과 다르면 서버 입력 계약은 맞지 않습니다. 후속 연결 교체 검증에서는 첫 오디오가 220Hz인지를 교체 전후로 대조한 기록도 있습니다. 입력과 조건이 다른 실험이므로 초기 무음 실험의 결과와 합치지는 않았습니다.
검증의 범위는 여기까지입니다. 무음 실험은 전달과 선택을, 톤 실험은 특정 입력의 내용 보존을 보여 줍니다. 실제 음악의 청감 품질, 모든 운영체제와 장시간 상용 방송까지 검증한 결과는 아닙니다.
처음 질문에 답하려면 “6개가 보인다” 다음에 “원하는 하나를 고를 수 있다”, 그리고 “그 하나에 의도한 소리가 있다”까지 확인해야 했습니다. 기능 이름 하나에 성공 표시를 붙이는 대신 이 세 단계를 나눈 것이 이후 입력 변경을 검토하는 기준이 됐습니다.