WAV·FLAC·MP3·AAC·Opus 선택법과 오디오 용량 계산

WAV는 담는 구조, PCM은 소리를 표현하는 방식입니다

오디오 형식을 고를 때는 먼저 ‘어떻게 담았는가’와 ‘소리를 어떻게 표현했는가’를 나누면 이해하기 쉽습니다. 컨테이너는 오디오 데이터와 형식 정보·메타데이터를 파일 안에 배치하는 구조입니다. 코덱은 데이터를 인코딩하고 다시 해석하는 규칙이며, PCM은 시간에 따른 샘플 값을 수치로 표현하는 방식입니다. 확장자는 파일 이름의 일부이므로 이름만 바꿔도 내부 데이터가 변하는 것은 아닙니다.

예를 들어 WAV 안에 48 kHz·24비트 정수 PCM 스테레오를 담을 수 있습니다. 여기서 WAV는 파일 구조, PCM은 샘플 표현, 48 kHz는 채널마다 1초에 담는 샘플 수, 24비트는 값의 표현 폭, 스테레오는 2채널이라는 뜻입니다. Microsoft의 RIFF/WAVE 설명에서 형식 정보는 fmt 청크에, 오디오 데이터는 data 청크에 들어갑니다. 같은 RIFF 계열 설명에 PCM과 ADPCM이 모두 등장하므로 ‘WAV이면 무조건 무압축 PCM’이라고 읽으면 안 됩니다.

Ogg와 Opus도 같은 관계입니다. RFC 6716은 Opus 코덱을 정의하고 RFC 7845는 그 Opus 데이터를 Ogg 구조 안에 담는 방식을 정의합니다. Ogg로 포장된 Opus 파일을 재생할 때는 먼저 저장 구조에서 패킷을 꺼내고, Opus 디코더가 그 데이터를 PCM으로 해석합니다. 따라서 Ogg를 읽는다는 설명만으로 그 안의 모든 코덱을 지원한다고 볼 수 없으며, Opus 자체가 Ogg 파일만을 뜻하지도 않습니다.

AAC도 코덱 계열 이름이고, MP4에 담긴 AAC를 설명할 때는 컨테이너와 세부 형식을 함께 적습니다. RFC 6381의 AAC-LC 표기는 mp4a.40.2입니다. 이는 설정을 구체적으로 전달하기 위한 이름이지 재생 성공 결과가 아닙니다. M4A라는 확장자만 보고 AAC-LC라고 확정하는 대신 파일 정보에서 실제 코덱을 확인하면, 파일은 열렸는데 오디오를 해석하지 못하는 문제를 더 정확히 좁힐 수 있습니다.

편집·보관·배포는 필요한 결과가 다릅니다

반복 편집에서 먼저 필요한 것은 다음 작업에도 사용할 기준본입니다. 편집기와 전달처가 WAV/PCM을 지원한다면 원본의 샘플레이트·채널 구성을 유지한 PCM 파일을 기준본으로 둘 수 있습니다. 파일 하나가 편집 프로젝트의 트랙·효과 설정까지 보관하는 것은 아니므로, 수정 가능한 프로젝트가 필요하면 프로젝트와 그 소스 파일도 함께 남깁니다. 포맷 선택만으로 편집 작업 전체의 백업이 완성되지는 않습니다.

보관에서 정수 PCM 샘플을 그대로 되찾으면서 압축하려면 FLAC이 후보입니다. RFC 9639의 무손실은 압축을 풀었을 때 입력 데이터를 정확히 복원한다는 뜻입니다. WAV를 FLAC으로 바꾼 두 파일의 전체 바이트나 헤더가 같다는 뜻은 아니므로, 오디오 샘플 보존과 제목·날짜 같은 메타데이터 보존은 구분해서 살펴봅니다. 압축률은 신호와 설정에 따라 달라지므로 FLAC이면 언제나 절반 크기가 된다고 계산할 수 없습니다.

