AAC 오디오 코덱: LC-AAC·HE-AAC 압축 원리와 FFmpeg 인코딩 설정

작성 0xmote · 2026년 5월 14일 · 25분 읽기 · 수정 2026년 5월 14일 중급 가이드

이 글의 핵심

AAC 코덱의 LC-AAC·HE-AAC 프로파일, MPEG-4 컨테이너 연동, FFmpeg 인코딩 옵션까지. 스트리밍·모바일 실무에서 품질과 용량을 맞추는 방법을 정리합니다.

들어가며

AAC(Advanced Audio Coding)는 MP3의 후속으로 설계된 MPEG 계열 손실 압축 코덱으로, 동일 비트레이트에서 일반적으로 MP3보다 나은 음질을 목표로 합니다. HLS·DASH·MP4 등 현대 스트리밍과 모바일 생태계에서 사실상 표준에 가깝게 사용되며, 인코더 품질과 프로파일(LC-AAC, HE-AAC) 선택이 곧 서비스 체감 음질과 대역폭 비용으로 이어집니다. YouTube, Netflix, Spotify 같은 주요 스트리밍 플랫폼에서 AAC를 기본 오디오 코덱으로 사용하는 이유는 압축 효율과 광범위한 기기 지원 때문입니다. 특히 모바일 환경에서는 하드웨어 가속 디코딩이 가능해 배터리 소모를 줄이면서도 고음질을 제공할 수 있습니다. 실무에서는 “어떤 프로파일을 쓸지”, “비트레이트는 몇 kbps로 잡을지”, “FFmpeg에서 어떤 인코더 옵션이 맞는지”를 동시에 결정해야 합니다. 이 글은 코덱 구조를 이해한 뒤, 재현 가능한 FFmpeg 예제와 품질·용량 트레이드오프까지 한 흐름으로 연결합니다.

이 글을 읽으면

AAC의 역사와 MPEG-2/4에서의 위치, 주요 프로파일(LC-AAC, HE-AAC) 차이를 이해합니다
심리음향 모델·MDCT 기반 블록 코딩의 큰 그림을 잡습니다
FFmpeg로 목적에 맞는 AAC 인코딩 명령을 구성할 수 있습니다
스트리밍·모바일 관점에서 비트레이트·컨테이너 선택 기준을 정리할 수 있습니다
실전에서 자주 발생하는 문제와 해결 방법을 익힙니다

코덱 개요

역사 및 개발 배경

AAC는 1997년 ISO/IEC 13818-7(MPEG-2 Part 7) 로 표준화되었으며, 이후 ISO/IEC 14496-3(MPEG-4 Audio) 에 통합·확장되었습니다. 개발 목표는 명확했습니다: MP3보다 나은 음질을 동일 비트레이트에서 제공하는 것. 이를 위해 MP3(MPEG-1/2 Layer 3) 대비 다음 요소들이 개선되었습니다:

더 정교한 필터뱅크: 주파수 분해능 향상
향상된 임계 대역 분할: 인간 청각 특성에 더 근접
개선된 톤·노이즈 모델링: 음악과 음성 모두에서 효율 증가
더 유연한 블록 크기: 순간적인 소리 변화에 적응 상용 서비스에서는 Apple 생태계(iTunes, Apple Music, AAC-LC 기반) 와 적응형 스트리밍(HLS의 AAC) 에서 널리 채택되었습니다. 2000년대 중반 iPod이 AAC를 지원하면서 대중화의 전환점을 맞았으며, 이후 YouTube, Netflix 등 주요 플랫폼이 AAC를 표준으로 채택했습니다.

기술적 특징

항목	설명
압축 방식	지각 코딩(Perceptual coding) 기반 손실 압축, MDCT 계열 변환·양자화·무손실 코드북 등
샘플레이트	8 kHz~96 kHz 지원 (프로파일·구현에 따름), 실무에서는 44.1/48 kHz가 대부분
비트레이트	음악: 128~256 kbps(스테레오) 구간이 흔함, HE-AAC는 더 낮은 비트레이트 대역에서 유리
채널	모노~멀티채널(5.1, 7.1 등) 확장 가능, 스트리밍에서는 스테레오가 대표적
지연	프레임 크기에 따라 약 20~50ms (프로파일·설정 의존)
컨테이너	MP4(.m4a), ADTS(.aac), 3GP, MPEG-TS 등

주요 프로파일

AAC는 용도에 따라 여러 프로파일을 제공합니다. 각 프로파일은 압축 효율과 복잡도 사이의 트레이드오프를 다르게 설정합니다.

프로파일	기술	권장 비트레이트	주요 용도
AAC-LC	기본 MDCT + 심리음향	128~256 kbps (스테레오)	음악, 팟캐스트, VOD, 범용
HE-AAC v1	LC + SBR(고역 복원)	64~96 kbps (스테레오)	모바일 스트리밍, 라디오
HE-AAC v2	v1 + PS(스테레오 파라메트릭)	32~64 kbps (스테레오)	초저대역폭, 음성 중심

AAC-LC (Low Complexity)

가장 널리 지원되는 기본 프로파일입니다. 복잡한 추가 기술 없이 MDCT와 심리음향 모델만으로 압축하므로:

장점:
- 거의 모든 기기에서 재생 가능 (스마트폰, PC, 자동차, 스마트TV 등)
- 디코딩 부하 낮음 (배터리 효율 좋음)
- 음질 예측 가능하고 안정적
- 하드웨어 가속 지원 광범위
단점:
- 저비트레이트(64 kbps 이하)에서는 HE-AAC보다 음질이 떨어질 수 있음
- 극한의 대역폭 절약이 필요한 환경에서는 비효율적
추천 시나리오:
- 일반 음악 스트리밍 (Spotify, Apple Music 등)
- 팟캐스트 (128~160 kbps)
- VOD 서비스 (영상의 오디오 트랙)
- 오프라인 음악 파일

HE-AAC v1 (High-Efficiency AAC)

SBR(Spectral Band Replication) 기술을 추가하여 고주파 성분을 효율적으로 복원합니다:

