Topic: Proposal to support rmid files with embedded SF2 soundfonts in Bassmidi

[Falcosoft]

Hi Ian,
My Midi player (FSMP) has been supporting Riff Midi files (*.rmid) with embedded SF2 soundfonts for years. Not so long ago user Spesek contaced me at Vogons forum that he would like to support the same format in his own synth SpessaSynth. We have talked about the details and he has made an official specification of the format:
https://github.com/spessasus/SpessaSynth/wiki/About-RMIDI

He also contacted the maintainers of Fluidsynth and it seems they are willing to support the format.

What do you think about including support in Bassmidi for this format? By supporting I mean that when BASS_MIDI_StreamCreateFile() loads files in this rmid format it should load the embedded SF2 soundfont together with the Midi and it should place the soundfont automatically at the proper bank (according to specification).
Maybe XMPlay can also support it...

Thanks in advance.

PS:
I have attached an example rmid file (GRABBAG_EmbeddedSF2.rmid. This was made before the official specification, but it is still valid).
And here is a link to an rmid file (Rock_test.rmi) that is an example for a scenario where the embedded SF2 is only for a variation tone at bank 1 and thus the rmid relies on a main GM/GS soundfont already loaded at bank 0.
https://www.vogons.org/download/file.php?id=198637

Anotther example file has been uploaded by Spesek here (with more complete INFO chunks):
https://www.vogons.org/download/file.php?id=198686

@Edit:
BTW, I think Spesek would like to support also compressed SF2Pack format soundfonts (SF3 is already supported by his synth). FSMP already supports compressed SF2Pack format soundfonts for embedding (thus for FSMP not only 'sfbk' but also 'sfpk' is a supported chunk type) but he has not found the specification of the format. His synth is a Javascript library and it is independent from Bass/Bassmidi.
Can you help?   
 
 

[Ian @ un4seen]

My Midi player (FSMP) has been supporting Riff Midi files (*.rmid) with embedded SF2 soundfonts for years. Not so long ago user Spesek contaced me at Vogons forum that he would like to support the same format in his own synth SpessaSynth. We have talked about the details and he has made an official specification of the format:
https://github.com/spessasus/SpessaSynth/wiki/About-RMIDI

He also contacted the maintainers of Fluidsynth and it seems they are willing to support the format.

What do you think about including support in Bassmidi for this format? By supporting I mean that when BASS_MIDI_StreamCreateFile() loads files in this rmid format it should load the embedded SF2 soundfont together with the Midi and it should place the soundfont automatically at the proper bank (according to specification).

That sounds interesting, I'll look into it.

BTW, I think Spesek would like to support also compressed SF2Pack format soundfonts (SF3 is already supported by his synth). FSMP already supports compressed SF2Pack format soundfonts for embedding (thus for FSMP not only 'sfbk' but also 'sfpk' is a supported chunk type) but he has not found the specification of the format. His synth is a Javascript library and it is independent from Bass/Bassmidi.
Can you help?   

An SF2PACK file is the same as the original SF2 file but with "sfbk" changed to "spfk" in the RIFF header, which indicates that the "smpl" chunk contains encoded sample data. If the original sample data was 24-bit then the "sm24" chunk will have been removed and its data combined into the "smpl" chunk, so the decoded data may be 24-bit.

[Falcosoft]

...
An SF2PACK file is the same as the original SF2 file but with "sfbk" changed to "spfk" in the RIFF header, which indicates that the "smpl" chunk contains encoded sample data. If the original sample data was 24-bit then the "sm24" chunk will have been removed and its data combined into the "smpl" chunk, so the decoded data may be 24-bit.

Thanks Ian,
Can you tell what is the main difference compared to SF3 (besides the 'sfpk' chunk and 24-bit sample handling)?
I'm asking because Spesek already has working SF3 (ogg/vorbis compressed) handling routines but when he tried my SF2Pack (ogg/vorbis compressed, too) soundfont he only could get garbage samples.

[Ian @ un4seen]

Can you tell what is the main difference compared to SF3 (besides the 'sfpk' chunk and 24-bit sample handling)?

The main difference is that SF2PACK keeps the sample data in one big block, as it is in the original SF2, which means the original sample info does not need to change. You would initialize a decoder for the entire "smpl" chunk. And then when you want to decode a sample from it, you would seek to the sample's start position in the decoder instead of directly in the file.

