3P by GN⁺ | ★ favorite | 댓글 1개
  • SeekTune은 Shazam의 노래 인식 알고리듬을 구현한 프로젝트로, Spotify와 YouTube API를 통합해 노래를 찾고 다운로드할 수 있게 함
  • 실행에는 Golang, FFmpeg, NPM, YT-DLP가 필요하며, Docker Compose 또는 네이티브 환경에서 서버와 클라이언트를 구동할 수 있음
  • Spotify 연동은 개발자 앱의 Client IDClient Secretserver/.env에 설정하는 방식이며, 앱이 필요한 액세스 토큰을 자동으로 가져오고 캐시함
  • 기본 데이터베이스는 SQLite이고, 환경 변수로 DB_TYPE=mongo를 지정하면 MongoDB를 사용할 수 있으며 사용자·비밀번호가 없으면 mongodb://localhost:27017로 연결함
  • CLI는 Spotify 링크 다운로드, 로컬 오디오 저장, 녹음 파일 매칭, 지문과 노래 삭제를 지원하며, YouTube ID가 없는 저장 항목은 프런트엔드에서 매칭 결과로 표시되지 않음

프로젝트 개요

  • SeekTune은 Shazam의 노래 인식 알고리듬을 구현한 애플리케이션임
  • 구현은 README의 리소스 섹션에 있는 자료들을 바탕으로 함
  • Spotify와 YouTube API를 통합해 노래를 찾고 다운로드할 수 있음
  • 데모와 제작 과정 링크가 제공됨

설치와 실행 방식

  • 필요한 도구는 Golang, FFmpeg, NPM, YT-DLP임

  • 저장소 복제 명령은 다음과 같음

    git clone https://github.com/cgzirim/seek-tune.git
    cd seek-tune
    
  • Spotify API 설정

    • Spotify 앱을 만들고 Client IDClient Secret을 얻어야 함
    • server 디렉터리에 .env 파일을 만들고 다음 값을 설정함
    SPOTIFY_CLIENT_ID=your-client-id
    SPOTIFY_CLIENT_SECRET=your-client-secret
    
    • 앱은 필요한 액세스 토큰을 자동으로 가져오고 캐시함
  • Docker 실행

    • Docker와 Docker Compose가 필요함
    • 빌드와 실행은 다음 명령으로 수행함
    docker-compose up --build
    
    docker-compose down
    
  • 네이티브 실행

    • 백엔드 의존성 설치
    cd server
    go get ./...
    
    • 클라이언트 의존성 설치
    cd client
    npm install
    

CLI 사용법

  • 클라이언트 앱은 client 디렉터리에서 실행함
    npm start
    
  • 백엔드는 별도 터미널에서 실행함
    cd server
    go run *.go serve [-proto <http|https> (default: http)] [-port <port number> (default: 5000)]
    
  • Spotify 링크로 노래를 다운로드할 수 있음
    go run *.go download <https://open.spotify.com/.../...>;
    
    • Spotify 모바일 앱에서 복사한 링크는 동작하지 않음
    • 데스크톱 또는 웹 앱에서 복사한 링크를 사용할 수 있음
  • 로컬 노래 파일이나 디렉터리를 데이터베이스에 저장할 수 있으며, 모든 오디오 형식을 지원함
    go run *.go save [-f|--force] <path_to_song_file_or_dir_of_songs>
    
    • -f 또는 --force는 YouTube ID를 찾지 못해도 노래를 저장함
    • YouTube ID가 없으면 프런트엔드가 매칭을 표시하지 않음
  • 노래나 녹음 파일의 매칭을 찾을 수 있음
    go run *.go find <path-to-wav-file>
    
  • 지문과 노래 삭제를 지원함
    go run *.go erase
    go run *.go erase db
    go run *.go erase all
    
    • 기본값은 데이터베이스만 삭제함
    • erase all은 데이터베이스와 노래 파일을 함께 삭제함
  • *.go가 동작하지 않으면 ./...를 사용할 수 있음

예시 출력

  • 다운로드 예시는 Spotify 트랙 정보를 가져온 뒤 트랙을 다운로드하고 지문을 저장함
    $ go run *.go download https://open.spotify.com/track/4pqwGuGu34g8KtfN8LDGZm/…
    Getting track info...
    Now, downloading track...
    Fingerprints saved in MongoDB successfully
    'Voilà' by 'André Rieu' was downloaded
    Total tracks downloaded: 1
    
  • 매칭 예시는 Voilà - André Rieu.wav에 대해 상위 20개 매칭과 최종 예측을 출력함
    • 최상위 결과는 Voilà by André Rieu이며 점수는 5390686.00
    • 검색 시간은 856.386557ms로 표시됨
    • 최종 예측도 Voilà by André Rieu로 표시됨

