N64에서 44100Hz 스테레오를 Opus급 비트레이트로, CPU 4%만 쓰는 ULC 코덱
- Aikku93이 만든 ULC(Ultra Low Complexity Codec)를 Libdragon의 RSP에 올려 N64에서 44100Hz 스테레오를 Opus에 가까운 비트레이트로 CPU 시간 약 4%만 써서 재생함. MDCT 기반 변환 코덱이지만 여러 대역으로 나누지 않고 허프만 엔트로피 부호화 없이 4비트 니블 문법으로 계수를 저장함.
- ULC의 니블 문법은 계수 값(-7~-2, 2~7), 제로 런(1~16), 긴 제로 런(17~288), 양자화기 변경, 노이즈 필을 4비트 코드로 구분하고 모든 데이터가 니블 경계에 맞춰져 있음. 계수 블록을 푸는 코드가 C 150줄 정도라 벡터 프로세서에 맞추기 쉬움.
- 코덱은 원래 Game Boy Advance(16MHz ARM, 벡터 명령 없음)에서 70kbps로 녹음 음악을 재생하는 데모용으로 만들어짐. 당시 MP3 계열 변환 코덱은 보통 80~100MHz CPU가 필요했고 ADPCM 같은 시간 영역 코덱은 같은 음질에 훨씬 높은 비트레이트를 요구했음.
- N64의 기존 선택지는 4배 압축되는 ADPCM뿐이라 44100Hz 5분 스테레오가 약 12MB가 됨. Mario 64 ROM 전체가 8MB, 최대 카트리지가 64MB였고 Libdragon에는 Giovanni Bajo가 만든 RSP 가속 Opus 디코더도 있지만 게임플레이 중 쓰기엔 너무 느림.
- Conker's Bad Fur Day는 Nintendo의 허락을 받아 RSP로 MP3를 풀었지만 디코딩 비용 때문에 프레임 레이트가 떨어져 컷신에만 쓸 만했음. 글쓴이의 게임 Xibalba 64는 32MB ROM 중 31MB를 ADPCM 음악에 썼음.
Hacker News 의견들
N64에 Half-Life라니, 이건 뭐임? 영상 보니까 진짜 놀랍던데.
요즘 N64 포팅이 폭발적으로 쏟아지는데 libdragon 같은 새 라이브러리랑 팬들의 열정, LLM 도움까지 겹친 결과임. Duke Nukem 3D, Portal 64, Resident Evil 64, Silent Hill 초기 WIP를 추적 중이고 Simpsons나 X-men, TMNT 아케이드도 나옴. 나오는 속도가 내가 해보는 속도보다 빠름.
이 코덱 27년 전에 나왔으면 딱이었겠지만 1999년에 특허 변호사들을 못 넘겼을 것임. 그때 코덱 시장은 특허 지뢰밭이었고 N64 MP3 디코더는 두 번 구현됐으며 Nintendo와 Rare가 RAD Game Tools 라이선스를 사서 방어했음. Fraunhofer가 직접 라이선스에 25만 달러쯤을 불렀는데 그건 무리였고. Conker의 프레임 문제는 사실 RDP 필레이트가 원인이었고 64Mb 카트리지에 모노 음성 넣는 것도 빠듯했음.
음악은 그렇다 쳐도 비디오는 여전히 지옥임. Windows에서 h265 재생하려고 0.99달러 내야 하는 꼴만 봐도 알 수 있음.
N64에서 제일 약한 부위는 필레이트가 아니라 텍스처 버퍼 크기였다고 봄.
멋지다. 나도 예전부터 내 오디오 코덱을 써보고 싶었는데 좋은 도전거리가 되겠음.
데모 듣고 품질이 왜 이 모양인가 했는데 보컬이 안 들리고 끊기는 건 원곡이 원래 그렇더라. 링크된 원곡 들어보면 앎.
그건 맞는데 압축 데모에 그렇게 안 유명한 곡을 고른 건 아쉬움. A/B 테스트하기 쉬운 익숙한 곡을 썼어야 함.
지적 고마움. 영상 교체했음.
궁금한 게 있는데, 디코더가 RSP IMEM 4k를 거의 다 채운다면 게임 그래픽에 쓸 공간이 없어지는 거 아님? 실제 게임에서 쓸 수 있는 건가?
IMEM은 DMEM처럼 아무 때나 교체 가능함. 음악 블록 처리가 끝나면 3D 변환 코드를 DMA로 넣으면 되고 Libdragon이 rspq 큐로 알아서 처리해줌.
MAS3507D에도 잘 맞을 것 같은데. 프로그램을 1킬로워드 RAM에 넣을 수 있다니 1024개 DSP 명령에 맞출 수 있으면 좋겠지만 프로그램 포맷 공개 문서가 없음.
LLM 얘기가 나오는 순간 다 깨짐. 데모씬과 홈브루는 지금 죽어가는 중임.