원리:
- 저주파 대역(~8kHz)만 실제로 전송
- 고주파는 저주파의 패턴을 분석하여 디코더에서 복원
- 인간 청각이 고주파 디테일에 덜 민감한 특성 활용
장점:
- 64~96 kbps에서 AAC-LC 128 kbps 수준의 음질 가능
- 대역폭 절약 효과 큼 (모바일 데이터 비용 절감)
- 음악과 음성 모두 적절한 품질 유지
단점:
- 디코딩 복잡도 증가 (CPU 사용량 약 1.5배)
- 구형 기기(2010년 이전)는 미지원 가능성
- 고주파가 중요한 음악(심벌, 하이햇)에서 아티팩트 발생 가능
추천 시나리오:
- 모바일 네트워크 환경 (3G, 느린 4G)
- 인터넷 라디오 방송
- 대역폭 제한이 있는 스트리밍

HE-AAC v2 (HE-AAC + PS)

Parametric Stereo(PS) 를 추가하여 스테레오 정보를 파라미터로 압축합니다:

원리:
- 모노 신호만 전송하고 스테레오 위치 정보는 파라미터로 전송
- 좌우 채널의 차이를 수학적 모델로 표현
- 디코더에서 모노 + 파라미터로 스테레오 재구성
장점:
- 32~48 kbps에서도 스테레오 느낌 유지
- 극한의 대역폭 절약 (음성 통화 수준)
- 파일 크기 최소화
단점:
- 음악보다는 음성/토크에 적합
- 복잡한 음악(오케스트라, 록)은 스테레오 이미지 왜곡
- 지원 기기 제한적 (최신 기기 위주)
추천 시나리오:
- 음성 통화, 오디오북
- 토크쇼, 팟캐스트 (음악 없는 경우)
- 극저대역폭 환경 (위성 통신 등) 선택 가이드:

flowchart TD
    START[비트레이트 결정]
    START --> Q1{128 kbps 이상?}
    Q1 -->|Yes| LC[AAC-LC 사용]
    Q1 -->|No| Q2{64~96 kbps?}
    Q2 -->|Yes| Q3{음악 위주?}
    Q3 -->|Yes| HE1[HE-AAC v1 사용]
    Q3 -->|No| HE2[HE-AAC v2 고려]
    Q2 -->|No| Q4{48 kbps 이하?}
    Q4 -->|Yes| Q5{음성만?}
    Q5 -->|Yes| HE2
    Q5 -->|No| OPUS[Opus 검토 권장]
    
    LC --> RESULT1["최고 호환성\n안정적 음질"]
    HE1 --> RESULT2["대역폭 절약\n모바일 최적"]
    HE2 --> RESULT3["극한 압축\n음성 특화"]
    OPUS --> RESULT4["실시간 통화\n초저지연"]

압축 원리

심리음향 모델(Psychoacoustic Model)

AAC의 핵심은 인간이 듣지 못하는 소리는 저장하지 않는다는 원칙입니다. 인간 청각은 다음과 같은 특성을 가집니다:

동시 마스킹(Simultaneous Masking): 큰 소리가 있으면 비슷한 주파수의 작은 소리를 듣지 못함
- 예: 드럼 킥이 울릴 때 베이스 기타의 미세한 떨림은 들리지 않음
시간적 마스킹(Temporal Masking): 큰 소리 직전·직후에는 작은 소리를 듣지 못함
- 예: 심벌 타격 직후 20~30ms 동안 배경 노이즈는 인지되지 않음
주파수 민감도 차이: 2~5 kHz 대역에 가장 민감하며, 저주파·고주파로 갈수록 둔감 AAC는 이를 이용해 지각적으로 덜 중요한 계수에 더 거친 양자화를 적용해 비트를 아낍니다. 즉 “데이터를 줄인다”기보다 들리지 않을 가능성이 높은 성분부터 줄이는 전략입니다.

MDCT(Modified Discrete Cosine Transform)

AAC 계열은 주로 MDCT 기반 필터뱅크로 시간 영역 신호를 주파수 계수로 바꿉니다.

MDCT의 특징:

중첩·접합(Overlap-Add) 구조: 블록 경계에서 발생하는 불연속성 제거
가변 블록 길이:
- 긴 블록(1024 샘플): 정상 상태 신호, 주파수 분해능 우수
- 짧은 블록(128 샘플): 순간적인 공격음(transient), 시간 분해능 우수
임계 대역 기반 그룹화: 인간 청각의 주파수 분해능에 맞춰 계수를 그룹화 왜 MDCT를 쓰나요? 시간 영역에서는 소리의 변화를 알 수 있지만 주파수 특성은 알기 어렵습니다. 반대로 주파수 영역에서는 어떤 음이 있는지 알 수 있지만 시간 정보가 부족합니다. MDCT는 이 둘을 적절히 균형있게 표현하면서도 중첩 구조로 블록 경계 아티팩트를 제거하는 장점이 있습니다.

비트레이트 할당 전략

내부적으로는 주파수 대역별로 비트 풀(bit pool) 을 나누고, 심리음향 가중치에 따라 톤·노이즈 성분에 비트를 배분합니다.

할당 과정:

심리음향 분석: 각 주파수 대역의 마스킹 임계값 계산
비트 예산 분배: 중요한 대역에 더 많은 비트 할당
양자화 단계 결정: 대역별로 다른 정밀도로 양자화
반복 최적화: 목표 비트레이트를 맞추면서 왜곡 최소화 저비트레이트에서는 다음 기법들이 추가로 작동합니다:

대역폭 제한: 고주파를 아예 전송하지 않음 (예: 16 kHz 이상 제거)
스펙트럴 라인 대체: 복잡한 주파수 성분을 노이즈로 근사
TNS(Temporal Noise Shaping): 시간 영역 노이즈 분포 최적화 HE-AAC 계열은 SBR(Spectral Band Replication) 로 고역 정보를 별도 레이어로 효율적으로 부호화합니다. 실제로 전송되는 데이터는 8 kHz 이하만 포함하며, 8~16 kHz는 SBR 파라미터로 복원합니다.

처리 흐름

아래는 AAC 인코딩의 전체 파이프라인을 보여줍니다.

