인식률이 얼마나 되냐는 질문에 그동안은 대략적으로만 답했습니다. 이번에 테스트 악보 일곱 장으로 실제 숫자를 냈습니다. 잘 되는 경우와 안 되는 경우를 구분해서 적습니다.
테스트에 쓴 악보
성격이 다른 악보를 골랐습니다. 인쇄 상태, 단 수, 표기 관습, 손글씨 유무가 서로 다릅니다.
| 구분 | 형태 | 특징 |
|---|---|---|
| 발라드 | 10단, 세로로 긴 인쇄 악보 | 분수 코드와 괄호 텐션이 많음 |
| 찬양곡 | 14단, 스캔 | 볼타 브래킷 4곳, 샵 코드 다수 |
| 축복송 | 3단, 사진 | 파란 펜 손글씨 주석 |
| 창작곡 | 3단, 깨끗한 인쇄 | GM7, CM7처럼 대문자 M 표기 |
| 반주 악보 A | 8단 | 일반적인 인쇄 상태 |
| 반주 악보 B | 7단 | 일반적인 인쇄 상태 |
| 애국가 | 4단, 멜로디와 가사만 | 코드 표기가 하나도 없음 |
마지막 악보를 일부러 넣었습니다. 코드가 없는 악보를 넣으면 어떻게 되는지 확인하려는 목적이었습니다.
인식 개수와 처리 시간
처리 시간은 로컬에서 잰 값입니다. 모델이 이미 메모리에 올라간 상태에서 측정했습니다.
| 악보 | 인식된 코드 | 처리 시간 |
|---|---|---|
| 찬양곡 (14단) | 104개 | — |
| 발라드 (10단) | 80개 | 0.85초 |
| 반주 악보 B (7단) | 60개 | — |
| 반주 악보 A (8단) | 48개 | — |
| 축복송 (3단) | 34개 | 0.19초 |
| 창작곡 (3단) | 20개 | — |
단당 처리 시간이 거의 일정합니다. 코드 개수에 비례해 문자 검출 호출이 늘어나기 때문입니다. 로컬에서는 1초 안쪽이고, 실제 서비스에서는 서버가 깨어나는 시간이 더해집니다.
정답을 붙여 채점한 세 장의 결과는 이렇습니다.
| 악보 | 정답 | 정밀도 | 재현율 |
|---|---|---|---|
| 찬양곡 | 101개 | 95.2% | 98.0% |
| 창작곡 | 15개 | 70.0% | 93.3% |
| 축복송 | 22개 | 67.7% | 95.5% |
잘 되는 악보의 조건
찬양곡이 정밀도 95.2%, 재현율 98.0%로 가장 좋았습니다. 이 악보의 조건을 보면 무엇이 중요한지 알 수 있습니다.
- 스캔본이라 오선이 완전히 수평입니다. 사진처럼 기울어지지 않았습니다.
- 배경이 흰색입니다. 그림자나 누런 변색이 없습니다.
- 코드가 보표 바로 위에 일정한 높이로 인쇄되어 있습니다.
- 손글씨가 없습니다.
오선을 찾는 과정이 이미지를 가로 행 단위로 훑어 잉크가 폭의 대부분을 채우는 행을 찾는 방식이기 때문에, 수평이 맞는 것이 가장 중요합니다. 사진이 2~3도만 기울어도 오선 한 줄의 좌우 끝이 100픽셀 넘게 어긋나서 어느 행도 조건을 만족하지 못합니다.
코드가 없는 악보에 코드가 생긴다
가장 예상 밖의 결과였습니다. 애국가 악보에는 코드 표기가 하나도 없는데, 분할 방식에 따라 1개에서 33개까지 검출됐습니다.
| 분할 방식 | 검출된 코드 (정답 0개) |
|---|---|
| 통째로 넣기 | 1개 |
| 상대 임계 | 5개 |
| 기존 방식 | 9개 |
| 닫힘 연산 | 33개 |
검출된 것을 확인해 보니 전부 가사였습니다. 3절과 4절 가사 줄이 보표 위쪽에 놓여 있었고, 이것을 코드 표기 영역으로 오인한 것입니다.
원인은 파이프라인 구조에 있습니다. 코드 표기 띠를 찾을 때 보표 위쪽에서 글자로 보이는 픽셀 덩어리가 모여 있는 띠를 찾습니다. 가사도 글자이므로 이 조건을 만족합니다. 코드인지 가사인지 구분하는 장치가 없습니다.
이 발견이 측정 방법에도 영향을 줬습니다. 처음에는 "검출 개수가 많으면 좋다"는 전제로 지표를 만들었는데, 코드가 없는 악보에서는 그 전제가 완전히 뒤집힙니다. 지표를 정답 기준 정밀도·재현율로 다시 짜야 했습니다.
코드가 없는 악보를 올리면 가사에서 나온 엉뚱한 코드가 표시됩니다. 편집 화면에서 삭제할 수 있지만, 개수가 많으면 번거롭습니다. 코드 표기가 없는 악보는 이 도구의 대상이 아니니 올리지 않는 편이 낫습니다.
손글씨가 섞이면 정밀도가 떨어진다
축복송 악보는 재현율 95.5%로 코드를 잘 찾았지만 정밀도가 67.7%였습니다. 검출 31개 중 10개가 정답에 없는 것이었습니다.
오검출의 출처는 세 가지였습니다.
- 파란 펜 손글씨 — 원래 코드 위에 다른 코드를 덧써 놓은 주석. 인쇄 코드와 손글씨 코드가 겹쳐 있어 둘 다 검출되거나 섞여 읽혔습니다.
- 리허설 마크 — 구간 표시용으로 네모 안에 넣은
V,IR같은 글자. 알파벳이라 코드로 인식됩니다. - 템포 표시 —
= 102같은 문자열. 숫자가 인식 대상 문자에 있어서 부분적으로 잡힙니다.
손글씨 자체는 인식 모델이 학습한 범위 밖이라 대체로 읽히지 않습니다. 문제는 손글씨가 인쇄 코드와 겹쳐 있을 때입니다. 겹친 픽셀이 하나의 덩어리가 되어 글자 형태가 망가집니다.
표기 관습이 결과를 가른다
창작곡 악보에서 흥미로운 일이 있었습니다. 이 악보는 인쇄 상태가 가장 깨끗한데도 정밀도가 70.0%로 낮았습니다.
원인은 표기였습니다. 이 악보는 메이저 세븐스를 GM7, CM7처럼 대문자 M으로 적습니다. 인식 과정에서 대문자를 새 코드의 시작으로 판정하고 있었기 때문에, GM7이 G와 M7 두 개로 갈라졌습니다.
이 문제를 고친 뒤 같은 악보의 F1이 57.9에서 80.0으로 올랐습니다. 22.1점 차이입니다. 인쇄 품질이 아니라 표기 관습 하나가 그만큼의 차이를 만들고 있었습니다.
같은 수정을 다른 악보에 적용해도 변화가 없었습니다. 그 악보들에는 대문자 M 표기가 없었기 때문입니다. 개선 효과가 악보 종류에 따라 완전히 갈린다는 뜻입니다.
| 표기 | 같은 코드 | 인식 상태 |
|---|---|---|
| Cmaj7 | C 메이저 세븐스 | 정상 |
| CM7 | 수정 전에는 갈라짐, 지금은 정상 | |
| Cdim | C 디미니시드 | 정상 |
| C° | 인식 대상 문자에 없음 | |
| Caug | C 오그멘티드 | 부분 인식 |
| C+ | 인식 대상 문자에 없음 |
기호식 표기를 쓰는 악보는 지금 구조로는 읽지 못합니다. 인식 대상 문자 25종에 그 기호들이 없기 때문입니다. 이런 악보는 편집 화면에서 직접 입력해야 합니다.
올리기 전 확인할 것
측정 결과를 실용적인 기준으로 정리하면 이렇습니다.
| 조건 | 기대할 수 있는 결과 |
|---|---|
| 스캔본, 수평, 인쇄 코드, 손글씨 없음 | 재현율 95% 이상. 대부분 그대로 사용 가능 |
| 대문자 M 표기 (CM7 등) | 수정 이후 정상. 결과는 확인 권장 |
| 손글씨 주석이 인쇄 코드와 겹침 | 겹친 부분은 검수 필요 |
| 리허설 마크, 템포 표시가 코드 높이에 있음 | 가짜 코드가 몇 개 생김. 삭제 필요 |
| 기호식 표기 (도, 플러스 등) | 인식되지 않음. 직접 입력 |
| 코드 표기가 없는 악보 | 가사가 코드로 잡힘. 사용 부적합 |
| 기울어진 사진 | 오선을 못 찾아 아무것도 검출되지 않을 수 있음 |
촬영 조건을 개선하는 구체적인 방법은 악보 사진 촬영 가이드에, 인식 오류를 고치는 방법은 인식 오류 가이드에 정리했습니다.
이 숫자의 한계
악보 일곱 장, 정답 138개는 작은 표본입니다. 특히 정답을 붙인 세 장에는 각각 다른 특성이 하나씩 있어서, 어느 한 장의 결과가 전체 지표를 크게 흔듭니다. 개선 효과가 한 악보에서만 나온 사례를 앞에서 적은 것도 같은 이유입니다.
표기 관습이 다른 악보를 더 모아 라벨링하는 것이 다음 할 일입니다. 지금 숫자는 참고용이고, 회원님의 악보에서 그대로 재현되지 않을 수 있습니다.