[Falcosoft]

Can you tell what is the main difference compared to SF3 (besides the 'sfpk' chunk and 24-bit sample handling)?

The main difference is that SF2PACK keeps the sample data in one big block, as it is in the original SF2, which means the original sample info does not need to change. You would initialize a decoder for the entire "smpl" chunk. And then when you want to decode a sample from it, you would seek to the sample's start position in the decoder instead of directly in the file.

Thanks!
One more question (maybe this should have been the fisrt...):
Is the SF2PACK format free/open in the sense that it can be used in open source projects (without using Bassmidi)?

[Ian @ un4seen]

Sure! Feel free to do what you like with it.

[Ian @ un4seen]

Is the "RMID with SF2" spec finalised or are changes still possible? If changes are possible then I think it may be best to leave out the new "DBNK" chunk, or at least make it default to 0. That would allow an embedded SF2 to be interchangeable with an embedded DLS, as in this earlier spec:

   https://web.archive.org/web/20110610135604/http://www.midi.org/about-midi/rp29spec(rmid).pdf

[spessasus]

Hi, spessasus here. (The co-creator of the standard and the writer of the spec)

The DBNK chunk may be changed if it's needed, but the offset of 1 will have to remain to stay compatible with older SF2 RMIDI files.
Also, the default offset of 1 was Falco's idea. The older sf2 RMI files (such as the grabbag in examples folder) which didn't use the DBNK chunk, would assume offset of 1.
Falco's reasoning for this were the old creative! demos which would use a full GM soundfont at bank 0 and a special one (which he embedded in the RMID, creating the standard) at bank 1. So the default offset will have to be 1, but I've added that the recommended offset should be 0.

Also I've added a clarification (maybe you've missed it)

https://github.com/spessasus/sf2-rmidi-specification?tab=readme-ov-file#handling-differences

Here it says that if a DLS soundfont is encountered instead of SF2 one, it should ignore the DBNK chunk and assume offset of 0, thus maintaining compability.

@EDIT: the chunk may be changed, but default offset has to stay, unless we want to break older SF2 rmidis

[Falcosoft]

Is the "RMID with SF2" spec finalised or are changes still possible? If changes are possible then I think it may be best to leave out the new "DBNK" chunk, or at least make it default to 0. That would allow an embedded SF2 to be interchangeable with an embedded DLS, as in this earlier spec:

   https://web.archive.org/web/20110610135604/http://www.midi.org/about-midi/rp29spec(rmid).pdf

Hi Ian,
Besides what Spessasus said a further reason for supporting bank 1 and keep this as default is older Creative SF2 HW synths that could not handle changing the deafult soundfont (or overwriting presets) at bank 0 through SFMAN32 API calls. Otherwise they can work perfectly with the new standard (I have actively tested this). Maybe you are aware but I mention this anyway that the bank 1 convention was introduced by Creative Labs when it released Midi+SF2 demo files. These pairs can be included without problems into this new container format but they only work with bank 1 offset.
I do not think that dls compatibility is more relevant in this context than supporting SF2 hardware synths.
Here are some example Creative Midi+SF2 demo files that I'm talking about:
https://www.vogons.org/download/file.php?id=197052
 
Moreover supporting bank 1 (or any other bank offsets) is not an obstacle for any of the newer software based SF2 synths I know of. So supporting bank 1 does not affect any HW or SW synths negatively but leaving out the support would affect
some HW based SF2 synths negatively.

PS:
Creative WaveSynth for SB16/AWE32/AWE64 (that is actually a soft synth from Seer Systems) has the same constraint as mentioned HW synths:
You cannot change its fixed GM bank at bank 0 or overwrite any presets at bank 0 through SFMAN32 API calls.

[Ian @ un4seen]

My thinking was that an embedded soundfont is likely to be custom created anyway (eg. only containing needed presets/samples), so the required bank number could be set there at the same time instead of in a separate "DBNK" chunk. That would be cleaner in my opinion (DLS interchangeability is a bonus). I hadn't considered those Creative demos, but the bank number could be changed to 1 in those soundfonts before embedding? It is an extra step, but a fairly simple one, eg. programatically update the file's sfPresetHeader values, or manually in Polyphone you can select all presets to change them all at once. Are there already many of these RMI+SF2 files out there, making it impractical to change things now?

