That's probably the ADPCM. The ADPCM encoding is the biggest difference between S-YXG50 and the MU50. All the long samples, like the acoustic pianos, is always U8 on S-YXG50, but mostly ADPCM on hardware. Both formats are 8-bits per sample, but the ADPCM should come out with a lot lower noise, perhaps at the cost of some frequency response

until recently, it wasn't possible to decode the ADPCM accurately, any samples that used the running delta modes had issues. Like *very* recently, I had to rewrite my decoder yesterday based on tarboh's work

I don't have a good bar chart setup for this but here's the raw data for sample formats on the GM mode patches in GS mode across S-YXG50, MU50 and MU80
https://pastebin.com/un97i9My
The u16 samples used by S-YXG50 here I believe are mostly the same sine wave used at the very highest keysplits. MU50's equivalent sine is 12-bit

Oh. i see what's goin on now. 8 bit adpcm actually can store considerably more dynamic range than 8 bit uncompressed. so decompressing them to 16 bit wav is actually correct.

Now i'm curious what would happen if the tg300b bank and mt32 got replaced with roland samples converted to the xg AWM2 format. 😀

It would be awesome if someone could make one spftsynth to rule them all. one that plays back all xg and gs midis correctly, and uses either the GS or XG gm1 or gm2 banks depending on which of xg or gs was played back first. 😀

Has anyone seen these two variants of the S-YXG50 by OnjLouis? They seem to be interesting, especially the S-YXG2026 Hybrid.
S-YXG100-Hybrid --> S-YXG50 + S-YXG100 VL/PVL + SG
S-YXG2026-Hybrid --> S-YXG2006LE, but apparently fully XG capable, thanks to using S-YXG50 as fallback

I had no idea, but I'm gonna check out that first one. It looks like something I've been hungering for.

Interesting idea there, but I think what we really want is to extract the patches from 2006 le and replace the matching ones in s-yxg50, or to upgrade 2006 if it has more effects in it.

Keeping the S-MU2000 plugin up-to-date is almost impossible right now. The guy is doing commits on his Github with almost demonic speed.
Meanwhile: I'm using this in combination with the Doom source port Woof!. By default, it is doing GM MIDI resets (can be changed via config). Should I switch this to GS or it's irrelevant here?

MaliceX wrote on 2026-09-16, 17:31:

It's practically indistinguishable from my MU2000 now, from the past 72+ hours of A/B-ing various examples over the years.

Some of us have waited for this to exist for over 20 years and it's finally here! 🤣

But yeah, definitely emulating a full CPU, even with optimizations, is always gonna be heavier. But it's basically a substitute at this point. Was thinking of attempting to do a WASM build but after seeing the interpreter performance first-hand with the VST2 experiment, I'll leave that to someone else more willing to waste time 😁

Depending on what tarboh wants to do with it once everything is mapped to hardware emulation there is then opportunity to take that and refactor into pure native dsp equivalence and see a lot of performance improvement. This is exactly why I started MUXG2K a couple of years ago. Here's the rough picture:

On a single core, our native C++ engine runs a MU2000 reverb at ~250× real-time and a single held note at ~600× — roughly ~0.4% and ~0.16% of a CPU core respectively. Software Emulating the same on the real SWP30 chip costs ~45% of a core regardless of how much is playing, because the hardware processes every voice slot and its full 384-step effects DSP every sample whether they're used or not. So the native version is on the order of ~100–285× lighter for a single reverb or note, narrowing to ~5× only at full 64-voice polyphony — which is exactly why we use the emulator as an offline accuracy reference but ship the native DSP. For DAW use emulation is difficult because even if you want a single voice, really all voice slots are hitting the CPU, not just one.

We already know this, because you'll see SYXG50 is doing much of an MU2000, just natively and barely touching the CPU, so you expect 200 to 600x Realtime performance capability.

Main issues with s-yxg50 is the 16 bit loop offset limit, and only the variation effect block, and no insertion effects.

if it has all the effect blocks and effects added to it, as well as the bigger patch table, it would essentially be a mu2k. but that one is still a playback vsti, with no DAW contrrols.

I can't reply to PMs yet but thanks for the table Zaphod

YMF-754Hi looks like an early version of the Vampire engine. It's the same as a regular S-YXG50 table, but all offsets have been expanded to 32-bits. It's an important step, no doubt, but the tables are unmodified, so the two biggest chokepoints in the table format remain: Wavedata entries limited to 255 (it uses 247) and the 24-bit loop address (it's at 10MB out of 16MB)

Shame about the GS breaking in the later version. The Vampire table has a full GS program definition section, too, but it looks like they disabled the GS bank definitions intentionally because they weren't addressing correctly

So can you fit the mu80 in without popping?

btw there are two other engines. the 2006 le engine which is xglite only, and an even later engine, but it only comes with a SINGLE lousy sample.

If anyone can figure out the latter ones bank format.....

what you are looking for is S-YXG2011EE.exe
oh. this apparently just loads a single instrument, and comes with the expansion editor. so it know show to play back a single voice. but it likely has a reasonably complete AWM2 engine inside it.

I have SYXG50 reverse engineered into C++. I did most of it 2 years ago when scoping if it could be modified to use decoded MU2000 voices and realised it was only capable of 2 element voices so stopped digging. I think it should compile into a VST3 or CLAP no problem. Would need more work on the Effects. I'll see if I can finish it today.