That indicates that your first guess is more likely than the second.
However, I'm out for this weekend.
At least now we know the whole thing is possible. And that's good to know.

We see that sample #452 (0x01C3) and further samples up to #512 are actually present in gusdirty.wfb and not that they are much different from #451. Looks like neither of my two previous guesses is true.

Note that WFB samples have numbers from 0x0000 to 0x01FF (not 0x0001 to 0x0200, which is somewhat confusing). Thus, 452 translates into 0x01C3 and not into 0x01C4.

What we also see is that samples starting from #451 (0x01C2) till the very last #512 are not actual samples but empty aliases (while preceding samples before #451 have multisample type). They contain no sample data and there are no difference between them save for the number.

Looking into Fanta GM 8 Mb WFB, we see somewhat similar scheme: samples starting from #424 (0x1A7) are empty aliases, while previous samples are aliases either but not empty.

Thus I have a new guess: Awave Studio writes a sample block length value that differs from actual sample block size when dealing with empty aliases. Look here:

For non-empty alias in Fanta GM we see sample block size (look at the beginning of selected data) is 0x8A, and our hex editor also reports a block size of 0x8A.

But looking at an empty alias, we notice a sample block length of 0x74, while the hex editor still reports 0x8A.

Thus, a WFB loader reads all samples up to the first empty alias, but for the second alias the data read is all screwed due to the incorrect offset, which in its turn is due to a non-relevant sample block size value found in the first empty alias (0x74 instead of 0x8A).

This is yet another guess, but it explains problems with both WFB banks. If I'm right, there are two further guesses:

1) 0x74 is correct value, extra data is wrongfully written.

2) 0x74 is incorrect and should be replaced by actual 0x8A value.

I have to look into it further.

In the case of Awave writing the WFB incorrectly, perhaps you can try to open it in Wavefront Studio? I think that is the Turtle Beach tool to create WFB files.

Where do I find that Wavefront Studio?

Anyway, here's another quick and dirty fix. Now there are 512 samples, but that bugged alias type sample sizes are changed to relevant values, that is from 0x74 to 0x8A.

http://geryon.ru/gusdirty2.zip - GUS
http://geryon.ru/fg8dirty2.zip - Fanta GM 8

bristlehog wrote:

Where do I find that Wavefront Studio?

it's in the package linked to in the first post
https://www.dropbox.com/sh/74c9dol7lls9xbn/SM … pps_goodies.rar

stamasd wrote:

it's in the package linked to in the first post
https://www.dropbox.com/sh/74c9dol7lls9xbn/SM … pps_goodies.rar

I don't see it. What folder is it in?

I believe it's in the WaveSE 1.1 and 1.3 folders. Can't check right now because I'm at work.

stamasd wrote:

I believe it's in the WaveSE 1.1 and 1.3 folders. Can't check right now because I'm at work.

There's no Wavefront Studio in that folders, but WaveSE sound editor. It doesn't understand WFB format.

There is, however, some WavePatch program (wavepatch folder), that might be what we search for, but it requires a WaveFront compatible synthesizer to start, so I can't run it until my Maui arrives.

I just tried converting some SF2 banks with Awave Studio 11, but it seems there is a sample limit at 348 on exporting.

Edit: Just got a "too many samples" warning on a 1 Mb soundfont with 152 waveforms, so something else is going on.

Edit2: When I export some small soundfonts to Gravis Ultrasound Patches + INI and load that, I see a huge number of waveforms. The soundfonts rely heavily on linked waveforms I guess.

FMJ software told me that the WFB file format is limites to 256 "patches" and 512 "samples".

Meanwhile, I have found WaveFront patches and banks specifications and converted them from Windows Write format to plain text.

Also, in README.WRI of WavePatch it's mentioned that Maui OS has at least a version of 1.18:

1A new feature in version 1.18 of the Maui operating system caused a crash in WavePatch.

Explanation of what programs, layers, patches and samples are in terms of WaveFront synthesizers is available in WavePatch's help file.

Help file is attached. If you have troubles opening it in your version of Windows, use either Microsoft's WinHlp32 (pre-Windows 10) or Help Explorer Viewer if you have Windows 10.

Thanks for your trememdous effort, bristlehog!
Thanks also to rawit and stamasd for contributing!

Looks like we get closer and closer to achieve our main goal.
It is great to learn how these WFB banks work in detail. Can't wait to test the new conversions!

Unfortunately I'm a bit sick at the moment but I think I can do the following things at the weekend:

- Test the new converted soundbanks
- Add all the new resources to the first posting
- Add some thoughts regarding this and that

I'm also very appreciative of all of the ingenuity and hard work put into this project. I can also try to test this weekend on my Maui.

Just a quick feedback from testing:

The Fanta 8MB bank failed with this error:

The GUS 6MB bank loads fine:

The bank is fully usable in games and Midi players, but the quality of some samples is really bad (drumkit), the volume alignment of the samples is also bad. But this is of course not a fault of the conversion. Although I didn't check it with the "original" .SF2 bank I suspect it sounding the same. Side observation: The Strings sample has quite a bit of reverb - must be prerecorded as I tested the soundbank with the MAUI. Although the conversion works fine I wouldn't recommend it over the default bank in the ROM of the MAUI.

I weren't attentive enough and screwed that FantaGM 8 bank by carelessly replacing every 0x00000074 with 0x0000008A. There were instances of 0x00000074 not corresponding to sample size, just by coincidence parts of some samples' bodies. Example:

But it's okay - just my stupid mistake. What's more bothering is this:

We see that sample #72 somewhy has its size written as 0x74, but clearly it's much bigger as it contains embedded sample data. That's how the bank got corrupted: I replaced that 0x74 by 0x8A, and the next sample #73 was read, consequently, from wrong offset, thus getting totally screwed as we can see at Fabian's screenshot: the sample number is all wrong (704 instead of 72), the sample name is some piece of pseudo-graphics etc.

It seems that I don't quite understand the meaning of that 0x00000074 piece of data. I have to research and think where my mistake is.

Meanwhile, here's the third version of Fanta GM 8:

http://geryon.ru/fg8dirt3.zip

It has been fixed the way that only sample #424 and further samples have their 0x74 value changed to 0x8A.

I have looked into it a bit further. Looks like 0x74 is the size of a structure containing sample information:

1struct WaveFrontExtendedSampleInfo
2{
3    DWORD dwSize;               // Size of this sample, including this struct and any following data
4    int   nSampleType;          // ST_SAMPLE, etc. constants from WFSYNTH.H
5    int   nNumber;              // The original location of the sample
6    char  szName[NAME_LENGTH];  // Name of the sample
7    DWORD dwSampleRate;         // Sample rate in Hz
8    DWORD dwSizeInBytes;        // Size of the sample data itself, in bytes
9    DWORD dwSizeInSamples;      // Number of samples in the file
10    UINT  nChannel;             // CH_ constants from WAVE.H
11    BYTE  byUnused[62];         // For expansion
12};  

I haven't found NAME_LENGTH constant anywhere, but empirically I can say that it's equal to 32 (0x20):

Thus, sizeof(WaveFrontExtendedSampleInfo) should be equal to 0x74. Here's the contradiction - on the one hand, first DWORD of sample header should represent the full size of sample:

1DWORD dwSize;               // Size of this sample, including this struct and any following data

It's confirmed in FILES.WRI:

1As an example of the above, here's how a sample would be stored in both embedded and unembedded format. Let's assume this is a 16 bit, 44.1 kHz mono sample which is 4096 bytes long. Its filename is C:\WAVES\TEDDY.WAV, and its internal name (as displayed in WavePatch) is "Teddy Belches".
2
3...
4
5Embedded:
6WavePatchExtendedSampleInfo:
7dwSize = sizeof(WavePatchExtendedSampleInfo) + sizeof(SAMPLE) + _MAX_PATH + 4096;
8nSampleType = ST_SAMPLE;
9nNumber = whatever;
10szName = "Teddy Belches";    // NAME_LENGTH bytes total
11dwSampleRate = 44100;
12dwSizeInBytes = 4096;
13dwSizeInSamples = 2048;
14nChannel = CH_MONO;
15byUnused = a_bunch_of_zeros; // 62 padding bytes (for expansion)
16SAMPLE:
17whatever;
18PathName:
19"EMBEDDED";                  // _MAX_PATH bytes total
20DATA:
214096 bytes of sample data

On the other hand, in sample #72 of FantaGM 8 that DWORD is equal just to sample header size (0x74), and everything breaks if we change this value. And on the yet another hand (think we stumbled into an octopus), for (some?) alias type samples, setting that DWORD to 0x74, vice-versa, breaks everything.

The 3rd conversion of the Fanta soundbank loads without any error but sounds odd. In GSPLAY it seems some instruments are missing (Slow strings, Synth strings1, Cello) or sounding like the samples have noise / cracking.
I will test the Fanta 8MB bank with a SoundBlaster 32 later today to compare the sample quality.

//edit: Can't find the FantaGM 8 .SF2 file anywhere, but can find the FANTAGM2.SBK , don't know if they are the same but I suspect they are different revisions with tuned / replaced samples. Maybe you can upload the FantaGM 8 .SF2 from your collection?

FGB wrote:

Can't find the FantaGM 8 .SF2 file anywhere, but can find the FANTAGM2.SBK , don't know if they are the same but I suspect they are different revisions with tuned / replaced samples. Maybe you can upload the FantaGM 8 .SF2 from your collection?

Can't upload before Tuesday (it's on the external hard drive). FANTAGM2.SBK is not the same bank, so we can't rely on it.

Let's use another bank:

http://geryon.ru/FF7.sf2
http://geryon.ru/ff7hack1.wfb - hacked by changing 0x74 to 0x8A in 'alias (mute)' type samples