배포에서 전송량을 줄여야 한다면 MP3·AAC·Opus 같은 손실 압축 형식을 고려합니다. 선택의 출발점은 받는 곳의 요구입니다. MP3를 지정한 전달처에는 MP3를, MP4 안의 AAC-LC를 지정한 곳에는 그 조합을 만들면 됩니다. 같은 숫자의 비트레이트를 맞췄다는 이유로 코덱 사이의 음질을 동급으로 취급할 수는 없습니다. 파일 크기 예산을 먼저 정하고 허용되는 형식 안에서 원본과 비교하는 편이 선택 이유를 분명하게 만듭니다.

실시간 통화는 저장 파일과 달리 전송 지연과 패킷 손실도 고려합니다. Opus는 RFC 6716에서 대화형 음성과 오디오를 위한 코덱으로 정의되지만, Opus 파일을 하나 만든다고 통화 경로가 구성되지는 않습니다. 사용하는 통신 시스템의 패킷 전달 방식과 설정을 따라야 합니다. 저장·전송 용도로 같은 코덱을 쓸 수 있어도 각 환경에서 데이터를 묶고 전달하는 방법까지 같다고 가정하지 않는 이유입니다.

3분 원본에서 편집본·보관본·미리듣기 파일을 고릅니다

다음은 실제 변환 기록이 아니라 조건을 정해 선택을 끝까지 풀어 보는 예시입니다. 원본은 길이 180초, 48 kHz, 24비트 정수 PCM, 스테레오 WAV라고 가정합니다. 편집 전달처는 같은 사양의 WAV/PCM을 요구하고, 보관은 그 PCM을 복원할 수 있어야 하며, 미리듣기 전달처는 MP4/AAC-LC를 지원하고 파일당 6 MB를 허용한다고 정합니다. 특정 서비스나 기기의 실제 제한을 인용한 것이 아닙니다.

이 조건에서 편집용 파일은 원본 사양의 WAV/PCM으로 정합니다. 이미 요구와 일치하므로 파일 크기를 줄이려고 MP3로 바꿨다가 다시 WAV로 되돌릴 이유가 없습니다. 보관용 압축 사본은 동일한 48 kHz·24비트·2채널 정수 PCM을 FLAC으로 저장하는 선택이 가능합니다. 원본 WAV도 유지하면 압축 사본에서 누락될 수 있는 원래의 파일 부가 정보까지 대조할 기준이 남습니다.

미리듣기 파일은 PCM 기준본에서 직접 AAC-LC로 인코딩해 MP4에 담는 것으로 정합니다. 예산 검토를 위해 평균 오디오 비트레이트를 192 kbit/s로 가정하면 192,000 × 180 ÷ 8 = 4,320,000바이트, 즉 오디오 부분이 약 4.32 MB입니다. 6 MB와의 차이 1.68 MB는 포장 정보와 설정에 따른 차이를 받아들일 여유입니다. 이 숫자는 품질 추천이나 실제 출력 크기가 아니라 설정을 고르는 계산 예시이며, 가변 비트레이트 출력은 완성된 파일 크기를 별도로 확인해야 합니다.

이렇게 선택하면 편집에는 WAV/PCM, 정수 PCM 압축 보관에는 FLAC, 가정한 미리듣기 전달처에는 MP4/AAC-LC라는 결론이 나옵니다. 전달처가 MP3만 받는 조건으로 바뀐다면 미리듣기 형식만 MP3로 바꿔 PCM 기준본에서 새로 만듭니다. 앞서 만든 AAC 파일을 MP3로 재변환할 필요는 없습니다. 선택의 기준은 코덱의 이름 순위가 아니라 원본 보존, 전달 사양, 크기 예산이라는 세 가지 요구입니다.

실제로 출력한 뒤 비교할 때는 원본과 출력본의 같은 구간을 비슷한 재생 음량으로 듣고, 음성 자음·타격음·잔향처럼 차이를 확인하려는 부분을 정합니다. 중간 파일 이름과 인코더 설정을 남기면 어떤 출력에서 차이가 들렸는지 다시 찾을 수 있습니다. 이 예시에서는 변환이나 청취를 실행하지 않았으므로 192 kbit/s에서 차이가 들리지 않는다거나 특정 코덱이 우수하다는 결론은 내리지 않습니다.

무압축 PCM 용량은 저장 바이트 수로 계산합니다

