MIDI 파일을 분석 해보자 2 - 헤더 청크

MIDI파일을 알아보기로한지 약 일주일만에 다시 알아보는 시간.

 

이번엔 무식하게 메모장을 열어 데이터의 변화를 알아보는 것이 아닌

hex에디터를 통하여 데이터를 좀 더 면밀하게 쳐다보기로 하였다.

 

에서

훨씬 분석하기 쉬워졌다.

 

 

분석하기전에 헤더청크의 구조를 살펴보면 아래와 같이 이루어져 있다.

 

청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

청크타입 : 이 청크가 어떤 청크인지 알려주는 역할, 예) 헤더청크냐 트랙청크냐

 

길이 : 길이 뒤에 나열되는 데이터들의 길이를 나타낸다. 헤더청크는 트랙청크처럼 가변길이가 아니기 때문에 항상 6이라고 기록된다.

 

- 데이터들

형식 : 단일 트랙 0, 다중 트랙 1, 다중 트랙이지만 동시에 연주하지 않음

 

트랙 수 : 말그대로 트랙의 개수다.

 

디비전 : 1 delta time의 길이를 표현하는데 두가지 형식이 존재한다.

맨 앞 비트에 따라 달라지는데

*참고 (1 delta time = 1 tick)

 

0 (양수)일 경우, 1 delta time = 1개의 4분음표길이 / 데이터

 

1 (음수)일 경우, 하위 1바이트 값은 프레임당 tick, 상위 1바이트에서 부호비트를 제외한 7비트 값을 FPS

 

 

이제 대략 눈치챘으니 실제 데이터를 기반으로 알아보자.

 

 

정확히 14바이트, 밑줄 친 부분만 보면 된다. 이후 트랙청크가 기록된 부분

 

- 청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

4D 54 68 64 를 아스키코드로 변환하면 MThd 라는 알파벳이 나오는 것을 알 수 있다.

 

 

- 청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

00 00 00 06 볼 것도 없다. 데이터들(형식, 트랙 수, 디비전)의 길이가 6바이트이기 때문.

 

 

- 청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

00 01 다중 트랙을 의미하는 1이 기록되어 있다.

 

 

- 청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

00 02 트랙 수는 2개다.

 

 

- 청크타입 (4바이트) / 길이 (4바이트) / 형식(2바이트) / 트랙 수(2바이트) / 디비전(2바이트)

 

01 E0 를 우선 2진수로 변환해보자.

0000 0001 1110 0000

 

최상위 비트가 0 (양수)이므로 1 delta time = 1개의 4분음표길이 / 데이터 식을 적용하면 된다.

 

0000 0001 1110 0000 는 10진수로 480이다.

고로, 1개의 4분음표길이 / 480 = 1 delta time

 

 

다음에는 트랙 청크를 분석해보자.

 

-------------------------

공부하고 분석하면서 굉장히 이해가 안됬던 점이

디비전에서 1개의 4분음표길이는 도대체 무슨 소린가? 이해가 쉽지 않았다.

 

글 작성과 동시에 공부 및 분석을 하였는데, 글의 마지막 줄을 작성하면서 대략적으로 파악이 완료되었다.

 

테스트 용으로 지난 번에 만들어 둔 것

테스트용 악보(미디)의 경우 120BPM으로 설정되어 있고 이를 초로 환산하면 한 마디안의 4분음표 한개가 0.5초마다 재생되어지는 속도이다. 이를 다시 식에 대입하면 0.5 / 480 = 1 delta time이 되겠다.

2를 곱해 1 / 960 = 1 delta time으로 만들어 1 delta time당 시간을 계산하며 된다.

(사실 0.5로 나눠도 값은 같다. 굳이 저렇게 표기한 이유는.. 그냥 보기 좋잖아?)

 

다음에 트랙청크 분석 글을 작성하겠지만

트랙청크에도 헤더청크와 비슷한 형식을 갖추고 있으며 델타 타임 + 이벤트 형식으로 연주를 기록한다.

델타 타임 * 1 delta time ( 1/ 960 ) + 이벤트 (어떤 음을 얼마나 세게 등)...

 

3200 델타타임이 기록되어 있다면 3.333....초에 이벤트가 있다는 말

 

뭐 대충 이런식..

그러면 악보 제작자가 곡의 빠르기를 알려주지 않으면 계산을 못하는 것이 아닌가? 할 수도 있지만

사실 빠르기도 데이터 상에 메타데이터로 기록이 되어있다.

FF 51로 시작하는 부분에서 알 수 있는데 다음 글때 알아보도록 하자.

 

정말.. 리듬게임 파싱은 양반이다.

 

유니티로 리듬게임을 만들면서 OSU의 노트데이터 형식을 참고하며 따라 만들어보았던 흔적, 참고로 해당 프로젝트는 깃허브에 공개해두었으니 궁금하면 찾아가시면 됩니다.

이렇게 친절한 형식이 어딨어!

미디도 저렇게 텍스트 형식으로 보여주면 얼마나 좋을까?

 

아무튼.. 저장공간을 아끼려던 옛사람의 눈물나는 흔적이 느껴지는 동기가 되었다.