Shazam은 대체 어떻게 작동할까?

• 음악 인식은 마이크가 받은 공기 진동을 파형으로 바꾼 뒤, 이를 스펙트로그램과 소수의 강한 주파수 피크로 압축해 곡의 지문을 만드는 방식으로 이뤄짐
• 원시 파형은 볼륨과 재생 환경에 따라 쉽게 달라지므로 식별 기준으로 쓰기 어렵고, 짧은 구간마다 FFT를 적용해 시간별 주파수 구조를 드러내야 안정적인 비교가 가능해짐
• 남겨진 피크들은 단일 점이 아니라 anchor와 target zone의 쌍으로 묶여 해시가 되며, 이런 조합은 특정 녹음본을 구분할 만큼 구체적인 지문 해시로 작동함
• 검색은 곡을 하나씩 대조하지 않고 해시를 키로 바로 찾는 hash-first 구조를 쓰며, 마지막에는 일치한 해시들의 시간 간격까지 맞는지 확인해 신뢰도를 높임
• 서버 기반 대규모 데이터베이스와 온디바이스 방식은 규모와 제약이 다르지만, 핵심은 대부분의 정보를 버리고 랜드마크 피크만 남겨 짧고 시끄러운 클립에서도 빠르게 곡을 찾아내는 데 있음

---

소리를 역으로 해석하는 과정

• 휴대폰 마이크는 매우 얇은 다이어프램으로 공기 진동을 측정하고, 이를 시간별 공기 압력을 나타내는 숫자열인 파형으로 바꿔 저장함
  • 귀의 고막도 같은 압력파를 받지만, 휴대폰은 이를 소리 자체가 아니라 숫자 시퀀스로 다룸
  • 들어온 소리는 초당 수만 번 샘플링되며, 보통 44,100 Hz를 사용함
• 원시 파형만으로는 곡 식별이 어렵고, 같은 곡도 더 크게 재생하면 전혀 다른 파형이 되며, 다른 곡끼리도 비슷한 파형을 만들 수 있음
  • 재생 환경이 달라져도 동일한 곡의 파형이 달라질 수 있어 파형 자체는 식별 기준으로 부적합함
• 이 문제를 줄이려면 파형을 작은 조각으로 나눈 뒤 FFT를 적용해 각 시점에 어떤 주파수들이 들어 있는지 분해해야 함
  • 질문으로 바꾸면, "이 짧은 소리 조각을 다시 만들려면 어떤 순수 톤들을 더해야 하는가"에 해당함
  • 각 조각의 결과를 옆으로 쌓으면 시간축, 주파수축, 밝기축으로 이뤄진 스펙트로그램이 됨
• FFT는 아무리 복잡한 파형도 서로 다른 주파수, 진폭, 위상을 가진 사인파 합으로 표현할 수 있다는 점을 이용함
  • 예시로 1,024개 샘플을 넣으면 각 주파수에 얼마나 많은 에너지가 있는지 나타내는 스펙트럼을 돌려줌
  • 각 주파수 bin마다 모든 샘플을 그 주파수의 사인파와 곱해 더하고, 해당 주파수가 실제 신호에 있으면 합이 커지고 없으면 상쇄됨
• FFT의 핵심은 속도이며, 순진한 분해는 조각마다 수백만 번 연산이 필요하지만 FFT는 수학적 대칭성을 이용해 대략 n log n 수준으로 줄임
  • 이 정도 속도라서 휴대폰에서도 초당 수백 번 실행 가능함
  • 장치는 이 창을 오디오 위로 계속 이동시키며 각 조각에 FFT를 적용하고, 그 결과를 쌓아 스펙트로그램을 만듦
• 단순한 예시는 순수 주파수 하나로 이뤄진 합성음이라 이해에는 도움이 되지만 실제 음악은 훨씬 복잡함
  • 실제 음악이나 허밍을 마이크로 넣으면 스펙트로그램이 훨씬 어수선하게 보이지만, FFT는 그 안에서도 실시간으로 구조를 드러냄
  • 브라우저 예시에서는 모든 오디오가 브라우저 내부에서 처리되며, 녹음하거나 외부로 전송하지 않음

적을수록 더 강해지는 지문

