Section 1: Introduction

1.1 Preamble

The SFe standard has been created to provide a successor to E-mu Systems®’s SoundFont® 2.04 standard.

• Large files (above 4 GiB) must use a 64-bit chunk header format.
• Programs that are designed to create existing SF2 files can easily be adapted to 64-bit with SFe.
• 64-bit headers will allow creators of sound banks to replace split banks with a large number of SF2 files, with large monolithic banks, where all samples and instruments can be used in every preset.
• SFe compatible players require a certain standard of features, which is in the program specification in section 11. This improves compatibility of SFe banks with players.

1.2 Changelog

For draft specification revision history, see draft revision history.

Changes from the previous version of the specification are highlighted.

1.3 History of improvements to the SF format

In 2005, E-mu released SoundFont® 2.04 (specification date September 2002), the last version before abandoning the format. It included 24-bit support, and was designed for the Sound Blaster® X-Fi. Creative Technology Ltd is still around, but their current sound cards (such as the AE-9) do not support the SoundFont® format.

At an unknown time, Kenneth Rundt, the author of SynthFont and a series of products based on it, added some custom features, mostly ported over from the DLS format:

• Always play the sample to the end
• Velocity to volume envelope attack (from DLS)
• Velocity to modulation envelope attack (from DLS)
• Vibrato LFO to volume (from DLS)

Werner Schweer found a way to compress SoundFont® 2 files (with the lossy Vorbis format) around 2010.

• The resulting format was known as SF3.
• It is commonly used by open source programs, such as MuseScore and FluidSynth.
• This is the reason why this format is not called .SF3.
• SFe incorporates the Werner SF3 specification as SFe Compression.

Another development was done by Cognitone, which created an open source program that can losslessly compress SoundFont® 2 files (with FLAC). This was done in 2017.

• This was unofficially called SF4.
• This is intended to be the true version 4, as Cognitone SF4 seems to not have been as widespread as SF3.
• SF4 has also been rejected by FluidSynth as too loosely defined.

Finally, stgiga found out that many programs don’t mind RIFF64 files.

• RIFF64 files have a much larger size limit than 32-bit RIFF files.
• It gives us a new horizon to experiment with longer, higher quality samples.
• There are also many other advantages of the RIFF64 format.

The SFe project started in 2020 as a proposal for a successor to legacy SF2.04 by Polyphone developer and SFe team member davy7125. Starting off as “SF3”, it was renamed to avoid confusion with Werner SF3, firstly to “SF32 and SF64” but eventually to SFe.

1.4 Scope and purpose

This is the specification for the SFe 4.0 file format, based on the famous E-mu Systems® SoundFont® 2.04, and Werner SF3 standards, and is intended to be a source of information on SFe.

• To create files that support SFe, you will need:
  • The SFe format, compatibility, and program specifications
  • E-mu’s provided documents for legacy SF2.04 (SFSPEC24.PDF)
• All features from legacy SF2.04 will be retained.

1.5 Important differences from the legacy SF specification document

• This is not a standalone document; it refers to SFSPEC24.PDF. All relevant information from the Werner SF3 specification is included.
• This document is unofficial and was not created by E-mu. If they want this to be removed, we will remove it, but we hope that this is because they have their own official update to the SF format ready.
• For copyright reasons, we cannot copy information from the original standard, except for what is required to interpret this document and what is allowed under fair use.
• The SFe specification includes many additional requirements over reading the file format.
• Document organisation has been significantly modified to accommodate the intricacies of the SFe format, and to make it easier to read.

1.6 Document organisation

The sections in this specification are different to the sections in SFSPEC24.PDF, however they roughly correspond to some of these sections:

• Sections 1-3 of this specification to sections 0-1 of SFSPEC24.PDF
• Section 4 of this specification to section 2 of SFSPEC24.PDF
• Section 5 of this specification to sections 3-7 of SFSPEC24.PDF
• Section 6 of this specification to section 8 of SFSPEC24.PDF
• Section 7 of this specification to section 9 of SFSPEC24.PDF
• Section 8 of this specification to section 10 of SFSPEC24.PDF
• Section 9 of this specification to section 11 of SFSPEC24.PDF
• Section 12 of this specification to section 12 of SFSPEC24.PDF

Section 6 also contains feature flags along with enumerators, section 9 also contains information about the AWE ROM emulator that can be implemented, and sections 10 and 11 include information on compatibility concerns and guidance on writing SFe-compatible software respectively.

Significant differences from the previous version of the specification will be highlighted.