Home Page Forums Other Emulator Message Boards Audio Overload AO SDK release 1.0 available

There's apparently a rumor that all of kingshriek's patches for the SCSP in MAME/AOSDK were simply Neill Corlett's Highly Experimental code. I'm sorry I even have to address something this mindbogglingly stupid, but here goes:

1) I was aware that KS had the HE code and I did keep an eye on the patches accordingly.

2) Anyone with decent C/C++ experience would agree that ElSemi's SCSP code in MAME has a pretty distinctive style and general way of doing things. Everything KS submitted fit that style and didn't attempt to make any major changes to how things worked, even when that would have been a good idea :-)

3) Some of the bugs fixed in MAME were also present in HE, so the fix had to have been independently derived.

4) FM mode doesn't exist in HE (at all, to my knowledge), so it was clearly all original engineering.

And the trump card:

5) Lord Nightmare asked Neill about this on IRC and Neill looked at the code and said there was no copying.

It's good stuff - I would know, I found it in SCSP sources few months ago and it replaced my own floating-point based decoder
Truth be told all you need is quantization width data and the clipping values (127 & 24576) - it's all in docs. What isn't there is how this works on loops
As for those loops - I've just had a very nice idea, need to test it. Keep your fingers crossed, if this solves my little mystery it will also benefit your ADPCM code.

WTF - anyone could have told that it wasn't copied. _I_ can tell that, and I don't even have the HE code. n00bs! kiddiez! OMGWTFBBQ gaahhh...

- Stiletto

I think it's an extension of the popular opinion that MAMEdevs are all really stupid and we've sort of "duh"ed ourselves through ~7000 romsets by some combination of theft and pure luck. Especially that Aaron guy.

Could happen, I guess, monkeys and Shakespeare... :P

My test was rather inconclusive.

The real problem with ADPCM is how exactly it behaves on loop return. Let's assume AICA does interpolation as some soures claim. Does that mean it also interpolates ADPCM sounds? If so, how does it fetch pos+1 sample, is decoder state preserved or modified - because if it is modified then it's always +1 ahead of actual play position. Is there really always one more valid sample after LEA to allow for interpolation?

Hell, I don't even know what's the correct loop end point, because docs says it goes 0, 1, 2, ..., LEA (inclusive) -> LSA+1, LSA+2, ... My own observations (though all I can do in that matter is closely monitor sample position counter) show this to be incorrect, it's 0, 1, 2, ..., LEA-1 -> LSA, LSA+1, ...

I got my own code to work in almost all cases. Almost, with one exception named "Soul Reaver" - which still distorts in-game dialogues from time to time.
Well, it's back to the drawing board for me I will help you with ADPCM but I suggest you try to discover things on your own as I'm clearly overlooking something again and again. On the bright side, I now know what it was that caused hissing when I tried to interpolate ADPCM and that was a silly mistake on my part.

as well as the atari/midway hardwares no one else tried to emulate, cps2 encryption and neogeo rewritten emulation (with all the flickering hardware originally had and other emus never showed)

there will always be people which do not believe to the facts, so don't bother

more on topic, I really like these progresses on DSF... kudos to all of you involved

It wasn't SCSP. I remember it now - I wanted to ditch my DirectSound based AICA and do a software mixer instead. Looking for some more information on Yamaha-based chips I found ymz280b.c in MAME sources. Multiplying every magic value by 256 to get an integer constant - somehow that never occured to me.

I've brought this up for a reason. I've peeked into this file again and I see that ADPCM decoder stores loop-entry state on first pass and restores it on each jump back. I gotta try this too - but at this very moment I'm in middle of swapping one of my HDDs and that will take some time. So feel free to experiment.

Also, I have a request of sorts. Love Hina game for DC has some sequenced music running on the title screen - but it was always very broken on Makaron. If this is one of those DSF things then perhaps someone could tell me how to extract it. AO has a bit different timer engine and interrupts processing - it would help me narrow down the source of this bug if I AO plays this tune right (or at least in a different way).

I've not done any DSF ripping of my own yet, but perhaps kingshriek has that game and could take a look? (Alternatively, if Makaron can dump the 2 MB of AICA RAM while that song is playing, I might be able to create a working DSF from it).

Incidentally, Samuele sent in some nice SH4 and Naomi improvements today - the PVR-TA is less buggy, at least for what displays, and the dumped cartridges all start to boot now. I gotta try and bang on Dreamcast soon :-)

It can, I've sent you memory image a moment ago.

I don't really know that much about Naomi, but I do know the GD-ROMs are encrypted. All I could tell by looking at big file (I assume that's 1:1 DIMM image) is the key is probably 8-bytes long, since some data repeats every 8 bytes. That's probably zero-padding or SEGASEGA.
And there's this strange NAOMIGD.BIN file that seems binary but has all bytes < 0x80...