• 시스템은 스펙트로그램 전체를 저장하지 않고, 가장 큰 피크만 남겨 희소한 점 집합으로 압축함
  • 약한 신호를 버리고 가장 강한 지점만 남기면 음향적으로 중요한 랜드마크만 남게 됨
• 이렇게 대부분을 버리는 이유는 전체 스펙트로그램을 저장하고 검색하는 일이 컴퓨터에도 지나치게 느리기 때문임
  • 임계값을 높일수록 희미한 신호는 사라지고 큰 피크만 살아남는 구조임
• 이 방식은 잡음 내성을 높여줌
  • 배경 잡음은 스펙트로그램 전반에 낮은 에너지를 더하지만, 보통 특정 영역의 최강 피크까지 만들지는 못함
  • 남는 랜드마크는 잡음을 뚫고 드러난 지배적 주파수들임
• 대신 이 지문 방식은 노래를 직접 불러 넣을 때 성능이 떨어지기 쉬움
  • 매우 잘 부르더라도 원곡과 다른 해시가 만들어질 가능성이 큼
  • 그래서 더 새로운 머신러닝 기반 시스템은 정확한 주파수 대신 멜로디를 기준으로 허밍과 노래를 처리함

점들을 연결해 해시 만들기

• 점 하나만으로는 구분력이 부족하지만, 두 점의 조합은 훨씬 덜 우연적이라 지문 해시로 쓰기 적합함
  • 예시로 어떤 시점의 1,200 Hz 하나는 수천 곡에 등장할 수 있지만, 1,200 Hz 뒤에 0.3초 후 2,400 Hz가 오는 조합은 훨씬 더 구체적임
• 알고리듬은 각 피크를 차례로 anchor로 삼고, 그 오른쪽에 시간과 주파수 범위를 가진 target zone을 잡아 그 안의 모든 피크와 짝지음
  • 각 쌍은 두 주파수와 시간 차이, 총 세 숫자로부터 짧은 hash를 만듦
• 해시는 같은 입력에서 항상 같은 결과가 나오고, 입력이 조금만 바뀌어도 완전히 다른 값이 나오는 짧은 코드로 동작함
  • Shazam류 시스템은 작은 변동을 다루는 체계를 갖고 있지만, 기본적으로 해시는 정확한 주파수와 타이밍에서 만들어짐
• 그 결과 이 해시는 곡 자체보다는 특정 녹음본의 지문처럼 작동함
  • 그래서 cover나 remix는 맞추기 더 어려워짐
• 3분짜리 곡 하나에서도 이런 지문 해시를 수천 개 만들 수 있고, 데이터베이스는 이를 모두 저장함
  • 휴대폰은 5초 클립에서 얻은 소수의 해시를 들고, 데이터베이스는 방대한 수의 곡에서 뽑은 수백만 해시를 들고 매칭 단계로 넘어감

정확한 매치 찾기

• 각 해시는 일종의 주소처럼 쓰이며, 시스템은 클립에서 얻은 해시마다 거대한 테이블을 바로 조회해 그 해시를 가진 곡을 찾음
  • 곡 단위로 하나씩 훑는 대신 해시 자체를 키로 삼아 접근함
• 직관적인 song-first 방식은 모든 곡을 하나씩 검사하며 해시 겹침을 확인해야 해서 곡 수가 늘수록 느려짐
  • 본문은 이를 O(N) 시간으로 표현함
  • 예시 데이터베이스와 5초 클립 해시 목록으로 이런 비효율을 시각화함
• 컴퓨터는 이를 뒤집어 hash-first 방식으로 처리할 수 있음
  • 각 해시에 대해 "어떤 곡들이 이 해시를 포함하는가"를 바로 물음
  • 책 뒤의 색인처럼, 모든 페이지를 다시 읽는 대신 특정 단어 항목으로 곧장 이동하는 구조에 비유함
• 이 접근은 조회를 거의 O(1) 에 가깝게 만듦
  • 곡이 100개든 1억 개든 대략 비슷한 시간 안에 처리됨
  • 가능한 해시 수가 매우 많아, 수백만 곡이 있어도 각 주소에는 보통 소수의 항목만 들어감
