https://team-edo.github.io/tags/pyin/Recent content in PYIN on 얼쑤 · Team EdoHugoko-krSun, 08 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/dtw-recording-memory/Sun, 08 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/dtw-recording-memory/<p>얼쑤는 연주자가 악보보다 조금 빠르거나 느리게 불어도 같은 음끼리 비교할 수 있도록 DTW로 두 시간축을 맞춥니다. 녹음 길이 제한을 검토하면서, 계산이 끝나는 데 걸리는 시간과 함께 한 요청이 차지하는 메모리도 확인했습니다. 운영과 같은 조건에서 120초 합성 녹음을 처리하는 데 <strong>17.25초</strong>가 걸렸고 프로세스 최대 메모리는 <strong>3,065MiB</strong>였습니다.</p> <h2 id="같은-서버-조건에서-길이를-바꿔-봤습니다">같은 서버에서 녹음 길이 비교</h2> <p>운영과 같은 분석 이미지와 6GiB 메모리 제한으로 일회용 컨테이너를 실행했습니다. 네트워크를 끄고 합성 음계를 이어 붙여 만든 녹음을 길이별로 한 번씩 처리했습니다. 각 실행에서 짧은 입력으로 pYIN을 먼저 호출해 준비 시간을 따로 기록했습니다. 아래 시간은 준비 이후의 음높이 추정과 채점을 합한 값입니다.</p>https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/<p>얼쑤의 연주 분석에는 60초 제한이 있습니다. 이 시간은 세션이 <code>PENDING</code>이 된 시각부터 결과를 저장할 수 있는 마감까지 흐릅니다. 실행기에서 대기하는 시간, 녹음 다운로드와 디코딩, 음높이 추정과 채점, DB 쓰기가 모두 같은 예산을 사용합니다. 모델의 처리 시간만 재면 가장 먼저 늦어지는 단계가 어디인지 알 수 없습니다.</p> <h2 id="같은-요청에도-여러-시간-제한이-있다">한 요청에 걸린 여러 제한</h2> <table> <thead> <tr> <th>시간 제한</th> <th>언제부터 재나</th> <th>만료되면</th> </tr> </thead> <tbody> <tr> <td>백엔드의 결과 저장 마감 <strong>60초</strong></td> <td>DB에 기록한 분석 시도 시작 시각부터</td> <td>늦은 결과는 저장하지 않고, 마감이 지난 <code>PENDING</code>은 상태 조회에서 <code>TIMEOUT</code>으로 처리합니다.</td> </tr> <tr> <td>백엔드 HTTP 클라이언트의 읽기 제한 기본 <strong>65초</strong></td> <td>AI 응답을 읽으면서 다음 응답 데이터를 기다릴 때</td> <td>대기 시간을 넘기면 HTTP 읽기가 실패합니다.</td> </tr> <tr> <td>앱의 상태 무응답 제한 <strong>70초</strong></td> <td>상태 조회를 시작하거나 재개한 시점부터, 응답을 받으면 그 시점부터</td> <td>앱이 시간 초과 화면을 표시합니다.</td> </tr> </tbody> </table> <p>HTTP 연결을 맺는 제한은 별도로 <strong>5초</strong>였습니다. 읽기 제한을 저장 마감보다 길게 둬, 느린 응답을 클라이언트가 먼저 끊어 서버 오류로 분류하는 경우를 줄이려 했습니다. HTTP 연결이 끊겨도 이미 실행 중인 AI 연산이 취소되는지는 별도의 문제입니다. 앱의 조회 간격과 무응답 경계는 가상 시계로 확인했습니다. <a href="https://team-edo.github.io/posts/2026/10/recording-analysis-polling/">녹음 업로드 202 이후 앱이 기다리는 것</a></p>https://team-edo.github.io/posts/2026/10/pyin-tuning-resolution/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/pyin-tuning-resolution/<p>얼쑤에서 백엔드의 분석 요청을 받아 음표별 판정을 돌려주는 API를 구현했습니다. 검증할 때 악보의 모든 음보다 <strong>20센트 낮게</strong> 만든 합성음을 넣었습니다. 반음이 100센트이므로, 같은 간격으로 음높이만 조금 낮춘 입력입니다.</p> <p>분석은 HTTP 200과 <code>DONE</code>으로 끝났습니다. 그런데 응답의 조율 보정값 <code>tuningOffsetCent</code>는 <strong>−15.0센트</strong>였습니다. 입력을 만들 때 정한 값과 채점기가 실제로 적용한 값 사이에 5센트 차이가 있었습니다.</p> <h2 id="보정값이-만들어지는-과정">pYIN 추정에서 조율 보정까지</h2> <p>로컬에서 실제 분석 API를 띄우고, 저장소 역할을 하는 로컬 HTTP 서버가 합성 M4A를 보내도록 했습니다. API는 오디오를 16kHz 모노로 디코딩한 뒤 pYIN으로 짧은 구간마다 기본 주파수를 추정합니다. 당시 요청에는 기준음이 없어서 황의 기준 주파수를 311.13Hz로 두고, 악보의 각 음이 거기서 몇 반음 떨어져 있는지로 목표 음높이를 구했습니다.</p>