라우드니스 처리 방식이 가장 자주 거론되는 여섯 개 스트리밍 서비스 가운데, 인용할 수 있는 노멀라이제이션 목표치를 공개하는 곳은 정확히 하나입니다. Spotify는 통합 라우드니스 −14 LUFS와 트루 피크 상한 −1 dBTP를 공개하며, 마스터가 −14 LUFS보다 크면 상한을 −2 dBTP로 조입니다. Apple Music, YouTube Music, Amazon Music, TIDAL, Deezer는 노멀라이제이션 목표치를 전혀 공개하지 않습니다. 이 다섯 곳에 대해 당신이 본 모든 수치는 공개된 것이 아니라 전해진 것이며, 누군가 그것을 가지고 자기 마스터가 얼마나 게인 감쇠를 받을지 계산하는 순간 그 차이가 문제가 됩니다.
공개된 유일한 스트리밍 수치
Spotify의 자사 라우드니스 노멀라이제이션 페이지는 목표치를 통합 −14 LUFS로 밝힙니다. 트루 피크 상한은 −1 dBTP로, −14 LUFS보다 크게 전송된 마스터에 대해서는 −2 dBTP로 명시합니다. 이 세 숫자가 이 글에 나오는 스트리밍 서비스 노멀라이제이션 규격 가운데 서비스 자신에게서 나온 전부입니다.
이는 대부분의 마스터링 조언이 암시하는 것보다 훨씬 좁은 사실적 토대입니다. 그러면서도 작업하기에는 충분합니다. 목표치가 공개되어 있지 않더라도 작동 방식은 어디서나 같기 때문입니다. 통합 라우드니스를 측정하고, 목표치와 비교하고, 재생 시점에 게인을 적용합니다.
아무것도 공개하지 않는 다섯 서비스
Apple Music, YouTube Music, Amazon Music, TIDAL, Deezer는 노멀라이제이션 목표치를 공개하지 않습니다. 이들에 대해 돌아다니는 수치는, 정직하게 표현할 수 있는 유일한 방식으로 적으면 이렇습니다.
널리 전해지고 있으나 서비스가 공개한 것은 아님: Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15.
이 수치들을 따로 떼어 놓은 것은 의도적이며, 함께 가는 규칙은 엄격합니다. 이 값으로 게인 수치를 계산하지 마십시오. "내 마스터가 −8이고 Apple이 −16이니 Apple은 나를 8 dB 내릴 것이다"는, 해당 회사가 한 번도 확인해 준 적 없는 숫자를 가지고, 역시 파라미터를 확인해 준 적 없는 알고리즘을 전제로 수행한 산술입니다. 뺄셈은 깔끔하지만 결과에는 근거가 없습니다.
이것은 출처 표기에 관한 까다로움의 문제가 아닙니다. 라우드니스 조언이 서로 그렇게 자주 모순되는 실질적 이유입니다. 두 필자가 같은 서비스에 대해 서로 다른 전언 값을 집어 들고, 둘 다 뺄셈을 하고, 둘 다 확신에 찬 숫자를 제시하는 것입니다.
−23, −16, −18: 서로 대체할 수 없는 세 수치
다른 세 숫자가 마치 대안적인 스트리밍 목표치인 양 돌아다닙니다. 그렇지 않습니다.
- EBU R 128은 −23 LUFS를 규정합니다. R 128은 방송 권고입니다. 스트리밍 목표치가 아니며 애초에 그럴 의도로 만들어지지 않았습니다. 스트리밍 전송을 논하는 자리에서 이를 인용하는 것은 더 엄격한 기준을 드는 것이 아니라 범주를 잘못 짚은 것입니다.
- AES TD1008은 음악에 대해 −16 LUFS를 제시합니다. 사람들이 AES를 인용할 때 대개 찾으려는 것이 이 스트리밍 지향 수치입니다.
- TD1008의 −18 LUFS는 말 중심 콘텐츠에 적용됩니다. 뉴스, 토크, 드라마 같은 것입니다. −18을 음악 목표치로 제시하는 것은 흔하면서도 중대한 오류입니다. 어떤 마스터링 가이드나 플러그인 프리셋, 포럼 글이 AES가 음악에 −18 LUFS를 권고한다고 말한다면, 그 문서는 말 중심 수치와 음악 수치를 혼동한 것이며 나머지 내용도 신뢰하지 않는 편이 낫습니다.
−16과 −18의 구분을 제대로 아는지는, 라우드니스에 대해 쓴 사람이 원문을 읽었는지 요약을 베꼈는지 가장 빠르게 가려내는 방법 중 하나입니다.
측정 표준, 그리고 현재 유효한 판
위의 모든 것은 ITU-R BS.1770으로 측정합니다. 판은 여섯 개입니다. -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) and -5 (November 2023).
현재 유효한 것은 BS.1770-5입니다. 2015년 10월의 BS.1770-4는 폐지되었습니다. 여전히 현장에 깔린 대부분의 미터가 인용하는 판이 -4이긴 하지만 말입니다. 미터 설명서에 -4가 적혀 있다면 그것은 설명서의 연식을 알려 줄 뿐, 어느 판이 유효한지를 알려 주지 않습니다. 현행으로 언급할 것은 -5입니다.
알고리즘이 실제로 하는 일, 그리고 미터가 틀리는 지점
규격은 짧고 정밀하며, 그중 몇몇 세부는 충분히 자주 잘못 구현되기 때문에 알아 둘 필요가 있습니다.
K-웨이팅. 2단 필터입니다. 하이 셸프("head" 필터) 다음에 하이패스(RLB)가 옵니다. 1 kHz에서 K-웨이팅 커브의 게인은 +0.698 dB, 선형으로는 1.0836입니다. 1 kHz 톤의 K-웨이팅 측정값이 웨이팅 없는 레벨과 같지 않은 이유가 이 오프셋입니다.
블록. 라우드니스는 75% 오버랩의 400 ms 블록 단위로 계산됩니다.
절대 게이트. −70 LUFS 미만의 블록은 그대로 버려집니다.
상대 게이트 — 가장 자주 잘못 서술되는 항목. 상대 게이트는 절대 게이트를 통과한 블록들의 평균에서 계산한 뒤 −10 LU만큼 내린 값입니다. 게이트를 거치지 않은 평균이 아닙니다. 게이트 없는 평균을 기준으로 상대 게이트를 잡는 미터는 긴 무음이 있는 트랙을 규격을 따르는 미터와 다르게 읽으며, 둘의 차이는 당신의 라우드니스가 아니라 편곡에 따라 달라집니다.
라우드니스 레인지. EBU Tech 3342에 정의된 LRA는 −20 LU 상대 게이트를 씁니다. −10 LU가 아닙니다. 통합 라우드니스용 게이트를 LRA에 재사용하는 것은 흔한 구현 버그이며, 다이내믹한 소재를 실제보다 균일해 보이게 만듭니다.
시간 창. 단기 라우드니스는 3 s 창을 씁니다(EBU Tech 3341). 순간 라우드니스는 400 ms를 씁니다. 이 둘은 하나의 측정에 스무딩 설정만 다르게 준 것이 아니라 서로 다른 측정입니다.
트루 피크. 트루 피크는 오버샘플링된 신호에서 측정합니다. BS.1770에서 최소 4×이고 8×가 더 낫습니다. 샘플 피크는 트루 피크가 아닙니다. 인터샘플 피크는 파일 안의 가장 큰 샘플 값을 넘어설 수 있으며, 샘플 피크 미터에서 정확히 0.0 dBFS로 읽히는 마스터가 손실 디코더에서 클리핑할 수 있는 이유가 이것입니다. Spotify의 −1 dBTP와 −2 dBTP 상한은 트루 피크 값이므로, 샘플 피크 미터로는 충족 여부를 알 수 없습니다.
| 항목 | 값 | 흔한 오류 |
|---|---|---|
| 절대 게이트 | −70 LUFS | — |
| 상대 게이트(통합) | 통과 블록 평균에서 −10 LU 아래 | 게이트 없는 평균으로 계산 |
| LRA 게이트 | −20 LU | 통합용 −10 LU를 그대로 사용 |
| 순간 측정 창 | 400 ms | — |
| 단기 측정 창 | 3 s | — |
| 트루 피크 오버샘플링 | 최소 4×, 8×가 더 나음 | 샘플 피크를 트루 피크로 보고 |
상향 노멀라이제이션: 예/아니오가 아니라 조건부
서비스는 재생 시점에 노멀라이즈합니다. 목표치보다 큰 마스터는 그 차이만큼 내려갑니다. 여기까지는 이론의 여지가 없습니다.
조용한 마스터의 경우가 확신에 찬 두 답 모두 틀리는 지점입니다. Spotify 페이지는 "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS"라고 밝힙니다. 또한 이렇게도 밝힙니다. "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality."
두 문장을 함께 읽으면 조건부 서술이 됩니다. 조용한 마스터는 목표치까지 올라갈 수 있습니다. 피크가 높은 조용한 마스터는 끝까지 올라가지 못할 수도 있습니다. 올리면 두 번째 문장이 확보해 두는 헤드룸을 잡아먹기 때문입니다.
그러므로,
- "조용한 마스터는 절대 올라가지 않는다"는 틀렸습니다.
- "조용한 마스터는 항상 목표치까지 올라간다"도 틀렸습니다.
- 맞는 것은 이렇습니다. 상향 게인은 실제로 존재하며, 트랙의 헤드룸을 조건으로 적용됩니다.
상향 게인을 원한다면 손잡이는 평균 레벨이 아니라 마스터의 피크 관리입니다. 진짜 헤드룸이 있는 마스터가 올라갈 여지가 있는 마스터입니다.
과도한 리미팅이 실제로 사 주는 것
조각들을 맞춰 보십시오. 통합 라우드니스를 높이 밀어 올린 마스터는 재생 시점에 자기 레벨과 목표치의 차이만큼 내려갑니다. 청취자에게 더 크게 도착하지 않습니다. 도착하는 것은 그 과정에서 당신이 마스터에 한 짓입니다. 줄어든 크레스트 팩터, 뭉개진 트랜지언트, 그리고 트루 피크 상한을 넘겨 밀었다면 손실 인코더가 자기 방식대로 처리할 인터샘플 피크입니다.
과도한 리미팅이 사 주는 것은 크기가 아니라 납작함입니다. 이것이 방어 가능한 진술이며, 목표치를 공개한 그 한 서비스 외에 다른 어떤 서비스의 공개 수치도 필요로 하지 않습니다. 나머지 다섯 곳에 대한 전언 수치가 전부 정확히 맞다고 밝혀지더라도 결론은 달라지지 않습니다. 일을 하는 것은 특정 숫자가 아니라 재생 시점에 노멀라이즈하여 큰 것을 내린다는 작동 방식 자체이기 때문입니다.
이것으로 무엇을 할 것인가
- 무엇을 전송하기 전이든 통합 라우드니스와 트루 피크를 오버샘플링으로 측정하십시오.
- 마스터를 −14 LUFS와 −1 dBTP(−14 LUFS보다 크다면 −2 dBTP)에 견주어 확인하십시오. 이것들이 공개된 값이고, 나머지는 전부 미검증으로 취급하십시오.
- 어떤 도구나 플러그인, 글이 Apple Music, YouTube Music, Amazon Music, TIDAL, Deezer의 서비스별 목표치를 공개된 것이 아니라 전해진 것이라고 표시하지 않은 채 제시한다면, 그것을 그 도구에 대한 신호로 받아들이십시오.
- 가능하다면 미터의 상대 게이트와 LRA 게이트 동작을 확인하십시오. 통합은 −10 LU, LRA는 −20 LU입니다.
- 재생 시점에 되돌려지는 숫자를 좇는 일을 그만두고, 상향 게인이 당신에게 닿을지를 결정하는 헤드룸을 지키기 시작하십시오.
Mazufa의 무료 라우드니스 체커는 /loudness-checker에 있습니다. 전부 브라우저 안에서 실행되고 오디오는 업로드되지 않으며, 공개된 Spotify 수치는 공개된 것으로, 나머지는 있는 그대로 표시합니다.
출처
- Spotify, "Loudness normalization" (artist support page) — 목표치 −14 LUFS, 트루 피크 상한 −1/−2 dBTP, 그리고 상향 게인과 1 dB 헤드룸에 관한 진술. support.spotify.com/us/artists/article/loudness-normalization/ — read 2026-09-07.
- ITU-R BS.1770 판 이력과 작동 방식. BS.1770-5 (November 2023) 유효, BS.1770-4 (October 2015) 폐지. itu.int — verified 2026-09-07.
- EBU R 128 — −23 LUFS, 방송용. 그리고 EBU Tech 3341(순간 및 단기 측정 창)과 EBU Tech 3342(라우드니스 레인지, −20 LU 게이트). tech.ebu.ch — 우리 자료집에 열람 날짜가 기록되어 있지 않습니다.
- AES TD1008 — 음악에 −16 LUFS, 말 중심 콘텐츠에 −18 LUFS. aes.org/community/technical-council/technical-document-aestd1008/ — 우리 자료집에 열람 날짜가 기록되어 있지 않습니다.