CVSD Compressed audio example

Chilly Willy · Post by **Chilly Willy** » Tue Jul 07, 2009 5:50 pm

As far as commenting goes, "Real programmers never comment - if it was hard to write, it should be harder to read, and impossible to change."

Yeah, the computer side compressor code can be more "fun" to write... thankfully the cvsd compressor was pretty easy.

By the way, here's the same game music demo, but compressed at 22kHz instead of 11kHz. I think you're right... I think it's better.

GameMusic-2.7z

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Jul 07, 2009 6:21 pm

Chilly Willy wrote:As far as commenting goes, "Real programmers never comment - if it was hard to write, it should be harder to read, and impossible to change."

hehe, spot on

the new demo sounds better, but quite minimally :/ So yea, voice samples is what its best at I suppose...

Chilly Willy · Post by **Chilly Willy** » Tue Jul 07, 2009 6:22 pm

Okay, here's another full archive: musicdemo-3.7z

This has "Eye of Time" compressed at 22kHz as well as the game music at 22kHz. Includes source.

Chilly Willy · Post by **Chilly Willy** » Thu Jul 09, 2009 12:40 am

And yet another full archive.

musicdemo2-1.7z

This is a modification on the code - where the previous code did 16:1 compression (eqv 8:1), this does 8:1 (eqv 4:1). Basically, 2 bits per sample instead of 1. This is the game music. See what you think. For more info on this compression, go to my CVSD thread linked in the first post.

Chilly Willy · Post by **Chilly Willy** » Thu Jul 09, 2009 5:06 am

Okay, I wanted to see how this works with more typical game music, so I made up a test with the Sonic CD present level CDDA tracks.

musicdemo2-2.7z

This one can play up to 8 songs. Press the directions for songs 1 to 4, and hold B while pressing a direction for songs 5 to 8. I only had room for seven songs in the rom, so song 8 is just the same as song 1.

notaz · Post by **notaz** » Thu Jul 09, 2009 11:47 am

Chilly Willy wrote:For more info on this compression, go to my CVSD thread linked in the first post.

For me link goes to a page which says "post doesn't exist" for some reason.

Chilly Willy · Post by **Chilly Willy** » Thu Jul 09, 2009 3:18 pm

Me guesses not everyone has access to it. It's probably a "devs-only" page or something. Of course, if you don't have access, YOU should considering you're one of those devs.

Maybe one of the mods can add you to the list. In the meantime, lemme make a brief explanation here, and the code is in the arcs, of course.

CVSD normally compresses the samples to just a sign bit. That tells the decompressor whether to add or subtract the delta from the derived sample. If delta was a constant, clearly you would only ever have slow saw-tooth representations of the original wave. The way CVSD works is to change delta after every sample depending on some criteria. The "normal" algorithm changes delta if you have three or four 1s or 0s in a row. In my code, I changed delta larger if the current bit matched the previous bit, and smaller if they differed. That was the original code. One bit per sample means it was equivalent to 8:1 compression compared to what you would store in the Genesis to playback. Of course, it really isn't suitable for music.

So my latest experiment decided to bump the samples to two bits instead of one. We still have the sign bit, but now an extra bit is used to tell the decompressor which way to shift delta. Instead of implicitly shifting based on matching previous bits, we now shift according to which will give less noise. That's what the last two arcs have used, and at two bits per sample, you get four to one compression. It can be suitable for music - some songs seem to encode very well at 4:1, while others show a little more noise than you'd like in your music. So this may or may not be suitable for people to use, depending on specific circumstances.

Again, remember that this is compressing 16 bit audio. While the code decompresses to 16 bits, only the top 8 bits are used with the YM2612 DAC. I may make another example of using 10 to 12 bits with the 32X audio.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Jul 11, 2009 6:29 pm

2bit files sound much nicer

Chilly Willy · Post by **Chilly Willy** » Sat Jul 11, 2009 7:33 pm

TmEE co.(TM) wrote:2bit files sound much nicer

Yeah, the difference was really amazing. It also gave me an idea for modifying the 1 bit encoder to maybe make that sound better. Going to try that this weekend.

I've been looking around for a 2 bit ADPCM routine so I could compare that to the 2 bit CVSD. All the ADPCM I've come across is all 4 bit. Anyone know of any 2 bit ones?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Jul 11, 2009 7:39 pm

I have an implementation of a 2bit flavor of ADPCM made for 8bit stuff in my notebook.....

Chilly Willy · Post by **Chilly Willy** » Sat Jul 11, 2009 8:57 pm

Well, if it's not "secret", maybe you could post some code? Or if the code is secret, but the compression isn't, post some pseudo code on how it works.

Chilly Willy · Post by **Chilly Willy** » Sun Jul 12, 2009 5:09 pm

Okay, here's demo 3.

musicdemo3.7z

This is just a change in the 8:1 compressor (I did change maxDelta, so everything is technically new). Before, the compressor simply chose the sign based on whether the next input value was greater than or less than the current derived sample. This compressor first calculates the error if you chosen the sign one way or the other, and then adds the minimum error for the NEXT sample after this one based on the same criteria. So this compressor chooses the sign based on what minimizes the error over the next two samples. The idea is to try to minimize the error (noise) rather than blindly using the current sign.

The rom image in this is like in demo 2 - the Sonic CD present levels. This is still noisy, just not quite as noisy as the last demo 1 release. I'd use this for music only in extreme circumstances - the music MUST be digitized and you NEED 8:1 compression. Otherwise, use the 4:1 compression. Note - I can do this same kind of error minimizing in the 4:1 compressor. It currently only tries to minimize the noise based on the next sample, not the next two samples.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Jul 12, 2009 6:33 pm

Chilly Willy wrote:Well, if it's not "secret", maybe you could post some code? Or if the code is secret, but the compression isn't, post some pseudo code on how it works.

That's all existing info about it...

The last demo has quite little noise, but it sounds like its 4bit audio, hehe

EDIT: it seems you're not really using your ICQ account ?

Chilly Willy · Post by **Chilly Willy** » Sun Jul 12, 2009 6:44 pm

TmEE co.(TM) wrote:
Chilly Willy wrote:Well, if it's not "secret", maybe you could post some code? Or if the code is secret, but the compression isn't, post some pseudo code on how it works.

That's all existing info about it...

Hahahaha! I've worked from worse.

The last demo has quite little noise, but it sounds like its 4bit audio, hehe

EDIT: it seems you're not really using your ICQ account ?

I don't use any of my IM accounts unless someone arranges to meet first. I dislike IM - I much prefer email since IM tends to make people linger when they could be doing something else. I generally check my email twice a day, so it's not a big deal in my opinion.

Chilly Willy · Post by **Chilly Willy** » Sun Jul 12, 2009 6:54 pm

Oh, a quick peek at that shows it's 3:1 compression (4 bytes for 12 samples). I'm gonna go work on an encoder and see what is sounds like.

Odd coinky-dink, but it's quite similar to my 2 bit CVSD, except you explicitly state a delta, use not instead of negate, and use delta instead of delta*2.