무압축 PCM의 오디오 데이터 크기는 ‘초당 샘플 수 × 채널 수 × 샘플 하나를 저장하는 바이트 수 × 초 단위 길이’입니다. Microsoft의 WAVEFORMATEX 문서는 PCM의 초당 바이트 수를 샘플레이트와 블록 크기의 곱으로 설명합니다. 여기서 한 블록은 같은 시점에 해당하는 모든 채널의 저장 단위입니다. 이 식은 PCM 데이터에 대한 것으로 FLAC이나 AAC의 압축된 크기를 구하는 공식은 아닙니다.

앞의 예에서 48 kHz는 채널마다 초당 48,000개 샘플이고, 24비트 샘플 하나를 빈 공간 없이 3바이트에 저장한다고 가정합니다. 따라서 2채널의 같은 시점 값은 2 × 3 = 6바이트, 1초는 48,000 × 6 = 288,000바이트입니다. 3분은 180초이므로 288,000 × 180 = 51,840,000바이트입니다. 이를 십진 단위로 쓰면 51.84 MB이고, 1 MiB = 1,048,576바이트인 이진 단위로 쓰면 약 49.44 MiB입니다.

이 51.84 MB에는 WAV의 헤더, 추가 메타데이터, 청크 정렬용 채움 바이트가 포함되지 않습니다. 파일 전체는 이런 부분까지 합쳐지므로 계산값과 정확히 같을 필요가 없습니다. 헤더가 언제나 44바이트라고 가정하는 것도 피해야 합니다. RIFF는 여러 청크를 담을 수 있고 어떤 형식 정보와 메타데이터가 있는지에 따라 부가 크기가 달라지기 때문입니다. 이 예시의 계산값은 파일 크기를 실측한 결과가 아닙니다.

또한 유효한 값이 24비트여도 샘플 하나를 32비트 저장 공간에 넣는 방식이라면 3바이트 대신 4바이트를 곱해야 합니다. 같은 길이와 채널 수에서 48,000 × 2 × 4 × 180 = 69,120,000바이트, 즉 69.12 MB가 됩니다. 이때의 저장 공간은 샘플당 바이트 폭을 뜻하며, 앞에서 말한 WAV·Ogg 같은 파일 컨테이너와는 다른 단위입니다. 비트 깊이 숫자와 실제 저장 폭을 나누면 예상 용량이 다른 이유를 찾을 수 있습니다.

첫 계산을 비트 단위로 바꾸면 288,000 × 8 = 2,304,000 bit/s, 즉 2,304 kbit/s입니다. 앞서 가정한 AAC의 평균 192 kbit/s보다 오디오 데이터 전송률이 12배 크지만, 이 비율이 음질의 배수를 뜻하지는 않습니다. 무압축 PCM은 고정된 저장 폭으로 값을 담고 압축 코덱은 다른 규칙으로 데이터를 표현하므로, 서로 다른 코덱의 비트레이트만으로 들리는 품질을 순위화할 수 없습니다.

다시 만들 때는 기준본으로 돌아가고, 전달 사양을 함께 남깁니다

변환은 파일 이름 변경, 재포장, 오디오 재인코딩을 구별해야 합니다. 이름만 바꾸면 내부 데이터는 그대로입니다. 재포장인 리먹스는 지원되는 다른 저장 구조로 압축 데이터를 옮기는 작업이고, 재인코딩은 소리를 디코딩한 다음 새 규칙으로 다시 저장하는 작업입니다. 도구가 오디오를 그대로 복사했는지 재인코딩했는지 출력 설정과 작업 기록을 보면, 단순히 파일 확장자가 달라졌다는 사실보다 실제 변화를 정확히 설명할 수 있습니다.

예를 들어 MP3를 WAV/PCM으로 풀어 저장하면 편집 가능한 PCM 파일이 생기지만 최초 MP3 압축에서 없어지거나 달라진 정보가 되살아나지는 않습니다. 그 WAV를 FLAC으로 저장해도 복원할 수 있는 것은 이번에 입력한 PCM입니다. 다시 손실 압축을 하면 추가 변화가 생길 수 있으므로, 배포본의 설정을 바꿀 때는 보존해 둔 PCM 기준본에서 새 출력본을 만드는 편이 변환 경로를 짧게 유지합니다.