• 단순히 같은 해시를 공유한다고 끝나지 않고, 마지막 검증은 시간 간격에서 이뤄짐
  • 예시로 클립 안에서 17403C와 19A998가 1.2초 간격이면, 매칭 후보 곡도 같은 두 해시가 1.2초 간격으로 나와야 함
  • 일치하는 해시들의 시간 차가 서로 맞아떨어지고 개수도 충분해야 신뢰도 높은 매치가 됨
• 시스템 전체는 컴퓨터가 특히 잘하는 작업에 맞춰 설계됨
  • 숫자 비교와 주소 조회 중심으로 구성됨
  • 그래서 수백만 곡을 상대로도 전체 조회가 1초보다 훨씬 짧은 시간 안에 끝남

더 현대적인 접근

• Shazam 같은 다수의 곡 인식 서비스는 오디오 클립을 서버로 보내고, 서버에 있는 대규모 지문 데이터베이스에서 매칭을 수행함
  • 데이터베이스가 매우 크고 계속 바뀌며, 검색에 상당한 연산 자원이 필요하기 때문에 이런 구조를 씀
• 반대로 Apple의 온디바이스 인식과 Google Pixel의 Now Playing은 휴대폰 안에서 전부 로컬로 실행됨
  • 더 작고 선별된 데이터베이스와 최적화된 모델을 사용함
  • 완전한 포괄성 대신 속도를 택하고, 잡음과 오디오 변형에 더 강한 정교한 머신러닝 접근도 포함함
• 온디바이스 방식은 더 빠르고 인터넷 연결 없이도 동작하지만, 매칭 가능한 곡 데이터베이스가 훨씬 작다는 제약이 있음
  • 새 노래 반영도 일반적으로 더 느림
  • 위치 변화가 감지되면 새로운 데이터를 다시 가져와야 할 수 있음
• 지역별 인기곡 차이도 온디바이스 데이터 구성에 영향을 줌
  • 일본의 히트곡과 미국의 히트곡은 다를 수 있음
• 매칭이 서버에서 일어나든 기기 안에서 일어나든 핵심 기법은 같음
  • 대부분의 정보를 버리고 소수의 랜드마크 피크만 남기면, 시끄러운 카페에서 얻은 5초 클립도 수백만 곡 중 한 곡을 짚을 만큼 정밀한 좌표 집합으로 바뀜
  • 인식의 핵심은 많은 것을 듣는 일이 아니라, 무시할 것을 정확히 버리는 일에 가까워짐

기반이 된 논문

• 본문 상당수는 Avery Wang의 2003년 논문 An Industrial-Strength Audio Search Algorithm에 기반을 둠
  • 신호 처리와 시스템 설계를 더 깊게 보고 싶다면 그 논문이 직접적인 출발점이 됨
• 전체 흐름은 파형 변환, 피크 선택, 피크 쌍 해시, 역색인 조회, 시간 정렬 검증으로 이어짐
  • 이 단계들이 합쳐져 짧고 시끄러운 클립에서도 빠른 곡 식별을 가능하게 만듦

[GN⁺]

Hacker News 의견들

• Shazam 관련 자료를 같이 보면 좋겠음 https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf 원 논문이 있고, 진짜 관심 있으면 저자의 YouTube 발표도 찾아볼 만함 https://news.ycombinator.com/item?id=18069968 에는 Shazam 직원 글이 있고, https://news.ycombinator.com/item?id=38538996 에는 공동창업자가 인정한 설명이 있으며, https://news.ycombinator.com/item?id=41127726 에는 Go로 만든 알고리즘 재현이 있음 결국 ML도 코드 자체보다 데이터 가치가 더 큰 경우가 많다고 봄

• 내 최근 추측은 전혀 아닐 수도 있다는 쪽임 대중음악에서는 대체로 잘 맞았는데, 아이스 스케이팅 대회 쉬는 시간에 나온 꽤 괜찮은 신스 음악들을 여러 번 Shazam 해봤더니 하나도 제대로 못 찾았음 아직 미발매 곡이었거나 극도로 니치한 음악이었을 수도 있지만, 그냥 Shazam이 크게 실패한 걸 수도 있어 보임

