Pattern Lab의 놀라운 진화

"Drum Patternology" 연구의 초기에는 이미 드럼 패턴 정보만 담고 있는 MIDI 파일을 작업 대상으로 했었다. 따라서 실제 곡 안에서 각 패턴이 어떤 관계에 있는지 분석하기는 어려웠다. 최근 들어 잘 알려진 팝송을 MIDI로 전환한 자료 뭉치를 분석하게 되면서 미처 생각하지 못했던 많은 것을 알게 되었다. 특히 '하나의 패턴은 두 마디'라는 원칙을 깨고 한 마디로 분석 단위를 낮추면서 하나의 곡 안에서 패턴이 어떻게 재사용되고 또 변형되는지를 보다 확실하게 파악할 수 있었다.

얼핏 생각하면 모든 패턴을 한 마디 단위로 잘게 잘라 놓을수록 그루브와 fill/break 사이의 문맥은 잃어버릴 것처럼 보인다. 그러나 더욱 진화한 PatternLab에서는 잘라낸 패턴을 다시 원곡의 시간 순서에 놓고 인접 관계를 분석하여 pattern transition graph를 생성한다. 분석 단위를 짧게 만든 대신, 패턴 사이의 관계를 별도의 층위에서 복원한 것이다.

앞으로 여러 곡의 transition 정보를 축적한다면, ARR 파일에서 패턴 체인을 만들 때 현재 선택한 패턴 뒤에 어떤 groove, fill 또는 break가 실제 음악에서 자주 이어졌는지를 확률적으로 제시하는 근거로 사용할 수도 있을 것이다. 물론 이것은 알려진 하나의 곡에서 나온 데이터일 뿐이다. 여러 곡을 거쳐서 분석하면 어떤 결과가 나올까? 실제로 여러 곡을 거쳐서 공통적으로 쓰이는 패턴은 현재까지의 연구에 의하면 그렇게 많은 것 같지 않다. 그리고 현실의 MIDI 파일 안에 들어 있는 노트  중 off-grid 상태인 것이 너무 많기 때문에 제대로 된 분석을 거치려면 보정을 거쳐야 한다. 

처음에는 원본 MIDI 파일의 타이밍을 인위적으로 보정하지 않은 상태에서 분석하려 했다. 그러나 현실의 MIDI 데이터는 그렇게 완벽하지 않았다. 미세한 off-grid가 서로 다른 패턴으로 인식되어 불필요한 long tail을 만들어 냈기 때문이다. 결국 원본은 그대로 보존하되, 일정한 허용 범위 안의 타격을 nearest grid로 옮긴 보정본을 별도로 만들어 분석하는 절차를 도입하였다.

그나마 다행스러운 것은 현재까지 만들어진 재생 시스템은 대대적인 수정을 거치지 않아도 1-bar 패턴을 수용할 수 있다. ADT/ADP v2.3이 매우 유연하고 개방적으로 설계된 때문일까. 

킴 칸스의 <Bette Davis Eyes> 분석 결과.

위 그림의 오른쪽에서 보인 그래프는 웹 브라우저 안에서 마우스로 각 노드를 움직일 수 있는 동적 그래프이다. 게다가 이 그래프는 SVG 파일로 출력할 수도 있다. 뿐만 아니라 condensed bar sequence(왼쪽)나 그래프 어느 것이든 해당 패턴을 클릭하면 재생이 이루어진다.

이어지는 분석 리포트에서는 패턴을 그루브 별로 그룹지어 보여준다. 예를 들어 반복하여 쓰이는 그루브와, 그 그루브의 모든 타격을 그대로 유지하면서 첫 박에 crash 하나만 추가된 패턴이 있다면 두 패턴은 별개의 패턴 ID를 갖게 된다. 그러나 음악적으로 이 둘을 완전히 독립적인 패턴으로 취급하는 것이 과연 합리적일까? 나는 첫 박의 crash가 기존 패턴 위에 부가적으로 얹힌 경우 이를 leading crash ornament로 보고 ORN의 일종으로 취급하려 한다. 원래 ORN은 특정 패턴에만 부속하여 타이밍 보정이나 flam 처리를 위한 것으로 정의하였다. 하지만 leading crash 같은 것은 다른 여러 패턴과 결합하여 사용할 수 있다. 그렇다면 ARR 파일에서 패턴의 레이어링도 허용하는 것이 옳다. 즉 ORN이 더 이상 특정 패턴에 종속된 부가 정보만을 의미하지 않고, 여러 core pattern 위에 재사용할 수 있는 독립적인 modifier vocabulary가 될 가능성이 생긴 것이다.

실은 오랜만에 BFD Player를 열어 보고서 '내가 지금 무슨 하찮은 일을 하고 있는 것인가'하고 한심하게 생각하고 있던 터였다. 상업적으로 만들어진 거대한 드럼 소프트웨어와 내가 취미로 만드는 시스템을 나란히 놓고 보면 당연히 그런 생각이 든다.

어제 업데이트한 BFD Player.

그러나 곰곰이 생각해 보면 내가 추구하는 것은 BFD와 경쟁하는 드럼 소프트웨어를 만드는 일이 아니다. 이미 존재하는 MIDI 음악에서 반복되는 리듬의 어휘를 찾아내고, 그것이 한 곡 안에서 어떻게 변형되고 연결되는지를 분석하여 다시 사용할 수 있는 형태로 만드는 것이 Drum Patternology의 관심사다. 목적이 다르다.

그러니 지나치게 실망할 일은 아니다. BFD가 좋은 드럼 연주를 제공한다면, Drum Patternology는 드럼 연주가 어떻게 조직되어 있는지를 알고 싶어 한다.

디지털 유산의 복원 — 내가 운영하는 깃허브 리포지토리가 6개로 늘어나다

새로 만들어진 sc-d70-win11-driver

'롤랜드 사운드캔버스 SC-D70을 Windows 11에서 제대로 쓸 수 없을까'라는 호기심을 충족하기 위해 약 이틀에 걸친 실험 끝에 성공에 이른 기록을 여섯 번째 리포지토리(sc-d70-win11-driver)에 남겼다. 이 작은 성취에 대해 여러 가지 의미를 부여할 수 있겠다. 무엇보다도 핵심은 드라이버 자체를 전혀 고치지 않았다는 것이다. 내가 그런 깊숙한 곳까지 건드릴 정도의 개발자는 되지 못한다. Vista x64 시절에 작성된 드라이버가 기능적으로 Windows 11과 근본적으로 맞지 않는다거나 하는 등의 문제는 없었다. 단지 Windows 11이 이 '낡은' 코드를 문 앞에서 거절하는 이유를 찾아내고 통과할 수 있도록 신뢰·서명·패키징 조건을 다시 만들어 준 것에 가깝다.

 “바이너리는 아직 기능한다. 최신 OS가 그것을 신뢰하지 않을 뿐이다”