flowchart TB
    subgraph INPUT[입력 단계]
        PCM["PCM 오디오\n44.1/48 kHz"]
    end
    
    subgraph ANALYSIS[분석 단계]
        PSY["심리음향 분석\n마스킹 임계값 계산"]
        MDCT["MDCT 변환\n시간→주파수 영역"]
    end
    
    subgraph ENCODING[인코딩 단계]
        QUANT["양자화\n대역별 비트 할당"]
        CODEBOOK["코드북 선택\n효율적 표현"]
        TNS["TNS 적용\n시간 노이즈 정형"]
    end
    
    subgraph OPTIONAL[선택적 기술]
        SBR["SBR\n고역 복원\nHE-AAC v1"]
        PS["PS\n스테레오 파라메트릭\nHE-AAC v2"]
    end
    
    subgraph OUTPUT[출력 단계]
        ENTROPY["엔트로피 코딩\nHuffman 등"]
        BITSTREAM["AAC 비트스트림\nADTS/MP4"]
    end
    
    PCM --> PSY
    PCM --> MDCT
    PSY --> QUANT
    MDCT --> QUANT
    QUANT --> CODEBOOK
    CODEBOOK --> TNS
    TNS --> ENTROPY
    
    PSY -.-> SBR
    QUANT -.-> SBR
    SBR -.-> ENTROPY
    
    PSY -.-> PS
    PS -.-> ENTROPY
    
    ENTROPY --> BITSTREAM
    
    style INPUT fill:#e3f2fd
    style ANALYSIS fill:#fff3e0
    style ENCODING fill:#f3e5f5
    style OPTIONAL fill:#e8f5e9
    style OUTPUT fill:#fce4ec

실전 인코딩

FFmpeg 인코더 선택

FFmpeg에서 실제로 고를 수 있는 AAC 인코더는 세 가지입니다:

인코더	특징	사용 시기
`aac`	네이티브 인코더, 모든 빌드에 기본 포함. LC만 지원(HE-AAC 불가)	128 kbps 이상 LC, 배포 가능한 바이너리가 필요할 때
`libfdk_aac`	Fraunhofer 인코더. LC·HE-AAC v1/v2·LD/ELD 지원, 저비트레이트에서 특히 우수	96 kbps 이하, HE-AAC가 필요할 때
`aac_at`	macOS/iOS의 AudioToolbox(Apple 인코더) 래퍼. LC·HE 지원	macOS 빌드 서버에서 인코딩할 때

제 기준은 이렇습니다. 128 kbps 이상 스테레오 LC라면 네이티브 aac로도 대부분의 청취자가 차이를 구분하기 어렵고, 배포·라이선스 문제가 없어서 기본값으로 둡니다. 비트레이트를 96 kbps 아래로 내려야 하거나 HE-AAC가 필요해지는 순간부터 libfdk_aac(또는 macOS라면 aac_at)를 씁니다. 네이티브 인코더는 저비트레이트에서 약점이 뚜렷하기 때문입니다.

주의할 점은 libfdk_aac의 라이선스가 GPL과 호환되지 않아서, 이를 포함한 FFmpeg는 --enable-nonfree로만 빌드되고 바이너리를 재배포할 수 없다는 것입니다. 그래서 배포판 패키지나 공식 정적 빌드에는 빠져 있고, 직접 빌드해 사내에서만 써야 합니다. 도커 이미지에 넣어 고객에게 배포하는 제품이라면 처음부터 네이티브 aac나 OS 인코더를 전제로 설계하는 편이 안전합니다.

인코더 확인:

# 사용 가능한 AAC 인코더 확인
ffmpeg -encoders | grep aac
# 출력 예시:
# A......aac                  AAC (Advanced Audio Coding)
# A......libfdk_aac           Fraunhofer FDK AAC

기본 인코딩 예제

1. AAC-LC, CBR 스테레오 128 kbps

가장 기본적이고 안정적인 설정입니다. 대부분의 음악 스트리밍에 적합합니다.

ffmpeg -i input.wav \
  -c:a aac \
  -b:a 128k \
  -ar 48000 \
  -ac 2 \
  output.m4a

옵션 설명:

-c:a aac: AAC 인코더 사용
-b:a 128k: 비트레이트 128 kbps
-ar 48000: 샘플레이트 48 kHz (영상과 합칠 때 권장)
-ac 2: 스테레오 (2채널)
인코딩 알고리즘(-aac_coder)은 기본값이 이미 품질 위주의 twoloop이라 따로 지정할 필요가 없습니다. fast로 바꾸면 빨라지는 대신 품질이 떨어집니다.

2. 네이티브 aac의 VBR(`-q:a`)은 쓰지 않는다

네이티브 aac 인코더도 -q:a를 받지만 FFmpeg 문서에서 실험적 기능으로 분류되어 있고, 값과 실제 비트레이트의 관계도 일정하지 않습니다(범위는 대략 0.1~2이며 값이 클수록 고품질입니다. MP3의 “-q:a 0이 최고 품질” 관례와 방향이 반대라 헷갈리기 쉽습니다). 품질을 예측 가능하게 관리하려면 네이티브 인코더는 -b:a로 비트레이트를 지정하고, 진짜 VBR이 필요하면 libfdk_aac의 -vbr을 쓰는 편이 낫습니다.

3. libfdk_aac 사용 (고품질)

libfdk_aac가 설치되어 있다면 더 나은 음질을 얻을 수 있습니다:

ffmpeg -i input.wav \
  -c:a libfdk_aac \
  -profile:a aac_low \
  -vbr 4 \
  -ar 44100 \
  -ac 2 \
  output.m4a

-vbr 값 가이드 (libfdk_aac, FFmpeg 위키 기준 채널당 대략값):

1: 20~32 kbps/ch
2: 32~40 kbps/ch
3: 48~56 kbps/ch
4: 64~~72 kbps/ch (스테레오 약 128~~144 kbps)
5: 96~~112 kbps/ch (스테레오 약 192~~224 kbps)

채널당 값이라는 걸 놓치면 스테레오 -vbr 4를 “96 kbps짜리”로 착각해 용량 계산이 크게 틀어집니다. 또 HE-AAC 프로파일과 VBR을 함께 쓸 때는 낮은 모드(1~3)만 의미가 있으니, HE-AAC는 -b:a로 지정하는 쪽이 단순합니다.

4. HE-AAC v1 인코딩

저비트레이트 모바일 스트리밍용:

ffmpeg -i input.wav \
  -c:a libfdk_aac \
  -profile:a aac_he \
  -b:a 64k \
  -ar 44100 \
  -ac 2 \
  output.m4a

주의: 네이티브 aac 인코더는 HE-AAC를 지원하지 않습니다. libfdk_aac 필수입니다.

5. HE-AAC v2 인코딩

극저비트레이트 음성용:

ffmpeg -i input.wav \
  -c:a libfdk_aac \
  -profile:a aac_he_v2 \
  -b:a 32k \
  -ar 44100 \
  -ac 2 \
  output.m4a

6. HLS 스트리밍용 AAC

HTTP Live Streaming을 위한 ADTS 포맷:

