📁 File4. 오디오06 · Streaming Audio — 오디오만 따로 보내는 표준

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
SpotifyOgg/Vorbis (free), Ogg/Vorbis 320k (Premium)Ogg96 / 160 / 320 kbpsWidevine (Custom)
Spotify HiFi (예고)FLACFLAC1411 kbpsWidevine
Apple MusicAAC, ALAC (lossless)M4A256 kbps AAC / 1411+ ALACFairPlay
TidalAAC, FLAC, MQAM4A / FLAC96 / 320 / 1411 / hi-resWidevine + FairPlay
YouTube MusicOpusWebM128 / 256 kbpsWidevine
Amazon Music HDFLACFLAC850 / 1411 / hi-resWidevine
DeezerMP3, FLACMP3 / FLAC128 / 320 / 1411 kbpsWidevine

→ 대부분이 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
EOF

MP3 팟캐스트 마스터링

# 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.mp3

Opus + WebM (DASH용)

ffmpeg -i input.wav \
  -c:a libopus -b:a 96k -application audio \
  -f webm \
  -dash 1 \
  audio_96k.webm

CMAF 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

권장 비트레이트 표 (사용처별)

사용처코덱비트레이트채널샘플레이트비고
인터넷 전화Opus24 kbpsmono16kWebRTC
음성 통화 (모바일)AMR-WB / Opus12~24 kbpsmono16kVoLTE
팟캐스트 (음성 위주)MP364 kbpsmono44.1kRSS 표준
팟캐스트 (음악 포함)MP3128 kbpsstereo44.1k
라디오 (인터넷)AAC-HE32 kbpsstereo44.1kSHOUTcast/HLS
음악 스트리밍 (일반)AAC128 kbpsstereo44.1k/48k사실상 표준
음악 스트리밍 (고음질)AAC / Opus256 kbps / 160 kbpsstereo44.1kPremium
음악 스트리밍 (lossless)FLAC / ALAC~1000 kbpsstereo44.1k/48kTidal HiFi
하이레졸루션FLAC~3000 kbpsstereo96k/24bitMQA, 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가 팟캐스트.