• 이건 당연히 TV의 ACR에도 쓰이는 같은 계열 기술임 그런데 Shazam이 온라인에서 평판이 훨씬 좋은 건 사용자의 의도와 동의를 존중하기 때문인 듯함 TV에서도 비슷한 구현을 하되 데이터가 광고 판매로만 가지 않는다면, 소비자에게 실제로 이득이 되는 형태가 가능하지 않을까 싶음

  • 그 가치라는 게 결국 지금 재생 중인 쇼나 영화 제목을 알려주는 정도라면, 이미 일시정지 버튼 눌렀을 때 뜨는 정보와 크게 다르지 않은 것 아닌가 싶음

• 이 글은 아마 2003년 Shazam 논문의 원래 오디오 핑거프린팅 알고리즘을 시각적으로 설명한 자료 중 최고 수준 같음 다만 지금쯤은 어느 시점에 ML 모델로 갈아탔을 것 같기도 함

• DTW(dynamic time warping) 라는 알고리즘이 있는데 자주 간과됨 내 감으로는 Shazam에도 이게 어느 정도 쓰였을 것 같음

  • 예전에 특정 소셜 미디어 사이트에서 봇 추적할 때 DTW를 썼음 봇들은 떼 지어 행동하는 경향이 있어서, 지연된 반복 행동을 부드럽게 맞춰 보는 데 DTW가 잘 먹힘

• 같은 녹음본 인식은 그리 어렵지 않음 같은 녹음이라면 코드 진행과 타이밍이 정확히 반복 가능해서, 이런 식의 인식 기술은 이미 10년도 훨씬 전부터 있었음 반면 커버 버전처럼 다른 녹음으로 같은 곡을 알아맞히는 건 훨씬 더 어려움 Audible Magic은 https://www.audiblemagic.com/2024/02/07/identifying-cover-songs-live-performances-ai-clones-and-more/ 에서 같은 곡의 여러 공연 버전이나 패러디까지 인식할 수 있다고 주장하는데, 당연히 AI와 더 많은 연산을 쓰는 방식임

  • 어렵지 않다는 표현이 너무 많은 걸 생략하고 있음 사회 전체 수준에서는 오래전에 해결한 단순한 기술처럼 보여도, 개별 개발자에게 답을 안 찾아보고 직접 만들라고 하면 실제로 해낼 사람은 많지 않을 거라 봄
  • 적어도 20년 이상 된 얘기임 예전에 Gracenote 컨설팅할 때 그쪽이 어떻게 동작하는지 본 기억이 있음
  • 그렇다면 그냥 타이밍 정보 삭제하면 되는 것 아닌가 싶음

• 또 이 주제인가 싶었는데, 보니 SCP였음 이 도메인은 좀 수상해 보임 CameronMacLeod의 2022년 글보다 더 완전한 분석으로는 https://news.ycombinator.com/item?id=38531428 이 있고, Slate의 2009년 글은 https://news.ycombinator.com/item?id=893353 임

  • 이 맥락에서 SCP가 뭔지 잘 모르겠음 평소 떠올리는 secure copy는 전혀 안 맞음 그래도 링크들 고마움, 제목의 질문은 예전부터 막연히 궁금했는데 제대로 파고든 적은 없어서 셋 다 읽어볼 생각임
  • 그래도 이 글의 인터랙티브 요소들은 꽤 멋짐

• 내 프로젝트 목록에 추가해야겠음 Dinosaur game인데 점프를 키 입력이 아니라 꼬끼오 소리로 하게 만들면 재밌을 듯함

• Shazam 같은 앱이 탐지하지 못하게 막는 방법이 있는지 궁금함 노이즈를 섞는다든가 다른 기법이 가능한가 싶음

  • 노이즈가 원본보다 특정 지배적 주파수에서 더 크게 나오지 않는 이상 어렵다고 봄 글에도 예시가 있는데, 이 알고리즘은 조회를 빠르게 하려고 기본적으로 주파수 피크만 남기고 나머지는 거의 버림
  • 프로듀서나 DJ들은 이 문제를 보통 아예 발매를 안 하거나 한참 뒤에 내는 식으로 해결함

• 1986년에 Apple ][c로 이걸 과학 프로젝트로 해봤음