ffmpeg -i input.wav \
  -c:a aac \
  -b:a 160k \
  -ar 48000 \
  -ac 2 \
  -f adts \
  output.aac

ADTS vs MP4:

ADTS: 각 프레임에 헤더 포함, 스트리밍 세그먼트에 적합
MP4: 메타데이터가 파일 시작/끝에 집중, 다운로드 재생에 적합

7. 영상과 함께 인코딩

비디오 파일의 오디오만 AAC로 재인코딩:

ffmpeg -i input.mp4 \
  -c:v copy \
  -c:a aac \
  -b:a 192k \
  -ar 48000 \
  output.mp4

-c:v copy: 비디오는 재인코딩하지 않고 복사 (빠르고 화질 손실 없음)

파라미터 튜닝 가이드

샘플레이트 선택

샘플레이트	용도	주의사항
44.1 kHz	CD 음질, 음악	원본이 44.1이면 유지 권장
48 kHz	영상 표준, 방송	비디오와 합칠 때 필수
32 kHz	저품질 스트리밍	대역폭 극한 절약 시만
22.05 kHz	음성, 라디오	음악에는 부적합

리샘플링 주의: 원본이 44.1 kHz인데 48 kHz로 올렸다가 다시 44.1 kHz로 내리면 앨리어싱·왜곡 위험이 생깁니다. 가능하면 원본 샘플레이트를 유지하세요.

비트레이트 선택

음악 스트리밍 (스테레오 기준):

비트레이트	음질	용도
256 kbps	투명에 가까움	고음질 스트리밍, 오디오파일
192 kbps	우수	일반 스트리밍
128 kbps	양호	표준 스트리밍, 모바일
96 kbps	보통	저대역폭 환경 (HE-AAC v1 권장)
64 kbps	낮음	HE-AAC v1 필수
48 kbps 이하	음성 전용	HE-AAC v2 또는 Opus

팟캐스트/음성:

음성만: 64~~96 kbps (모노 32~~48 kbps도 가능)
음성 + 배경음악: 96~128 kbps
고품질 인터뷰: 128~160 kbps 장르별 권장 비트레이트:
클래식, 재즈: 192~256 kbps (잔향·디테일 중요)
팝, 록: 128~192 kbps
일렉트로닉: 160~192 kbps (고주파 신시사이저)
토크, 오디오북: 64~96 kbps

품질 vs 파일 크기 트레이드오프

실제 파일 크기 예시 (3분 음악, 스테레오):

비트레이트	파일 크기	음질 체감
320 kbps (MP3 최고)	~7.2 MB	투명
256 kbps (AAC)	~5.8 MB	거의 투명
192 kbps (AAC)	~4.3 MB	우수 (대부분 만족)
128 kbps (AAC)	~2.9 MB	양호 (일반 청취 OK)
96 kbps (HE-AAC v1)	~2.2 MB	보통 (모바일 환경)
64 kbps (HE-AAC v1)	~1.4 MB	낮음 (음성 위주)

동일 청취 환경에서 192 kbps 대 128 kbps는 파일 크기 대비 체감이 큰 편입니다. 반면 256 kbps 이상은 상황에 따라 수익 분석(대역폭·CDN 비용)이 필요합니다. ABX 청취 테스트로 팀 기준선을 정하는 것을 권장합니다:

# 같은 소스를 여러 비트레이트로 인코딩
ffmpeg -i source.wav -c:a aac -b:a 128k test_128.m4a
ffmpeg -i source.wav -c:a aac -b:a 192k test_192.m4a
ffmpeg -i source.wav -c:a aac -b:a 256k test_256.m4a
# 블라인드 테스트로 차이 확인

성능 비교

다른 코덱과의 압축 효율

동일 주관 청취 조건에서의 일반적인 평가입니다 (콘텐츠·인코더에 따라 달라질 수 있음):

비트레이트	MP3	AAC-LC	HE-AAC v1	Opus
32 kbps	매우 낮음	낮음	보통	우수 (음성)
64 kbps	낮음	보통	양호	우수
96 kbps	보통	양호	우수	우수
128 kbps	양호	우수	과잉	우수
192 kbps	우수	거의 투명	과잉	거의 투명

결론:

128 kbps 이상: AAC-LC와 MP3의 차이가 명확, AAC가 유리
64~96 kbps: HE-AAC v1이 AAC-LC보다 명확히 우수
48 kbps 이하: Opus가 AAC보다 우수한 경우 많음 (음성 특화)

인코딩·디코딩 속도

디코딩 성능:

하드웨어 가속: 대부분의 모바일 SoC에 AAC 하드웨어 디코더 내장
- iOS·Android 모두 OS 미디어 프레임워크(AVFoundation, MediaCodec)를 통해 오디오 DSP나 최적화된 디코더를 씀
- PC에서는 AAC 디코딩 부하 자체가 매우 작아 소프트웨어 디코딩으로 충분합니다(Quick Sync 같은 GPU 미디어 엔진은 비디오용)
배터리 효율: 모바일에서 화면을 끈 백그라운드 재생 시 저전력 오디오 경로를 탈 수 있다는 점이 AAC의 실질적 장점입니다. 앱이 자체 소프트웨어 디코더를 번들하면 이 이점을 잃을 수 있습니다. 인코딩 성능: 오디오 인코딩은 영상에 비하면 부담이 매우 작아서, 어느 인코더든 일반 CPU에서 실시간보다 수십 배 빠르게 처리됩니다. 네이티브 aac가 가장 빠르고, libfdk_aac와 HE-AAC(SBR 분석이 추가됨)가 그보다 느립니다. 대량 배치에서 병목은 대개 인코더가 아니라 원본 디코딩·디스크 I/O이니, 인코더 선택은 속도보다 품질과 라이선스로 판단하면 됩니다.

주관적 음질(MOS)

MOS(Mean Opinion Score)는 실험 조건·코덱 버전에 따라 달라집니다. 그래서 특정 MOS 숫자를 기준표처럼 쓰기보다, 공개된 청취 테스트들이 공통으로 보여 주는 경향만 기억하는 편이 안전합니다. 64 kbps 전후에서는 HE-AAC가 LC보다 확실히 낫고, 128 kbps 이상 스테레오에서는 좋은 LC 인코더와 원본을 구분하기 어려운 청취자가 대부분이며, 같은 비트레이트면 MP3보다 AAC가 앞섭니다.

실무에서는 ITU-R BS.1534(MUSHRA) 같은 표준 청취 절차를 참고하되, 서비스별 타깃 기기·이어폰으로 자체 MOS 설문을 설계하는 것이 안전합니다.

