I will add to this if I do more work on it. Suffice to say, this stuff is really irritating. As I mentioned before, the code is a joke. You have numerous functions doing mostly the same thing - calling one another after numerous checks to decide everything from loops to which channel to dump the effect on. The field module does this by script, which is fair enough, but the battle module doesn't have a set standard. Take a look at the following paths that the processor took to initiate a sound effect from dsound:
Path for enemy attack (just one I chose at random)
Path for menu cursor (menu outside of battle also)
Path for Summon effects
path for disappearing characters
As you can see, this isn't a case of a sane, or rational, or well coded function. It's a giant mess. Some effects, like the sound used when characters disappear before a Summon, use a dedicated function, like 00748F8F. This function is ONLY called for this ONE effect. Despite the fact they could have just used 00745160 - or any other function that eventually calls 0074A795. And there's the first problem. Even if you do hijack the functions that do most of the work: 005BFFF3 and 0074580A , you are still left with these oddities. There are others out there too.
It's like the programmers lost track entirely of what was going on. There is a ton of duplicate checking code.
005BFFF3: This has 3 parameters.
1: Pushes identification to decide how to proceed.
21 to 23: Calls 00749404
24 to 27: call 745606 and let it decide the channel.
28:Channel 1, call 745160
29:Channel 2, call 745160
30:Channel 3, call 745160
31:Channel 4, call 745160
Else call 745606 and let's it decide the channel.
Yeah, you aren't going to believe how these silly ID numbers come into being either. They seem to be plucked from someone's brown end. When the function is called, it deducts 21 from the ID. So if the value is less than 21, you get 20 - 21 = -1 (sigh which is then seen as HIGHER than 10 using a "Ja" - so it ends up calling 745606. It also has a silly table to decide the jump positions and even that isn't logical. I have solved this above (as you can see).
2. L/R Balance of the sound effect (where 00 is left, 64 is centre and 127 is right).
3. Effect ID (0-750, but some of these don't even exist past a certain number). Note that a check is done in numerous functions to make sure that the range is correct.
So as you can see, 005BFFF3 doesn't know what to do until the programmer tells it. It is sent a balance value and the effect to play, but what path it takes from there depends on the stupid ID it is given.
0074580A: Haven't really gone into this one much but it ultimately ends up either playing the effect with centred panning on channel 5 (4) using 745160, or it calls 00745CF3 with the effect ID and does another raft of checking. It's bizarre.
Then we have akao/akao2 from field script. At least we know exactly how this works and it is guaranteed that one of these is going to be called in order to play an effect from the field. So, unlike battle, you aren't running around trying to disassemble the universe. The field code effects probably won't take me long to code. But the battle side of things is tougher if we want to completely replace the original engine. Unless someone can shed some light on how call 0074A795 actually uses all the data it is given to produce the effect using dsound.
But even then it may still need multiple changes elsewhere.