음량을 고쳤는데 최종 MP4의 피크가 다시 달라졌나요?

이번 측정에서는 보정한 WAV와 최종 AAC MP4의 통합 음량은 -15.9 LUFS로 같았지만, 트루피크는 -6.4 dBFS에서 -5.7 dBFS로 0.7dB 올라갔습니다. 음량을 한 번 맞췄다고 내보낸 MP4의 피크가 그대로라고 가정하면 안 되고, 내보낸 파일을 다시 재야 한다는 뜻입니다. 아래는 한 대본으로 단계마다 측정한 결과입니다.

직접 측정한 결과: 한 대본, 네 단계

2026년 10월 12일, 15.4초 한국어 대본(macOS 기본 한국어 음성으로 합성)을 48kHz 모노 WAV로 만들고 FFmpeg 9.0.1의 ebur128 필터로 통합 음량과 트루피크를 측정했습니다. 보정 입력은 9dB 게인을 요청해 만든 A’ WAV였습니다. 이 파일의 첫 패스 측정값(input_i -9.25, input_tp 0.30, input_lra 1.10, input_thresh -19.27)을 loudnorm의 measured 옵션에 넣고, 목표 -16 LUFS·트루피크 -1.5 dBTP·LRA 11의 선형 보정을 두 번째 패스에 적용한 것으로 자체 작업 기록에 남아 있습니다. 이때 목표 피크는 반드시 그 값까지 끌어올리라는 뜻이 아니라 최대값입니다. 보정한 WAV를 검은 화면 영상에 AAC로 넣어 MP4를 만든 다음 그 MP4의 소리를 다시 디코딩해 쟀습니다.

표의 “9dB 키운 WAV”에서 9dB는 변환할 때 요청한 게인 설정입니다. 실제 통합 음량 변화는 +8.6 LU(-17.8→-9.2), 트루피크 변화는 +1.0dB(-0.7→+0.3)로, 최종 측정값이 모두 9dB씩 증가했다는 뜻은 아닙니다. 세 WAV는 모두 16비트 PCM이며, 과대 게인 적용 때의 포화·클리핑 등 각 요인의 기여를 이번 비교에서 따로 검증하지 않았습니다. 키운 WAV는 트루피크가 0 dBFS를 넘었고, 보정 후에는 목표 -16 LUFS와 0.1 LU 차이인 -15.9 LUFS까지 내려왔습니다. 샘플 피크로 보면 보정 WAV는 -6.75 dBFS, 128k MP4는 -5.76 dBFS였습니다. 샘플 피크는 약 0.99dB, 트루피크는 0.7dB 높아졌습니다. AAC로 압축하고 다시 디코딩하는 과정에서 파형이 달라졌을 가능성이 있으나 이번 측정만으로 원인을 따로 검증한 것은 아닙니다. 64k와 128k는 소수 첫째 자리까지 같은 값이었습니다.

이 결과가 말해 주는 것과 말해 주지 않는 것

• 말해 주는 것: 이 대본과 이 설정에서는 코덱을 거치며 피크가 바뀌었고, 통합 음량은 소수 첫째 자리까지 유지됐습니다.
• 말해 주지 않는 것: 음질이 좋아졌는지, 다른 음성이나 다른 코덱에서도 같은 차이가 나는지, 특정 플랫폼이 어떤 기준으로 음량을 조정하는지는 이번 측정으로 알 수 없습니다. 소리를 귀로 비교한 평가도 하지 않았고 숫자만 쟀습니다.

이번에는 목표 트루피크 -1.5 dBTP보다 한참 아래인 -6.4에서 시작했기 때문에 AAC 이후에도 여유가 있었습니다. 목표 피크에 가깝게 맞춘 파일이라면 같은 0.7dB 상승이 기준을 넘길 수도 있으므로, 여유를 얼마나 둘지는 직접 재 보고 정해야 합니다.

작업 순서와 기록해 둘 것

이번 순서는 원본 측정, 보정, 내보내기, 내보낸 파일 재측정 네 단계였습니다. 마지막 재측정이 빠지면 보정 단계의 숫자만 믿게 되므로, 영상 편집기에서 내보낸 최종 MP4를 기준 파일로 삼는 편이 안전합니다. 기록에는 사용한 FFmpeg 버전, loudnorm 목표값, 코덱과 비트레이트, 측정한 날짜를 함께 남기면 나중에 같은 조건으로 다시 비교할 수 있습니다. 대본이나 음성이 바뀌면 결과도 달라질 수 있으니 숫자는 그 파일에 대한 값으로만 읽어야 합니다. 표의 다섯 줄은 이 글을 위해 만든 같은 대본의 다섯 파일에서 다시 확인한 값입니다. 이 글에는 대본 원문·음성 합성 세부 설정·음성·영상 원본 파일을 공개하지 않았으므로 독자가 동일 파일이나 표의 숫자를 그대로 재현할 수 있다는 뜻은 아닙니다. 자신의 파일에서 아래 명령으로 같은 측정 절차를 실행할 수 있지만 음성·인코더·설정에 따라 값은 달라집니다.

한 가지 더, 이번 비교는 소리만 있는 검은 화면 영상이었습니다. 실제 영상에서는 편집기가 오디오를 다시 믹싱하거나 다른 효과음을 얹을 수 있으므로, 플랫폼 업로드 전 최종 내보내기 파일을 기준으로 다시 측정해야 합니다. 숫자가 기준에 가깝다면 보정 목표를 조금 낮춰 다시 내보내고 같은 명령으로 확인하면 됩니다.

같은 방법으로 직접 확인하는 명령