실무 활용 사례

스트리밍 서비스

주요 플랫폼의 AAC 사용:

Apple Music: 기본 스트리밍은 AAC 256 kbps, 무손실은 ALAC
YouTube: MP4 계열 재생에서는 AAC-LC 약 128 kbps, WebM 계열에서는 Opus를 주로 사용 (같은 영상에 두 트랙이 모두 존재)
Netflix: 스테레오는 AAC/HE-AAC 계열, 5.1 이상 서라운드는 주로 Dolby Digital Plus(E-AC-3). Android에서는 음량 제어를 위해 xHE-AAC를 도입했다고 공개한 바 있음
Spotify: 앱은 주로 Ogg Vorbis, 웹 플레이어는 AAC 적응형 스트리밍 구성 예시:

# 여러 비트레이트 버전 생성
ffmpeg -i source.wav -c:a aac -b:a 256k -ar 48000 audio_256k.m4a
ffmpeg -i source.wav -c:a aac -b:a 192k -ar 48000 audio_192k.m4a
ffmpeg -i source.wav -c:a aac -b:a 128k -ar 48000 audio_128k.m4a
ffmpeg -i source.wav -c:a libfdk_aac -profile:a aac_he -b:a 64k audio_64k.m4a

클라이언트는 네트워크 속도에 따라 자동으로 적절한 버전을 선택합니다.

모바일 앱

iOS·Android 모두 AAC 디코딩이 기본적으로 잘 지원됩니다.

모바일 최적화 전략:

오프라인 캐시:
- Wi-Fi: 192 kbps AAC-LC
- 모바일 데이터: 96 kbps HE-AAC v1
백그라운드 재생: 하드웨어 디코딩으로 배터리 절약
A/B 테스트:
- 사용자 그룹별로 다른 비트레이트 제공
- 이탈률, 재생 완료율, 사용자 피드백 수집 실제 구현 예시 (의사 코드):

// 네트워크 상태에 따른 품질 선택
const quality = networkSpeed > 5000 ? 'high' : 
                networkSpeed > 2000 ? 'medium' : 'low';
const audioUrl = {
  high: '/audio/song_192k.m4a',    // AAC-LC 192 kbps
  medium: '/audio/song_128k.m4a',  // AAC-LC 128 kbps
  low: '/audio/song_64k.m4a'       // HE-AAC v1 64 kbps
}[quality];

팟캐스트 제작

팟캐스트는 음성이 주이므로 낮은 비트레이트도 충분합니다:

권장 설정:

# 음성 전용 팟캐스트 (모노)
ffmpeg -i podcast.wav \
  -c:a aac \
  -b:a 64k \
  -ar 44100 \
  -ac 1 \
  podcast_mono.m4a
# 음성 + 인트로/아웃트로 음악 (스테레오)
ffmpeg -i podcast.wav \
  -c:a aac \
  -b:a 96k \
  -ar 44100 \
  -ac 2 \
  podcast_stereo.m4a

파일 크기 비교 (1시간 팟캐스트):

64 kbps 모노: ~28 MB
96 kbps 스테레오: ~43 MB
128 kbps 스테레오: ~57 MB

VoIP 및 WebRTC

실시간 음성 통신에서는 AAC보다 Opus가 더 적합합니다:

AAC-LC/HE-AAC: 프레임이 1024샘플(48kHz에서 약 21ms)이고 룩어헤드까지 더해져 알고리즘 지연이 큼. HE-AAC는 더 큼
AAC-LD/ELD: 통화용 저지연 변형(Apple FaceTime이 AAC-ELD 사용)이지만 브라우저 WebRTC에서는 쓸 수 없음
Opus: 프레임 2.5~60ms 가변, 기본 20ms 프레임에서 알고리즘 지연 약 26.5ms이며 WebRTC 필수 코덱 AAC는 지연·프레이밍 특성상 실시간 통화보다는 녹음된 미디어 파일·적응형 스트리밍 쪽에 가깝습니다.

브라우저 지원

HTML5 <audio> 태그:

<audio controls>
  <source src="audio.m4a" type="audio/mp4">
  <source src="audio.mp3" type="audio/mpeg">
  브라우저가 오디오를 지원하지 않습니다.
</audio>

지원 현황:

브라우저	AAC in MP4	ADTS(.aac)
Chrome/Edge	✅	재생은 되나 길이·탐색 부정확
Firefox	✅ (OS 디코더 사용)	재생은 되나 길이·탐색 부정확
Safari	✅	✅

권장: 웹에서는 MP4 컨테이너(.m4a) 를 사용하세요. ADTS는 인덱스가 없어 길이 표시·탐색이 불안정하고, 일부 리눅스 배포판의 Chromium·Firefox는 특허 코덱을 빼고 빌드되거나 OS 코덱 패키지가 없어 AAC 자체가 재생되지 않을 수 있습니다.

xHE-AAC(USAC): 다음 세대

xHE-AAC는 음성과 음악을 모두 저비트레이트에서 다루도록 설계된 USAC 기반 프로파일로, 매우 낮은 비트레이트부터 고음질 구간까지 하나의 코덱으로 적응형 스트리밍할 수 있고 MPEG-D DRC(음량·다이내믹 레인지 제어)를 필수로 지원합니다. Android 9 이상과 iOS 13/macOS 10.15 이상이 디코딩을 지원합니다. 다만 오픈소스 인코더 선택지가 거의 없고 브라우저·구형 기기 지원이 고르지 않아서, 일반 서비스라면 LC/HE-AAC 사다리를 유지하고 xHE-AAC는 대상 기기가 확실한 앱에서 검토하는 정도가 현실적입니다. MSE(Media Source Extensions) 환경에서 AAC in fMP4(fragmented MP4) 는 널리 지원됩니다. HLS, DASH 같은 적응형 스트리밍의 기반 기술입니다.

최적화 팁

음질 유지하며 파일 크기 줄이기

1. 불필요한 리샘플 제거

원본 샘플레이트를 유지하면 품질 손실과 처리 시간을 줄일 수 있습니다:

# 나쁜 예: 불필요한 리샘플
ffmpeg -i input_44100.wav -ar 48000 -c:a aac -b:a 128k temp.m4a
ffmpeg -i temp.m4a -ar 44100 output.m4a  # 품질 저하!
# 좋은 예: 원본 유지
ffmpeg -i input_44100.wav -c:a aac -b:a 128k output.m4a

