linear resample audio on sega genesis vs no resample quality

[sega16]

I was thinking about possible ways to get better quality digital audio from the sega genesis without huge files so I wrote a program that linearly re-samples a audio sample (in real time and in this case stored at 6000hz) and re samples it to 25600hz this made a slight but not significant difference which makes sense because re-sampling can not magically create more data from less data but I think this kind of smoothed out the sample abit and made it quieter before I removed the shift to the right by 1. Removing it increased the volume at the cost of very minor peaking after removing it the volume seemed for the most part the same between no re-sampling and re sampling. However I think that my test was unfair because I used only regen and kega fusion to test it (I do not have a flash cart) and emulators perform their own re-sampling. If anybody has a flash cart to test it that would be great. Here is the demo + source for both players with and without re-sampling.Note:originally I was going to use two buffers but I didn't see how this would improve performance in my case so I just used byte by byte.Edit fixed pitches
http://www.mediafire.com/download.php?8l0il39bfpblvz3

[Chilly Willy]

I ran this on my CDX... the resampled audio sounds better. There's clearly less quantization noise. What resampling does is to push the quantization noise up higher in the spectrum, at which point the filters on the audio cut the noise to a higher degree. It's the same reason CD players oversample at 2 to 8 times the nominal sample rate.

When I listen to the plain sample, it has some high pitched ringing - a clear indicator of a low sample rate as the sharp edges of the samples contribute to noise. The resampled pcm has much less of that high pitch sound.

[sega16]

Thank you Chilly Willy good explanation. I will use the linear resample code for my game since it sounds better without any disadvantages.Also did each demo's pitch playback at different speeds in regen the pitch sounded the same for both demos but in kega fusion the pitch was a significant different when comparing demos I went with regen's timing because I have heard it is more accurate. I found that to be very strange.

[Chilly Willy]

Well, remember that emulators are resampling at some point to what the computer can play. Some emulators do that in the middle of emulating the FM/PSG chips, and others emulate the chips, then resample THAT to the computer sample rate. It can make a big difference in how it sounds.

[TmEE co.(TM)]

Playing a sample twice or more, but not beyond ~26KHz did improve the soudn very slightly from my experiments long ago.
But when you add interpolation to the mix you'll lose all the edge, all the aliases are dwindling and this kills the effort to me.

I will look at the files at home, right now I am at work.

[sega16]

Playing a sample twice or more, but not beyond ~26KHz did improve the soudn very slightly from my experiments long ago.
But when you add interpolation to the mix you'll lose all the edge, all the aliases are dwindling and this kills the effort to me.

I will look at the files at home, right now I am at work.

So you think a nearest neighbor approach would be better quality wise?
I wrote a program that uses nearest neighbor re sampling to 25,600hz.
Also would it be possible to control game logic with the z80? I was thinking about making a mod player (It is very possible the genesis game toy story did it) but I don't think the z80 is fast enough. I will probably use nearest neighbor re-sampling for that because with linear re sampling if I can get 25,600hz for one channel without any waits then 25,600/4 channels =6,400hz that is way to low.

[Stef]

Playing a sample twice or more, but not beyond ~26KHz did improve the soudn very slightly from my experiments long ago.
But when you add interpolation to the mix you'll lose all the edge, all the aliases are dwindling and this kills the effort to me.

I will look at the files at home, right now I am at work.

So you think a nearest neighbor approach would be better quality wise?
I wrote a program that uses nearest neighbor re sampling to 25,600hz.
Also would it be possible to control game logic with the z80? I was thinking about making a mod player (It is very possible the genesis game toy story did it) but I don't think the z80 is fast enough. I will probably use nearest neighbor re-sampling for that because with linear re sampling if I can get 25,600hz for one channel without any waits then 25,600/4 channels =6,400hz that is way to low.

I already though about making a MOD player on the Z80 CPU only but really i don't think that is possible or at a very low quality (8 Khz or else) and with 3 channels at max. Toy Story does 3 channels at 16 Khz with the 68000, developers of this game were very talentued (each level of this game are very impressive technically) so i don't think we can do better

[TmEE co.(TM)]

Your tests run at different speeds which makes hard to judge anything.

Z80 can run your game logic but you need 68K do actual HW accesses as Z has limited access

[sega16]

I already though about making a MOD player on the Z80 CPU only but really i don't think that is possible or at a very low quality (8 Khz or else) and with 3 channels at max. Toy Story does 3 channels at 16 Khz with the 68000, developers of this game were very talentued (each level of this game are very impressive technically) so i don't think we can do better

Even if it is not possible to do better than toy story it would be fine to get a similar result and although I don't like reinventing the wheel I am no good at hacking and It does not seem like a good idea to disassemble the mod player there could be potential legal problems with disassembling it and using the player in another game. So I would be better off writhing my own. I think that a mod player would be good for a simple game like a space shooter with good music have a mod player running on the 68k and use the z80 to move the sprites and use the FM and PSG channels for sound effects. I have never programmed for the z80 but I believe the z80 can access the vram to move the sprites around.

Your tests run at different speeds which makes hard to judge anything.

Z80 can run your game logic but you need 68K do actual HW accesses as Z has limited access

So kega fusion was correct not regen? I will fix that. In regen the pitches were the same for both demos but in kega fusion the pitches were different (I believe I mentioned this earlier). Edit I updated the link with the pitches that were correct in kega fusion.

[Stef]

Unfortunately the VDP IO are 16 bits when Z80 is only able to do 8 bits IO... that is the main problem elsewhere you could run at simple game using Z80 ram for logic.

[sega16]

Unfortunately the VDP IO are 16 bits when Z80 is only able to do 8 bits IO... that is the main problem elsewhere you could run at simple game using Z80 ram for logic.

I guess when writing this I would have to find time to transfer a sprite table. A sprite table is not that big so it should work.

[Stef]

Unfortunately the VDP IO are 16 bits when Z80 is only able to do 8 bits IO... that is the main problem elsewhere you could run at simple game using Z80 ram for logic.

I guess when writing this I would have to find time to transfer a sprite table. A sprite table is not that big so it should work.

No the problem is that technically it is impossible to do 16 bits write to VDP port from Z80... as Z80 data BUS is only 8 bits wide writing a 16 bits from Z80 is equivalent to write 2 times a 8 bits values... which is taken a 2 writes to VDP port which result in incorrect writes :-/

Edit :
Ah sorry i misunderstood you reply, maybe you were speaking about using 68k for a short time to transfer sprite table ? You have also tilemap, tiles and stuff to update in vram... all VDP reads/writes have to be done from the 68000.

[sega16]

Edit :
Ah sorry i misunderstood you reply, maybe you were speaking about using 68k for a short time to transfer sprite table ? You have also tilemap, tiles and stuff to update in vram... all VDP reads/writes have to be done from the 68000.

Yes that is what I meant my plan is to load all the tiles with the 68k then start the mod and transfer the sprite table with the 68k while the mod is playing.

[Chilly Willy]

Some people LIKE the harsh metallic buzzing you get from low rate samples... it sounds more "retro". Some people prefer to eliminate that as much as possible. The default for modern MOD players is generally toward eliminating quantization and alias noise - you have to change the prefs if you want that harsh buzzing like your old Amiga used to play.

So I think interpolation should be the default, but with the option to not do so if the person so desires.

[TmEE co.(TM)]

interpolation gives the same effect as lowering sample rate, except for the really intensive methods like sinc and the like