요약
잘 알려지지 않은 코덱 ULC 덕분에 N64에서도 Opus에 가까운 음질을 적은 연산으로 낼 수 있습니다.
개발자 도미니크 샤블레프스키(phoboslab)가 오픈소스 N64 개발 도구 libdragon에 ULC 디코더를 옮긴 과정을 정리했습니다. 자기 게임 Xibalba 64에서 32MB 롬 가운데 31MB를 소리와 음악이 차지한 경험이 출발점이었습니다.
왜 중요한가
- 카트리지 용량에 묶였던 N64 자작 게임이 긴 음악과 많은 효과음을 함께 담을 수 있게 됩니다.
- 실제로 Half-Life N64 이식판은 효과음 2,500개와 음악 27곡을 ULC로 압축해 64MB 카트리지 하나에 넣었습니다.
- 기존 선택지는 용량이 큰 ADPCM과 게임 중에 쓰기엔 느린 Opus뿐이었는데, 그 사이를 메웁니다.
핵심 내용
- 44.1kHz 스테레오 곡 하나를 재생하는 데 CPU 시간 약 4%, RSP(N64의 벡터 보조 프로세서) 시간 약 5%가 듭니다.
- 음질과 비트레이트는 Opus에 가깝고, 연산량은 ADPCM의 4배 정도에 그칩니다.
- ULC는 MDCT(소리를 주파수 성분으로 바꾸는 변환) 계수를 압축 부호 없이 4비트 단위로 저장해 해독이 단순합니다.
- RSP의 4KB 데이터 메모리에 맞추려고 16비트 고정소수점과 1,024샘플 블록을 골랐고, 큰 소리에서 희미한 잡음만 남았습니다.
- Codex로 C 코드를 RSP용 언어로 조금씩 옮기며 검증했고, 결과물은 libdragon 미리보기 브랜치에 들어갔습니다.
HN 반응
- 당시 코덱 분야는 특허 지뢰밭이라 1999년이었다면 쓰기 어려웠을 것이라는 개발 경험담에, 영상 코덱은 지금도 그렇다는 지적이 이어졌습니다.
- LLM을 썼다는 대목에 실망했다는 반응이 나오자, 코드 변환에 쓴 것이 무슨 문제냐는 반론이 맞섰습니다.
이 코덱이 27년 전에 나왔다면 정말 좋았을 겁니다! 다만 1999년이었다면 특허 변호사들을 통과하지 못했을 것 같습니다. 지금 보면 귀여워 보이지만, 당시 코덱 분야 전체가 특허 지뢰밭이었습니다. N64용 mp3 디코더는 두 번 구현됐는데(한 번은 레퍼런스 코덱 기반, 한 번은 클린룸 방식), 닌텐도/레어는 래드 게임 툴스(RAD Game Tools)에 돈을 내고 그쪽 디코더 라이선스를 받았습니다... 그쪽 코드는 하나도 쓰지 않았지만, 래드가 mp3 특허권자(프라운호퍼)의 라이선스를 갖고 있어서 닌텐도가 소송으로부터 보호받을 수 있었죠. 프라운호퍼에 직접 라이선스를 받으려면 25만 달러쯤 요구했는데, 그건 말도 안 되는 금액이었습니다.
그리고 콘커의 프레임레이트 문제는 대부분 RDP 필레이트 자체의 한계 때문이었다는 점도 짚어 두겠습니다. N64 하드웨어에서 단연 가장 약한 부분이었죠. (당시 기준으로) 아름다운 삼각형을 그릴 수는 있었지만 정말정말 느렸습니다. 게임 플레이 중에도 음성이 꽤 많이 나왔고, RSP mp3 코덱을 썼습니다. 카트리지 용량은 여전히 문제였습니다. 64Mb로 모노 음성을 상당히 담을 수 있었지만, 그래도 한 비트가 아쉬운 형편이었습니다.
오디오에서야 그럴지 몰라도, 비디오는 여전히 완전 악몽 같아요. 윈도에서 h265 영상을 재생하려고 0.99달러를 내야 하는 어처구니없는 상황만 봐도 그렇잖아요.
AV1은 로열티가 없고 더 좋습니다!
실제 사례를 들겠습니다. ATSC 안테나로 월드 시리즈를 녹화한 뒤, 32스레드 znver5 머신에서 90초 분량 샘플을 여러 설정으로 다시 인코딩해 봤습니다.
(참고: 같은 CRF라도 느린 프리셋일수록 화질이 더 좋습니다. 보관용이라 가장 느린 축에 속하는 프리셋을 썼습니다.)
(1)과 (2)는 프레임을 하나하나 넘겨 가며 순간적인 움직임 아티팩트를 찾지 않는 한 원본과 구분이 안 됩니다. (3)은 어두운 배경이 뿌옇게 날아간 한 장면에서만 구분됩니다. AV1은 H265만큼 좋은 결과를 낼 뿐 아니라, 같은 크기와 화질 기준으로 인코딩도 꽤 더 빠릅니다.
다만 지난 10년간 h264로 인코딩된 영상을 워낙 많이 봐서, 은은한 "눈송이 노이즈"를 고화질의 신호로 받아들이도록 길들여진 것 같습니다. 객관적으로는 더 충실한 화질이라고 생각하는데도, AV1이 배경을 뭉개듯 섞는 방식이 H265의 디더링보다 눈에 더 거슬립니다. 인생 전반부를 NTSC TV로 보낸 탓에 고프레임레이트 영상이 "가짜"처럼 느껴지는 것과 비슷합니다.
더 빠른 프리셋의 libx265로 같은 시각적 품질을 얻는 데 필요했던 CRF와 그때의 결과 크기는 다음과 같습니다.
그래도 공짜로 구할 수 있어요: https://www.free-codecs.com/guides/how_to_download_hevc_video_extension_for_free.htm
예전에는 윈도에서 공짜로 받을 수 있었는데[0] 지금은 안 되는 것 같네요.
물론 VLC는 언제나 있고요.
0: https://apps.microsoft.com/detail/9n4wgh0z6vhq
저는 가장 약한 부분이 텍스처 버퍼 크기라고 생각했는데요.
아무도 N64가 올 줄은 몰랐겠죠! 저희의 가장 약한 부분은 두 가지, 바로 RDP 필레이트와 코딱지만 한 텍스처 버퍼예요.
좋아요, 성능 측면에서는 RDP 필레이트가 가장 큰 문제였습니다. 아티스트에게는 텍스처 버퍼가 엄청난 난관이었고요.
RDP 클럭이 4배 빠르고 텍스처 크기가 4배였다면 정말 대단했을 겁니다... 예쁜 픽셀을 만들어 내거든요!
램버스 DRAM 지연 시간도 큰 문제였다고 들었는데, 그게 필레이트에도 영향을 줬나요? 아니면 주로 CPU에 병목을 일으킨 건가요?
그리고 메모리 대역폭도요. 저희의 가장 약한 부분은 세 가지, RDP 필레이트, 코딱지만 한 텍스처 버퍼, 쥐꼬리만 한 메모리 병목... 그리고 디버그 모드 컴파일... 저희의 네 가지... 아니... 저희의 가장 약한 부분 중에는... 이런 요소들이... 다시 들어올게요.
N64를 너무 높은 데서 내려다보며 깎아내리진 마세요. PC 하드웨어에서는 2년이 영겁이던 시절에 1998년(그리고 2026년)의 실시간 렌더링 개념들을 들여왔잖아요.
그래서 요즘 프로그래머들이 N64로, 1996년에 존 카맥이 해냈다면 밤잠을 설쳤을 법한 일들을 해내는 거죠.
데모에 들어가 보고 음질이 끔찍하다고(보컬이 알아들을 수 없고 계속 끊긴다고) 생각하신 분이 계실 텐데, 알고 보니 원곡이 원래 그렇습니다:
https://www.youtube.com/watch?v=i1gVxKhdGPs&t=57s
좋은 지적입니다! 영상을 교체했습니다.
처음엔 저도 헷갈렸는데, 압축 시연용으로는 정말 안 좋은 곡을 골랐다는 걸 알았어요.
음악 취향 자체를 말하는 게 아니라, A/B 테스트하기 쉽게 좀 더 잘 알려진 곡을 골랐어야 한다는 거예요.
수잰 베가의 Tom’s Diner가 멋진 선택이었을 거예요. MP3 압축 알고리즘을 개발하는 동안 평가하고 다듬는 데 쓰인 곡이니까요.
이게 MAS3507D에도 딱 맞지 않을까 궁금합니다! 1킬로워드 RAM에 직접 만든 프로그램으로 교체할 수 있다고 하더라고요(기본 MP3 디코더는 ROM에 들어 있고 아마 더 클 겁니다). 이 코덱을 MIPS 명령어 1024개에 넣을 수 있다면, 이 DSP 명령어 1024개로도 가능할지 모르죠…
아쉽게도 이 프로그램들의 형식에 관한 공개 문서가 사실상 전혀 없네요(에뮬레이터 같은 것도 없고요).
LLM 사용을 언급하기 전까지는 다 좋았는데요.
데모씬과 홈브루 씬은 지금 이 순간에도 죽어 가고 있어요.
아니요, 안 죽어요. 다만 AI 찬성파와 반대파로 갈라지고 있을 뿐이죠.
생각해 보세요. 2019년에 누가 데모에 GPT-2를 넣었다면 같은 씬에서 배꼽을 잡고 웃었을 거예요. 문제는 AI가 아니라 우리가 AI를 쓰는 방식이고, 다들 AI에 질려 버렸다는 거죠.
코드를 트랜스파일하는 데 LLM을 쓴 게 그렇게 큰 죄인가요?
잘 읽었습니다, 감사합니다!
무지를 양해해 주시고, 궁금한 게 하나 있습니다. 디코더가 4k짜리 RSP 명령어 메모리(IMEM)를 거의 다 채운다면, 게임이 그래픽 처리에 그 공간을 써야 하지 않나요? 그렇다면 예컨대 게임에서도 이걸 쓸 수 있는 건가요?
DMEM처럼 IMEM도 언제든 교체할 수 있습니다. 이 경우 음악 한 블록 처리를 마치면 3D 변환이든 다른 무엇이든 그 코드를 RSP로 DMA 하면 됩니다.
Libdragon이 큐[1]로 이 과정을 알아서 처리해 줍니다.
[1] https://libdragon.dev/ref/rspq_8h.html
멋지네요! 오래전부터 오디오 코덱을 직접 만들어 보고 싶었는데, 이게 좋은 도전이 될 것 같아요.
Top Gear Overdrive(1998)가 MP3 트랙을 쓰지 않았나요? 그라인드스톤의 곡이 여러 개 있어서 레이스 중에 흘러나왔는데요. 음질이 아주 좋지는 않지만 가사는 대체로 알아들을 수 있어요.
https://www.youtube.com/watch?v=kyXsWd7DpEs
Wipeout 64에는 플루크와 프로펠러헤즈의 음악이 있었는데, 제가 알기로 짧은 녹음본으로 트랙을 재구성하는 트래커 포맷을 썼던 걸로 거의 확실해요. 솔직히 소리가 끔찍한데, 음질 때문만이 아니라 반복적이고 전개가 없어서이기도 해요.
죄송한데 뭐라고요? N64에서 Half-Life라니?? 엄청나 보이는데요!
최근 N64 포트가 폭발적으로 늘고 있습니다. 새 라이브러리(libdragon), 순수한 팬들의 열정, 그리고 LLM의 도움이 한데 어우러진 결과죠.
제가 지켜보고 있는 것들입니다.
Duke Nukem 3D (즉, 기능이 온전한 PC 버전) https://github.com/BigChat88/N64DukeNukem3DPort
Portal 64 Still alive https://github.com/mwpenny/portal64-still-alive
Resident Evil 64 (RE2가 아니라 첫 번째 작품입니다) https://www.youtube.com/watch?v=_xRiwy8Z6S0
Silent Hill (아직 초기 WIP) https://www.youtube.com/watch?v=v7fM06jmHso
직접 해 보지는 않았지만 흥미로워 보이는 것들입니다.
Simpsons Arcade https://www.youtube.com/watch?v=zH9JYQVzKDE
X-men Arcade https://www.youtube.com/watch?v=ah3nB8MP4CM
TMNT Arcade Collection https://www.youtube.com/watch?v=CiR5-ZpLtyI
지금은 나오는 속도가 제가 플레이하는 속도보다 빠릅니다. 저는 지금 Duke 3D 2편을 하는 중인데 아주 좋습니다. 원래 64 버전도 늘 재미있었지만, 레벨 중간 저장은 정말 판도를 바꿔 놓습니다.
모든 포트가 폭발적으로 늘고 있어요. 미쳤죠.
Ocarina of Time은 오늘 공식 출시됐는데 벌써 ARM 맥에서 플레이할 수 있어요. 엄밀히 말하면 포트도 아니고, Switch의 ARM 코드를 네이티브로 실행하는 거예요. 물론 플랫폼에 상관없이 에뮬레이터로도 할 수 있고요.
libdragon은 확실히 새로운 게 아니에요. 2008년쯤 원작자인 dragonminded와 이야기를 나눴던 게 뚜렷이 기억나요. 그분이 N64 개발 키트에 딸려 온 RSP 코드를 리버스 엔지니어링하려 애쓰던 일, 그리고 이어서 RSP 자체를 리버싱하려 했던 일에 대해서요. 게임이 늘어나는 속도는 충분히 믿겠지만요.