Windows 11에서 나의 SC-D70은 USB 오디오 기기, MIDI 기기로서 정상적으로 동작할 뿐만 아니라 ASIO 검증도 통과하였다. 비록 샘플링 레이트는 48kHz를 넘지 못하지만, 2026년에도 충분히 실용적인 음악 장비임을 보여주었다. UEFI BIOS에서 Secure Boot를 끄고 'bcdedit /set testsigning on' 명령으로 Test Signing을 활성화했으니 Windows의 기본 보안 상태를 약간 낮추었지만, 필요 이상으로 보안을 해제하지 않았다. 즉, 다음의 세 가지 중요한 요소를 모두 만족하고 있다는 것이다.

• 원래 드라이버 코드는 고치지 않았다.
• Windows의 보안 메커니즘을 패치하거나 제거하지 않았다.
• 필요한 범위에서 Windows가 제공하는 테스트 신뢰 체계를 이용했다.

요즘 내가 필요 이상으로 몰두하고 있는 Ardule Drum Patternology와 SC-D70의 Windows 11 드라이버 실험은 얼핏 보기에 관련이 별로 없다. 하나는 오래된 MIDI 파일에서 드럼 패턴을 찾아내 분석하고 추상화하여 다시 사용할 수 있는 형태로 만드는 일이고, 다른 하나는 2000년대 초에 발매된 MIDI 음원 모듈을 최신 운영체제에서 작동하게 만드는 것이다.

그러나 두 작업을 아우르는 공통된 주제는 바로 디지털 유산의 복원(digital heritage restoration)이라고 생각한다. 옛것을 현대적으로 뜯어고치는 것이 아니라, 그 속에 남아있던 생명력을 확인하는 일에 더욱 가깝다. 

디지털 유산의 복원이란 작동하지 않게 된 옛것을 박물관에 전시하거나 수장고에 넣어두는 것이 아니다. 과거의 데이터와 코드가 오늘날에도 다시 의미를 갖고 작동할 수 있도록 그 연결고리를 다시 만들어 나가는 것도 중요한 보존의 방식이다. 낯선 드라이버 서명 체계를 이해하고 실험 절차를 세우거나, 수많은 MIDI 데이터를 분석할 도구를 만드는 과정에서 인공지능은 중요한 조력자가 되었다

새로운 것을 만드는 일도 중요하다. 그러나 사라질 뻔한 것들 속에서 아직 살아 있는 것을 찾아내고, 그것이 다시 움직일 수 있도록 연결해 주는 일도 그에 못지않게 흥미롭다. 그것이 내가 요즘 몰두하고 있는 일이다.

Not planned, just happened.

And only afterward did I realize that I had been restoring digital heritage all along.

Old digital soldiers never die. They just wait to be rediscovered.

Roland SC-D70을 Windows 11에서 다시 살려 보다 (2) — 2007년 드라이버를 2026년에 다시 서명하다

Windows 11 시대에 다시 살아난 롤랜드 사운드캔버스 SC-D70. ChatGPT와 함께 몇 시간 동안 시행착오를 거친 끝에 얻은 결과다.

앞 글에서는 2007년에 배포된 Roland SC-D70용 Windows Vista x64 드라이버가 Windows 11에서도 실제로 동작한다는 것을 확인하였다. Windows의 Driver Signature Enforcement를 일시적으로 해제하고 부팅하면 SC-D70이 정상적으로 인식되었고, MIDI PART A와 PART B는 물론 USB Audio 입출력까지 모두 사용할 수 있었다. 처음에는 Memory Integrity도 꺼야 하는 것으로 생각했으나, 다시 켜고 시험해 보니 그것 역시 문제가 되지 않았다. 결국 드라이버의 기능이나 Windows 11과의 실질적인 호환성보다는 오래된 드라이버의 서명이 현재 Windows의 요구 조건을 충족하지 못하는 것이 문제의 핵심인 것으로 보였다.

그렇다면 다음 실험은 자연스럽게 정해진다. 이 오래된 드라이버를 현대적인 방법으로 다시 서명하면 어떻게 될까? 물론 Roland의 소스 코드를 가지고 있는 것도 아니고 새로운 Windows 11용 드라이버를 작성할 생각도 없다. 여기서 말하는 '새 드라이버'란 기존의 2007년 드라이버 바이너리를 그대로 사용하되, 현재의 Windows Driver Kit(WDK)를 이용하여 새로운 catalog를 만들고 자체적인 테스트 인증서로 다시 서명한 드라이버 패키지를 뜻한다. 이것이 성공한다면 적어도 Windows가 제공하는 test-signing 환경에서는 매번 Driver Signature Enforcement를 일시적으로 해제하지 않고도 SC-D70을 사용할 수 있을 것이다.

19년 된 드라이버를 최신 WDK에 넣어 보다

먼저 Microsoft의 Windows SDK와 WDK를 설치하였다. 이번에 사용한 도구의 버전은 10.0.28000.0이었다. 원본 SC-D70 Vista x64 드라이버는 별도의 작업 디렉터리로 복사하였다. 여기에는 RDIF1012.INF, RDWM1012.SYS, RDID1012.CAT를 비롯하여 제어판과 오디오 기능에 필요한 DLL과 DAT 파일들이 들어 있다. 당연히 원본 파일은 별도로 보존하였다.