2. HE-AAC 활용

저비트레이트 모바일 스트림이라면 HE-AAC가 용량 대비 체감에 유리할 수 있습니다:

# AAC-LC 128 kbps vs HE-AAC v1 64 kbps 비교
ffmpeg -i input.wav -c:a aac -b:a 128k lc_128.m4a
ffmpeg -i input.wav -c:a libfdk_aac -profile:a aac_he -b:a 64k he_64.m4a
# 파일 크기는 절반, 음질은 비슷한 수준

주의: 클라이언트 지원 확인 필수. 구형 기기는 HE-AAC를 재생하지 못할 수 있습니다.

3. 무음 구간 최적화

긴 무음이 있는 콘텐츠(강의, 인터뷰)는 편집으로 제거하면 파일 크기 감소:

# 무음 감지 및 제거 (FFmpeg)
ffmpeg -i input.wav \
  -af "silenceremove=start_periods=1:start_silence=0.1:start_threshold=-50dB" \
  -c:a aac -b:a 96k \
  output.m4a

인코딩 속도 개선

1. 단일 패스 CBR 사용

VBR이나 멀티패스보다 빠르고 예측 가능합니다:

# 빠른 인코딩 (CBR)
ffmpeg -i input.wav -c:a aac -b:a 128k -ar 48000 output.m4a

2. CPU 병렬화

여러 파일을 동시에 인코딩:

# GNU parallel 사용
find ./wav -name '*.wav' -print0 | \
  parallel -0 -j 4 \
  ffmpeg -y -i {} -c:a aac -b:a 160k {.}.m4a

-j 4: 동시에 4개 파일 처리 (CPU 코어 수에 맞게 조정)

3. 하드웨어 가속 (인코딩은 제한적)

AAC 인코딩은 대부분 소프트웨어 기반입니다. 하드웨어 가속은 디코딩에만 광범위하게 지원됩니다.

배치 처리 자동화

대량의 파일을 일관되게 인코딩하는 스크립트 예시:

#!/bin/bash
# batch_encode.sh
INPUT_DIR="./source"
OUTPUT_DIR="./encoded"
BITRATE="128k"
SAMPLE_RATE="48000"
mkdir -p "$OUTPUT_DIR"
for file in "$INPUT_DIR"/*.wav; do
  filename=$(basename "$file" .wav)
  echo "Encoding: $filename"
  
  ffmpeg -i "$file" \
    -c:a aac \
    -b:a "$BITRATE" \
    -ar "$SAMPLE_RATE" \
    -ac 2 \
    -aac_coder twoloop \
    "$OUTPUT_DIR/${filename}.m4a" \
    -y
    
  # 품질 검증: 스펙트로그램 생성
  ffmpeg -i "$OUTPUT_DIR/${filename}.m4a" \
    -lavfi showspectrumpic=s=1920x1080 \
    "$OUTPUT_DIR/${filename}_spectrum.png" \
    -y
done
echo "Batch encoding complete!"

CI/CD 통합:

# .github/workflows/encode-audio.yml
name: Encode Audio Files
on:
  push:
    paths:
      - 'audio/source/**/*.wav'