A BASSMIDI update it pretty much ready now, including support for the "DBNK" chunk, but I would prefer to get rid of that part

[spessasus]

Hi Ian,
I agree with the way you think. My program always exports RMIDIs as DBNK 0 and the soundfont is automatically trimmed to contain the needed stuff just like you've described. And to be honest, I still don't get why the bank offset is even a thing, but again, it was Falco's idea.

There aren't many RMI files out there to be honest, so changing it now would not make a big difference (and it would make the spec a lot simpler  ) So yeah, it's a good idea to remove it IMO. And the creative demos can be simply edited (just move the soundfont's bank up by 1) which would be a better option than complicating the standard for just a few demos.

Though unless Falco agrees to deleting DBNK, it will have to stay (he's this new standard's creator after all).

[Falcosoft]

My thinking was that an embedded soundfont is likely to be custom created anyway (eg. only containing needed presets/samples), so the required bank number could be set there at the same time instead of in a separate "DBNK" chunk. That would be cleaner in my opinion (DLS interchangeability is a bonus). I hadn't considered those Creative demos, but the bank number could be changed to 1 in those soundfonts before embedding? It is an extra step, but a fairly simple one, eg. programatically update the file's sfPresetHeader values, or manually in Polyphone you can select all presets to change them all at once. Are there already many of these RMI+SF2 files out there, making it impractical to change things now?

A BASSMIDI update it pretty much ready now, including support for the "DBNK" chunk, but I would prefer to get rid of that part

Hi,
I'm a little bit surprised that you are so against the "DBNK" chunk since the same function is available in BassMidi's HSOUNDFONT structure's bank field
Quote from Bassmidi's documentation:

When using all presets in a soundfont, the bank member is a base number that is added to the soundfont's banks. For example, if bank=1 then the soundfont's bank 0 becomes bank 1, etc. Negative base numbers are allowed.

https://www.un4seen.com/doc/#bassmidi/BASS_MIDI_FONT.html
(To translate the "DBNK" chunk to Bassmidi's terms it is exactly the same as the above quoted bank field that tells the sounfont engine where to load the soundfont in the Midi space.).

And with this option Bassmidi actually reflects the working logic of Creative's Soundfont Bank Manager. That is you can assign a soundfont to a bank in the Midi space independently from the eaxact bank numbers used by the soundfont. And the Creative demo files rely on this logic (that Bassmidi already supports...).
So I still consider the "DBNK" chunk as a useful addition that can increase the versatility of the format.

[spessasus]

This standard isn't designed to replicate BASSMIDI's behavior. Instead, it's essentially a wrapper for combining SF2 and MIDI into a single file. The DBNK chunk adds a layer of complexity that seems unnecessary.

The primary use for DBNK appears to be for the Creative demos, which is a rather niche application. Even for those demos, a simple adjustment, like raising the bank number by 1 in the soundfont, could address the issue with minimal effort.

I understand that supporting legacy features can be important, but I'm curious about the significance of maintaining support for these older demos. Do they have enough impact to justify adding this complexity to the specification?

Also imagine that someone wants to implement the spec.

They look at it and go: "Alright, this is just 2 RIFF chunks, that's easy" and then they read the DBNK section and think: "...what? Now way, I'm not adding this. This would require rewriting a lot of code."

Not to mention that the DBNK offset creates issues with things like the XG drum channel (Which is undefined in the spec). FSMP6 expects bank msb 1 to be sent on offset 1, while spessa expects 127.

Overall, I think it is better to just remove this chunk and avoid the potential confusion for the developers looking to implement this format. MIDIs that used a bank offset could be adjusted like Ian suggested, eliminating all purpose the DBNK chunk (currently) serves .

[Falcosoft]

This standard isn't designed to replicate BASSMIDI's behavior. Instead, it's essentially a wrapper for combining SF2 and MIDI into a single file. The DBNK chunk adds a layer of complexity that seems unnecessary.

The primary use for DBNK appears to be for the Creative demos, which is a rather niche application. Even for those demos, a simple adjustment, like raising the bank number by 1 in the soundfont, could address the issue with minimal effort.

I understand that supporting legacy features can be important, but I'm curious about the significance of maintaining support for these older demos. Do they have enough impact to justify adding this complexity to the specification?

Also imagine that someone wants to implement the spec.

They look at it and go: "Alright, this is just 2 RIFF chunks, that's easy" and then they read the DBNK section and think: "...what? Now way, I'm not adding this. This would require rewriting a lot of code."

Not to mention that the DBNK offset creates issues with things like the XG drum channel (Which is undefined in the spec). FSMP6 expects bank msb 1 to be sent on offset 1, while spessa expects 127.

Overall, I think it is better to just remove this chunk and avoid the potential confusion for the developers looking to implement this format. MIDIs that used a bank offset could be adjusted like Ian suggested, eliminating all purpose the DBNK chunk (currently) serves .

First and foremost the standard would like to be as compatible with every SF2 compatible synth engine as it can be. This includes hardware based SF2 synths. If you exclude the  DBNK section then to preserve compatibility you have to drop Bank 0 as a default for the standard since you cannot overwrite Bank 0 in case of some HW SF2 synths. So no matter how you modify the soundfont the valid default bank has to be bigger than 0 (e.g. 1). This was the starting point where the 'DBNK' idea was born since you were against the fixed bank 1 idea.
(The Creative demo files just reflect this restriction of SF2 HW synths.)
 

[spessasus]

And why would we want support the hardware synths? I just don't understand.

While I don't own one, I don't see a reason to support them at all:
According this wikipedia link the maximum amount of RAM (soundfont's size) is 64 MiB. Not to be rude, but that's really bad compared to any soft synth out there.
Why would anyone use one too? Soft synths provide more polyphony, better XG support like what’s available in BASS, and can handle larger soundfonts. Modern computers can easily manage a large number of voices, eliminating the need for hardware acceleration (is it really acceleration here?).
Additionally, the retro argument does not apply here, as this standard is brand new and not used in retro games at all.

For those who prefer hardware synths, it’s possible to use soundfonts and MIDI separately without specific support for these sound cards.

When I was new to the sfont standard, I didn't even know that hardware synths were a thing. I just thought it was the spec and that fluidsynth was the de facto standard (which it technically is nowadays, given how many things it is incorporated into). And you very much can change the bank 0 soundfont there.


So, in conclusion, I agree with Ian’s suggestion to default the bank to 0 for better compatibility with older DLS MIDIs and to remove the DBNK chunk as there's simply no point to creating a new and simple standard that is overcomplicated just so it can support 20 years old hardware...

Please reconsider the removal of DBNK chunk as it would make the format easier and widely available. Or at least defaulting it to 0 and optionally specifying bank 1 if needed as there are like 10 files with this format, so it wouldn't hurt.

[Ian @ un4seen]

I'm a little bit surprised that you are so against the "DBNK" chunk since the same function is available in BassMidi's HSOUNDFONT structure's bank field
Quote from Bassmidi's documentation:

When using all presets in a soundfont, the bank member is a base number that is added to the soundfont's banks. For example, if bank=1 then the soundfont's bank 0 becomes bank 1, etc. Negative base numbers are allowed.

https://www.un4seen.com/doc/#bassmidi/BASS_MIDI_FONT.html
(To translate the "DBNK" chunk to Bassmidi's terms it is exactly the same as the above quoted bank field that tells the sounfont engine where to load the soundfont in the Midi space.).

And with this option Bassmidi actually reflects the working logic of Creative's Soundfont Bank Manager. That is you can assign a soundfont to a bank in the Midi space independently from the eaxact bank numbers used by the soundfont. And the Creative demo files rely on this logic (that Bassmidi already supports...).

I think the difference is that those BASSMIDI and Soundfont Bank Manager options allow the stacking of multiple soundfonts to create custom soundsets, while the embedded soundfont is a single soundfont intended specifically for the attached MIDI data, so it doesn't need such flexibility/complexity.

Creative demo soundfonts modified to use bank 1 should still be usable with Creative/SB hardware, in case that's the concern? You would just need to stack them in bank 0 instead of bank 1 in Soundfont Bank Manager.

[Falcosoft]

And why would we want support the hardware synths? I just don't understand.

While I don't own one, I don't see a reason to support them at all:
According this wikipedia link the maximum amount of RAM (soundfont's size) is 64 MiB. Not to be rude, but that's really bad compared to any soft synth out there.
Why would anyone use one too? Soft synths provide more polyphony, better XG support like what’s available in BASS, and can handle larger soundfonts. Modern computers can easily manage a large number of voices, eliminating the need for hardware acceleration (is it really acceleration here?).
Additionally, the retro argument does not apply here, as this standard is brand new and not used in retro games at all.

For those who prefer hardware synths, it’s possible to use soundfonts and MIDI separately without specific support for these sound cards.

When I was new to the sfont standard, I didn't even know that hardware synths were a thing. I just thought it was the spec and that fluidsynth was the de facto standard (which it technically is nowadays, given how many things it is incorporated into). And you very much can change the bank 0 soundfont there.


So, in conclusion, I agree with Ian’s suggestion to default the bank to 0 for better compatibility with older DLS MIDIs and to remove the DBNK chunk as there's simply no point to creating a new and simple standard that is overcomplicated just so it can support 20 years old hardware...

Please reconsider the removal of DBNK chunk as it would make the format easier and widely available. Or at least defaulting it to 0 and optionally specifying bank 1 if needed as there are like 10 files with this format, so it wouldn't hurt.

Because we can if we want. And I would like to. Classic hardware has its charm (together with its constarint). You appreciate it if you are a little bit retro oriented. And you should be since SF2 format itself is retro.
No one uses it anymore for serious sound engineering. DAWs use virtual instruments and even new era soundfont enthusiasts use SFZ instead of SF2.
All I wanted is a format that can be used in FSMP for both its native SF2 HW synth output and for its Bassmidi SF2 SW output. And I created it and it worked.
Now we are at the point that I should drop this beacause of ... I do not know why.
Let me be honest: I never wanted a 'standard' from this format. You wanted this. So I gladly resign as a maintainer and let you do whatever you want. I really do not care/mind.
Just let me preserve the function in my Midi player to support HW SF2 synths since me and my community at Vogons like these old hardware synths. 

[Falcosoft]

Creative demo soundfonts modified to use bank 1 should still be usable with Creative/SB hardware, in case that's the concern? You would just need to stack them in bank 0 instead of bank 1 in Soundfont Bank Manager.

You can ONLY do this through Soundfont Bank Manager manually. But you cannot do this with the help of SFMAN32 API calls. That is the problem. My Midi palyer already supports HW SF2 synths and can automatically load custom SF2 user banks with the help of SFMAN32 API calls. But if you try to overwrite anything in Bank 0 you will get an invalid bank index error (but this constraint is somewhat documented as I had already shown above).

[spessasus]

And why would we want support the hardware synths? I just don't understand.

While I don't own one, I don't see a reason to support them at all:
According this wikipedia link the maximum amount of RAM (soundfont's size) is 64 MiB. Not to be rude, but that's really bad compared to any soft synth out there.
Why would anyone use one too? Soft synths provide more polyphony, better XG support like what’s available in BASS, and can handle larger soundfonts. Modern computers can easily manage a large number of voices, eliminating the need for hardware acceleration (is it really acceleration here?).
Additionally, the retro argument does not apply here, as this standard is brand new and not used in retro games at all.

For those who prefer hardware synths, it’s possible to use soundfonts and MIDI separately without specific support for these sound cards.

When I was new to the sfont standard, I didn't even know that hardware synths were a thing. I just thought it was the spec and that fluidsynth was the de facto standard (which it technically is nowadays, given how many things it is incorporated into). And you very much can change the bank 0 soundfont there.


So, in conclusion, I agree with Ian’s suggestion to default the bank to 0 for better compatibility with older DLS MIDIs and to remove the DBNK chunk as there's simply no point to creating a new and simple standard that is overcomplicated just so it can support 20 years old hardware...

Please reconsider the removal of DBNK chunk as it would make the format easier and widely available. Or at least defaulting it to 0 and optionally specifying bank 1 if needed as there are like 10 files with this format, so it wouldn't hurt.

Because we can if we want. And I would like to. Classic hardware has its charm (together with its constarint). You appreciate it if you are a little bit retro oriented. And you should be since SF2 format itself is retro.
No one uses it anymore for serious sound engineering. DAWS use virtual instruments and even new era soundfont enthusiasts use SFZ instead of SF2.
All I wanted is a format that can be used in FSMP for both its native SF2 HW synth output and for its Bassmidi SF2 SW output. And I created it and it worked.
Now we are at the point that I should drop this beacause of ... I do not know why.
Let me be honest: I never wanted a 'standard' from this format. You wanted this. So I gladly resign as a maintainer and let you do whatever you want. I really do not care/mind.
Just let me preserve the function in my Midi player to support HW SF2 synths since me and my community at Vogons like these old hardware synths. 
OK.
Let me be honest.
I never wanted a

Alright, that's fine, the DBNK chunk can stay if you want it to.
And I didn't think of the retro feeling for the hw synths. Sorry!

So DBNK will stay as is

[Ian @ un4seen]

You can ONLY do this through Soundfont Bank Manager manually. But you cannot do this with the help of SFMAN32 API calls. That is the problem. My Midi palyer already supports HW SF2 synths and can automatically load custom SF2 user banks with the help of SFMAN32 API calls. But if you try to overwrite anything in Bank 0 you will get an invalid bank index error (but this constraint is somewhat documented as I had already shown above).

Ah OK, I wasn't aware of SFMAN32 and its limitations. Strictly speaking, the modified soundfonts wouldn't be overwriting anything in bank 0, as they don't contain anything in bank 0. Still won't work? I wonder how Soundfont Bank Manager does it then. Perhaps an undocumented API/function?

[Falcosoft]

Please reconsider the removal of DBNK chunk as it would make the format easier and widely available. Or at least defaulting it to 0 and optionally specifying bank 1 if needed as there are like 10 files with this format, so it wouldn't hurt.

I have more than 100 such files from old soundfont forums and CDs (not including the ones that I created with mod2midi that uses the same convention).
But the important questioin is where are the 'other' kinds?
To tell you the truth I have not met the whole aramada of SF2+mid files that do NOT use the old Creative convention...

[Falcosoft]

You can ONLY do this through Soundfont Bank Manager manually. But you cannot do this with the help of SFMAN32 API calls. That is the problem. My Midi palyer already supports HW SF2 synths and can automatically load custom SF2 user banks with the help of SFMAN32 API calls. But if you try to overwrite anything in Bank 0 you will get an invalid bank index error (but this constraint is somewhat documented as I had already shown above).

Ah OK, I wasn't aware of SFMAN32 and its limitations. Strictly speaking, the modified soundfonts wouldn't be overwriting anything in bank 0, as they don't contain anything in bank 0. Still won't work? I wonder how Soundfont Bank Manager does it then. Perhaps an undocumented API/function?

1. No, since the problem is not the used banks by the SF2 soundfont itself but the destination bank in Midi space. So if you modify the presets in the SF2 file to be at bank 1 you still can not load it to bank 0 programatically. So in this case (if you set the presets at bank 1 in the soundfont and you load it at bank 1 as the first available valid bank) in the Midi file you should set Bank MSB to 2 to get the proper presets.
2. Yes, most likely. AFAIK it has never been documented.
3. If you have HW SF2 synths you can try it since the KX project still has the necessary header files:
https://github.com/kxproject/kx-audio-driver/blob/master/h/sfman/SFMAN.H

[Ian @ un4seen]

I think I have a possible solution/workaround for SFMAN32. You would first find the lowest bank that an embedded SF2 has in all its sfPresetHeader (in "phdr" chunk), and then shift them all down by that (so the lowest bank is now 0) before loading the SF2 to that bank with SFMAN32. For example, if bank 1 is the lowest in the SF2 then you would subtract 1 in all its sfPresetHeader, and then load it to bank 1 with SFMAN32. What do you think? Seems like it should work and avoid the need for the "DBNK" chunk.

[Falcosoft]

I think I have a possible solution/workaround for SFMAN32. You would first find the lowest bank that an embedded SF2 has in all its sfPresetHeader (in "phdr" chunk), and then shift them all down by that (so the lowest bank is now 0) before loading the SF2 to that bank with SFMAN32. For example, if bank 1 is the lowest in the SF2 then you would subtract 1 in all its sfPresetHeader, and then load it to bank 1 with SFMAN32. What do you think? Seems like it should work and avoid the need for the "DBNK" chunk.

Hi,
1. I do not think this would solve anything since in all cases I know the lowest used bank in the SF2 file is already 0.  Please, looak at the attached example Creative demo files again. The problem is  (according to  Spessasus) that if you would like to use the SF2 files's bank 0 you have to use Bank MSB 1 on channels in the Midi file. Spessasus would like to use Bank MSB 0 as default in the Midi file and this is incompatible with SFMAN32's logic. Your proposal cannot cure this problem at all.   
2. In my Midi player there is no SF2 editing infrastructure currently and I do not think I would like to search for and include a library just for solving this (otherwise non-existing) problem.

If you really insist on removing the DBNK chunk then the only solution that is compatible with all existing SF2 hardware and software synths is to use Bank offset +1 in Midi files on channels that use the embedded soundfont and to load the embedded soundfont to Bank 1.
BTW, currently this is the default behavior according to the standard when you omit the DBNK chunk. The DBNK chunk is optional according to the current standard so you do not have to implement it if you do not want to. I still do not understand what would be the benefit if it was fully removed...

The clear Benefit of DBNK chunk that you can define with the help of it explicitly that you do not want to use the fixed Bank 1 (offset) and you want to use Bank 0 since you do not care about SF2 hardware or you would like to use XG setup where the bank offset can cause problems with drums, etc.

Also in the standard I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0 and and only contains a variation bank that is loaded to a different bank. This is independent from the SFMAN32 related problems.

Ps: I think I have told everything I wanted to on this subject.
I have shared all my arguments but if both you and Spessasus feel that this is all irrelevant then I do not want to prevent you to modify the standard the way you want.
In this case I'm out and my implementation will be out of standard but as I have told already it's not a problem for me.

[Ian @ un4seen]

1. I do not think this would solve anything since in all cases I know the lowest used bank in the SF2 file is already 0.  Please, looak at the attached example Creative demo files again. The problem is  (according to  Spessasus) that if you would like to use the SF2 files's bank 0 you have to use Bank MSB 1 on channels in the Midi file. Spessasus would like to use Bank MSB 0 as default in the Midi file and this is incompatible with SFMAN32's logic. Your proposal cannot cure this problem at all.   

Perhaps I didn't explain it well enough. The solution I'm proposing is that the SF2 is modified to assume DBNK=0 when embedding it in the RMID file, eg. add 1 to the banks in the Creative demo case. That avoids the need for a DBNK chunk because it's always 0. Then your player (and any others that use SFMAN32) can do what I wrote in my last post when using SFMAN32, while other software can use the soundfont as it is (they don't need to avoid bank 0).

2. In my Midi player there is no SF2 editing infrastructure currently and I do not think I would like to search for and include a library just for solving this (otherwise non-existing) problem.

I can post some code for this. It's basically just reading and patching the file's "phdr" chunk, so there won't be any need for a whole SF2 editing library.

If you really insist on removing the DBNK chunk then the only solution that is compatible with all existing SF2 hardware and software synths is to use Bank offset +1 in Midi files on channels that use the embedded soundfont and to load the embedded soundfont to Bank 1.
BTW, currently this is the default behavior according to the standard when you omit the DBNK chunk. The DBNK chunk is optional according to the current standard so you do not have to implement it if you do not want to. I still do not understand what would be the benefit if it was fully removed...

Because the soundfont already contains bank information, I think the DBNK chunk adds unnecessary complexity, ie. it's an extra thing that all software will need to process. Assuming bank 1 will also add complexity, ie. if a MIDI file uses bank 0 then you will need to modify it to use bank 1 by inserting bank select events - simpler to patch the soundfont (if necessary) instead.

I think it's best to keep things as simple as possible for general usage, and have any software with special requirements (eg. using SFMAN32) adapt themselves to it, rather than the other way round.

Also in the standard I would like to preserve the philosophy of the original SB demo files that was about variation/user banks. In this sense for me there is no fundamental difference between Mid+SF2 pairs and rmi files with embedded Mid + SF2 pairs. It's only a container thing. I consider the rmi (Mid+SF2) format to be completely valid for only variation banks that rely on a preloaded full GM bank at bank 0 and and only contains a variation bank that is loaded to a different bank. This is independent from the SFMAN32 related problems.

But what if you want the embedded soundfont to provide all sounds, not just some? I think tailoring the format to variations limits its potential usage.