PCM audio quantization error

[SmileyDude]

I've been playing a little bit with PCM audio (AUDCx = 0 and changing AUDVx quickly to produce sound). I was able to get some decent results fairly quickly, but I think my naive 8-to-4-bit (s >> 4) quantization method is introducing too much noise into the conversion.

 

I've done some looking into ways to clean up the audio, including dithering and FIR, but the results just aren't sounding that much better than the naive method. I'm currently using 15720Hz as my sampling rate -- just using WSYNC right before filling in AUDVx. I could try to tighten up the code a bit and increase the rate, but I really don't want to spend *all* the CPU time handling audio. At least I should have enough time with my current method to put something on the display, even if it isn't very advanced.

 

Has anyone else here tackled the quantization error issue?

[+SpiceWare]

I did some work on digitized audio a few years ago for Frantic. If you go to my Frantic blog entries and head back to (what's currently) page 7 you'll find the blog entries related to using samples.

 

In the comments for this blog entry EricBall recommends doing a low pass filter below 7.8 KHz.

 

It's been long enough that I don't recall what all I was doing or why, so I'm planning to start over with the digitized audio routines in the near future. One of the things I plan to look into is compression using ADPCM to reduce the storage requirements.

[iesposta]

I was just asked how I got speech into my "Flappy" game.

This blog post it's where I started.

http://atariage.com/forums/topic/222161-flappy-my-1st-released-game/?p=2943651

If you get any better tools, please share.

 

Also, have you heard those 1-bit beeper tracker music?

I would like to hear that running on Atari 2600. It is like Pitfall DPC times 1000

[SmileyDude]

I did some work on digitized audio a few years ago for Frantic. If you go to my Frantic blog entries and head back to (what's currently) page 7 you'll find the blog entries related to using samples.

 

In the comments for this blog entry EricBall recommends doing a low pass filter below 7.8 KHz.

 

It's been long enough that I don't recall what all I was doing or why, so I'm planning to start over with the digitized audio routines in the near future. One of the things I plan to look into is compression using ADPCM to reduce the storage requirements.

 

Good call on the low pass filter -- that's probably where a good chunk of my noise is coming from. I'll give that a try to see how it effects the sound.

 

As for ADPCM -- would that help in the case of the 2600? You only have 4-bits to work with on the output side. You would have to squeeze it down to 2-bits to really make it worthwhile, but you would be sacrificing a huge chunk of your dynamic range (which is already a fraction of what a CD has).

 

I was also thinking of doing some sort of compression as well. Was going to experiment with trying to RLE the samples to see if that saved any space.

 

With the Harmony cart, I bet you could pull off some nice audio. The ARM in the Harmony could just feed samples to the 2600 in a tight loop without having to worry about any unpacking, loop overhead or bank switching on the 6502 side. I might have to play with that at some point as well.

[SmileyDude]

I was just asked how I got speech into my "Flappy" game.

This blog post it's where I started.

http://atariage.com/forums/topic/222161-flappy-my-1st-released-game/?p=2943651

If you get any better tools, please share.

 

Also, have you heard those 1-bit beeper tracker music?

I would like to hear that running on Atari 2600. It is like Pitfall DPC times 1000

 

I think that perl script is just doing decimation of the 8-bit samples down to 4-bit. That introduces quantization error, which may or may not be a huge deal on the 2600 -- I still need to try some other things first before I say that's my problem.

 

The 1-bit beeper stuff is pretty amazing, IMO. I still listen the the Chronos title music from the ZX Spectrum every once in a while. I would love to get something like that working on the 2600 or even the Apple II, which has just a 1-bit beeper as well. Amazingly good and even more impressive that it was done without the help of all the tools we have access to these days like high end PCs and instant access to knowledge via the Internet.

[+SpiceWare]

As for ADPCM -- would that help in the case of the 2600? You only have 4-bits to work with on the output side. You would have to squeeze it down to 2-bits to really make it worthwhile, but you would be sacrificing a huge chunk of your dynamic range (which is already a fraction of what a CD has).

 

 

Tjoppen did some work on it a while back. He said it sounded good, but he lost the code.

[Rybags]

I've played around with variations on the 8-bit computer - since it's 4 bits/voice the principles are virtually the same as on the 2600.

 

One thing I found - playing 2-bit samples at double the rate sounds practically the same as 4-bit samples at half rate, e.g. 2 bits, once per scanline vs 4 bits, every 2nd scanline.

 

Another - in the case of slower sample rates, plugging in the "average" value between current/next sample increases the quality slightly.

 

2-bit samples of course can increase the processing time required per sample played back. Tables in ROM and/or packing the samples out of order can be helpful there.

e.g. the important bits are bits 2,3 - and on 6502 you can implement an 8-bit rotate using CMP #$80 / ROL A. So you'd pack samples in order such that first is bits 2,3 then 1,0 followed by 7,6 and 5,4.

 

Even 1-bit samples can sound OK but the playback rate needs to be pretty high.

 

Using multiple voices - since TIA only has 2 it's less improvement. With 4-bit samples a good idea is to use the averaging technique.

 

PWM - since 2600 has no refresh or DMA holdups of the CPU, timing can be precisely implemented. Higher perceived precision than 4 bits can be achieved using only 1 bit output.

But the disadvantages - the CPU utlization is practically 100% and there's constant noise at the sample rate.

[raindog]

I think that perl script is just doing decimation of the 8-bit samples down to 4-bit. That introduces quantization error, which may or may not be a huge deal on the 2600 -- I still need to try some other things first before I say that's my problem.

 

Unless your 8-bit samples are confined to 16 linear values or fewer, you are going to have quantization error; it's just a matter of how much, and whether you can shape it into something less offensive. I'd thought about doing what that perl script did, figuring it would create the least noise since anything below 50% amplitude would be eliminated, but that only works if you're using unsigned samples. If it's signed, you'd want to remove the four middle bits, not the lower four. If it's unsigned, I'd think it would be better to condense each set of two bits into one using OR, so that 10110011 becomes 1101, but I haven't tried that.

 

(Edit: that would probably actually be pretty bad since 75% of 2-bit combinations would result in a 1, so maybe just discarding every other bit would be better.)

 

I also started looking a few years back into a different approach. I wrote a Perl script in the late '90s to find duplicate images by reducing them to 8x8 greyscale or 16x16 1-bit bitmaps, subtracting them from each other and counting the remaining bits, and if the number of bits fell below a given threshold, it was a match. It was incredibly effective, but quite slow (my directory of about 20,000 images took about 2 days to process) and other free software programs do a much faster and easier job of it now.

 

But imagine converting each 17 millisecond (1 NTSC frame) chunk of audio into a bitmap using FFT, having reference bitmaps of 17ms worth of every possible VCS distortion/pitch combination, and playing the most similar one on each frame. I remember programs purporting to make the Yamaha DX7 (an FM synth) simulate sample playback using similar methods in the late '80s, with varying levels of success, but they didn't have anywhere near 17ms granularity. I haven't had a VCS toolchain set up for a long time due to DASM's sorry state and my own lack of time to get it to build, so I haven't tested it, but it sounds awesome in my head.

 

The errors it would introduce would certainly make 8->4 bit quantization error look like nothing, but maybe it would be possible to at least get speech that's more intelligible than the Intellivision's "YER OUT" growl, if not music, while not having to blank the screen or use the DPC+. (With the DPC+, I'd think it could be possible to make it sound much better than just hitting AUDVx on every scanline with the same distortion pattern.)

Edited March 8, 2014 by raindog