Nintendo 64はオーディオに関して重大な技術的課題に直面していました。カートリッジの容量は極めて限られており、93 MHzのCPUは処理のためのサイクルが制限されていました。CDから非圧縮のRedbookオーディオをストリーミングできたPlayStationとは異なり、N64は音楽をカートリッジに収めるために圧縮フォーマットを必要としました。コンソールのRSP（Reality Signal Processor）コプロセッサは一部の展開処理を処理できましたが、標準的なソリューションは不十分なことが多々ありました。ADPCM（Adaptive Differential Pulse Code Modulation）は容量を節約できましたが非効率であり、高品質なトラックを収めるにはストレージを消費しすぎることがよくありました。逆に、MP3やOpusのような現代的なフォーマットは優れた圧縮を提供しましたが、アクティブなゲームプレイ中にフレームレートに深刻な影響を与えることなく実行するには計算コストが高すぎました。

Ultra Low Complexity Codec (ULC)は、MP3フォーマットの「より単純な」バージョンとして機能することで、これらの問題を解決します。MP3と同様に、ULCはModified Discrete Cosine Transform (MDCT)を使用してPCMデータを周波数領域に変換する変換コーデックです。しかし、ULCはMP3で使用される複雑なエントロピー符号化（ハフマン符号化など）を排除しています。その代わりに、ULCは各係数がわずか4ビットで保存されるニブルベースの構文を使用します。この設計により、デコーダーは任意のビット読み取りを行うことなく動作でき、非常に効率的になります。また、ULCには「ノイズフィル」機能が含まれており、これはシンバルやスネアのような打楽器の音をエンコードする際に特に効果的です。これらはMP3が正確に表現するのに苦労する要素です。

N64にULCを実装するには、RSPの厳しいメモリ制限、特に4096バイトのデータメモリ（DMEM）と命令メモリ（IMEM）を克服する必要がありました。デコーダーをこのスペースに収めるために、実装では32ビット浮動小数点数ではなく16ビット固定小数点数（Q1.14）を使用しています。この選択により、DMAトラフィックが減少し計算速度が向上しますが、技術的にはノイズフロアが高くなります。実際には、著者はこのノイズは無視できるレベルであると発見しました。結果として、このデコーダーはN64のCPU時間の約4％、RSPの時間の約5％しか消費せず、Opusに近いビットレートで44100 Hzのステレオオーディオを実現します。この効率性はHalf-LifeのN64移植で実証されており、ULCによって64 MBのカートリッジイメージ内に2,500のサウンドと27の音楽トラックを含めることが可能になりました。

ULCはN64ハードウェアにとって画期的な進歩ですが、その効率性が高度なアルゴリズムではなく、簡略化された構文から来ていることに注意が必要です。標準的な変換コーデックの「不要な要素（cruft）」を避けることで、この特定のハードウェアにおいてADPCMもOpusも提供できなかった品質とパフォーマンスのバランスを実現しています。しかし、RSPのメモリ制約を満たすために16ビット固定小数点数に依存しているため、聴き手にはほとんど感知できない差ではあっても、浮動小数点ベースのデコーダーが持つ絶対的な最高忠実度には達しない可能性があります。