jobs:
  encode:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Install FFmpeg
        run: sudo apt-get install -y ffmpeg
      
      - name: Encode AAC
        run: |
          for file in audio/source/*.wav; do
            ffmpeg -i "$file" -c:a aac -b:a 192k "${file%.wav}.m4a"
          done
      
      - name: Upload artifacts
        uses: actions/upload-artifact@v3
        with:
          name: encoded-audio
          path: audio/source/*.m4a

CI에서 입력 지문(체크섬)·출력 스펙트로그램 스냅샷을 저장하면, 인코더 업그레이드 시 회귀 탐지에 도움이 됩니다.

흔한 문제와 해결

호환성 이슈

문제 1: HE-AAC가 재생되지 않음

증상: 구형 기기에서 소리가 안 나오거나 에러 발생 원인: HE-AAC 디코더 미지원 (2010년 이전 기기) 해결:

# 폴백 전략: AAC-LC 버전도 함께 제공
ffmpeg -i input.wav -c:a aac -b:a 128k fallback_lc.m4a
ffmpeg -i input.wav -c:a libfdk_aac -profile:a aac_he -b:a 64k modern_he.m4a

웹에서는 <audio> 태그에 여러 소스 제공:

<audio controls>
  <source src="audio_he.m4a" type='audio/mp4; codecs="mp4a.40.5"'>
  <source src="audio_lc.m4a" type='audio/mp4; codecs="mp4a.40.2"'>
</audio>

type을 audio/mp4로만 적으면 브라우저는 두 소스를 구분할 수 없어 첫 번째를 그대로 고릅니다. codecs 파라미터(mp4a.40.2=LC, mp4a.40.5=HE-AAC v1, mp4a.40.29=HE-AAC v2)를 붙여야 “이 프로파일을 재생할 수 있는가”로 판단합니다. HLS 마스터 플레이리스트의 CODECS 속성도 같은 문자열을 쓰는데, 실제 스트림과 다르게 적으면 일부 플레이어가 변형을 건너뛰니 인코딩 설정과 함께 관리해야 합니다.

문제 2: ADTS 파일이 브라우저에서 재생 안 됨

증상: .aac 파일이 일부 환경에서 재생되지 않거나, 재생은 되는데 전체 길이가 틀리게 표시되고 탐색(seek)이 엉뚱한 위치로 튐 원인: ADTS는 프레임마다 헤더만 있고 전체 길이·탐색 인덱스가 없는 원시 스트림이라, 플레이어가 길이를 추정해야 합니다. 서버가 audio/aac MIME 타입을 보내지 않는 경우도 흔합니다. 해결:

# ADTS를 MP4로 변환 (재인코딩 없이)
ffmpeg -i input.aac -c:a copy -movflags +faststart output.m4a

-movflags +faststart: moov atom을 파일 앞으로 이동 (스트리밍 최적화)

문제 3: 영상과 오디오 동기 안 맞음

증상: 비디오와 오디오가 점점 어긋남 원인: 샘플레이트 불일치, 타임스탬프 오류 해결:

# 영상과 오디오 샘플레이트 통일
ffmpeg -i video.mp4 -i audio.wav \
  -c:v copy \
  -c:a aac -b:a 192k -ar 48000 \
  -af aresample=async=1 \
  output.mp4

aresample=async=1: 오디오 타임스탬프의 틈·겹침을 샘플을 늘리거나 줄여 보정합니다(예전 -async 1 옵션은 deprecated). 싱크가 “점점” 어긋난다면 대개 녹음 장비의 실제 샘플레이트가 명목값과 미세하게 다른 문제이고, 처음부터 일정하게 어긋나 있다면 아래 인코더 지연(priming) 문제일 가능성이 큽니다.

음질 저하 문제

문제 4: 소리가 “깨진” 느낌

원인 1: 클리핑 원본 오디오가 0 dBFS를 초과하여 왜곡 발생:

# 게인 조정으로 헤드룸 확보
ffmpeg -i input.wav \
  -af "volume=-3dB" \
  -c:a aac -b:a 192k \
  output.m4a

권장 헤드룸: -1~-3 dBTP (True Peak) 원인 2: 비트레이트 부족 저비트레이트에서 복잡한 음악 인코딩:

# 비트레이트 상향 조정
ffmpeg -i input.wav -c:a aac -b:a 192k output.m4a  # 128k → 192k

문제 5: 고주파가 거칠게 들림

증상: 하이햇, 심벌, 고음 보컬이 “쉭쉭” 거림 원인: 저비트레이트에서 고주파 양자화 오류 해결 1: 비트레이트 증가

ffmpeg -i input.wav -c:a aac -b:a 192k output.m4a

해결 2: HE-AAC 사용

# SBR로 고주파 복원
ffmpeg -i input.wav \
  -c:a libfdk_aac \
  -profile:a aac_he \
  -b:a 96k \
  output.m4a

문제 6: 스테레오 이미지 손실

증상: 좌우 분리감이 약해짐 원인: 저비트레이트에서 스테레오 정보 손실 해결: AAC 인코더는 Mid/Side 스테레오를 이미 프레임 단위로 자동 선택하므로 따로 켜고 끌 옵션이 있는 게 아닙니다. 저비트레이트에서 좌우 분리감이 무너지는 건 비트가 부족해 인코더가 사이드 채널을 희생하기 때문이라, 비트레이트를 올리거나(LC 128 kbps 이상) libfdk_aac로 바꾸는 것이 실질적인 해결입니다. 반대로 HE-AAC v2는 스테레오를 모노+파라미터로 표현하는 방식이라 음악의 스테레오 이미지가 약해지는 게 정상이며, 음성 전용으로만 쓰는 것이 맞습니다.

인코더 지연(priming)과 갭리스 재생

AAC 디코더는 첫 프레임을 온전히 복원하려면 앞선 데이터가 필요하기 때문에, 인코더는 파일 앞에 무음에 가까운 priming 샘플을 붙입니다(LC 기준 보통 1024샘플, Apple 인코더는 2112샘플, HE-AAC는 SBR 때문에 더 깁니다). MP4 컨테이너는 편집 리스트(edit list)나 iTunSMPB 메타데이터로 “앞의 N샘플은 버려라”를 기록해 두고, 이를 해석하는 플레이어는 정확한 위치부터 재생합니다.

문제는 이 정보가 사라지는 경로입니다. ADTS(.aac)에는 담을 곳이 없고, 일부 도구로 MP4를 다시 먹싱하면 편집 리스트가 빠집니다. 그러면 트랙 앞에 수십 ms의 무음이 생겨 라이브 앨범처럼 곡이 이어지는 음반에서는 곡 사이에 끊김이 들리고, 영상에서는 오디오가 일정하게 늦는 싱크 오차로 나타납니다. 저는 갭리스가 중요한 콘텐츠라면 중간 산출물을 ADTS로 두지 않고 처음부터 MP4(.m4a)로 유지하며, 먹싱 후 ffprobe -show_streams로 오디오 스트림의 start_time이 음수(priming이 기록됨)로 나오는지 확인합니다.

라이선스 고려사항

AAC는 특허 풀·제품 카테고리에 따라 라이선스 이슈가 논의될 수 있습니다. 주요 특허 풀: AAC 특허 풀은 Via Licensing이 관리해 왔고, 2023년 MPEG LA와 합병해 현재는 Via LA가 창구입니다. 초기 AAC 관련 특허는 상당수 만료됐지만 HE-AAC·xHE-AAC 쪽은 유효한 특허가 남아 있습니다. 라이선스 시나리오:

사용 형태	라이선스 필요 여부
개인 사용	불필요
OS 코덱을 호출하는 앱 (iOS/Android/Windows 기본 디코더·인코더)	대개 OS 공급자의 라이선스로 커버
인코더·디코더를 직접 번들한 앱·서버 제품	무료·유료와 무관하게 검토 필요
하드웨어 제품	필요 (제조사 책임)

라이선스는 “돈을 받느냐”보다 AAC 구현체를 누가 배포하느냐가 기준이라는 점이 흔히 오해되는 부분입니다. 브라우저·OS가 제공하는 디코더로 재생만 하는 웹 서비스와, FFmpeg를 서버 제품에 넣어 고객사에 설치해 주는 경우는 전혀 다른 상황입니다.

FFmpeg 인코더별 라이선스:

aac (네이티브): FFmpeg 라이선스 (LGPL/GPL)
libfdk_aac: Fraunhofer FDK AAC 라이선스. GPL과 호환되지 않아 이를 포함한 FFmpeg 바이너리는 재배포할 수 없고, 라이선스 자체가 특허 사용권을 부여하지 않는다고 명시합니다. 상용 제품·대규모 배포 시에는 법무 검토와 사용 중인 인코더·디코더의 조항을 확인하세요.

안전한 선택:

개인/소규모: FFmpeg 네이티브 aac 인코더 사용
상업/대규모: 법무팀과 라이선스 검토 후 결정

메타데이터 관리

AAC 파일에 메타데이터(제목, 아티스트, 앨범 등)를 추가:

ffmpeg -i input.wav \
  -c:a aac -b:a 192k \
  -metadata title="노래 제목" \
  -metadata artist="아티스트" \
  -metadata album="앨범명" \
  -metadata date="2026" \
  -metadata genre="Pop" \
  output.m4a

앨범 아트 추가:

ffmpeg -i input.wav -i cover.jpg \
  -c:a aac -b:a 192k \
  -c:v copy \
  -disposition:v:0 attached_pic \
  -metadata title="노래 제목" \
  output.m4a

마무리

핵심 요약

AAC는 MPEG-4 오디오의 중심 코덱으로, LC-AAC가 호환성 기준선이고 HE-AAC는 저비트레이트에서 강점이 있습니다.
내부적으로는 심리음향 모델 + MDCT 기반 블록 코딩으로 지각적으로 덜 중요한 정보의 비트를 줄입니다.
실무에서는 샘플레이트 통일·비트레이트 계층·컨테이너(MP4/ADTS) 를 함께 설계해야 합니다.
프로파일 선택은 비트레이트와 콘텐츠 유형에 따라 결정: 128 kbps 이상은 LC, 64~96 kbps는 HE-AAC v1, 48 kbps 이하는 HE-AAC v2 또는 Opus

다음 단계

실험: 자신의 콘텐츠로 여러 비트레이트를 테스트하고 최적점 찾기
모니터링: 사용자 피드백과 대역폭 비용 분석
최적화: 콘텐츠 유형별로 다른 프로파일·비트레이트 적용
업데이트: FFmpeg 버전 업그레이드로 인코더 품질 개선 지속 한 줄 정리: AAC는 압축 효율과 호환성의 균형이 뛰어나 현대 스트리밍의 표준이며, 비트레이트와 프로파일을 콘텐츠에 맞게 선택하는 것이 핵심입니다.

공식 스펙 및 표준 문서

AAC 공식 표준

ISO/IEC 14496-3 (MPEG-4 Part 3: Audio)

공식 스펙: https://www.iso.org/standard/53943.html

읽어야 할 핵심 섹션:

섹션	제목	핵심 내용	실무 활용
Part 3, Section 4	Audio Object Types	AAC-LC, HE-AAC, AAC-LD 정의	프로파일 선택 기준
Section 4.5	AAC-LC (Low Complexity)	기본 AAC 알고리즘	가장 많이 사용
Section 4.6	SBR (Spectral Band Replication)	HE-AAC의 핵심 기술	저비트레이트 최적화
Section 4.7	PS (Parametric Stereo)	HE-AAC v2의 스테레오 압축	초저비트레이트
Section 1.6	ADTS Frame Format	헤더 구조 (스트리밍용)	라이브 스트리밍
Subpart 4	General Audio Coding	MDCT, 윈도잉, 심리음향 모델	코덱 내부 이해

무료 참고 문서:

MPEG Audio Coding Overview: https://mpeg.chiariglione.org/standards/mpeg-4/audio
3GPP TS 26.401: AAC 프로파일 (모바일용) - https://www.3gpp.org/

실무자를 위한 스펙 읽기 가이드

1단계: 프로파일 결정 (Section 4)

목적에 맞는 Audio Object Type 선택:

음질 우선 (128 kbps+)
→ Section 4.5 (AAC-LC) 정독

대역폭 절약 (64~96 kbps)
→ Section 4.6 (SBR/HE-AAC v1)

초저대역폭 (32~48 kbps)
→ Section 4.7 (PS/HE-AAC v2)

저지연 필요 (VoIP, 게임)
→ Section 4.8 (AAC-LD, AAC-ELD)

2단계: 비트스트림 형식 (Section 1.6)

스트리밍/방송:
→ ADTS (Audio Data Transport Stream)
→ 각 프레임마다 헤더 포함
→ Section 1.6.2: ADTS 헤더 구조

파일 저장/전송:
→ MP4/M4A 컨테이너 (ISO BMFF)
→ 헤더는 moov 박스에 한 번만
→ ISO/IEC 14496-12 (MP4 컨테이너 스펙) 참조

3단계: 심리음향 모델 이해 (Subpart 4)

AAC의 압축 핵심 원리:
→ Section 4.6.12: Perceptual Model
→ 청각 마스킹 효과 (큰 소리가 작은 소리를 가림)
→ 임계 대역 (Critical Band) 분석
→ 지각적으로 덜 중요한 주파수 대역의 비트 절감

디버깅 도구로 스펙 확인

# 1. ffprobe로 AAC 상세 정보
ffprobe -show_streams -select_streams a:0 audio.m4a

# 주요 확인 항목:
# - codec_name: aac
# - profile: LC / HE-AAC / HE-AACv2
# - sample_rate: 44100 / 48000
# - channels: 2 (stereo) / 1 (mono)
# - bit_rate: 128000 (128 kbps)

# 2. AAC 프레임 구조 분석
ffprobe -show_frames -select_streams a:0 audio.m4a | head -n 50

# 3. ADTS 헤더 덤프 (hex)
xxd audio.aac | head -n 10

# ADTS 헤더 구조 (첫 7바이트):
# FFF1 = Sync word (12 bits) + MPEG-4 (1 bit) + Layer (2 bits) + No CRC (1 bit)
# 50 = Profile (2 bits) + Sample rate index (4 bits) + Private (1 bit) + Channel config (3 bits)
# ...

# 4. mediainfo로 상세 분석
mediainfo --Full audio.m4a

# 출력:
# Format profile: LC (Low Complexity)
# Format settings: SBR (Spectral Band Replication)

FFmpeg 옵션과 스펙 매핑

FFmpeg 옵션	AAC 스펙 대응	스펙 위치	설명
`-c:a aac`	AAC-LC	Section 4.5	기본 프로파일
`-profile:a aac_he`	HE-AAC v1 (AAC+SBR)	Section 4.6	저비트레이트
`-profile:a aac_he_v2`	HE-AAC v2 (AAC+SBR+PS)	Section 4.7	초저비트레이트
`-profile:a aac_ld`	AAC-LD	Section 4.8	저지연
`-b:a 128k`	Target bitrate	-	비트레이트 제어
`-ar 44100`	Sample rate	Section 4.4.1	8000~96000 Hz
`-cutoff 18000`	Frequency cutoff	Section 4.6.12.3	고주파 필터링

자주 묻는 질문 (FAQ)

Q. FFmpeg 기본 aac와 libfdk_aac, 어느 쪽을 써야 하나요?

A. 128 kbps 이상 LC라면 기본 aac로 충분하고 배포 제약도 없습니다. 96 kbps 이하나 HE-AAC가 필요하면 libfdk_aac(macOS라면 aac_at)를 쓰되, libfdk_aac를 넣은 FFmpeg는 재배포할 수 없다는 점을 감안하세요.

Q. AAC로 인코딩한 트랙 앞에 짧은 무음이 생기는 이유는?

A. 인코더가 붙이는 priming 샘플 때문입니다. MP4는 편집 리스트로 이를 잘라내지만 ADTS로 변환하거나 재먹싱 중 정보가 빠지면 무음이 드러납니다. 중간 산출물을 MP4로 유지하세요.