I can post with confidence in this megabump that this issue is with the ADPCM decoder. Either it is broken, or it is being misused.
This particular file appears to switch several channels into ADPCM mode while they are still running.
Specifically, 07bg30c.dsf. I can't really find any other startling cases of ADPCM messes, except it does seem to affect percussion in at least this file.
It is a mystery, one which I'll be taking a short break from.
E: Is there a single DSF player that can play this file without problems?
Despite lack of dsp and probably being outdated as ****, the in_aodsf plugin seemed to play them without issues... except too much positive output (for lack of better words) that screwed with volume.
As I already reported, they play back sort-of fine if you disable the DSP, but they still start to overflow.
Killing 4-bit ADPCM sample decoding nukes the drums in most of the songs, but completely fixes all volume issues, even when rendering a perfect DSP chain.
There are issues with the ADPCM decoding. I need to figure out what they are. Eventually.
I tried to create a sample logger, that would log each nibble of an ADPCM sample to a new file for each new ADPCM note, and ran into a crash with the logger. The crash was triggered by an odd address on the first nibble of an ADPCM sample, because something switched a running channel over to ADPCM mode, and this core doesn't double the sample position or halve it when switching between modes.
This stuff needs more testing against real hardware. It's not that hard to test, either. Especially since they're static DSF files.
Basically, to play them on real hardware, you just need to halt the AICA's processor, upload the data from offset 4-end of the DSF compressed section to the AICA RAM address indicated in the first four bytes as a little endian number. Then reset/start the ARM7.
Simple if you know how to program for the Dreamcast, I guess.
Bumping this edit with a link to a GENH sample. This ride cymbal decodes oddly with the known decoder, and presumably decodes perfectly fine on actual hardware:
If at all possible, a digital capture. But I know that would require capturing the input pins to the DAC? I don't even know if there's a way to do that.
So, just an analog capture.
The DSFs should be "easy" enough to play. I assume it's not too hard to boot up, with the AICA halted, upload the DSF dump to the sound RAM, then reset/start the sound processor. I haven't done any actual console programming, so I have no experience in that department.
Maybe I'll try to locate a used console on eBay or something, and eventually toy around with this stuff some day. Some day, at least.
But yeah, a lot of my contributions since the day one initial commit (which was entirely Neill's code) have been either common sense fixes, total screwups I later undid, or MAME imports that I have since dropped.
E: Feel free to post at least one DSF so I can take a look at it? Maybe I ay actually have enough knowledge to see what it's doing. Or you could try debugging it yourself.
Not really tested on real hardware (I don't know how to do that), but they did work with the in_aodsf plugin.
Here are sample files from Soul Cal. that I posted some time ago: https://www.dropbox.com/s/fu0gau8o9iewwyq/IV.7z?dl=1
On another issue, some dsf's for lilith's Gloomy Puppet Show from Vampire Chronicles appear to have broken with the update. Link to files (Specifically 2_14,17, and 18): https://www.dropbox.com/s/we7ru7h6txq10hq/GloomyPuppetShow.7z?dl=1
Please verify the Gloomy Puppet Show DSFs with the latest, version 2.0.47. I broke ADPCM decoding a few versions ago and just fixed it within a few hours ago.
As for the timing for the other stuff, I'll probably break down and replace Neill Corlett's ARM core with the ARM7 from MAME, if it'll do any good.
Looks like it's running out of voices, and not detecting that voices have ended, for whatever reason? Feel free to contribute fixes to yam.c to fix the sample control logic. I don't really want to replace the envelope code with MAME's again, though.
On another note, tested out timing for a naomi title and it seems to be more off in 2.0.47 than .46.
A few mp3s of the same track from both 46 and 47, plus a real hardware recording from youtube (https://www.youtube.com/watch?v=UoxghOaDHEc), and from demul 0.7 alpha just for reference:
Aha, the emulators are playing it too fast. Except for Demul, which is useless for this since it is a closed source emulator that documents absolutely nothing.
Maybe find some other emulator that also gets it right, and also happens to be open source?
E: Wait, I see some code on Google Code? What's up with this?
There aren't any that I know of really. Reicast might have a decent core, but I never used it since it has no Naomi support and can only find videos of people using the thing on their @^(*&^@I! smartphones.
Just found another dsf that ends up having similar issues as the lilith dsfs from an earlier post. Demolish Fist's Character Select theme(BGM_SEL) is appearenly broken on 2.0.46, but works on other players. It could be a manatee driver issue, but I doubt it.
I fixed the Gloomy Puppet Show DSFs, by clearing the channel loop bit when it is read by register. I already did this in the code that was in use in Cog, and somehow didn't transplant that into the Highly_Theoretical source repository and foo_input_ht.
I'll try to look into updating the Winamp, XMPlay, and other platform plugins that used the original ESP source base, but I'm not sure what would be involved. The original code should just build, and it should be as simple as dropping the new Highly Experimental and Highly Theoretical libraries into it.
Just a heads up: on the latest version of the plugin, a few Saturn games seem messed up. Specifically, the Radiant Silvergun games (both Saturn and STV) have artifacts for some instruments and other instruments sound drastically changed in timbre and cutoff.
I'll see if I have an older version of the plugin to do an a/b comparison, but wanted to report that here first.