리먹스도 모든 조합에 가능한 것은 아닙니다. 새 컨테이너가 기존 코덱을 담을 수 있어야 하고, 대상 앱이 그 조합을 지원해야 합니다. 오디오 패킷을 그대로 옮겼더라도 제목이나 시간 정보가 같은 방식으로 전달되는지는 별도 문제입니다. 파일이 열리지 않을 때는 실제 코덱과 컨테이너를 먼저 읽어 전달 사양과 대조하면, 구조만 바꾸면 되는지 PCM 기준본에서 다시 인코딩해야 하는지를 판단할 수 있습니다.

앞의 가정으로 전달 메모를 작성한다면 ‘편집용은 WAV/PCM 48 kHz·24비트·2채널·180초, 압축 보관용은 동일 정수 PCM의 FLAC, 미리듣기용은 PCM 기준본에서 만든 MP4/AAC-LC이며 평균 192 kbit/s를 크기 예산의 출발값으로 사용’이라고 쓸 수 있습니다. 이것은 만들 파일의 사양을 완성한 문장입니다. 실제 작업 후에는 출력한 파일의 크기와 길이, 재생에 사용한 앱·버전, 확인된 문제를 덧붙여 제작 결과로 바꿉니다.

최종 전달에서는 출력 파일의 코덱·채널 수·길이가 의도와 맞는지 보고, 받는 환경에서 시작부터 끝까지 읽히는지와 필요한 제목·날짜 정보가 남았는지 확인합니다. 확인하지 않은 기기의 성공을 대신 적을 필요는 없습니다. 기준본과 출력 사양이 남아 있으면 받는 곳의 조건이 바뀌어도 압축된 배포본을 거듭 변환하지 않고 같은 기준에서 새 파일을 만들 수 있습니다.

갱신 이력

과거 게시·수정 이력은 확인 중이며, 확인된 변경부터 기록합니다.

• 내용 수정 / 2026-09-08

  반복적인 작성자 서사를 삭제하고 컨테이너·코덱 구분을 WAV/PCM과 Ogg/Opus 예시로 설명했습니다. 3분 원본의 편집·보관·배포 선택 사례, 51.84 MB 무압축 용량 계산과 저장 폭·헤더 가정을 추가하고 두 시각 자료를 구체적인 선택 예시로 고쳤습니다. 실제 변환·청취·기기 시험 및 사람의 검토를 수행했다는 의미는 아닙니다.

KEEP EXPLORING

관련 글

• 

  AUDIO

  디지털 오디오: 샘플·채널·PCM·파일 구조 이해하기

  좌우 채널의 짧은 숫자 배열로 샘플과 샘플 프레임을 구분하고 PCM, 컨테이너, 메타데이터의 역할을 설명합니다.

• 

  AUDIO

  샘플레이트와 비트 깊이, 원본과 납품 조건에 맞춰 선택하기

  샘플레이트는 시간 간격, 비트 깊이는 값의 표현 정밀도입니다. 원본과 납품 조건이 다른 세 가지 경우로 변환 위치를 정합니다.

• 

  MIX

  마스터링 뒤 음원 납품하기: 파일 목록과 누락 수정 예시

  보관용 마스터와 전달용 음원을 구분하고, 가상의 완성된 납품 파일 목록과 반주 파일 누락 수정 사례를 설명합니다. 기존 합성 음원의 로컬 검사 기록도 별도로 제시합니다.

• 

  REC

  녹음 세션·테이크·백업을 다시 열 수 있게 정리하기

  가상 녹음 프로젝트의 폴더와 테이크 이름을 정하고, 외부 음원 누락을 찾은 뒤 백업을 다시 여는 순서를 설명합니다.

• 

  AUDIO

  피크·RMS·LUFS: 미터가 답하는 질문을 구분하는 법

  피크·RMS·LUFS의 차이를 짧은 배열 계산과 가상 음량 보고서로 읽고, 측정 구간과 목표 규격을 구분합니다.