[Feature Proposal] Add Bank Select LSB Support via other byte of wBank, as well as other features later

[stgiga]

So, according to the SoundFont standard, the value (known as wBank) normally used to store Controller Change 0 (Bank Select MSB) is actually a 16-bit value. If we use the OTHER byte to store the Controller Change 32 (Bank Select LSB) value, we can support Bank Se]ect LSB in SF2, thus proper Yamaha XG SoundFonts, and proper DLS-to-SF2 conversions can be made. The spec says to preserve (but not play) these values should the other byte than MSB be used. Also, the second percussion toggle is a bit that OpenMPT 1.30 will respond to as a percussion toggle. I have a test-of-LSB SF2 here: https://drive.google.com/file/d/1cerpko6kL4SctyHG9ozYFtwePmbHX7CW/view as well as an attached diagram of the bits for wBank with LSB support. There have been some reworks to this.

Furthermore, the SoundFont specification says to not play SoundFonts which have the sm24 chunk (used to store the upper 8 bits of a 24-bit sample) but not the regular 16-bit sample chunk underneath. However, it does NOT tell us to reject these. So 8 bits-per-sample samples in SF2 are possible. Meaning that MOD samples-to-SF2-conversions could be outright 1:1.

In terms of priority, I would say that the 16-bit wBank part would be the best to support first.
These three features are part of a project me and a collaborator have to improve the SF2 format via taking the standard completely literally. We also rely on the spec not explicitly defining the RIFF used as 32-bit RIFF, so we have devised a RIFF64 extension, but given the differences between RIFF and RIFF64, there are some significant reworks needed, giving us room to add in features not possible on 32-bit RIFF. This 64-bit RIFF SF2 format is in its infancy and is not part of this present request.

The wBank LSB use is the feature we feel is the one that is of current most importance. The test SF2 was made by my collaborator via hex editing the wBank values in some XG-mapped patches to put them on their LSBs (Yamaha XG uses Bank Select LSB for its patch variations outside General MIDI rather than Bank Select MSB as is done in Roland GS) as is proper, while following the attached bit diagram of wBank.

This whole proposal has been in the works for months.

I know that it might seem a bit wild to do this, but having Bank Select LSB also opens the doors to more SoundFonts of other synthesizers, because a no-LSB beyond-GM synth outside Roland SoundCanvas lines in native mode is extremely rare.

Furthermore, I have pitched the proposal to other people in the SoundFont player and editor community, such as Polyphone on Github, and also on Un4seen. The gist of this proposal is that wBank LSB use is what we find to be of current most importance, but we have additional plans for later.

Best wishes to everyone involved!

PS: If I needed, I will open a feature ticket for this.

[derselbst]

I found it a bit hard to follow your thoughts because you start right with the solution, rather than with the problem. I'm not in favor of making too many customizations to the Soundfont standard, so I'll only comment on the following two issues for now.

1. Promoting wBank to 16-bit

So, the problem here is that you want to support XG Soundfonts and DLS soundfonts to be properly converted to SF2. And therefore you're suggesting to use the upper unused byte of the wBank member of the PresetHeader. I'm all in favor for this. Loading your demo soundfont in Polyphone acutally preserves these values, however, as soon as you try to change the bank it's getting truncated to 128.

I haven't tested how fluidsynth behaves when confronted with this soundfont. However, it should be pretty straight forward to just retain the value and make sure the correct preset is selected whenever synth.midi-bank-select is set to xg. I'd welcome a PR for that.

2. Abusing the SM24 chunk

You're asking for a straightforward way to convert 8-bit MOD samples to SF2. And therefore you want to only use the SM24 chunk while not providing the SMPL chunk. I am not in favor of this. Any SF2 file which provides the SM24 chunk while not providing the regular SMPL chunk is structurally defective, and this should be clearly signaled to the user as an error, IMO. The chance that such a file actually contains valid 8bit MOD samples is rather low.

IMO, it would be better to just promote the 8bit samples to 16bit and store them in the regular SMPL chunk, or use our proposed (but yet unimplemented) SoundFont3 standard to store it as FLAC compressed or similar.

[stgiga]

Honestly what I care about the most is the wBank thing.

[stgiga]

Here's something that is important to note:

For this to work right, SF2s doing 16-bit wBank must have the lsb=0 patches first.

To elaborate:

As mentioned in the SF 2.04 specification, if the wPreset and wBank are identical, the player should play the first preset found in the PHDR.

The legacy AWE player will read the low byte of the wBank (as MSB), but will ignore the high byte.

Therefore, if you have multiple presets with the same low byte of wBank (MSB value), you need to put the preset which you want to fall back to first. This may be LSB=0, LSB=3 (for stereo XG sounds), or any arbitrary LSB value.

This is the internal order, and not the displayed order. The displayed order depends on which program you opened the SF2 file in anyway. It could be alphabetical, internal or something else entirely.

Therefore, editors should allow the selection of the preferred fallback preset, and also respect the internal order of presets in the file.

[stgiga]

Here's the test SF2 that accounts for the "Important to note" comment: https://drive.google.com/file/d/1JuhW46fbt3y8kD7UqeIFwmMb_Mg3R2-L/view?usp=sharing