06 · Streaming Audio — 오디오만 따로 보내는 표준
이 문서가 답하는 질문: 비디오는 HLS/DASH가 표준인데, 오디오만 보낼 때는 무엇을 쓰는가? 팟캐스트는 왜 아직 MP3 단순 다운로드인가? 선행 지식:
03-codecs-overview.md,06-streaming/(비디오 스트리밍 전반)
한 줄 답
오디오 스트리밍은 콘텐츠 형태에 따라 3 갈래로 갈린다 — ① 팟캐스트는 RSS + MP3 단순 다운로드, ② 음악 스트리밍은 자체 프로토콜 위 Ogg/Opus/AAC, ③ 라이브·HLS audio-only는
.m3u8+.aac세그먼트. 비디오 ABR과 달리 오디오 ABR은 2~3 단계로 충분하다 (대역 차이가 작아서).
Why — 왜 오디오 스트리밍이 비디오와 다른가
1) 대역폭 차이가 작다
비디오 ABR은 240p ~ 4K로 60배 대역폭 차이. 오디오는 64 kbps ~ 320 kbps로 5배 차이밖에 안 남.
→ 비디오는 ABR ladder가 510 단계, 오디오는 23 단계로 충분.
2) 청자가 한 번 결정하면 거의 안 바꾼다
비디오는 풀스크린/PiP/모바일 등 화면 크기 변화에 따라 해상도를 바꾼다. 오디오는 거의 안 바꿈. → ABR보다는 고정 비트레이트로 다운로드 후 캐싱이 더 자주 쓰인다.
3) 작아서 그냥 다운받아도 된다
3분 곡 @ 128 kbps = 약 3 MB. 모바일 LTE에서 1~2초 안에 다운. → 진짜 streaming(progressive download이 아닌 chunked transfer + manifest)이 필수가 아닌 경우가 많음.
→ 결과적으로 오디오는 단순한 게 표준: 팟캐스트는 30년째 MP3 진행 다운로드.
How — 3 갈래의 메커니즘
1) 팟캐스트: RSS + MP3 progressive download
- 표준: RSS 2.0 + iTunes namespace (Apple이 2005년 정의)
- 콘텐츠: MP3 단일 파일, 보통 64~128 kbps mono/stereo
- 전송: HTTP GET + Range 헤더로 seek
- 메타데이터: ID3v2 태그 (제목, 아트워크, chapter marks)
왜 아직도 MP3? RSS 2.0이 굳어진 2005년의 표준이고, 모든 팟캐스트 앱이 MP3 디코더를 깔고 있음. AAC로 바꾸면 한 시즌의 호환성 작업이 필요. 표준의 화석화.
{/* RSS 2.0 + iTunes namespace 예시 */}
<item>
<title>Episode 42</title>
<itunes:duration>00:42:30</itunes:duration>
<enclosure
url="https://cdn.example.com/ep42.mp3"
type="audio/mpeg"
length="40500000" />
<itunes:image href="https://.../cover.jpg" />
</item>2) 음악 스트리밍: 플랫폼별 자체 프로토콜
| 플랫폼 | 코덱 | 컨테이너 | 비트레이트 단계 | DRM |
|---|---|---|---|---|
| Spotify | Ogg/Vorbis (free), Ogg/Vorbis 320k (Premium) | Ogg | 96 / 160 / 320 kbps | Widevine (Custom) |
| Spotify HiFi (예고) | FLAC | FLAC | 1411 kbps | Widevine |
| Apple Music | AAC, ALAC (lossless) | M4A | 256 kbps AAC / 1411+ ALAC | FairPlay |
| Tidal | AAC, FLAC, MQA | M4A / FLAC | 96 / 320 / 1411 / hi-res | Widevine + FairPlay |
| YouTube Music | Opus | WebM | 128 / 256 kbps | Widevine |
| Amazon Music HD | FLAC | FLAC | 850 / 1411 / hi-res | Widevine |
| Deezer | MP3, FLAC | MP3 / FLAC | 128 / 320 / 1411 kbps | Widevine |
→ 대부분이 HLS/DASH가 아니라 자체 청크 프로토콜 + DRM. 음원은 비디오보다 추적·복제가 쉬워 DRM이 핵심.
Spotify의 흥미로운 사실: Vorbis를 고른 이유는 라이선스 비용 절감 (AAC는 MPEG-LA royalty). 후발 플랫폼(YouTube)은 Opus를 채택해 효율 + 라이선스 둘 다 잡음.
3) HLS audio-only: 라이브 라디오, 일부 음악 서비스
비디오 HLS와 같은 메커니즘 — .m3u8 master + media playlist + .aac 세그먼트.
master.m3u8
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Default",
DEFAULT=YES,AUTOSELECT=YES,URI="audio/playlist.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=128000,CODECS="mp4a.40.2",AUDIO="aac"
audio/playlist.m3u8
audio/playlist.m3u8
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.0,
seg0.aac
#EXTINF:6.0,
seg1.aac
...- 코덱: AAC-LC (필수), HE-AAC (옵션)
- 세그먼트 길이: 6초 (LL-HLS는 1초 + parts)
- 컨테이너: ADTS (
.aac) 또는 fMP4 (.m4s)
iOS Safari 제약: HLS audio-only는 AAC만 공식 지원. Opus는 거부. → 웹 표준은 Opus가 우월하지만 Apple 생태계는 AAC 강제.
4) Icecast / SHOUTcast: 인터넷 라디오의 화석
http://radio.example.com:8000/stream- 1990년대 후반 표준, MP3/AAC/Ogg를 ICY 메타데이터 헤더와 함께 무한 청크로 전송
- 지금도 인터넷 라디오 방송국 다수가 이걸로 동작
- 메타데이터(곡명)는
icy-metaint헤더로 inline 삽입
→ “왜 안 죽었나”의 이유는 RTMP와 비슷 — 굴러가니까 안 바꾼다.
5) 오디오 ABR 단계 설계
비디오 ABR은 5~10 단계지만 오디오는 3 단계가 보통 한계. 더 잘게 쪼개도 사용자가 차이를 못 느낌.
What — 구체 사양 / 명령어
HLS audio-only 생성
# AAC 96 kbps, 6초 세그먼트
ffmpeg -i input.mp3 \
-c:a aac -b:a 96k -ar 48000 -ac 2 \
-f hls \
-hls_time 6 \
-hls_playlist_type vod \
-hls_segment_filename "seg%03d.aac" \
playlist.m3u8
# Master playlist 직접 작성
cat > master.m3u8 <<EOF
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=96000,CODECS="mp4a.40.2"
playlist.m3u8
EOFMP3 팟캐스트 마스터링
# 64 kbps mono, ID3v2 태그, ReplayGain
ffmpeg -i master.wav \
-c:a libmp3lame -b:a 64k -ar 44100 -ac 1 \
-metadata title="Episode 42" \
-metadata artist="Show Name" \
-metadata album="Season 3" \
-metadata date="2026" \
-id3v2_version 3 \
episode42.mp3
# LUFS 정규화 + MP3 인코딩 통합
ffmpeg -i master.wav \
-af "loudnorm=I=-16:TP=-1:LRA=11" \
-c:a libmp3lame -b:a 64k -ar 44100 -ac 1 \
episode42.mp3Opus + WebM (DASH용)
ffmpeg -i input.wav \
-c:a libopus -b:a 96k -application audio \
-f webm \
-dash 1 \
audio_96k.webmCMAF audio fragment (DASH/HLS 공통)
ffmpeg -i input.wav \
-c:a aac -b:a 128k \
-f mp4 \
-movflags "frag_keyframe+empty_moov+default_base_moof" \
-frag_duration 6000000 \
audio.cmaf.mp4권장 비트레이트 표 (사용처별)
| 사용처 | 코덱 | 비트레이트 | 채널 | 샘플레이트 | 비고 |
|---|---|---|---|---|---|
| 인터넷 전화 | Opus | 24 kbps | mono | 16k | WebRTC |
| 음성 통화 (모바일) | AMR-WB / Opus | 12~24 kbps | mono | 16k | VoLTE |
| 팟캐스트 (음성 위주) | MP3 | 64 kbps | mono | 44.1k | RSS 표준 |
| 팟캐스트 (음악 포함) | MP3 | 128 kbps | stereo | 44.1k | |
| 라디오 (인터넷) | AAC-HE | 32 kbps | stereo | 44.1k | SHOUTcast/HLS |
| 음악 스트리밍 (일반) | AAC | 128 kbps | stereo | 44.1k/48k | 사실상 표준 |
| 음악 스트리밍 (고음질) | AAC / Opus | 256 kbps / 160 kbps | stereo | 44.1k | Premium |
| 음악 스트리밍 (lossless) | FLAC / ALAC | ~1000 kbps | stereo | 44.1k/48k | Tidal HiFi |
| 하이레졸루션 | FLAC | ~3000 kbps | stereo | 96k/24bit | MQA, Hi-Res Audio |
What-if — 잘못 만들면 어떻게 깨지는가
1. HLS에 Opus 넣기
iOS Safari 18까지 HLS Opus 거부. Chrome은 정상. → 크로스플랫폼은 AAC, 웹 전용은 Opus.
2. 팟캐스트에 AAC
Apple Podcasts는 AAC도 받지만 일부 레거시 앱(2010년대 podcatcher)은 거부. RSS 2.0의 enclosure type="audio/x-aac"를 못 알아듣는 앱이 여전히 있음.
→ 호환성 우선이면 MP3 64k mono.
3. ABR 단계 너무 많음
오디오 5단계 ladder는 의미 없음 — 64/96/128/192/256 사이 전환이 사용자에게 인지 안 됨. 오히려 segmenter 비용만 5배. → 2단계 (저대역 + 고대역) 또는 3단계가 한계.
4. Live HLS의 첫 청크 지연
세그먼트 6초면 첫 재생까지 최소 12~18초 (3 세그먼트 버퍼링). 라이브 라디오엔 너무 느림. → LL-HLS (parts 1초) 또는 SHOUTcast/Icecast (chunked transfer, 거의 즉시).
5. DRM과 progressive download 혼용
음악 플랫폼이 progressive MP3 + DRM을 시도하면 다 깨진다 (DRM은 청크 단위 키 교환을 가정). DRM은 fMP4/CMAF + EME 기반 매니페스트 스트리밍이 정상.
6. 라이브 ICY 메타데이터 누락
Icecast/SHOUTcast 스트림에서 icy-metaint 헤더가 없으면 클라이언트가 곡명/아티스트를 못 받음. UI에 “Unknown”만 표시됨.
7. ID3 태그 인코딩 실수
ID3v2.3은 UTF-16, ID3v2.4는 UTF-8. 한글 제목을 UTF-8로 v2.3 태그에 넣으면 mojibake. → v2.4 권장 (또는 v2.3 + UTF-16BE BOM).
Insight — 흥미로운 이야기
“팟캐스트가 30년째 MP3인 이유”
2005년 Adam Curry + Dave Winer가 RSS 2.0 enclosure 사양으로 팟캐스트를 정의. 그때 MP3가 절대 표준이었고, Apple이 iTunes에 팟캐스트를 통합하며 “MP3가 표준”으로 굳혀버림. 이제 와서 AAC로 바꾸면 모든 podcatcher 앱(수백 개)의 호환성을 다 검증해야 함. “표준이 굳은 자리는 음질로 못 흔든다” — 팟캐스트는 그 산증인.
“Spotify는 왜 Ogg/Vorbis를 골랐는가”
2008년 Spotify 출시 시 AAC를 쓰려면 MPEG-LA에 사용자당 라이선스 비용을 내야 했다. 무료 + royalty-free Vorbis를 채택해 비용을 0으로. 음질은 AAC와 거의 비슷. 후발 YouTube는 같은 이유로 Opus를 채택, Apple은 자체 생태계라 AAC 비용을 감수. 표준은 라이선스 모델이 결정한다.
“왜 음악 스트리밍은 HLS를 안 쓰는가”
HLS는 비디오 ABR + 라이브 위주의 설계. 음악은 ABR이 의미 없고 라이브도 아님. 자체 청크 프로토콜 + DRM이 더 효율적 (HTTP overhead 없이 binary protocol). Spotify Connect는 자체 RTSP-like 프로토콜이고, Apple Music도 fairplay-protected mp4 직접 다운. “표준이 강력해도 도메인 fit이 안 맞으면 안 쓴다.”
“라이브 라디오의 SHOUTcast가 안 죽는 이유”
1999년 Nullsoft(Winamp 회사)가 만든 ICY 프로토콜. HTTP 위에 라디오 메타데이터를 inline으로 삽입. 모든 인터넷 라디오 방송국이 이미 SHOUTcast/Icecast 위에 운영 → 마이그레이션 비용 압도적. HLS LL-HLS가 기술적으로 더 우월해도 라디오는 안 옮긴다 — 비용 + 호환성.
“Apple Music이 ALAC을 늦게 추가한 이유”
2021년에야 Apple Music이 lossless를 추가. 그 전엔 256 kbps AAC만. 이유는 라이브러리 trans-coding 비용 — 7천만 곡을 ALAC로 다시 인코딩 + 저장 = 페타바이트 단위. Tidal/Qobuz가 lossless로 차별화하자 Apple도 따라 옴 — 후발주자가 시장을 흔든 사례.
한 단락 요약 + Mermaid
오디오 스트리밍은 비디오와 달리 단순한 게 살아남았다 — 팟캐스트 MP3 progressive, 음악 자체 프로토콜, 라이브 SHOUTcast/HLS audio-only. ABR 단계는 2~3개로 충분하고, DRM은 음악 플랫폼의 핵심. 표준 처방: AAC 128 kbps + HLS 6s segment가 크로스플랫폼 안전판, Opus 96 kbps + WebM/DASH가 웹 효율판, MP3 64k mono가 팟캐스트.