가장 먼저 해 본 것은 현재 WDK의 Inf2Cat이 2007년에 만들어진 이 드라이버 패키지를 받아들이는지 확인하는 일이었다. 기존 RDID1012.CAT 파일의 이름을 바꾸어 보관한 뒤 다음과 같이 새로운 catalog를 생성하였다.

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.28000.0\x86\Inf2Cat.exe" `
  /driver:"C:\projects\SC-D70_Win11-TestSigned" `
  /os:10_X64

결과는 의외로 깨끗했다.

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.

2007년의 INF 파일을 특별히 수정하지 않았는데도 현재의 Inf2Cat이 오류나 경고 하나 없이 catalog를 만들어 주었다. 이것만으로 Windows 11에서 정상적으로 사용할 수 있다는 뜻은 아니지만, 적어도 드라이버 패키지의 기본 구조가 현대 WDK에서 거부될 정도로 낡은 것은 아니었다.

테스트 인증서를 만들고 드라이버에 서명하다

다음으로 PowerShell의 New-SelfSignedCertificate를 이용하여 코드 서명용 자체 인증서를 만들었다. 인증서 이름은 단순하게 'SC-D70 Win11 Test Driver'라고 하였다. SHA-256을 사용하였으며, 만들어진 인증서는 Local Machine의 인증서 저장소에 넣고 Trusted Root Certification Authorities와 Trusted Publishers에도 등록하였다. 이것은 어디까지나 개인적인 실험을 위한 test certificate이며 Microsoft나 Roland가 인증한 서명이 아니다.

$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=SC-D70 Win11 Test Driver" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -HashAlgorithm SHA256

여기에서 한 가지 흥미로운 사실을 확인하였다. SignTool로 RDWM1012.SYS를 조사해 보니 이 파일 자체에는 embedded signature가 없었다. 원래의 드라이버 패키지는 catalog의 서명에 의존했던 것으로 보인다. 이번 실험에서는 Memory Integrity를 켠 상태에서도 사용할 수 있는지 확인하고 싶었으므로 SYS 파일 자체에도 테스트 서명을 추가하기로 하였다.

$SignTool = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.28000.0\x64\signtool.exe"

& $SignTool sign /v /fd SHA256 `
  /s My /sm `
  /sha1 $cert.Thumbprint `
  .\RDWM1012.SYS

여기에서는 작업 순서가 중요하다. SYS에 embedded signature를 추가하면 파일 자체가 달라지므로 그 전에 만들어 놓은 catalog에 기록된 해시도 더 이상 맞지 않는다. 따라서 SYS를 먼저 서명하고, 그 상태에서 Inf2Cat을 다시 실행하여 RDID1012.CAT를 새로 만들었다. 마지막으로 이 catalog에도 같은 테스트 인증서로 SHA-256 서명을 하였다.

