Sound effects quality issue

[jayare5]

Many sound effects no longer sound as good as they used to in older versions of Picodrive.
An easy sound test is Sonic The Hedgehog 2, when the game's logo appears.
Or one can go to the sound test menu, first play sound 1D (it is a short song that will stop the music from playing when it's done so we can isolate SFX) and then play sound 35 which is supposed to sound very clean, but sounds "dirty" in the lastest version of the core.

Another good test is Streets of Rage 2's sound test menu, specifically SE 09.

The issue is specifically noticeable in high frequency sounds. Tried all the core options but nothing seems to fix it!

It seems that this problem came after this commit: d127b3f

[irixxxx]

This is a consequence of irixxxx#50. I guess that could only be avoided by adding a better resampler from the internal rate of the ym2612 down to 44.1 KHz. The current "resampler" is nearest neighbour without any filtering, which creates aliasing in the high spectrum. A multiphase resampler would probably solve this, but is computationally rather expensive.
I reckon you need very good hearing for frequencies close to the Nyquist frequency (22.05 KHz) to note it. My hearing definitely isn't good enough for that ;-)

[irixxxx]

Definitely a resampling artifact. I can see it if I do recordings at different sample rates and view the spectrum in audacity. I can clearly see the differences there. Try different sample rates, you will most probably hear the difference as well.
However... there's no readily usable short term solution. I can't revert this since the old code had audible artifacts elsewhere (e.g. in Thunder Force III). I can't easily add filtering since a reasonable quality probably requires a multiphase FIR with a lot of taps, which is computationally expensive and would contradict the concept of Picodrive.
What could be done is to offer an additional sampling rate of 53266 Hz - the native sample rate of the ym2612 chip. That would most probably be a remedy to this. But is that acceptable?

[hizzlekizzle]

I think libretro cores typically expect the frontend to resample the output anyway, so it should be fine, I would think.

[jayare5]

It would certainly be worth a try!

If it doesn't work, can it be optional? (Although if it was, users would have to know when to switch, and that would require already knowing games beforehand...)

In the end I accept that emulators can't be all that accurate while also being really fast, but I already thought Picodrive was really good as I actually never found any differences between original hardware and the emulator with all the games I own, until this sound commit, now I couldn't play Sonic with it sounding like this and the Sega CD boot is a bit unpleasant too. I think that's a big sacrifice for Thunder Force III. (Are there many games that shared TFIII's problem though?)

[irixxxx]

Everything using operator feedback was IMO calculated wrongly. However IDK how rampant the usage of this feature is, I've never done statistics.

[irixxxx]

Not really fixable with neither the old nor the new code without introducing some noticeable overhead.
However, I believe this to be greatly improved by 882f697, e2e2b6a, 68a9508.

Try either the native rate setting, or another rate with FM filtering, whichever is faster on your platform. Both should produce better quality sound output at the price of the overhead.
Non-native rates without filtering will produce wrong sound similar to the old code.

[irixxxx]

Since my own tests show substantial improvements and no other feedback.