ffmpeg -nostats -i final.mp4 -vn -af ebur128=peak=true -f null -

출력 마지막의 Summary에서 Integrated loudness의 I 값과 True peak의 Peak 값을 보면 됩니다. 보정 전 파일을 재려면 같은 명령에 해당 파일을 넣으면 되고, 보정은 먼저 측정값을 얻은 뒤 그 값을 loudnorm의 measured 옵션에 넣어 선형으로 적용하는 방식입니다. 자세한 옵션은 loudnorm 공식 문서에 있습니다. 내보내기 전후 피크를 확인하는 기본 방법은 내보낸 영상의 음량과 트루피크 확인하기에서 먼저 다뤘습니다.

샘플로 같은 네 단계를 직접 돌려 보기

위 표의 음성 파일은 공개하지 않았으므로, 같은 네 단계(원본 측정 → 보정 → AAC MP4로 내보내기 → 내보낸 파일 재측정)를 합성 샘플로 따라 해 보는 명령을 따로 적습니다. 이 구획은 2026년 10월 13일 추가했으며, 위 표의 음성 파일을 다시 잰 것이 아닙니다.

재현용 원본은 LUFS·트루 피크 점검 글의 같은 분홍 잡음 샘플입니다. 여기서는 보정·AAC 변환 단계만 이어서 확인하며 독립 실험 두 건으로 세지 않습니다. 원본 a_original.wav와 거기서 9dB 더 키운 a_loud.wav를 만드는 명령은 영상 올리기 전, 내보낸 파일의 소리 크기(LUFS)와 트루 피크를 ffmpeg로 재는 법의 “같은 측정을 직접 해 보는 샘플 만들기” 구획에 있습니다. 두 파일이 있는 폴더에서 아래 명령을 이어서 실행하세요.

# 1) 보정 입력의 첫 패스 측정: 출력 끝 JSON의 input_i, input_tp, input_lra, input_thresh, target_offset을 읽습니다
ffmpeg -hide_banner -nostats -i a_loud.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -
# 2) 읽은 값을 measured_*·offset에 넣어 선형 보정합니다(아래 숫자는 이 샘플에서 읽은 값)
ffmpeg -hide_banner -loglevel error -i a_loud.wav -af "loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-8.72:measured_TP=5.04:measured_LRA=0.10:measured_thresh=-18.72:offset=0.01:linear=true" -ar 48000 -c:a pcm_s16le b_normalized.wav
# 3) 검은 화면 영상에 AAC로 넣어 MP4로 내보냅니다(128k, 64k)
ffmpeg -hide_banner -loglevel error -f lavfi -i "color=c=black:s=320x568:r=10:d=15" -i b_normalized.wav -shortest -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 128k c_128k.mp4
ffmpeg -hide_banner -loglevel error -f lavfi -i "color=c=black:s=320x568:r=10:d=15" -i b_normalized.wav -shortest -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 64k c_64k.mp4
# 4) 원본·보정 전·보정 후·내보낸 파일을 같은 방식으로 다시 잽니다
for f in a_original.wav a_loud.wav b_normalized.wav c_128k.mp4 c_64k.mp4; do echo "== $f"; ffmpeg -hide_banner -nostats -i "$f" -vn -af ebur128=peak=true -f null - 2>&1 | grep -E "^[[:space:]]+(I:|Peak:)"; done

2026년 10월 13일 FFmpeg 9.0.1(macOS)에서 같은 명령을 두 번 실행해 같은 값을 얻었습니다. 첫 패스 값은 input_i -8.72, input_tp 5.04, input_lra 0.10, input_thresh -18.72, target_offset 0.01이었고, 다시 잰 값은 다음과 같습니다.

이 샘플에서는 보정 WAV를 AAC 128k MP4로 내보낸 뒤 통합 음량이 0.4 LU, 트루 피크가 0.3dB 내려갔습니다(소수 첫째 자리 표시값 기준). 위 음성 파일에서 트루피크가 0.7dB 올라간 것과 방향이 반대였고, 음성 파일에서는 같았던 64k와 128k도 이 샘플에서는 값이 달랐습니다. 같은 보정을 해도 파일과 비트레이트에 따라 내보낸 뒤의 값이 다른 방향으로 움직일 수 있으니, 마지막 파일을 다시 재야 한다는 점만 확인하는 용도입니다. 분홍 잡음은 음성이 아니므로 이 값을 음성의 값으로 일반화하지 않으며, 다른 환경에서는 소수 첫째 자리가 조금 다를 수 있습니다.

자주 찾는 질문

보정을 했는데 왜 MP4에서 피크가 달라지나요? 일반적으로 손실 압축 뒤 디코딩한 값은 원본과 달라질 수 있습니다. 이번 파일의 트루피크는 0.7dB 올랐지만, AAC 압축·디코딩이 이 차이에 얼마나 기여했는지는 따로 분리해 검증하지 않았습니다. 음량도 같이 바뀌나요? 이번 측정에서는 통합 음량이 같았습니다. 비트레이트를 낮추면 더 달라지나요? 이번 64k와 128k 비교에서는 표시 자릿수 안에서 같았지만 더 낮은 값이나 다른 인코더는 확인하지 않았습니다.

함께 보면 좋은 글

같은 대본을 로컬 음성과 클라우드 음성으로 각각 만들어 같은 받아쓰기 모델로 대조하고 음량과 트루 피크도 함께 잰 기록은 같은 한국어 대본, 무료 로컬 음성과 클라우드 음성에서 무엇이 빠질까요? 글에 있습니다.

참고 자료

• FFmpeg Filters: loudnorm
• FFmpeg Filters: ebur128