& $SignTool sign /v /fd SHA256 `
  /s My /sm `
  /sha1 $cert.Thumbprint `
  .\RDID1012.CAT

SignTool의 /pa 옵션으로 SYS와 CAT를 각각 검증한 결과 두 파일 모두 오류 없이 검증되었다. 이로써 원본 드라이버의 코드는 그대로 두면서 2026년에 만든 SHA-256 test signature를 가진 새로운 SC-D70 드라이버 패키지가 만들어졌다. 엄밀히 말하면 새로운 드라이버를 개발한 것은 아니다. 2007년의 드라이버를 현재의 Windows 개발 환경에 맞추어 다시 패키징하고 test-signing한 것이다.

Windows 11을 Test Mode로 부팅하다

이제 실제로 Windows가 이 패키지를 받아들이는지 확인할 차례였다. 여기에는 중요한 대가가 하나 있다. Microsoft가 정식으로 서명한 production driver가 아니므로 Windows의 Test Signing 기능을 사용해야 하고, 이를 위해 이 컴퓨터에서는 UEFI의 Secure Boot를 꺼야 했다. BitLocker가 활성화되어 있다면 UEFI 설정을 변경하기 전에 복구 키 등의 문제를 먼저 확인해야 한다. 내가 실험한 PC의 C: 드라이브에는 BitLocker가 설정되어 있지 않았다.

Secure Boot를 끈 뒤 Windows에서 다음 명령으로 상태가 False임을 확인하였다.

Confirm-SecureBootUEFI

그 다음 관리자 권한의 PowerShell에서 Test Signing을 활성화하였다.

bcdedit /set testsigning on

평범하게 재부팅하자 Windows 11 바탕화면 오른쪽 아래에 Test Mode라는 표시가 나타났다. 이것은 오류 메시지가 아니다. 현재 Windows가 Microsoft의 production signing 정책을 충족하지 않는 테스트 서명 드라이버를 개발 및 시험 목적으로 받아들이도록 설정되어 있음을 나타내는 표시이다. 이 실험에서는 Memory Integrity는 계속 켜 두었다.

마지막까지 순조롭게 진행되지는 않았다

처음에는 이렇게 만든 RDIF1012.INF를 곧바로 pnputil로 설치하였다. 그런데 Windows는 새 드라이버를 설치하지 않았다. 이미 Driver Store에 들어 있던 기존 Roland 패키지와 INF가 사실상 동일하기 때문에 기존 oem76.inf가 이미 설치되어 있고 최신 상태라는 판단을 내린 것이다. 장치 상태를 확인해 보니 여전히 Code 52, 즉 서명 문제를 나타내고 있었고 signer도 여전히 Roland Corporation으로 표시되었다.

해결 방법은 간단했다. SC-D70을 USB에서 분리하고 기존 Roland 패키지를 Driver Store에서 제거한 다음, 우리가 새로 만든 test-signed 패키지를 다시 넣었다. 내 컴퓨터에서는 기존 패키지의 게시 이름이 oem76.inf였으므로 다음과 같이 하였다. 이 oem 번호는 컴퓨터마다 다를 수 있으므로 그대로 따라 쓰면 안 된다.

pnputil /delete-driver oem76.inf /uninstall /force

cd C:\projects\SC-D70_Win11-TestSigned
pnputil /add-driver .\RDIF1012.INF

이번에는 드라이버 패키지가 실제로 새로 추가되었다. 재미있게도 삭제하면서 비어 있던 번호가 다시 사용되어 새 패키지 역시 내 컴퓨터에서는 oem76.inf가 되었다. 따라서 oem 번호 자체가 중요한 것은 아니다. 중요한 것은 Driver Store에 있던 기존 Roland 패키지를 제거하고 새로 test-signing한 패키지가 들어갔다는 점이다.

SC-D70을 다시 연결하고 장치를 검색하였다. 결과는 이번에는 달랐다.

Status  Class          FriendlyName
------  -----          ------------
OK      AudioEndpoint  IN(Roland SC-D70)
OK      MEDIA          Roland SC-D70
OK      AudioEndpoint  OUT(Roland SC-D70)

실제 프로그램에서도 확인하였다. Roland SC-D70 PART A와 PART B가 모두 나타났고 양쪽 포트로 MIDI 데이터를 보내 정상적으로 연주할 수 있었다. MIDI IN/OUT도 사용할 수 있었으며 Windows의 오디오 장치로 SC-D70을 선택했을 때 USB Audio도 정상적으로 재생되었다. 앞 글에서 Driver Signature Enforcement를 일시적으로 해제했을 때 확인했던 기능들이 이번에도 그대로 살아났다.

그냥 재부팅해 보았다

마지막 시험은 단순했다. 아무런 고급 시작 옵션도 선택하지 않고 Windows를 평범하게 재부팅하였다. 앞 글에서 사용했던 Driver Signature Enforcement의 일시적인 해제도 하지 않았다. Windows 11이 다시 올라온 뒤 SC-D70을 확인하였다. 장치는 정상적으로 인식되었고 PART A와 PART B가 모두 보였다. USB Audio도 정상적으로 작동하였다.

결국 성공하였다. 2007년의 RDWM1012.SYS 코드를 수정하거나 새 드라이버를 작성하지 않았다. 원본 SYS에 현대적인 SHA-256 test signature를 추가하고, 그 상태에서 catalog를 다시 만들어 같은 인증서로 서명했을 뿐이다. 그런데 그것으로 2026년의 Windows 11에서 정상적인 재부팅을 거친 뒤에도 SC-D70의 USB MIDI와 USB Audio 기능을 지속적으로 사용할 수 있게 되었다.

물론 이것을 'Windows 11용 정식 SC-D70 드라이버'라고 부를 수는 없다. 현재 PC는 Secure Boot가 꺼져 있고 Windows의 Test Signing이 활성화되어 있다. 바탕화면에도 Test Mode라는 표시가 나온다. Memory Integrity는 켜 놓은 상태로 정상 동작했지만, Secure Boot를 포기하고 테스트 서명 커널 드라이버를 허용하는 것은 일상적인 Windows의 정상 보안 상태와 같지 않다. 따라서 이 설정을 일반 사용자에게 상시 사용하라고 권하기는 어렵다. SC-D70을 가끔 사용하는 경우라면 Secure Boot와 정상적인 서명 정책을 유지하고, 필요할 때만 Driver Signature Enforcement를 한 번의 부팅에 한하여 일시적으로 해제하는 방법이 보안 측면에서는 더 나을 수도 있다.

그래도 이번 실험에서 확인한 사실은 꽤 분명하다. SC-D70이 Windows 11에서 작동하지 않는 이유는 적어도 내가 시험한 범위에서는 드라이버의 기능이 낡아서가 아니었다. 2007년에 만들어진 Vista x64 드라이버는 19년 뒤의 Windows 11에서도 USB Audio와 두 개의 MIDI PART를 제대로 다룰 수 있었다. 최신 WDK의 Inf2Cat도 이 패키지를 오류나 경고 없이 처리하였다. 문제는 오래된 하드웨어나 오래된 코드 자체라기보다는 그 코드를 신뢰할 것인가를 결정하는 현대 Windows의 서명 체계에 있었다.

이제 남은 질문은 기술적인 것이라기보다 제도적인 것에 가깝다. Secure Boot를 다시 켜고 Test Mode도 사용하지 않으면서 이 드라이버를 정상적으로 로드하려면 Microsoft가 신뢰하는 production 수준의 서명이 필요하다. 그러나 이 드라이버는 Roland가 만든 것이므로, 개인적으로 다시 서명하여 시험하는 것과 정식 서명을 받아 공개적으로 배포하는 것은 전혀 다른 문제이다. 실제로 그 단계까지 가려면 Roland의 동의와 Microsoft의 현재 드라이버 서명 절차를 검토해야 할 것이다.

원본 드라이버의 날짜는 2007년 1월 22일이고 버전은 1.0.0.0이다. 2027년이면 이 64비트 드라이버도 20주년을 맞는다. 여기까지 왔으니 20주년을 맞아 정식으로 다시 서명된 SC-D70 드라이버를 볼 수 있다면 재미있겠다는 생각도 든다. 그것이 실제로 가능한지는 아직 모르겠다.

일단 이번 실험의 결론은 이것으로 충분하다. 2007년의 드라이버는 아직 작동한다. 2000년에 출시된 SC-D70도 아직 작동한다. 새로 만들어야 했던 것은 드라이버 자체가 아니라, 2026년의 Windows가 그것을 다시 믿어 볼 수 있도록 해 주는 서명이었다.

으아! ASIO 드라이버도 살아났다. 다음은 Tracktion Waveform Free의 Settings 화면이다. 테스트 버튼을 눌렀을 때 반가운 '삐~' 소리가 남을 확인하였다.

단순히 오래된 커널 드라이버가 간신히 로드된 게 아니라 당시 드라이버 패키지가 제공하던 MIDI + WDM Audio + ASIO라는 상당히 완전한 기능 스택이 Windows 11에서도 살아났다!

앞으로 무엇을 할 것인가

연속하여 작성한 두 편의 글은 내가 실제로 Windows PowerShell에 입력한 명령어와 화면 출력을 충실히 반영하여 만든 step-by-step 가이드는 아니다. 따라서 이 일에 관심을 갖고 재현해 보려는 독자를 위해 보다 친절한 문서를 만들 필요가 있다. GitHub에 나의 여섯번째 리포지토리인 Roland SC-D70 on Windows 11(sc-d70-win11-driver)를 만들고 상세한 설명과 함께 ps1 스크립트를 마련하여 업로드하기 시작하였다.

---

Reviving the Roland SC-D70 on Windows 11, Part 2: Re-signing a 2007 Driver in 2026

The original 64-bit Windows Vista driver for the Roland SC-D70, released in 2007, remains functionally compatible with Windows 11, but its legacy signing no longer satisfies current Windows driver-signing requirements. In this experiment, the original driver binary was left unchanged at the source-code level and given a new SHA-256 test signature using current Windows SDK/WDK tools. A new catalog was generated with Inf2Cat and signed with the same self-signed test certificate. With Secure Boot disabled, Windows Test Signing enabled, and Memory Integrity left enabled, the repackaged driver loaded successfully after an ordinary Windows 11 reboot. Both MIDI PART A and PART B, as well as USB audio input and output, operated normally. This is not a production-signed Windows 11 driver, but the experiment shows that the principal obstacle to using the SC-D70 on current Windows is the modern driver trust and signing policy rather than a fundamental incompatibility of the original 2007 driver code.

Roland SC-D70을 Windows 11에서 다시 살려 보다(1) - 2007년 Vista 64비트 드라이버는 아직 살아 있었다

2020년 8월 31일에 촬영한 나의 롤랜드'ED' SC-D70.

Roland SC-D70은 2000년 무렵에 출시된 Sound Canvas 계열의 사운드 모듈이다. 단순한 MIDI 음원 모듈을 넘어 USB를 통한 MIDI와 디지털 오디오 입출력을 함께 지원한다. 특히 USB MIDI로 연결하면 PART A와 PART B라는 두 개의 독립적인 MIDI 포트를 사용할 수 있으므로 32파트 멀티팀버 음원으로 활용할 수 있다.

문제는 세월이다. SC-D70은 이미 20년을 훌쩍 넘긴 장비이고 Roland가 제공했던 Windows용 드라이버 역시 오래전에 지원이 끝났다. 최근에는 DIN MIDI 단자를 별도의 USB-MIDI 인터페이스나 구형 키보드 컨트롤러에 연결하여 SC-D70을 사용하고 있었다. 이 방법으로도 일반적인 MIDI 음원으로 사용하는 데에는 별 문제가 없지만 USB 직결에 비하면 몇 가지 불편함이 있다. PART A에만 접근하게 되어 SC-D70의 32파트 기능을 온전히 활용하기 어렵고, 전원을 켤 때 버튼을 동시에 눌러 MIDI 모드로 전환해야 하는 번거로움도 있다. 흥미로운 것은 Linux에서는 SC-D70을 USB로 연결하는 데 별 문제가 없다는 점이다. 그렇다면 Windows 11에서도 어떻게든 USB 기능을 되살릴 수 있지 않을까?

사실 2022년에도 비슷한 일을 했었다

나는 2022년 4월에 이미 SC-D70을 다시 꺼내 Windows 10에서 사용해 본 기록을 남겨 놓았던 것이다(음악 작업 환경 바꾸기 (2022년 4월 26일)). 당시 글에는 Vista 64비트용 드라이버를 이용하여 Windows 10에서 SC-D70의 녹음과 재생이 정상적으로 작동했다고 적어 놓았다. 당시에는 특별한 문제 없이 설치가 되었었던 것으로 기억한다. 그러나 Windows 11이 되면서 이 드라이버는 설치는 되지만, 강화된 드라이버 서명 정책 때문에 정상적으로 로드되지 않는다.

Vista x64용 원본 드라이버를 다시 구하다

조사해 보니 Roland가 과거 배포했던 SC-D70의 Windows Vista 64비트용 드라이버가 존재했다. 파일 이름은 SC-D70_win_vista_x64.zip이고 버전은 1.0.0.0, 날짜는 2007년 1월 22일이다. 놀랍게도 이 오래된 드라이버 파일은 2026년 현재에도 Roland의 서버에서 직접 다운로드할 수 있다.

현재 다운로드되는 URL은 다음과 같다.

http://lib.roland.co.jp/support/en/downloads/res/1812426/SC-D70_win_vista_x64.zip

주의할 점은 HTTPS가 아니라 HTTP를 사용해야 한다는 것이다. https://로 시작하는 주소로는 다운로드되지 않았지만, http:// 주소로 접속하면 원본 ZIP 파일을 정상적으로 내려받을 수 있었다. 압축을 풀어 보니 INF, SYS, CAT 파일은 물론 ASIO 관련 DLL과 Control Panel까지 들어 있는 완전한 드라이버 패키지였다.

INF 파일에는 SC-D70의 USB hardware ID인 USB\VID_0582&PID_000C가 명시되어 있었고, 더욱 흥미로운 것은 MIDI 포트 정의였다.

Roland SC-D70 PART A
Roland SC-D70 PART B
Roland SC-D70 MIDI OUT

Roland SC-D70
Roland SC-D70 MIDI IN

즉 SC-D70의 USB 연결에서 제공되던 PART A와 PART B 기능이 원래 Windows 드라이버 안에 그대로 들어 있었다. 새로운 Windows 11용 MIDI 드라이버를 처음부터 만드는 것보다 이 드라이버를 어떻게든 다시 실행시키는 것이 훨씬 합리적인 접근으로 보였다.

Windows 11에 원본 드라이버를 설치하다

Windows 11의 관리자 권한 PowerShell에서 다음과 같이 드라이버를 설치했다.

pnputil /add-driver RDIF1012.INF /install

뜻밖에도 설치 자체는 아무 문제 없이 이루어졌다. Windows 11은 이 오래된 INF를 받아들였고 Driver Store에 정상적으로 추가했으며, 실제로 연결된 SC-D70에도 해당 드라이버를 연결했다.

드라이버 패키지를 추가했습니다.
게시된 이름: oem76.inf
드라이버 패키지가 장치에 설치됨: USB\VID_0582&PID_000C\...

그러나 장치 상태는 Error였다. 처음 확인했을 때에는 Problem Code 39 (CM_PROB_DRIVER_FAILED_LOAD)와 0xC000007B가 나타났다. 드라이버 패키지를 설치하고 장치에 연결하는 데까지는 성공했지만 실제 커널 드라이버가 로드되지 않은 것이다.

Memory Integrity와 오래된 드라이버

Windows 11에는 Memory Integrity, 즉 메모리 무결성이라는 보안 기능이 있다. 이는 HVCI(Hypervisor-protected Code Integrity)의 사용자 인터페이스 이름으로, 가상화 기반 보안 기능을 이용하여 커널에서 실행되는 코드의 무결성을 보호한다. 2007년에 만들어진 드라이버는 이런 현대적인 Windows 보안 환경을 고려하지 않았으므로 이것이 원인일 가능성을 확인해 보기로 했다.

Windows 보안의 장치 보안 → 코어 격리 → 메모리 무결성을 시험적으로 끄고 재부팅하였다. 그러자 오류의 형태가 달라졌다.

Problem Code: 52
CM_PROB_UNSIGNED_DRIVER

Problem Status: 0xC0000428

이번에는 원인이 훨씬 명확하게 드러났다. 오래된 Roland 드라이버의 디지털 서명을 현재 Windows가 커널 드라이버용으로 받아들이지 않는 것이었다. 중요한 것은 Memory Integrity를 끄는 것만으로는 SC-D70이 작동하지 않았다는 것이다. 보안 설정을 하나 낮추었음에도 드라이버는 여전히 Code 52 상태였다.

드라이버 서명 적용을 한 번만 해제해 보다

다음으로 Windows의 고급 시작 옵션을 이용하였다. 명령 프롬프트 또는 PowerShell에서 shutdown /r /o /t 0을 실행하면 Windows 복구 시작 화면으로 들어갈 수 있다. 그 뒤 문제 해결 → 고급 옵션 → 시작 설정 → 다시 시작을 선택하고 7번: 드라이버 서명 적용 사용 안 함(Disable Driver Signature Enforcement)을 선택하였다. 이 설정은 영구적으로 Windows 보안을 변경하는 것이 아니라 해당 부팅 세션에서만 적용되는 임시 옵션이므로 다음에 정상적으로 재부팅하면 원상 복구된다.

SC-D70이 살아났다

Windows가 다시 올라온 뒤 장치 상태를 확인했더니 이번에는 완전히 정상 상태였다.

OK   MEDIA          Roland SC-D70
OK   AudioEndpoint  IN(Roland SC-D70)
OK   AudioEndpoint  OUT(Roland SC-D70)

MIDI 프로그램을 실행하여 포트를 확인하니 출력에는 Roland SC-D70 PART A, Roland SC-D70 PART B, Roland SC-D70 MIDI OUT의 세 포트가 나타났고 입력 쪽에도 SC-D70의 MIDI 포트가 정상적으로 나타났다. 가장 중요한 PART A와 PART B를 각각 시험해 보았는데 둘 다 정상적으로 작동하였다. 따라서 DIN MIDI를 통한 우회 연결에서는 사용할 수 없었던 SC-D70의 두 MIDI 포트를 Windows 11에서 USB 연결로 온전히 사용할 수 있게 되었다. 즉 32파트 MIDI 기능이 다시 살아난 것이다.

SC-D70의 두 파트가 전부 보인다(MidiEditor).

USB Audio도 정상 작동한다

MIDI만 되는 것도 아니었다. Windows의 사운드 설정을 열어 보니 SC-D70이 정상적인 오디오 장치로 나타났고, OUT(Roland SC-D70)을 Windows의 출력 장치로 선택하여 실제 오디오를 재생해 보니 소리가 정상적으로 출력되었다. 따라서 이번 실험으로 확인한 것은 단순한 USB MIDI 호환성 정도가 아니다. 2007년의 Windows Vista x64용 Roland SC-D70 드라이버가 Windows 11에서 실제로 로드되었고, USB MIDI와 PART A/B를 통한 32파트 MIDI는 물론 Windows USB Audio 출력까지 정상적으로 작동하였다. USB Audio IN/OUT endpoint도 정상적으로 생성되었다. ASIO와 실제 Audio Input 녹음 기능은 아직 별도로 시험하지 않았다.

USB Audio로 작동하는 모습. 유튜브에서 래리 칼튼의 'Smiles And Smiles To Go'를 재생하고 있다.

드라이버가 낡았다기보다 서명이 낡았다

이번 실험에서 가장 재미있는 점은 여기에 있다. 처음에는 오래된 SC-D70을 Windows 11에서 사용하려면 새로운 USB MIDI 드라이버를 만들어야 할지도 모른다고 생각했다. 그러나 실제로는 그렇지 않았다. 2007년에 만들어진 64비트 Roland WDM 드라이버 자체는 Windows 11에서도 여전히 동작한다. 적어도 이번 실험에서 확인한 직접적인 장애물은 드라이버 코드 자체의 호환성보다는 오래된 디지털 서명과 현대 Windows의 커널 드라이버 서명 정책이었다.

처음에는 Memory Integrity를 끈 상태에서도 서명 오류 때문에 드라이버가 로드되지 않았고, 그 상태에서 Driver Signature Enforcement까지 일시적으로 해제했을 때 비로소 드라이버가 정상적으로 로드되었다. 여기까지만 놓고 보면 Memory Integrity와 드라이버 서명 검사를 모두 해제해야 하는 것처럼 보일 수도 있었다. 그러나 두 보안 기능 중 어느 것이 실제 장애물인지 구분하려면 변수를 하나 더 분리할 필요가 있었다.

Memory Integrity를 다시 켜고 시험하다

그래서 추가 실험을 하였다. Windows 보안에서 Memory Integrity를 다시 ON으로 설정하고 정상적으로 재부팅하여 이 보안 기능을 원상복구하였다. 그 다음 다시 Windows의 고급 시작 옵션으로 들어가 Driver Signature Enforcement만 이번 부팅에 한하여 해제하였다. 즉 이번에는 Memory Integrity ON + Driver Signature Enforcement OFF라는 조건이었다.

결과는 예상보다 좋았다. SC-D70은 아무런 오류 없이 정상적으로 올라왔고 PowerShell에서 확인한 관련 장치는 모두 OK 상태였다.

OK  MidiEndpoint    Roland SC-D70
OK  SoftwareDevice  Roland SC-D70
OK  SoftwareDevice  Roland SC-D70 MIDI IN
OK  SoftwareDevice  Roland SC-D70 PART A
OK  SoftwareDevice  Roland SC-D70 PART B
OK  SoftwareDevice  Roland SC-D70 MIDI OUT
OK  AudioEndpoint   IN(Roland SC-D70)
OK  MEDIA           Roland SC-D70
OK  AudioEndpoint   OUT(Roland SC-D70)

MIDI 프로그램에서도 PART A와 PART B가 모두 그대로 나타났으며 실제 MIDI 재생도 정상적으로 이루어졌다. Windows의 USB Audio 역시 문제없이 작동하였다. 따라서 Memory Integrity는 이 오래된 SC-D70 드라이버의 동작을 방해하지 않는다는 사실을 실제로 확인할 수 있었다. 적어도 이 시스템에서 SC-D70을 사용하기 위해 Memory Integrity를 끌 필요는 없다.

Memory Integrity는 계속 켜 두어도 된다

이 결과는 보안 측면에서도 반가운 일이다. Memory Integrity는 단순히 오래된 드라이버를 귀찮게 검사하는 옵션이 아니다. Windows의 가상화 기반 보안 기능을 이용하여 커널 영역에서 허가되지 않은 코드가 실행되거나 커널 메모리가 변조되는 것을 어렵게 만드는 보호 기능이다. 이를 끈다고 해서 컴퓨터가 곧바로 위험한 상태가 되는 것은 아니지만, Windows가 제공하는 중요한 커널 수준의 방어층 하나를 제거하는 것은 분명하다.

처음에는 문제를 진단하기 위해 Memory Integrity를 잠시 껐지만 결과적으로 그럴 필요가 없다는 것을 확인하였다. Memory Integrity를 다시 활성화한 상태에서도 SC-D70의 USB MIDI와 USB Audio는 모두 정상적으로 작동한다. 따라서 이 설정은 계속 ON으로 유지하면 된다. 반면 현재 SC-D70의 동작 여부를 결정하는 것은 Driver Signature Enforcement였다. 이것을 일시적으로 해제했을 때 드라이버가 정상적으로 로드되었고, 다시 정상 부팅하면 서명 검사가 자동으로 활성화되어 구형 드라이버가 다시 차단될 것으로 예상된다.

결국 남은 문제는 하나

이제 문제는 상당히 단순해졌다. 하드웨어 호환성 문제도 아니고, Vista 시대의 64비트 WDM 드라이버가 Windows 11에서 실행되지 않는 것도 아니며, Memory Integrity와의 충돌도 아니었다. 남은 장애물은 2007년 Roland 드라이버의 디지털 서명을 현재 Windows 11이 정상적인 커널 드라이버 서명으로 받아들이지 않는다는 것이다.

현재 사용한 Disable Driver Signature Enforcement는 기술적인 검증에는 훌륭하지만 일상적인 해결책은 아니다. 이 설정은 해당 부팅 세션에만 적용되므로 SC-D70을 사용할 때마다 Windows 복구 메뉴로 들어가 이를 선택해야 한다. 그렇다고 Windows 전체를 Test Mode로 사용하는 것도 썩 만족스러운 해결책은 아니다.

따라서 다음 과제는 더욱 명확해졌다. Memory Integrity를 포함한 Windows 11의 정상적인 보안 기능은 가능한 한 그대로 유지하면서, 2007년 Roland SC-D70 드라이버를 정상 부팅에서도 지속적으로 사용할 방법을 찾는 것이다. 현재의 방법으로는 SC-D70을 사용할 때마다 Windows의 고급 시작 옵션으로 들어가 Driver Signature Enforcement를 일시적으로 해제해야 한다. 드라이버 자체가 Windows 11에서 정상적으로 동작한다는 사실은 확인했으므로, 이제 남은 질문은 이것이다. 2007년의 원본 드라이버 코드는 그대로 두고 현대적인 방법으로 다시 서명한다면, 이런 일회성 부팅 절차 없이도 SC-D70을 사용할 수 있을까?

그러나 오늘 확인한 것만으로도 충분히 재미있는 결론을 내릴 수 있다. 2000년에 출시된 Roland SC-D70은 2026년의 Windows 11에서도 USB MIDI와 USB Audio로 잘 작동한다. PART A와 PART B를 모두 사용할 수 있고 Windows의 USB Audio 출력도 정상적으로 동작한다. 더구나 추가 실험을 통해 Memory Integrity를 끌 필요조차 없다는 것도 확인하였다. 하드웨어가 죽은 것도 아니었고, 19년 된 Vista용 드라이버가 완전히 쓸모없어진 것도 아니었다. 드라이버의 코드보다 그동안 Windows의 문지기가 훨씬 엄격해졌을 뿐이다.

그렇다면 여기까지 온 김에 한 걸음 더 가 보기로 했다. 최신 Windows Driver Kit를 이용하여 이 오래된 드라이버를 다시 패키징하고 test-signing한다면 어떻게 될까? SC-D70은 아직 은퇴할 때가 아니다. 물론 리눅스에서는 이야기가 달라진다. USB 케이블만 꽂으면 최신 리눅스에서도 잘 작동하기 때문이다

이 실험은 다음 글에서 계속한다.

---

Reviving the Roland SC-D70 on Windows 11: A 2007 Vista x64 Driver Still Works

The Roland SC-D70, introduced around 2000, provides both USB MIDI and digital audio interfaces, including two independent MIDI ports, PART A and PART B, for 32-part multitimbral operation. Although official Windows support for the device ended many years ago, an original Roland Windows Vista x64 driver (version 1.0.0.0, dated January 22, 2007) was tested on Windows 11 in 2026. Windows 11 successfully installed and associated the driver with the SC-D70 but refused to load it normally because of current kernel driver-signing requirements. When Windows was booted once with Driver Signature Enforcement temporarily disabled, the original driver loaded successfully. Both PART A and PART B were fully functional, and USB audio playback also worked normally. A further test showed that the same MIDI and audio functions continued to work with Windows Memory Integrity enabled, demonstrating that Memory Integrity itself does not need to be disabled for this legacy driver. The remaining obstacle is therefore the acceptance of the driver's 2007 digital signature under the current Windows 11 kernel driver-signing policy, rather than fundamental incompatibility with the hardware, the driver code, or Memory Integrity. The next challenge is to find a practical way to load the original driver during normal Windows startup while retaining the standard security configuration of Windows 11.

약간의 독서 기록

 

케어리스 피플 - 책임, 공감, 원칙이 사라진 거대 플랫폼 기업의 세계 

이 책의 저자인 새라 윈윌리엄스는 뉴질랜드 출신의 메타(구 페이스북) 전직 임원이다. 이 책은 메타 내부의 권력과 위선적 이면을 강력히 고발한 용기 있는 책이다. 전 직장에서 있었던 일에 대해서 이렇게 상세하게 내부 고발을 하고 있으니 당연히 메타 측으로부터 소송이 들어올 것을 예상하고 쓴 것일게다. 세상을 연결하여 개방과 협력을 끌어내겠다는 멋진 표어가 있지만 어디까지나 기업은 기업이다. 테크 기업의 막대한 영향력 아래 어려움을 당하는 사람이라든가 사측의 무리한 요구로 힘들게 일하는 내부 직원들에게는 소홀하고 부주의한 사람들, 그게 바로 이 책의 제목이다.

정책은 왜 실패하는가 - 대한민국 정책 생태계의 민낯과 가능

실패를 최소화하는 정책 설계의 4대 기준(380쪽)은 다음과 같다.

1. 바람직함(Desirability)
2. 현실성(Feasibility)
3. 지속 가능성(Sustainability)
4. 수용성(Acceptability)

어제 있었던 '칼자루를 쥔 사람들과의 회의'에서도 희망을 읽을 수 없었다. '교수'라는 강력한 민원인 앞에 우리는 늘 무력하다. 우리는 그 민원인들과 한자리에서 현실성과 지속 가능성 등을 놓고 논쟁할 기회조차 갖지 못한다. 대신 칼자루를 쥔 사람이 민원사항을 전달하며 우리를 죄인 취급할 뿐이다. 수행 주체인 우리는 항상 해명이나 자아비판을 해야 한다. 걸핏하면 감사 받을 각오를 하라는 말을 들으며 일을 하고 싶지는 않다.

정책 설계의 블랙박스 안에는 누가 계신가요?(288쪽)

광장 비판 - 민주주의에 대해 우리가 말하지 않는 것

Ardule의 중심이 된 두 대표 도구: MIDI Player와 Drum Studio

Ardule Drum Patternology 프로젝트를 진행하면서 많은 도구를 만들고 개선하여 왔다. 무엇보다도 중요한 일은 제대로 된 이름을 붙이는 것이다. 개별 스크립트의 이름, 프로젝트를 대표하는 이름... 무엇 하나 가볍게 생각할 수 없었다.

이제는 다음의 두 가지 도구를 대표 자격으로 내세우기로 마음먹었다. 

Ardule MIDI Player는 Standard MIDI File을 재생하면서 채널별 연주와 드럼 롤을 웹 GUI에서 확인할 수 있는 프로그램이다. 별도의 Python 환경을 준비할 필요 없이 Windows용 배포 파일(v0.1)을 내려받아 바로 실행할 수 있도록 FluidSynth와 General MIDI 호환 SoundFont까지 함께 묶었다.

Ardule Drum Studio는 드럼 패턴을 보고, 듣고, 편집하는 self-contained HTML 도구(v0.4.6)이다. HTML 파일 하나만 내려받아 웹브라우저에서 열면 되며, 스마트폰에서도 쉽게 실행이 된다. 44개의 기본 패턴이 들어 있으며, Ardule에서 정의한 ADT(Ardule Drum Text) 패턴과 ORN sidecar 파일도 불러올 수 있다. 패턴을 이어붙여 곡 단위로 만드는 것도 가능하다. 

출처: https://github.com/jeong0449/Ardule

두 프로그램은 모두 웹 GUI로 작동하며, 설치 절차가 번거롭지 않다. 즉, 파이썬 인터프리터나 FluidSynth 및 사운드폰트 파일을 사용자가 별도로 설치하지 않아도 된다. 

프로그램의 완성도를 높인 것에 그치지 않고 GitHub의 문서도 그에 맞추어 체계화하였으며, 실제 작동 모습을 보여주는 소개 영상도 유튜브에 올렸다(링크). 그동안 만들어 온 분석 스크립트, ADT/ADP/ORN 포맷, 패턴 컬렉션 등의 결과물이 이제 조금씩 하나의 'Ardule 드럼 패턴학' (Ardule Drum Patternology)이라는 생태계 안에서 자리를 잡아 가는 느낌이다.

이렇게 함으로써 다른 사람에게 내가 무엇을 만들고 있는지  복잡한 설명 없이 화면(심지어 휴대폰 화면으로!)과 한두 문장으로 쉽게 설명할 수 있게 되었다.

깨지지 않는 원칙은 없다

오늘도 '드럼 패턴학' 이야기를 조금 더 해보려 한다. 그저께까지 만든 분석용 스크립트가 완벽하고, 그것을 이용해서 어제까지 매만진 패턴은 다시는 고칠 일이 없을 것이라고 생각했었다. 그러나 그러한 기대는 몇 시간 가지 않는다. 새로운 아이디어가 계속 샘솟는 것이 아니라 바라볼수록 부끄러운 구석이 눈에 뜨인다. 

"도저히 이대로 놔 둘 수가 없다!"

그래서 스크립트를 고치고, 데이터 뭉치를 다시 처리하기를 반복한다. 스크립트는 오류가 줄어들고 새로운 기능을 품는 것으로 끝나지 않고 아예 인수(argument) 체계가 다시 세워진다. 예를 들어 작업 대상 파일 하나를 인수로 제공하였다가 이제는 아예 디렉토리를 통째로 제공하는 것이다. 이렇게 함으로써 파워셸 수준에서 반복문을 돌릴 필요가 없게 되었다.

드럼 패턴 분석 작업의 제1원칙은 MIDI 원본 데이터는 손을 대지 않는 것이었다. 분할 후 추상화를 거치지만 타이밍 정보는 절대 손을 대지 않으려고 하였다. 특히 드럼 머신용 패턴이라는 이름으로 돌아다니는 MIDI 파일은 완벽할 것으로 기대했었다. 그러나 꼭 그렇지만도 않았다. 노트 단위로 그리드에서 벗어나는 것이 있어서 눈물을 머금고 tick을 가감하여 그리드에 맞추는 일이 벌어졌다. 

Flam을 처리하는 일은 한층 더 어려웠다. 1 마디 16 스텝, 즉 16분음표 간격으로 노트를 나열하는 체계에서 만나는 grace note는 거의 대부분 스텝을 32로 세분하면 정상적인 음표처럼 취급할 수 있다.

그러나 이렇게 패턴을 잘게 나누니 그리드 위에 표시하면 장식음 + 주 음표의 관계가 선명하게 드러나지 않는다. PDF 파일로 돌아다니는 원전이 있어서 'F'로 표기된 flam을 명확히 파악할 수 있었고, 스크립트 수준에서 이를 자동으로 검출하게 만드느라 무척 애를 먹었다. 

드럼 패턴 책자를 옮겼다는 MIDI 파일도 혹시 '제작자'의 실수가 있었던 것은 아닐까하는 생각이 들 때가 있다. 위에서 보인 그림 중 왼쪽의 악기명을 살펴보면 심벌에 해당하는 것의 약어는 CY-C이다. Crash 심벌이라는 의심이 들지만, 실제 MIDI 파일엣는 ride로 바뀌어 있었다. 마디 시작 위치에서 한번 타격하는 것은 ride보다 crash가 더 어울린다. 하지만 그렇다고 하여 이를 MIDI로 'transcription'한 결과물이 명백히 틀렸다고 볼 수도 없는 노릇이 아닌가. 그래서 그냥 두기로 했다.

원칙을 잘 수립하고, 침습 또는 비침습척 처리를 하는 경계를 잘 기록해 두며, 모든 것을 자동화에 맡기지 말고 반드시 눈이나 귀로 확인하는 버릇을 들이는 것. 그것이 신뢰할 수 있는 데이터를 만드는 과정이다.