데이터베이스 선택

  • 기본 데이터베이스는 SQLite
  • MongoDB를 사용하려면 MongoDB를 설치하고 연결 환경 변수를 설정함
    • DB_TYPE: MongoDB 사용을 위해 "mongo"로 설정
    • DB_USER: MongoDB 사용자 이름
    • DB_PASS: MongoDB 비밀번호
    • DB_NAME: 사용할 MongoDB 데이터베이스 이름
    • DB_HOST: MongoDB 서버 호스트명 또는 IP 주소
    • DB_PORT: MongoDB 서버 포트 번호
  • 데이터베이스 연결 URI는 환경 변수로 구성됨
  • DB_USER 또는 DB_PASS가 없으면 기본적으로 mongodb://localhost:27017에 연결함

참고 자료와 라이선스

댓글과 토론

Hacker News 의견들
  • Shazam 기술의 일부는 Stanford 캠퍼스의 CCRMA에서 나왔고, 이곳은 초기 컴퓨터 역사와도 깊이 연결된 특별한 장소임
    초기 컴퓨터 기술의 응용이 오디오와 관련된 경우가 유난히 많다는 점이 흥미로움. John Bardeen의 뮤직박스, 트랜지스터의 첫 상업적 응용이었던 보청기, Palo Alto의 HP 차고에서 만들던 오디오 발진기, iPod에서 이어진 iPhone, 아날로그 전화선을 실어 나르던 구리선 위에 세워진 인터넷, Bell Labs까지 사례가 계속 이어짐
    어쩌면 인간은 kHz 영역을 다루는 법을 먼저 익힌 뒤 MHz/GHz 영역으로 넘어간다는 가설도 꽤 매력적으로 들림

    • 오디오는 전자적으로 조작하기 상대적으로 쉬워서 그런 것 같음
      오디오 신호는 비교적 쉽게 전기 신호로 바꿀 수 있지만, 그래픽은 화면에 보이게 만드는 것부터 훨씬 복잡함. 전기 신호를 음파로 바꾸는 스피커도 핵심 구조만 보면 아주 단순한 장치임
      게다가 오디오는 사람에게 강한 인상을 주기 때문에, 전자공학이나 컴퓨터의 힘을 보여주려면 나라도 오디오를 택했을 듯함
    • 너무 억지로 연결한 해석 같음
  • 이게 Shazam의 진짜 재현이라면, 적어도 2025년 3월까지 Apple 특허 아래 있을 수 있음: https://patents.google.com/patent/US7627477

    • Shazam이 알고리즘을 설명한 논문 “An Industrial-Strength Audio Search Algorithm”(https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf)에는 명확한 출판일이 없지만, https://www.researchgate.net/publication/220723446_An_Industrial_Strength_Audio_Search_Algorithm를 보면 2003년 논문으로 보임
      해당 특허는 미국에서 2004-10-21에 출원됐음. 법률 전문가는 아니지만, 미국에서는 이 특허에 불리한 근거가 될 수 있어 보임
    • 10년 전쯤 HN에서 Shazam이 알고리즘 공개를 법적으로 위협해서 인기 글이나 소스가 내려간 적이 있었던 것으로 기억함
      아마 원문 글에 있는 Google Drive PDF 캡처가 그 자료였던 것 같음
    • 핵심은 오디오 신호의 빠른 푸리에 변환에서 간단한 지문을 만들고, 단순한 색인과 단순한 유사도 검색을 하는 구조임
      다만 이 방식이 동작하려면 지구상의 모든 음악에 대한 서명이 필요함 ;)
    • 그러면 미국 밖에서는 집행하기 어렵다는 뜻임
    • 그러니까 지금 저장소를 클론해 두라는 말이군
  • Shazam 공동창업자 Avery Wang이 DAFx17에서 한 발표가 좋았음
    알고리즘의 이론적 배경을 조금 다루고, 배경 소음 같은 실제 문제도 살펴봄: https://www.youtube.com/watch?v=YVTnj3OIhwI

    • 이건 시청 목록에 추가함. 이 논문을 읽었을 때가 컴퓨팅 알고리즘에서 처음으로 하는 순간을 느낀 때 중 하나였음
  • 최근 Shazam의 정확도가 떨어진 것 같고, 오히려 SoundHound가 더 나은 결과를 줌
    Shazam에서는 아시아권 음악 전통에 속한 결과가 많이 나오는데, 그 자체는 좋지만 문제는 틀린 곡이라는 점임. 선택 대상 음악 범위를 넓혔다면 알고리즘도 개선해야 할 듯하고, 지금은 해시 테이블 충돌이 더 많아진 느낌임
    참고: https://github.com/cgzirim/not-shazam/…

    • SoundHound는 늘 Shazam보다 나았음. 사람이 부르는 노래나 아주 조용한 곡도 잡아냄
    • 2021년 8월에 Shazam, SoundHound, BeatFind의 음악 인식 라이브러리를 비교해 봤음
      결론은 BeatFind와 Shazam이 가장 많은 곡을 알고 있었지만, 서로 보완적인 면도 있었고 모든 서비스가 각자만 인식한 곡을 최소 하나씩 갖고 있었다는 것임
      테스트에는 여러 장르와 인지도 수준의 곡을 섞었지만 표본 수가 더 컸다면 더 좋았을 것임. 또 사람 말소리 같은 소음이나 벽 너머로 들리는 필터링된 음악은 테스트하지 않았음
      재미있게도 “Night Driver”는 “1 Shazams”라고 나와서 아마 내가 처음 Shazam한 사람 같았고, “THEY'RE TAKING THE HOBBITS TO ISENGARD!”는 어디로 호빗을 데려가는지 다들 알지만 서비스들은 아무도 못 알아봄
  • 프로젝트가 쓰고 고치기 좋아 보이긴 하지만, 개인적으로는 아직 공개하기엔 조금 이르다고 봄
    실행 방법 안내가 부정확해 보이고, MongoDB가 필요하지만 연결·사용법 설명이 빠져 있음. 가능하면 DB를 교체 가능하게 만들고 sqlite처럼 부담이 덜한 선택지를 제공하는 편이 나음
    MongoDB를 대체할 수 없다면 Dockerfile과 docker compose를 제공해서 쉽게 실행하고 테스트할 수 있게 해야 함. 클라이언트의 npm install에서 치명적 취약점 8개가 나오는데 실제로 문제가 아닐 수도 있어도 테스트를 계속하기 망설여짐
    특허나 저작권을 신경 쓰지 않더라도 이름은 바꾸는 게 좋음. GitHub 자체가 미국에 있으니 DMCA가 들어오면 프로젝트를 내릴 수 있음
    마지막으로 WAV 파일에서 곡을 추가하는 기능도 있으면 좋겠음. 테스트하고 싶은 오디오가 전부 Spotify나 YouTube에 있는 건 아님
    낙담시키려는 뜻은 아니고, 이런 사소한 마감이 부족하면 사람들이 프로젝트를 무시하거나 낮게 평가하기 쉬움. 시간이 되면 PR을 보낼 수도 있고, 음악 외 영역의 오디오 매칭을 실험하고 싶어서 이 프로젝트가 수정하기 가장 쉬워 보임

    • 프로젝트에 마감 작업이 더 필요하다는 데 동의함
      설정 안내를 개선하고, 유연성을 위해 파일 기반 DB를 추가하는 방안과 npm 취약점 해결을 우선순위에 두겠음. WAV 파일을 바로 지문화하는 기능도 좋은 아이디어라 우선적으로 보겠음
      프로젝트 이름의 법적 위험도 이해했고 바꿀 예정임. 좋은 이름 제안이 있으면 받고 싶음
    • 이런 귀중한 피드백을 받으려고 HN에 올리는 것임. 좋은 정리임
  • 저장소를 아직 자세히 보진 않았는데, 검색 대상이 되는 데이터가 어디서 오는지 궁금함
    라이브러리를 로드하는 건지, 아니면 어딘가에서 확보한 대형 라이브러리를 검색하는 건지 궁금함

    • 데이터는 서버에 연결된 지문 데이터베이스에서 옴. 곡이 추가될 때마다 이런 지문이 만들어짐
  • 이런 걸 꼭 만들어 보고 싶었던 버킷리스트가 있었는데, 정말 멋짐

    • 영감을 줬다니 기쁨. 클론해서 더 발전시켜도 좋음
  • 지문을 커뮤니티 기반으로 공유하는 방법이 있으면 꽤 좋을 듯함

    • 오디오뿐 아니라 이미지와 동영상 클립에도 그런 방식이 있으면 좋겠음
      기억하기로 BitTorrent는 분산 해시 테이블을 쓰지만 해시는 전체 콘텐츠 기준이라, 출처 표기가 엉망인 파생작의 원본을 찾는 용도에는 별로 유용하지 않음
      이미지 원본 찾기에는 Tineye가 가끔 쓸 만함
    • MusicBrainz가 이걸 지원하는 것 같음: https://musicbrainz.org/doc/AcoustID
  • Spotify 곡을 넣는다면, 결과도 Spotify 곡으로 내보내는 게 더 자연스럽지 않나?

    • 실제로 그게 맞음. 다만 Spotify는 직접 다운로드를 허용하지 않아서 YouTube에서 곡을 찾아 내려받아야 했음
  • Google 폰에는 내장된 음악 인식 기능이 있고, 이 분야에서 가장 잘 구현된 것으로 들었음
    어떤 접근을 썼는지 아는 사람이 있는지 궁금함. 별개로 SoundHound가 Shazam보다 낫다고 늘 느꼈음

    • 기억으로는 음악이 재생 중일 때만 깨우는 작은 알고리즘이나 하드웨어 조각이 있었던 것 같음
      그래서 휴대폰이 항상 활성 상태일 필요가 없고, 그 다음부터는 어떤 기존 감지 알고리즘을 써도 됐을 듯함. 나에게는 그 초저전력 단계가 마법처럼 느껴졌지만, 세부사항을 읽어본 적은 없음