Audio Pro
검색

AUDIO / FOUNDATIONS

오디오 포맷·컨테이너·코덱을 구분하는 법

WAV·FLAC·MP3·AAC·Opus를 하나의 순위로 놓지 않고 파일 이름, container·framing, codec·profile과 decoder 지원을 목적별로 확인합니다.

짧은 답: 파일 확장자와 media type은 외부 단서이고, container나 framing은 오디오 packet과 metadata를 묶는 구조이며, codec과 profile은 데이터를 표현하고 해석하는 규칙입니다. 보관·편집·배포·실시간 전송 중 목적을 먼저 정한 뒤 이 조합을 대상 decoder에서 확인해야 하며, 확장자나 codec 이름 하나만으로 품질과 호환성을 보장할 수 없습니다.

작성
Audio Pro 콘텐츠 에디터
사실 검토
오디오·플랫폼 사실 검증 담당
최종 검토
2026-08-22
최종 갱신
2026-08-22
광고 상태
광고 없음

1. 확장자부터 decoded PCM까지 층별로 읽습니다

파일 이름의 확장자와 media type은 어떤 구조일 가능성이 있는지 알려 주는 단서지만 내부 데이터를 모두 증명하지는 않습니다. RIFF의 WAVE 형식은 chunk 구조 안에 format 정보와 audio data를 배치하며, format tag와 WAVEFORMAT 계열 정보에 따라 실제 오디오 표현이 달라질 수 있습니다. 그래서 WAV를 언제나 하나의 고정 PCM codec과 같은 말로 쓰지 않습니다.

container나 framing은 packet, track, timestamp와 metadata를 묶는 규칙이고 codec과 profile은 encoded audio를 decoder가 해석하는 규칙입니다. RFC 7845는 Opus codec을 Ogg logical bitstream에 넣는 별도의 encapsulation을 정의합니다. 이 구분은 Opus와 Ogg가 같은 층의 이름이 아니며 codec만 알아도 파일 구조 전체를 안다고 볼 수 없음을 보여 줍니다.

  1. File name · media type

    파일을 찾고 전달할 때 쓰는 외부 단서

  2. Container · framing

    packet·track·metadata를 정한 구조로 묶는 층

  3. Codec · profile

    오디오를 표현하고 decoder가 해석하는 규칙

  4. Encoded audio data

    선택한 규칙으로 저장되거나 전송되는 payload

  5. Decoded PCM

    재생·편집을 위해 decoder가 내놓는 sample 데이터

직접 제작한 질문 계층입니다. 하나의 확장자에 codec이나 profile이 항상 하나만 대응한다는 호환성 표가 아닙니다.

2. 무손실·손실과 remux·re-encode를 분리합니다

RFC 9639는 FLAC이 PCM audio를 정보 손실 없이 압축하고 다시 복원하도록 정의합니다. 하지만 이미 손실 codec으로 인코딩된 파일을 decode한 뒤 FLAC으로 저장하는 일은 이전 인코딩에서 제거된 정보를 되살리지 않습니다. 새 파일은 그 시점의 decoded 결과를 무손실로 보관할 뿐이므로 source의 생성 이력을 함께 기록해야 합니다.

remux는 호환되는 encoded payload를 decode·encode하지 않고 다른 container나 framing에 다시 묶는 작업이고, re-encode는 decode한 뒤 codec 설정에 따라 새 encoded data를 만드는 작업입니다. 도구가 두 작업을 모두 conversion이라고 표시할 수 있으므로 작업 로그에는 원본 codec, 대상 container·codec, encode 실행 여부와 metadata·timestamp 보존 여부를 따로 적습니다.

표 전체를 보려면 가로로 스크롤하세요.

직접 제작한 보관·편집·배포·실시간 선택 질문표
목적첫 질문확인할 증거피할 결론
원본 보관decoded PCM을 손실 없이 다시 얻어야 하는가?무손실 여부·metadata·checksum·복구 시험손실 source를 FLAC으로 바꾸면 원본이 복구된다는 판단
반복 편집현재 편집기가 안정적으로 읽고 다시 쓸 수 있는가?codec·sample format·channel·timecode와 재열기확장자만 바꾸거나 매 저장마다 손실 재인코딩
파일 배포대상 앱·브라우저·기기가 어떤 조합을 해석하는가?container·codec·profile·media type·실기 재생고정된 범용 호환 순위나 codec만으로 성공 보장
실시간 전송지연·오류 회복·대역폭 조건이 무엇인가?전송 규격·framing·decoder 설정·네트워크 조건저장 파일의 선택 기준을 실시간 경로에 그대로 적용
구조만 변경같은 encoded payload를 다른 wrapper로 옮길 수 있는가?remux 가능 여부와 timestamp·metadata 보존remux와 decode 후 re-encode를 같은 변환으로 부르기

3. 목적과 대상 decoder를 기준으로 최종 확인합니다

원본 보관은 되돌릴 수 있는지와 metadata·무결성 확인이 중요하고, 반복 편집은 editor가 해당 sample format과 channel 구조를 안정적으로 읽고 쓰는지가 중요합니다. 파일 배포는 대상 앱·브라우저·기기의 실제 container·codec·profile 지원을, 실시간 전송은 latency와 packetization·오류 조건을 함께 확인합니다. 하나의 codec 품질 순위를 모든 목적에 적용하지 않습니다.

MP3, AAC와 Opus처럼 손실 codec을 비교할 때도 이름만으로 고정 bitrate나 청감 품질을 단정하지 않습니다. encoder와 profile, bitrate mode, source, 세대 손실, decoder와 청취 조건이 달라질 수 있기 때문입니다. 최종 파일의 media 정보만 보는 데서 끝내지 않고 실제 대상 decoder에서 처음·중간·끝과 필요한 metadata를 다시 확인합니다.

  • 확장자·media type과 실제 container·codec 정보를 나누어 확인합니다.
  • WAV와 PCM, AAC와 M4A, Opus와 Ogg를 같은 층의 이름으로 쓰지 않습니다.
  • 손실 source를 FLAC으로 바꿔도 제거된 정보는 복구되지 않습니다.
  • remux와 re-encode를 작업 로그에서 구분합니다.
  • 고정 호환표 대신 실제 대상 decoder에서 납품 파일을 검수합니다.

ORIGINAL MATERIALS

이 글의 직접 제작 자료

  • 파일·container·codec·PCM 계층도

    파일 이름과 media type에서 container·framing, codec·profile, encoded data와 decoded PCM으로 이어지는 질문 층을 직접 제작한 도식입니다.

  • 목적별 포맷 선택 전 질문표

    원본 보관, 반복 편집, 파일 배포, 실시간 전송과 remux에서 확인할 증거와 피할 결론을 정리한 직접 제작 표입니다.

SOURCE NOTES

출처와 검토일

갱신 이력

  • 최초 공개 / 2026-08-22

    파일 이름, container·framing, codec·profile과 목적별 검수 순서를 처음 공개했습니다.

KEEP EXPLORING