샘플레이트 44.1 vs 48, 뭘로 시작할지는 목적지가 정합니다
새 프로젝트 설정 창에는 매번 발을 멈추게 하는 메뉴가 하나 있습니다. 샘플레이트. 44100과 48000 중에 고르라는데 판단할 근거가 없으니, 대개 지난번에 골랐던 쪽을 그대로 두고 넘어갑니다. 그러면서 어딘가 찜찜합니다. 혹시 낮은 쪽을 골라서 소리가 손해를 보고 있나.
그 걱정부터 덜어 드리면, 이 메뉴는 음질 설정이 아니라 배송지 입력란입니다. 완성본이 유튜브나 영상으로 갈 곡이면 48, CD나 음원 유통만 생각하면 44.1로 충분합니다. 정해진 곳이 없으면 48로 시작하세요. 44.1과 48 사이에 들리는 음질 차이는 없습니다. 달라지는 건 내보낼 때 변환을 몇 번 거치느냐입니다. 왜 그런지는 이 숫자가 뭘 정하는 값인지부터 보면 짧게 끝납니다.
샘플레이트가 정하는 것: 담을 수 있는 가장 높은 주파수
샘플레이트는 소리를 1초에 몇 번 재느냐는 값입니다. 44.1kHz면 1초에 44,100번 잽니다. 이 횟수가 정하는 건 딱 하나, 담을 수 있는 가장 높은 주파수입니다. 디지털 신호는 잰 횟수의 절반까지 주파수를 담을 수 있습니다. 나이퀴스트(Nyquist) 정리라고 부르는 규칙입니다. 그래서 이론상 44.1kHz는 22.05kHz까지, 48kHz는 24kHz까지 담습니다.
사람 귀의 상한은 잘 들리는 젊은 귀 기준으로도 20kHz 언저리입니다. 두 샘플레이트 모두 그 위까지 담습니다. “48이 더 촘촘하게 재니까 더 매끄러운 소리”라는 직관이 여기서 무너집니다. 더 촘촘하게 재서 얻는 이득은 “더 높은 주파수까지 담는 것” 하나뿐입니다. 귀에 들리는 구간 안에서는 두 값 모두 파형을 되살리는 데 필요한 정보를 이미 다 갖고 있습니다. 잰 점 사이가 계단으로 남지도 않습니다. 재생 단계에서 매끈한 곡선 하나로 복원됩니다.
숫자가 두 개인 이유: 출신이 다른 두 표준
그럼 왜 하필 두 개가 남았을까요. 720p와 1080p 같은 등급 관계라면 높은 쪽만 쓰면 될 텐데요. 두 숫자는 서로 다른 산업에서 태어난 표준입니다.
44.1kHz는 CD의 숫자인데, 뿌리를 캐면 뜻밖에 비디오테이프가 나옵니다. CD 개발 전, 디지털 오디오를 저장할 만한 대용량 매체가 비디오테이프뿐이라 방송용 비디오 장비에 오디오 샘플을 실어 녹음했습니다. 그때 비디오 주사선 구조에 맞아떨어지는 숫자가 44,100이었습니다. 유럽 PAL 방송에서 화면을 이루는 가로줄(주사선) 가운데 오디오를 실을 수 있는 294줄 × 화면이 갱신되는 초당 50번 × 줄당 3샘플 = 44,100. 미국 NTSC 방식으로 계산해도 똑같이 44,100이 나오는, 양쪽 장비에 다 걸치는 숫자였습니다. 이 값이 그대로 CD 규격이 됐고, CD의 시대를 지나며 음악 쪽 표준으로 굳었습니다.
48kHz는 영상 쪽 숫자입니다. 영화의 초당 24프레임 기준으로 48,000은 프레임당 정확히 2,000샘플로 떨어집니다. 44,100을 24로 나누면 1,837.5 — 프레임 경계와 샘플 경계가 어긋납니다. 오디오와 영상을 한 타임라인에서 다뤄야 하는 방송·영화 쪽이 48을 표준으로 삼은 이유고, 지금도 영상에 붙는 오디오는 48이 기본입니다.
음악 유통 쪽 출신이 44.1, 영상 쪽 출신이 48. 그게 전부입니다.
진짜 비용은 내보낼 때 생깁니다
프로젝트 샘플레이트와 목적지 샘플레이트가 다르면, 내보내는 길 어딘가에서 샘플레이트 변환(SRC, sample rate conversion)이 한 번 들어갑니다. 44.1과 48은 비율이 정수로 떨어지지 않아 변환기가 일을 꽤 해야 하는 조합인데, 다행히 요즘 변환기는 잘 만들어져 있어서 품질 좋은 변환 한 번이 들리는 흠을 남길 가능성은 낮습니다.
그런데도 목적지에 맞춰 시작하라는 이유는, 그 변환이 언제 어디서 몇 번 일어나는지를 내 관리 안에 두기 위해서입니다. 목적지와 맞는 프로젝트는 변환이 0번입니다. 다르면 최소 1번이고, 중간에 협업자와 파일을 주고받거나 영상 편집 툴을 오가기 시작하면 누가 언제 변환했는지 아무도 모르는 파일이 생깁니다. 변환 자체보다 이 관리 안 되는 왕복이 문제를 만듭니다.
목적지들은 실제로 숫자를 지목하고 있습니다. 유튜브는 업로드 권장 사양에서 오디오 샘플레이트 48kHz를 권장하고, 넷플릭스는 납품 사양에서 48kHz/24비트를 요구합니다. 음원 쪽인 스포티파이는 44.1kHz 이상이면 받고, 더 높은 파일은 자기들이 알아서 변환합니다. 홈스튜디오에서 나온 곡의 첫 목적지가 유튜브인 경우가 많아진 지금은, 그래서 망설여질 때의 기본값이 48 쪽으로 기울었습니다. 저도 몇 년 전 곡을 영상에 얹어 올리는 일이 늘면서 템플릿을 44.1에서 48로 바꿨고, 그 뒤로는 내보내기 창에서 샘플레이트를 신경 쓴 기억이 없습니다.
하나 조심할 건 프로젝트 안에서의 불일치입니다. 44.1로 잰 파일을 48 세션이 변환 없이 그대로 재생하면 샘플을 원래보다 빨리 읽어 치우니 소리가 빨라지고 피치가 올라갑니다. 요즘 DAW는 프로젝트와 다른 샘플레이트의 파일을 넣으면 대개 자동으로 변환해 주지만, 오디오 인터페이스 설정과 프로젝트가 어긋나 있거나 변환을 묻는 창에서 아니오를 눌러 버리면 이 사고는 지금도 납니다. 받은 파일의 샘플레이트를 확인하는 습관, 보낼 파일에 샘플레이트를 적어 주는 습관이 변환기 성능보다 먼저입니다.
그래도 96kHz로 올리면 좋지 않냐는 반론
높은 샘플레이트가 실제로 유리한 지점이 있긴 합니다. 제일 힘 있는 반론은 앨리어싱(aliasing)입니다. 새추레이션이나 컴프레서 같은 비선형 처리는 원음 위로 새 배음을 만들어 뻗는데, 나이퀴스트 상한을 넘어간 배음은 상한에 부딪혀 가청 대역 안으로 접혀 내려옵니다. 원음과 어울리지 않는 음높이로 떨어지니 탁하고 거친 소리가 되고요. 상한이 높을수록 접힐 일이 줄어드니 96kHz 프로젝트가 유리한 건 사실입니다. 샘플을 크게 늘이고 줄이는 사운드 디자인에서도 여유가 생깁니다.
다만 앨리어싱에는 이미 더 싼 해법이 표준이 됐습니다. 요즘 플러그인은 자기가 처리하는 구간만 내부에서 몇 배 샘플레이트로 올려 처리하고 다시 내리는 오버샘플링(oversampling)을 씁니다. 왜곡이 생기는 단계만 골라 올리는 쪽이, 프로젝트 전체를 올려 모든 트랙의 용량과 CPU 부담을 키우는 쪽보다 같은 문제를 훨씬 싸게 풉니다.
담는 쪽 상한을 올리는 게 공짜도 아닙니다. 20kHz 위의 초음파가 최종본까지 살아남으면 문제가 생길 수 있습니다. 재생 기기는 신호를 완벽히 그대로 내보내지 못하는데, 그 불완전함이 초음파들을 뒤섞어 가청 대역 안에 원곡에 없던 왜곡을 만들어냅니다(상호변조, intermodulation). 귀에 안 들리는 대역이 귀에 들리는 문제를 일으키는 겁니다. 마이어와 모런이 2007년 논문으로 정리한 블라인드 테스트에서는, 고해상도 음원을 CD 품질(44.1kHz/16비트)로 낮춘 버전과 원본을 554회에 걸쳐 비교했는데 정답률이 49.8%, 동전 던지기 수준이었습니다. 그보다 격차가 훨씬 작은 44.1 대 48은 말할 것도 없고요. 그리고 무엇보다 — 앨리어싱이든 상호변조든 전부 96 대 48의 논쟁입니다. 44.1 대 48 사이에는 이 차이조차 없습니다.
시작할 때 3초, 그걸로 끝
정리하면 이렇게 됩니다.
- 낼 곳이 정해져 있으면 그 숫자로 시작합니다. 유튜브·영상이면 48, 음원 유통 중심이면 44.1도 충분합니다.
- 모르면 48로 시작합니다. 요즘 곡의 첫 목적지는 영상 플랫폼인 경우가 많고, 스포티파이는 어차피 48도 받습니다.
- 프로젝트 중간에는 바꾸지 않습니다. 어떤 값이든 하나로 끝까지 가는 게 변환 횟수를 줄입니다.
- 주고받는 파일에는 샘플레이트를 적습니다. 변환기 성능이 아무리 좋아도, 변환이 일어난 줄 모르는 게 사고의 시작입니다.
새 프로젝트 창에서 3초 고민할 가치는 있는 메뉴입니다. 다만 고민의 내용이 “어느 쪽이 좋은 소리냐”라면 그 3초는 버리는 시간입니다. 메뉴가 묻는 건 행선지입니다. 이 곡, 어디로 보낼 겁니까.
여백 — 마흔세 개 폴더에서 골라낸 그 심사용 곡은 48로 시작했습니다. 목적지가 유튜브라서요. 고르는 데 3초도 안 걸렸습니다.
참고 — 샘플레이트는 높을수록 좋을까? (Ejim, YouTube), 24/192 Music Downloads are Very Silly Indeed (Monty Montgomery, xiph.org)
댓글