ScorePlayer TIL 3
악보 파일(MusicXML — 악보 프로그램끼리 음표·박자·가사를 주고받는 표준 형식)을 읽어 화면에 그리고 그걸 투명 영상으로 뽑는 데까지 하루에 갔다. 기능 목록으로 보면 셋이지만, 견적을 잘못 잡을 뻔한 지점이 둘 있었다.
남이 정한 형식을 받는 기능은 견적을 두 배로 잡는다
“MusicXML을 읽는다”는 한 줄짜리 기능처럼 보인다. 실제로는 그 형식을 만든 사람들이 오랫동안 쌓아 둔 규칙을 따라가는 일이다.
이번에 걸린 것만 봐도 — 파일 안에서 시간이 앞으로만 흐르지 않고(피아노 두 손을 겹쳐 적으려고 되감는다), 길이가 초가 아닌 자체 단위(divisions — 4분음표 하나를 몇 칸으로 쪼갤지 파일마다 정해 두는 값)로 적혀 있고, 같은 시각에 울리는 음을 따로 표시한다. 하나라도 놓치면 소리는 나는데 박자가 통째로 밀린다.
여기서 가져갈 판단은 두 가지다.
- 표준 파일을 받는 기능은 “읽어서 화면에 뿌린다”가 아니라 “그 형식의 규칙을 구현한다”로 본다. 견적도 그렇게 잡는다.
- 대신 그 값을 한 번만 치른다. 읽는 쪽에서 형식의 별난 점을 전부 흡수해 우리 말로 바꿔 넘기면, 나머지 코드는 그 형식을 몰라도 된다. 흡수를 미루면 그 별난 점이 프로젝트 전체에 번진다.
손으로 만든 테스트 파일로만 확인한 것도 위험했다. 실제 악보 프로그램이 내보낸 파일을 열자 그제야 안 맞는 게 드러났다. 남의 형식은 남이 만든 실물로 확인해야 한다.
배경이 투명한 결과물은 만드는 내내 값을 물린다
이 도구의 결과물은 배경이 없는 영상이다. 그래야 연주 영상 위에 얹힌다. 그런데 배경이 없다는 건 만드는 과정 내내 제약이 따라온다는 뜻이었다.
가장 뚜렷한 예 — 화면 왼쪽에 고정해 둔 기호 위로 음표가 지나가 겹쳤다. 보통이라면 그 자리를 배경색 사각형으로 덮으면 끝이다. 여기서는 못 한다. 흰 사각형으로 덮으면 영상에 흰 판이 남고, 검은 사각형이면 검은 판이 남는다. 투명한 결과물에서 “가리기”는 덮기가 아니라 지우기여야 한다.
이런 게 한 곳이 아니었다. 반투명한 부분의 색이 저장 방식에 따라 달라지는 문제도 있었고(premultiplied alpha, 미리 곱한 알파 — 그림 도구는 색 값에 투명도를 미리 곱해 들고 있는데, 영상 형식은 곱하기 전 값을 받는다), 압축 방식 선택지도 좁아졌다(투명도 채널을 담을 수 있는 코덱이 몇 안 된다).
판단으로 남길 것은 이것이다. 투명 배경은 결과물의 한 속성이 아니라 프로젝트 전반에 붙는 제약이다. 그 제약을 감수할 가치가 있는지는 처음에 정해야 하고, 정했으면 곳곳에서 값을 치를 각오를 한다. 우리는 감수하기로 했다 — 배경 없는 소재가 이 도구의 존재 이유다.
빠른 길을 찾으면 결과가 같은지부터 확인한다
느린 부분(미리 곱한 알파를 곱하기 전 값으로 되돌리는 계산)을 FFmpeg(영상을 인코딩·변환하는 명령줄 도구)의 필터에 맡겼더니 1.6배 빨라졌다. 그런데 결과물을 열어 값을 확인해 보니 색이 달랐다. 빠른 게 아니라 다른 일을 하고 있었다.
눈으로는 알아채기 어려운 종류였다. 반투명한 부분만 조금 어두워지는 거라, 속도만 보고 채택했으면 그대로 계속 뽑았을 것이다.
그래서 규칙 하나를 세웠다. 빨라졌다고 좋아하기 전에 “결과가 같은가”를 먼저 확인한다. 눈으로 확인하기 어려운 값(투명도·색)일수록 숫자로 대조한다. 결국 원래 방식을 여러 코어에 나눠 1.8배를 벌었고, 그건 결과가 완전히 같은지 확인한 뒤에 채택했다.
요약
- 표준 파일을 받는 기능은 “읽기”가 아니라 “그 형식의 규칙 구현”이다. 견적을 그렇게 잡는다
- 형식의 별난 점은 읽는 쪽에서 한 번에 흡수한다. 미루면 프로젝트 전체로 번진다
- 남의 형식은 남이 만든 실물 파일로 확인한다. 직접 만든 예제는 만든 쪽의 가정만 확인해 준다
- 투명 배경은 결과물의 속성이 아니라 프로젝트 전반의 제약이다. 감수할 값인지 처음에 정한다
- 빨라진 길은 결과가 같은지부터 대조한다. 눈에 안 보이는 값일수록 숫자로 본다