and BTW, I even forgot about that the so highly praised here S-YXG50 4MB Bank is buggy:

Re: Yamaha Sequence Object Linking (SOL) 2

and in reality it's worst than the 2MB one - and yeah Yamaha's bug, it was released by them like that - I guess it's beneficial to me even to re-read my own old posts.

mattw wrote on 2023-10-30, 20:57:

and how many times I explained and proved in this very thread that is neither true, nor the case. What I don't understand is why @Falcosoft is making such statements when he can program much better than I can, i.e. I cannot do anything even close to his MIDI Player (and thank you for it!), when he can just open the MAME source code where the decompression algorithms of the real hardware Device WaveROM are documented:

Hi,
Sherman claimed:

I'm pretty sure the samples that come with that portable S-YXG50 are not the ones that were originally shipped with the softsynth. It is a 4mb sound bank, not sure where from, but potentially one of the MU devices.

That is he claimed that the portable Veg version samples are NOT from the original (SOL2) but most likely from one of the MU devices.
Then I claimed:

And I'm pretty sure that they are the same.

That is the samples in Veg's version are the same that come from the original (SOL2).
And then you claim:

So, for, I don't know, at least, 10th time, S-YXG50 4MB bank comes from SOL2:

And my whole argument was based on this so it's hard to understand how you could misunderstood it...
Please, read more carefully next time...

mattw wrote on 2023-10-31, 01:00:

and BTW, I even forgot about that the so highly praised here S-YXG50 4MB Bank is buggy:

Yeah, you claim it is buggy the 2nd time , but you have given no proof of it even once.
You have written at the other topic:

What's interesting about the VSTi is that its 4MB bank has broken drum sets and because of that sounds worse than the 2MB bank.

So please, be more specific so that we can test it. It's obviously not true that (all) drum sets are broken so an example Midi file or checking process how to confirm your claim would be helpful.

Falcosoft wrote on 2023-10-31, 04:40:

so it's hard to understand how you could misunderstood it...
Please, read more carefully next time...

I apologize if I misunderstood what you meant. In any way, as soon as I find some time (which may be never), I will code a small tool that decompresses the whole bank - in case someone else wants to do it, here is some information, I prepared so far:

the main Wave-Data-Table (WDT) is located @ offset 0x707E6 of v1.04, May 22, 1995 Control ROM (based on that it's easy to be located in v1.05, Aug. 21, 1995 Control ROM as well). each entry in that table is 0x10 bytes in size. So, let's take one sound as example:

1WDT@ ControlROM offset 0x0x707E6 [+0x3680] :
2450000FD000 001001390C3870040FF00

changing the Endianness and adding some format in order to easy read it:

100 45FD 00 0000 00 0190 1387C2 4000 00FF

then:

1main_adr = (wdt_entry[0x9]<<16) + (wdt_entry[0xa]<<8) + wdt_entry[0xb];
2loop_ofs = (wdt_entry[0x7]<<8) + wdt_entry[0x8];
3start_ofs = (wdt_entry[0x4]<<8) + wdt_entry[0x5];
4
5sample_fmt = wdt_entry[0xc]; //always value 0x80 in x86 (8-bit), in the above 12-bit case example it's 0x40
6
7bytes_width  = (sample_fmt  == 0x80) ? 0x01 : 0x02; //TODO: needs to be changed to take into account 12-bit samples
8
9sample_ptr = main_adr - start_ofs*bytes_width; //start_ofs and loop_ofs indeed are in "in units of samples"
10
11sample_size  = main_adr + loop_ofs*bytes_width + 1;

Falcosoft wrote on 2023-10-31, 04:56:

Yeah, you claim it is buggy the 2nd time , but you have given no proof of it even once.

the post here:

Re: Yamaha Sequence Object Linking (SOL) 2

has screenshot of the About menu of the VST where that is fixed - if you have that VST you can make tests for yourself. do you see I have a history I claim something that is not proven to be truth or if it turns out that I am wrong that I don't admit it and correct myself? I am not interested in such fruitless discussions, especially when I spent already so much time and I just don't want to waste even more.

[EDIT] and after all - everyone is free to use what he/she believes is correct and sounds good. I don't have a goal to convince people in anything, even less shatter their believes.

mattw wrote on 2023-10-31, 05:02:

has screenshot of the About menu of the VST where that is fixed - if you have that VST you can make tests for yourself. do you see I have a history I claim something that is not proven to be truth or if it turns out that I am wrong that I don't admit it and correct myself? I am not interested in such fruitless discussions, especially when I spent already so much time and I just don't want to waste even more.

To be clear: I did not want to be personal. I have just written about what I found.
And still you have given us no details about what to test on that VSTi that allegedly fixed the problem. So once again: Please at least tell me/us which drum set has the bug (Standard, Room, Rock kit etc.) and at what note the bug can be found.
Or just refer to an example Midi file where the difference between the fixed and the wrong drum sound can be heard.
Thanks in advance.

@Edit:
After re-reading my 2nd post of today I had to realize that it could be considered somewhat offending. I apologize for this.
To my excuse all I can say is that maybe I was a little too hot-tempered when I read that you totally misrepresented what I said and otherwise reacted nothing to the real argument and implicit question. That is:
How is it possible that a so crappy and crippled (moreover buggy) VSTi with the original (SOL2) 22kHz/8-bit samples produced so good sounding recordings that are difficult to distinguish from even the MU-80?
I refer to these recordings:
https://archive.org/details/DOS-Gaming-Genera … MIDI-Comparison

DB60XG(XR712) and NEC OEM XR385 both use same program ROM (XR560B0) and are identical functionally, with only difference being in the silkscreen on PCB. There's no different startup mode etc. as mentioned some posts back.

Hiya, author of the Grand MS-DOS gaming General MIDI showdown here.

Like some of you guys said, the difference between Veg's hacked/"liberated" S-YXG50 and the Yamaha MU80 is indeed extremely small. You can read my evaluation of the S-YXG50 VSTi vs MU80 hardware here. I don't claim to understand what sample set Veg's VSTi uses, but to my ears it sounds 95% identical to the MU80, and I've compared no less than 46 very different DOS MIDI soundtracks (check out the recordings, all available in FLAC on archive.org). I've been doing music production for over 30 years now and I'm using good quality equipment—there is some difference in the overall sonic signature between the VSTi and the hardware, but it's rather subtle, and to my ears the sample sets are practically identical (barring one flute sample I mentioned in my summary).

I'm looking forward to the day when we can integrate an authentic MU80 emulation into DOSBox Staging, similarly to the MT-32/CM-32L stuff. Veg's S-YXG50 is very nice, but it's a 32-bit Windows VSTi, so adding built-in cross-platform support for the Yamaha would be a very nice enhancement. I'm quite impressed that the MAME guys have also reversed the effects DSP; the stellar reverb algos of the Yahama MU80 are essential to the module's sound (it's a league above the SC-55's reverb, in my opinion; so much richer and more "3D").

Regarding the night and day differences in the various sample sets, 8/16-bit, 22/44-kHz, whatnot... Dunno, I treated the hardware and the portable plugin as black boxes, only judging them by the actual audio output they produce and I don't particularly care about the technicalities. If it sounds good, it's good 😎 Also an interesting note from Veg's site about the portable version:

The patch doesn't affect sound synthesis of the original VSTi. It was tested on hundreds of MIDI files to ensure that the output is bit-identical to the original S-YXG50 VSTi with the same settings.

So according to him the S-YXG50 always sounded like that. But like I said, I don't care about the technicalities 😀

There were a few Mame commits around the MU50 code in the past week. So yesterday I build a new SVN version. But the main things that sounded broken, still sound broken. So we will have to be patient.

gerwin wrote on 2023-11-10, 18:17:

There were a few Mame commits around the MU50 code in the past week. So yesterday I build a new SVN version. But the main things that sounded broken, still sound broken. So we will have to be patient.

It is improving, but yeah, I'm still hearing plenty of issues.

Note, for those on Windows who don't want to try and compile MAME (it looks rather daunting!), Windows builds are available from the "Actions" tab in Github.

This is VERY interesting.

i know for a fact that the db50 (and sw60) were intended to be a mu-50 on a pc card, not a mu-80.

that's why it was called the db50 in the first place. it even does the qs300 stuff that the mu-50 does.

actually tested this. it's definitely not there yet, but effects do seem to work.

here's a good reference recording of a real mu-50 and an xg midi that uses a decent amount of effects and dynamics.

https://www.youtube.com/watch?v=5YZ6_sn8Uh8

this is the famous children (xg) midi file that's floating around, on an actual db50. when mame sounds like this, things should pretty much be done. 😀

From listening to this it has merit, but has some serious playback issues.

so does anyone have the 16 bit samples gotten from mame for the softsynth?

people said this is doable but i have no idea how to make the full wavetable.

If it would help, I could post a link to the original Yamaha SY-XG50 softsynth. You'd need Win7 or earlier to install it. I also have the VST dll for the SY-XG50 (it's just over 4.5mb), that works great with the midi plugin for Fubar2000.

The syxg50 .sf2 file floating around sounds absolutely nothing at all like the SY-XG50.

no, that's wont help. i need to change the wavetable for the s-yxg50 vst to the actual decrypted waves from the real rom.