FAQs

SFE is intended to solve the problem of the SoundFont format being abandoned by Creative / E-mu for multiple years, and the resulting lack of new features despite community request.

We hope that SFE becomes widely adopted by major open-source software developers, and that it becomes something that gains popularity in the open-source space.

Currently, the SpessaSynth-based reference implementation is partially complete.

While SpessaSynth already includes some SFE features, our reference implementation also includes limited ISFe support and UTF-8 text support.

If you are a sound bank program developer, then you can read the specification and implement support in your program! Don't worry too much about full support, use the recommended program support levels and the feature flags system to indicate how much support you have implemented.

If you are a sound bank user, then when SFE editor programs become available, please use additional SFE features when appropriate! This would paint the SFE format in a good light.

While SFE is designed with forwards compatibility with SoundFont programs in mind, feel free to create a legacy SoundFont version of your sound bank, so programs that haven't updated to fully support SFE can use it without regression.

The simplest method to convert an existing SoundFont, or a sound bank with Werner SF3 compression, to SFE, is to update the version number and add the appropriate sub-chunk.

While the minimal SFE bank includes an ISFe sub-chunk, we recommend that you add DMOD and xdta sub-chunks to your bank later to enable the use of additional features.

In the future, software compatible with the SFE format should make the process of converting existing sound banks to SFE significantly easier.

Currently, SpessaSynth provides partial support for some SFE features, and our reference implementation based on SpessaSynth is in development.

Currently, SFE banks provide simple MSB/LSB/preset selection. This means that no more than one preset can resolve to the same preset location. If two extended GM mappings conflict, then the sound bank creator must currently choose one mapping.

However, future versions of SFE will use Bankmaps, which allow more than one preset to resolve to the same preset location based on extended GM resets, and eventually you will be able to use any MIDI instruction sequence to select Bankmaps.

SFE supports multiple percussion banks by extending the percussion bit in legacy SoundFont.

In legacy SoundFont, only bank 128 corresponds to a valid percussion bank, however in SFE, you can use MSB byte 128-255 to denote that a bank is a percussion bank with MSB equal to the byte minus 128.

This can also be used with LSB banks, which are specific to SFE.

Sample containerisation is optional, but it allows the use of compressed samples and samples with more metadata.

It works by integrating entire audio files, including their header, into an SFE sound bank's sample chunk, and letting a decoder accept entire sample containers as inputs.

This simplifies sample parsing, and allows additional features.

64-bit headers and sample addresses currently work using the RIFS (RIFF 64-bit static) container format, which simply extends all chunk size labels on RIFF to 64-bit.

It is used because it is more simple than RF64/BW64.

Future versions of SFE will introduce the dynamic RIFF container format, which allows some format chunks to have a variable size.

With extended generators, the size of generator values is doubled from 16 bits to 32 bits by adding an extra 16-bit value in the xdta sub-chunk.

This can increase the precision of generator values for smoother sound variations, increase the range of values of generators, or allow control of multiple parameters using one generator value.

Players should gracefully ignore unknown chunks, which allows the player to be forwards compatible with future 4.x versions of SFE.

If there is more than one preset that shares a preset location identifier, then the first preset in the file should be loaded.

SFE 4 with 32-bit chunk headers uses ifil version 2.1024 or higher for non-containerised sound banks and 3.1024 or higher for containerised sound banks, stores the actual version tag in the SFvx field in the ISFe sub-chunk, and uses the .sf4 file extension.

SFE 4 with 64-bit chunk headers uses ifil version 4.x for non-containerised and containerised sound banks, with the two being distinguished by the value of the SFty field in the ISFe sub-chunk, and uses the .sf4 or .sf64 file extensions.

SFE 4 with Dynamic RIFF uses ifil version 4.x, similarly to 64-bit SFE 4, however it will likely use the .sfd or .sf4d file extensions.

SFE 5 and later will likely use an ifil version corresponding to the version number, and will likely use the .sfe file extension.

The ability to use generated waveforms without requiring samples will likely be available in a future version of SFE 4.x.

The ability to use shaped envelopes and alternate LFO shapes will likely be available in a future version of SFE 4.x.

Right now, it's confirmed that phaser, equaliser, distortion, echo and delay effects will be added, however full support for XG and CC94 effects is also being planned.

The AudioShader architecture is planned for a future version of SFE after SFE 5 that allows fully-programmable synthesis models using a new audio programming language.