Ideas for compressing BRR samples further

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Ideas for compressing BRR samples further

Post by Bregalad » Sun Jun 14, 2020 1:53 am

Nikku4211 wrote:
Sat Jun 13, 2020 4:13 pm
Yeah, it'd be awesome to use the SPC700 itself to generate samples. I imagine it could be possible to even do software synth mixing on the SPC700 itself too, right?
You're approaching a whole different beast ! What I meant is one-time sample generation (typically while not playing back any sound, or perhaps at certain specific points in the music). What you mean is constantly generating waveform data, which is certainly possible, but remember that the SPC700 runs at only 1.024 MHz, so almost twice slower than the NES, which is also commonly believed to be too slow to generate sound in real-time without dedicating 100% of the CPU to that task.

psycopathicteen
Posts: 2943
Joined: Wed May 19, 2010 6:12 pm

Re: Ideas for compressing BRR samples further

Post by psycopathicteen » Sun Jun 14, 2020 8:58 am

The cycle timing would have to be perfect too. Exactly 32 cycles per sample every time.

psycopathicteen
Posts: 2943
Joined: Wed May 19, 2010 6:12 pm

Re: Ideas for compressing BRR samples further

Post by psycopathicteen » Thu Jun 18, 2020 2:28 pm

I'm planning on doing huffman code on top of the LZ4 data. I'll do it on a 4-bit level but I'm having a hard time figuring out how to make sure the huffman tree never takes more than 8-bits per huffman code.

psycopathicteen
Posts: 2943
Joined: Wed May 19, 2010 6:12 pm

Re: Ideas for compressing BRR samples further

Post by psycopathicteen » Tue Jun 23, 2020 9:44 am

With huffman encoding (with 4-bit code size) after LZ4 it takes:

9816 bytes for sawtooth
4896 bytes for pulse

Post Reply