Skip to main content

Historique: SoundFont specification SF2

Afficher la page publiée Réduire en sessions d'édition

Aperçu de cette version: 78

 attention
Page en cours d'écriture
ardoisebleue - 13 12 2013



Préambule


Ce tutoriel a été créé à partir de tests et de la traduction de la spécification soundfont SF2. cette norme est destinée à fournir un format d'échange universel, portable et extensible pour les synthétiseur à base d'échantillons; Elle est portable et universelle grace à l'utilisation d'une définition précise des paramètres indépendants du matériel, ainsi que par des pratiques spécifiques conçues pour être supportées par un large éventail de technologies.
Dans ce mémo, j'ai utilisé le langage de programmation C++ ( QT4 ) pour illustrer les exemples. J'ai créé un fichier soundfont SF2 avec Swami sur un seul échantillon stéréo (un signal LA de 1 seconde), un seul intrument, et un seul preset.
 info

le terme énumérateur peut-être compris dans le sens désignation.
les termes générateur et modulateur peuvent être compris comme terme de paramètrage.

Voir terminologie en annexe A.

Le format du fichier SF2


Un fichier SF2 est stocké en format RIFF (Resource Interchange File Format) qui est une structure de fichier balisé, développée pour les fichiers de ressources multimédia. La structure de fichier balisé est intéressante car elle permet d'éviter les problèmes de compatibilité qui pourraient se produire dans des changements de définition de fichier au fil du temps, par le fait que chaque élément de données du fichier est identifié par un entête standard, une application qui ne reconnaîtrait pas un de ces éléments de données peut éluder cette information inconnue.
Un fichier RIFF est construit à partir de blocs et sous-blocs stratifiés en niveaux, la lecture doit se faire séquentiellement, bloc par bloc, afin de récupérer la taille de ces blocs et de pouvoir lire les données "en paquet" d'octets ou par une structure de donnée (struct), ou passer au bloc suivant.

Principe des blocs


Les blocs sont "balisés" par des chaines de 4 octets ( ex: snbk, INAM, ifil, LIST ... ), la spécification n'impose pas si ces caractères doivent être majuscules, minuscules ou les deux.
La valeur "taille" du bloc est écrite sur 4 octets le premier est celui de poids faible, le quatrième de poids fort, ce qui implique que le calcul de cette valeur s'effectuera après la lecture des octets de la façon suivante :
octet1 + octet2*256 + octet3*(256²) + octet4*(256³) etc...
ex : 44 F1 02 00 => 192836

Les informations concernant d'autres données techniques sont en annexe A .

Le premier bloc


Dans ce bloc, nous récupérons le type de structure, la taille du bloc de données et le type de fichier RIFF. Il a une taille invariable de 12 octets
Copy to clipboard
struct entete{
    DWORD   typestructure;// RIFF   = #52494646
    DWORD   taillefichier;
    DWORD   typefichier;//sfbk      = #7366626b
};

Ce premier bloc est commun à tous les fichier RIFF, il fournit les informations sur le fichier à traiter, dans notre cas, nous avons à faire avec un fichier RIFF de type soundfont. Quant à la donnée taillefichier, elle renseigne sur la taille du bloc de donnée, c'est à dire que sa valeur = (taille réelle du fichier) - 8 octets (RIFF et taillefichier).

les blocs suivants


Ces blocs peuvent être organisés dans le RIFF dans n'importe quel ordre, puisqu'il commence toujours par des balises pour les décrire. De plus, ces blocs ne sont pas obligatoirement prèsents, ainsi que certaines de leurs données peuvent être absentes. Il est aussi possible que des blocs écrits dans le fichier ou des données ne soient pas utilisable dans le logiciel. C'est ce qui fait la souplesse et fiabilité dans le temps des fichier RIFF (sous réserve que le logiciel qui les utilise soit doté des contrôles nécessaires).
Mais, il est plus judicieux de se conformer à une organisation "standard" lors de la création d'un fichier RIFF ( c'est à dire, l'ordre dans lequel la spécification décrit ces blocs ).
Un bloc commence toujours par la balise LIST suivie de la taille du bloc et des quatre octets décrivant le nom du bloc, ce qui permet (si le bloc n'est pas traitable par le logiciel) d'aller immédiatement au bloc suivant en utilisant la valeur taille_du_bloc (ici des exemples de sauts de bloc).
Copy to clipboard
struct baliseLIST{
    DWORD   balise;// LIST
    DWORD   taille_du_bloc_qui_suit;
    DWORD   nom_balise_bloc;//INFO
};

Chaque donnée contenue dans une balise_bloc à une structure simple, elle est composée d'un nom, d'une taille et de la valeur de la donnée.
Copy to clipboard
struct balise_donnee{
    DWORD  nom_de_balise;// ex: ifil -> N° de version de la norme SF2 utilisée
    DWORD  taille_de_la_donnee;// ex: 04 00 00 00
	.........		//valeur = octet*taille_de_la_donnée
};

Pour récupérer la valeur de la donnée il suffit d'utiliser "taille_de_la_donnee".
On procéde de cette façon jusqu'à la limite finale du bloc donnée par "taille_du_bloc". Après quoi, un nouveau bloc, commençant par une balise LIST commence.

Description des blocs et de leurs données


Les données de type chaines de caractères ASCII finissent par un ou deux octets à 0, de manière à obtenir éventuellement, la longueur de la chaine ; Donc la taille concernant ces chaines (taille_de_la_donnee) comprend les valeurs 0 finales. Les caractères ASCII doivent être considérés comme sensible à la casse, en d'autres termes "abc" n'est pas la même chose que "ABC". Les chaines acceptées sont de 256 octets ou moins, sauf indication contraires. Dans le cas des chaines dont la longueur est fixée (ex : noms des preset 20cars ), les octets non-utilisés doivent être mis à 0.

Le bloc INFO

[+]

Le bloc des presets et instruments : pdta


Les données d'articulation au sein d'un fichier compatible SF2 sont décrites dans 9 sous-blocs obligatoires. La structure a été conçue à des fins d'échange et n'est pas optimisé que ce soit pour une synthèse d'exécution ou une édition on-the-fly.
Bien faire la différence entre le terme preset et instrument : le preset est l'élément utilisé et dont le nom est visible dans les patches par les séquenceurs et synthétiseurs, alors que l'instrument est un élément paramètré, intermédiaire entre le preset et le sample.
    • Un preset est généralement constitué de plusieurs instruments superposés et/ou adjacents, avec des réglages différents, pour générer les notes tout le long du clavier.
    • Un instrument peut être constitué d'une série de samples différents et/ou identiques.
    • Un sample, peut-être utilisé par plusieurs instruments réglés différemment pour obtenir des variations dans le jeu du sample.

  • balise
    phdr
C'est une liste sous-blocs décrivant tous les Presets dans le fichier SF2. La taille du bloc est toujours multiple de 38 octets, et contient
    • un enregistrement pour chaque Preset.
    • un enregistrement final vide pour terminer la liste.
Si aucun preset n'est décrit, il n'y a que l'enregistrement final dans la liste.
Copy to clipboard
struct sfEntetePreset
{
  CHAR	NomDuPreset[20];  // contient le nom du preset en ASCII
  WORD	NumSelectMidi;            // numéro de présélection MIDI
  WORD	NumBanque;              // numéro de banque MIDI qui s appliquent à cette présélection
  WORD  IdxPbag;             // indice de la liste de zone du préréglage dans le sous-bloc pbag
/*Les trois valeurs suivantes sont reservées pour la mise en œuvre future
d une fonction de gestion de la bibliothèque de presets ellse doivent exister et être = 0 */
	DWORD 	Librairie;
	DWORD	Genre;
	DWORD	Morpho; 
};

{FANCYTABLE(head="nom|description", sortable=n)}
NomDuPreset | Les caractères du champ ASCII inutilisés doivent être mis à 0. Les noms prédéfinis sont sensibles à la casse. Un nom unique doit toujours être attribué à chaque preset pour permettre l'identification. Toutefois, si une banque contient des noms identiques, les presets doivent être soit conservés comme lisible ou de préférence renommés avec un nom unique.
Notez que les presets ne sont pas ordonnés dans la banque, ils doivent avoir un ensemble unique de numéros NumSelectMidi et NumBanque. Toutefois, si deux presets ont ces deux valeurs identiques, le premier de ces presets se connectant dans le bloc phdr devient le preset actif ; Tous les autres avec des valeurs identiques seront maintenus afin qu'ils puissent être renumérotés et utilisés ultérieurement. Le cas particulier de la banque de percussion General MIDI est traitée de manière classique par une valeur NumBanque=128.
IdxPbag | Comme la liste de la zone preset est dans le même ordre que la liste phdr, les pbag seront réguliers et croissants suivant l'incrémentation des phdr.
Le dernier enregistrement sfEntetePreset ne doit jamais être accessible (ou être lu), et n'existe que pour fournir un IdxPbag final permettant de terminer le nombre de zones du dernier Preset. Toutes les autres valeurs de cet enregistrement final sont mises à 0, à l'exception de NomDuPreset, qui peut éventuellement être "EOP" indiquant la fin des Presets.
  • balise
    pbag
C'est une liste de sous-blocs contenant les index des zones de valeurs décrivant les Presets. Il a toujours une taille multiple de 4 octets, et contient un enregistrement pour chaque Preset zone, plus un enregistrement vide pour clore la liste.
Copy to clipboard
struct sfPresetBag 
{ 
WORD  IdxGen; // indice dans la liste de zone presets des générateurs dans le sous-bloc pgen
WORD  IdxMod; // indice dans la liste des modulateurs dans le sous-bloc pmod.
};

La première zone de donnée pour un Preset est située à l'indice IdxPbag dans la zone de données pbag. Le nombre de zones de ce Preset est déterminé par la différence entre le IdxPbag du Preset en cours et le IdxPbag du Preset suivant.
Comme les listes de génerateurs et modulateurs sont dans le même ordre que le phdr les indices IdxGen et IdxMod seront incrémenter de façon régulière avec l'augmentation des zones de Preset.
  • balise
    pmod
C'est une liste sous-bloc décrivant tous les modulateurs des zones d'un Preset. Sa taille est toujours un multiple de 10 octets. Elle contient zéro, un ou plusieurs modulateurs, plus un enregistrement vide de clôture.
Copy to clipboard
struct sfModList 
{
  SFModulator   SfModSrcOper; // valeur de l une des énumérations SFModulator
  SFGenerator   sfModDestOper; // indique la destination du modulateur.
  SHORT      modAmount; // valeur signée indiquant le degré auquel la source module la destination.
  SFModulator   sfModAmtSrcOper; // valeur de l une des énumérations SFModulator
  SFTransform  sfModTransOper; // valeur de l une des énumérations SFTransform
} ;

Le IdxMod de sfPresetBag pointe vers le premier modulateur pour le Preset, et le nombre de modulateurs présents pour un Preset est déterminé par la différence entre la IdxMod du Preset suivant et le IdxMod du Preset en cours. Une différence égale à 0 indique qu'il n'y a pas de modulateurs pour ce Preset. Tous les éléments de cette structure sont de 2 octets.
    • SfModSrcOper : Cette valeur indique la source de données pour le modulateur. Les valeurs inconnues ou indéfinies seront ignorées. Les Modulateurs avec sfModAmtSrcOper fixés par un «lien» qui n'aboutit pas sont ignorés.
    • sfModDestOper : la destination est soit une valeur du type d'énumération SFGenerator , soit un lien vers le sfModSrcOper d'un autre bloc modulateur. Celle-ci est indiquée par le bit haut du champ sfModDestOper, les 15 autres bits désigne la valeur de l'indice du modulateur dont la source doit être la sortie du modulateur en cours par rapport au premier modulateur dans la zone instrument. Les valeurs inconnues ou indéfinies sont ignorées. Des modulateurs avec des liens qui pointent vers un indice modulateur qui dépasse le nombre total de modulateurs pour une zone donnée sont ignorées. Des modulateurs liés qui font partie de liens circulaires sont ignorés.
    • modAmount : Une valeur de zéro indique qu'il n'y a pas de modulation fixée.
    • sfModAmtSrcOper : Cette valeur qui indique le degré auquel la source module la destination doit être commandé par la source de modulation spécifié. les valeurs inconnues ou indéfinies sont ignorées. Des modulateurs avec sfModAmtSrcOper fixé à un «lien» sont ignorés.
    • sfModTransOper : Cette valeur indique qu'une transformée du type spécifié est appliqué à la source de modulation avant l'application sur le modulateur. Les valeurs inconnues ou indéfinies sont ignorées.
L'enregistrement de clôture qui sera toujours ignoré contient, par convention, 0 dans tous les champs.
Un modulateur est défini par son sfModSrcOper, son sfModDestOper, et son sfModSrcAmtOper.
Des modulateurs du sous-bloc pmod peuvent être utilisés comme modulateurs additionnels en respectant ceux du sous-bloc imod. En d'autres termes, un modulateur pmod peut augmenter ou diminuer l'action d'un modulateur de imod.
En SoundFont 2.00, aucun modulateurs n'a encore été défini, et le sous-bloc pmod sera toujours composé de 10 octets de valeur 0.
  • balise
    pgen
Ce bloc contient une liste de générateurs pour chaque preset. sa taille est toujours multiple de 4 octets, et contient un ou plusieurs générateurs pour chaque preset (à l'exception d'une zone globale contenant uniquement des modulateurs) plus un enregistrement vide pour clore la zone.
Copy to clipboard
typedef struct { BYTE byLo, byHi; } rangesType; 
typedef union
{
 rangesType  ranges; 
 SHORT       shAmount; 
 WORD        wAmount; 
} genAmountType; 

struct sfGenList 
{
  SFGenerator    sfGenOper; // une des valeurs de type énumération SFGenerator
  genAmountType  genAmount; // valeur à attribuer au Generator spécifié
};

    • sfGenOper
Cette valeur indique le type de Generator utilisé. Notez que cette énumération est de deux octets.
    • genAmount
Peut être de trois formats :
      • Certains générateurs spécifient une plage de numéros de clé MIDI de vélocité MIDI, avec une valeur minimum et maximum.
      • D'autres générateurs spécifient une valeur WORD non signé.
      • Mais la plupart des générateurs, spécifient une valeur WORD 16 bits signé.
Le IdxGen du preset pointe au premier générateurs pour ce preset.
Sauf si la zone est une zone globale : le dernier générateur de la liste est un générateur Instrument, dont la valeur est un pointeur vers le générateur associé à cette zone.
      • Si un générateur key range existe pour un preset, il est toujours le premier générateur dans la liste pour ce preset.
      • Si un générateur velocity range existe pour un preset, il devra n'être précédé que par un générateur de «keyrange ».
Un générateur est défini par sfGenOper. Tous les générateurs dans une zone doivent avoir un énumérateur sfGenOper unique.
Les générateurs dans le sous-bloc pgen sont appliqués par rapport aux générateurs dans le sous-bloc igen d'une manière additionnelle. En d'autres termes : les générateurs pgen augmentent ou diminuent la valeur d'un générateur igen.
  • balise
    inst
C'est une liste décrivant tous les instruments dans le fichier. Sa taille est toujours multiple de 22 octets, et contient au moins deux enregistrements, un enregistrement pour chaque instrument et un enregistrement vide de cloture.
Copy to clipboard
struct sfInst
{
CHAR  NomInstrument[20]; // contient le nom de l instrument exprimé en ASCII
WORD  IdxIbag; // indice de la liste de la zone de l instrument dans ibag
};

nom description
NomInstrument Les caractères inutilisés sont mis à 0. Les noms d'instruments sont sensibles à la casse. Un nom unique doit toujours être attribué à chaque instrument pour permettre l'identification. Toutefois, si plusieurs noms identiques sont trouvés, les instruments doivent être renommés avec un nom unique.
IdxIbag Comme la liste des zones instrument est dans le même ordre que la liste des instruments, les indices IdxIbag de instrument bag sera incrémentée régulièrement avec l'accroissement de la liste des instruments.

L'enregistrement sfInst de cloture ne doit jamais être accessible, et n'existe que pour fournir un IdxIbag de fin permettant de déterminer le nombre de zones dans le dernier instrument. Toutes les autres valeurs sont par convention à 0, à l'exception de NomInstrument, qui devrait être "EOI" indiquant la fin des instruments.
Tous les instruments présents dans le sous-bloc inst sont généralement référencés par au moins un Preset. Toutefois, un fichier ne contenant que des instruments «orphelins» peut être traité.
  • balise
    ibag
C'est un sous-bloc dont la liste d'éléments décrit les zones des instrument. Sa taille est toujours multiple de 4 octets, et contient un enregistrement pour chaque zone instrument plus un enregistrement de fermeture.
Copy to clipboard
struct sfInstBag
{ 
  WORD  wInstGenNdx; // indice de la liste des zone de générateurs igen
  WORD  wInstModNdx; // indice de la liste des zonez de modulateurs imod
};

La première zone, dans un instrument donné est placée à l'indice IdxIbag de cet instrument. Le nombre de zones de cet instrument est déterminé par la différence entre le IdxIbag de l'instrument suivant et le IdxIbag courant.
Comme les listes de générateurs et les listes de modulateurs sont dans le même ordre que les listes d'instrument et de zone, ces indices wInstGenNdx et wInstModNdx seront incrémenter régulièrement avec l'ajout de zones.
  • balise
    imod
Ce sous-bloc décrit toutes les zones modulateur de l'instrument. Sa taille est toujours multiple de 10 octets, et contient 0, un ou plusieurs modulateurs en plus d'un enregistrement de cloture.
Copy to clipboard
struct sfModList 
{ 
  SFModulator  sfModSrcOper; // valeur du type d énumérateur SFModulator
  SFGenerator  sfModDestOper; // indique la destination du modulateur.
  SHORT        modAmount; // valeur signée indiquant le degré avec lequel la source module la destination
  SFModulator  sfModAmtSrcOper; // valeur du type d énumérateur SFModulator
  SFTransform  sfModTransOper; // valeur du type d énumérateur SFTransform
};

L'index WInstModNdx pointe sur le premier modulateur de cette zone, et le nombre de modulateurs présents pour une zone est déterminée par la différence entre la wInstModNdx de la zone suivante et le wModNdx de la zone courante. Un résultat à zéro indique qu'il n'y a pas de modulateurs dans la zone. Notez que ces énumérateurs sont de 2 octets.
nom description
sfModSrcOper indique la source de données pour le modulateur.
sfModDestOper soit une valeur du type énumérateur SFGenerator, soit un «lien» vers la sfModSrcOper d'un autre bloc modulateur. Cette destination est indiquée par le bit haut du champ de sfModDestOper, les 15 autres bits désignent la valeur de l'indice du modulateur dont la source doit être la sortie du modulateur courant par rapport au premier modulateur dans la zone instrument.
modAmount Une valeur à zéro indique qu'il n'y a pas de valeur fixée.
sfModAmtSrcOper indique avec quel degré de modulation la destination doit être commandée par la source de modulation spécifiée.
sfModTransOper indique qu'une transformée du type spécifié est appliquée à la source de modulation avant l'application sur le modulateur.

 info

En SoundFont 2.00, aucun modulateurs n'a encore été défini, et le sous-bloc imod sera toujours composé de 10 octets de valeur 0.

Par convention, l'enregistrement de cloture contient 0 dans tous ses champs, et est toujours ignoré.
Un modulateur est défini par ses sfModSrcOper, sfModDestOper, et sfModSrcAmtOper. Tous les modulateurs dans une zone doivent disposer d'un ensemble unique de ces trois énumérateurs. Si un second modulateur est rencontré avec les trois mêmes énumérateurs comme modulateur précédent dans cette même zone, le premier modulateur sera ignoré.
Des modulateurs du sous-bloc imod sont absolus, cela signifie qu'un modulateur de imod remplace, plutôt que de s'ajouter, à un modulateur par défaut. Toutefois, l'effet d'un modulateur sur un générateur est additif, à savoir la sortie d'un modulateur s'ajoute à une valeur de générateur.
  • balise
    igen
C'est un sous-bloc décrivant une liste de zone générateurs pour chaque zone instrument dans le fichier SoundFont. Sa taille est toujours multiple de 4 octets, et contient un ou plusieurs générateurs pour chaque zone (à l'exception d'une zone globale contenant uniquement des modulateurs) plus un enregistrement de cloture.
Copy to clipboard
structure où les types sont définis comme dans la zone pgen ci-dessus.
struct sfInstGenList 
{ 
  SFGenerator  sfGenOper; // 
  genAmountType genAmount; // valeur à attribuer au Generator spécifiée
};

genAmount peut être de trois formats
      • générateur qui spécifie une plage de numéros de key MIDI, de vélocité MIDI, avec une valeur minimum et maximum.
      • générateur qui spécifie une valeur WORD non signé.
      • cependant la plupart des générateurs spécifie une valeur 16 bits signé.
Le champs WInstGenNdx pointe le premier générateur de cette zone.
A part le cas où la zone est une zone globale, le dernier générateur de la liste est un générateur sampleID, dont la valeur est un pointeur vers le sample associé à cette zone. Si un générateur "key range" existe pour la zone, il est toujours le premier générateur dans la liste de cette zone. Si un générateur "velocity range" existe pour la zone, il ne sera précédé que par un générateur de « key range ». Si des générateurs suivent un générateur sampleID, ils seront ignorés.
Un générateur est défini par sa sfGenOper. Tous les générateurs dans une zone doivent avoir un énumérateur de sfGenOper unique. Si un second générateur est rencontré avec le même énumérateur sfGenOper comme un des générateurs précédent dans la même zone, le premier générateur sera ignoré.
Des générateurs du sous-bloc igen sont absolus. Cela signifie qu'un générateur igen remplace, plutôt que s'ajoute, à la valeur par défaut du générateur.
  • balise
    shdr
C'est une liste de sous-blocs décrivant tous les échantillons du sous-blocs smpl et les samples référencés dans la ROM. Sa taille est toujours un multiple de 46 octets et contient un enregistrement pour chaque échantillon, plus un enregistrement de cloture.
Copy to clipboard
struct sfSample
{ 
 CHAR  NomDuSample[20]; // contient le nom de l échantillon
 DWORD  dwStart;
 DWORD  dwEnd;
 DWORD  dwStartloop;
 DWORD dwEndloop;
 DWORD  dwSampleRate;
 BYTE  byOriginalPitch;
 CHAR  chPitchCorrection;
 WORD  wSampleLink;
 SFSampleLink  sfSampleType;
};

nom description
NomDuSample Les caractères inutilisés du champ sont mis à 0. les noms des échantillons sont sensibles à la casse. Un nom unique doit toujours être attribué à chaque échantillon pour permettre l'identification. Toutefois, si une banque est lue et contient des échantillons avec des noms identiques, ils doivent être soit conservés comme lisible ou, de préférence, renommés avec un nom unique.
dwStart index du datapoint à partir du début du champ de données de l'échantillon jusqu'au premier point de cet échantillon de données.
dwEnd index du datapoint à partir du début du champ de données de l'échantillon jusque la première de la série de 46 datapoints à zéro qui suivent cet échantillon.
dwStartloop index du datapoint depuis le début du champ de données de l'échantillon jusqu'au premier datapoint de sa boucle.
dwEndloop index du datapoint depuis le début du champ de données de l'échantillon jusqu'au premier datapoint de fin sa boucle.
Notez que dwEndloop est le datapoint "équivalent" au premier datapoint de boucle, et que pour produire une boucle librement portablee, les 8 datapoints contigus entourant à la fois la Startloop et Endloop doivent être identiques.
dwSampleRate fréquence d'échantillonnage en hertz, lors de l'enregistrement de l'échantillon où de sa plus récente conversion. Des valeurs supérieures à 50000 ou inférieur à 400 peuvent ne pas être reproduites par certain matériels et doivent être évités. La valeur 0 ne doit pas être utilisée.
byOriginalPitch Valeur de la touche du pitch nominal de l'échantillon.
Exemple : l'enregistrement d'un instrument qui joue au centre C (261.62 Hz) doit recevoir une valeur de 60. Cette valeur est utilisée comme la touche root par défaut de l'échantillon, de sorte qu'une commande clavier MIDI pour le numéro de note 60 devrait reproduire le son à sa hauteur d'origine. Pour les sons sons indéterminés, une valeur conventionnelle de 255 doit être utilisé. Les valeurs comprises entre 128 et 254 sont interdites.
chPitchCorrection Correction de hauteur en cents qui doit être appliquée pour la lecture de l'échantillon. Le but de ce champ est de compenser les erreurs de pitch intervenues pendant l'enregistrement de l'échantillon.
Ex : si le son est trop haut de 4 cents, une correction diminuant de 4 cents est nécessaire; la valeur doit être -4.
wSampleLink Le type d'échantillon lié n'est pas encore pleinement défini dans la spécification SF2, mais devrait définir une liste circulaire d'échantillons liés en utilisant wSampleLink. Notez que cette énumération est de 2 octets.
sfSampleType Une valeur d'énumérateur entre les 8 valeurs suivantes :
monoSample=1
rightSample =2
leftSample=4
linkedSample=8
RomMonoSample=32769
RomRightSample=32770
RomLeftSample =32772
RomLinkedSample=32776
On peut voir que les valeurs énumérées de sfSampleType sont codées de telle sorte que le bit 15 est activé si l'échantillon est dans la ROM, et remis à 0 si elle est incluse dans la banque compatible SoundFont. Les quatre bits LS du WORD sont alors exclusivement mis en indiquant mono, gauche, droite, ou liés.

dwStart,dwEnd,dwStartloop et dwEndloop doivent avoir une valeur dans l'intervalle du champs de données de l'échantillon inclu dans la banque compatible SoundFont ou référencés dans la ROM. Aussi, pour permettre à une variété de plates-formes matérielles de reproduire ces données, les échantillons auront une longueur minimale de 48 datapoints, une taille minimale de boucle de 32 datapoints et un minimum de 8 points valides avant dwStartloop et après dwEndloop. Ainsi dwStart doit être inférieure à dwStartloop-7, dwStartloop doit être inférieure à dwEndloop-31, et dwEndloop doit être inférieure à dwEnd-7. Si ces contraintes ne sont pas remplies, le son peut éventuellement ne pas être lisible si le matériel ne prend pas en charge la lecture concernant les paramètres indiqués.
L'enregistrement de cloture n'est jamais référencé, et est entièrement mis à 0, à l'exception de NomDuSample, qui devrait être "EOS" indiquant la fin des échantillons.
Tous les échantillons présents dans le sous-bloc smpl sont généralement référencés par un instrument, mais un fichier contenant des échantillons «orphelins» ne doit pas être rejeté. Des applications compatibles SoundFont pouvant éventuellement ignorer ou filtrer ces orphelins selon les choix de l'utilisateur.

Le bloc LIST des échantillons : sdta


Les échantillons stockés dans la SF2 peuvent être du format 16 bits OU 24 bits, c'est le créateur de la banque qui définit le format de stockage des échantillons suivant le format des fichiers échantillonés à stocker.
Le bloc sdta contient un seul sous-bloc optionnel : smpl. Celui-ci contient toutes les données de sons 16 bits qui seront placées en mémoire et liées à la banque. Sa taille est variable, et contient obligatoirement un nombre pair d'octets. Quant au sous-bloc sm24, si les données stockées sont au format 24 bits, il fait exactement la moitié de la taille du smpl, plus 1 octet, si nécessaire pour satisfaire l'alignement sur 16 bits (nombre pair d'octets).
Si le bloc sdta est absent ça signifie que soit il n'y a pas de sons joués, soit la banque fait référence aux échantillons d'une ROM.
Copy to clipboard
struct bloc_sdta{
    smpl;// bloc d échantillon 16 bits
    sm24;// bloc d échantillons 24 bits
};


Le bloc smpl


S'il est présent, il contient un ou plusieurs «échantillons» de l'information audio numérique sous la forme d'un code seize bits, signés, little endian (octet le moins significatif en premier). Chaque échantillon est suivi d'un minimum de 46 datapoints égaux à 0 qui sont nécessaires pour garantir la possibilité de faire une boucle sur des données 0 à la fin du son avec des valeurs raisonnables de pitch en une interpolation raisonnable.

Le bloc sm24


S'il est présent, il contient les octets les moins significatifs correspondants à chacun des data_points contenu dans le bloc smpl. Notez que cela signifie pour chaque paire d'octets dans le smpl il y a obligatoirement un octet supplèmentaire dans le sm24.
Ces points de forme d'onde de l'échantillon doivent être combinées avec les points de forme d'onde des échantillons correspondants smpl, pour créer ensemble un seul pool de données de l'échantillon avec une résolution de 24 bits.
  • Si la version ifil du format est inférieur à la version 2.04 la SM24 doit être ignorée.

L'utilisation des boucles dans les échantillons


Au sein de chaque échantillon, une ou plusieurs paires de points de boucles peuvent exister. Les emplacements de ces points sont définis dans le bloc pdta, mais dans les échantillons, les data_points doivent se conformer à certains critères pour que la boucle soit compatible sur de multiples plateformes.
Les boucles sont définies par des «points équivalents» dans l'échantillon. Cela signifie qu'il y a deux data_points qui sont logiquement équivalents, et une boucle se produit lorsqu'un de ces points est raccordé à l'autre. En théorie, le point de fin de boucle n'est jamais joué au cours du bouclage ; A la place, le point de départ de la boucle suit le point juste avant le point de fin de boucle. Une boucle doit montrée des données pratiquement identiques autour des 2 points équivalents pour avoir la meilleure transition possible.
schema-passage-de -boucle.png En réalité, à cause des divers algorithmes d'interpolation utilisés par des synthétiseurs d'échantillons, les données entourant à la fois le début de la boucle et les points d'extrémité peuvent affecter le son de la boucle. Ainsi les points à la fois le début et la fin de la boucle doivent être entourés par des données audio continue. Par exemple : même si le son est programmé pour continuer à boucler pendant le decay, les data_points doivent être fournis au-delà du point de fin de boucle. Ces données seront généralement identiques aux données au début de la boucle. Un minimum de 8 points de données valides doivent être présents avant le début de la boucle et après la fin de la boucle.
Ces huit points de données (quatre de chaque côté) entourant les deux points équivalents doivent être équivalents si possible.
En forçant les données à être identiques, tous les algorithmes d'interpolation garantissent la reproduction correcte d'une boucle sans articulations. Voir notions de boucle dans Banque SF2 avec swami pour plus de détails.

Les énumérateurs


Les générateurs et modulateur destinataire.


Un générateur et un modulator destinataire sont deux termes signifiant la même chose, des paramètres de synthétiseurs. le générateur est utilisé dans les listes igen et pgen, et le modulateur destinataire est utilisé dans les listes imod et pmod.
Cinq types d'énumérateurs de générateur existent :

  • Index Generators : c'est un index de générateur dans une structure de données. il y a deux index de générateur
    • Instrument : définition d'un instrument dans la zone instrument
    • sampleID : définition d'un échantillon dans la zone sample.
  • Range Generators : définit un intervalle où les note-on extérieures à cette zone sont ignorées. Il y a deux générateurs actuellement définis :
    • keyRange : la plage de touche qui produiront un son quand elle seront appuyées.
    • velRange : la plage de vélocité (force d'appui sur une touche) dans laquelle la touche produira un son si la force d'appui est dans l'intervalle.
  • Substitution Generators : ce sont des générateurs qui remplacent une valeur pour un note-on. 2 Generateurs sont actuellement définis :
    • overridingKeyNumber
    • overridingVelocity.
  • Sample Generators : ces générateurs affectent directement les propriètés d'un échantillon. Ils ne sont pas définissables au niveau du preset.
    • générateur : sampleMode
    • générateur : Overriding Root Key
    • générateur : Exclusive Class
  • Value Generators : ce sont des générateurs qui affectent directement un paramètre de traitement du signal. La plupart des générateurs font partie de ce type. Les modulateur-destinataires font aussi partie de la liste Value Generators.

Définition des énumatereurs de générateur.

[+]

Paramètres et modèle de synthèse

[+]

Annexe A :


Dans les exemples de codes qui suivent, tous les contrôles de validité ont été éludés pour faciliter la lecture.

type de données

[+]

Terminologie utilisée


Structures de données

[+]

Synthétiseur

[+]

Paramètres

[+]

Annexe B


exemples


lecture d'un bloc de fichier RIFF.

[+]

Décryptage d'un fichier SF2

[+]

Exemple de lecture d'un fichier SF2

[+]

Liens et commentaires

Historique

Information Version
Tue 31 Jan 2023 18:12 ardoisebleue ajouter un ancrage blocbalisedhdr 95
Afficher
Tue 24 Jan 2023 09:49 ardoisebleue ajout ancre 94
Afficher
Mon 26 Mar 2018 11:27 ardoisebleue 93
Afficher
Tue 26 mai 2015 16:51 ardoisebleue 92
Afficher
Sat 23 mai 2015 15:19 ardoisebleue 91
Afficher
Sun 10 mai 2015 14:22 ardoisebleue ajout du lien pour la doc en anglais 90
Afficher
Sat 28 Dec 2013 10:25 ardoisebleue 89
Afficher
Sat 28 Dec 2013 10:20 ardoisebleue mise en page 88
Afficher
Sat 28 Dec 2013 10:00 ardoisebleue correction et mise en page 87
Afficher
Sat 28 Dec 2013 09:53 ardoisebleue 86
Afficher
Sat 28 Dec 2013 09:50 ardoisebleue 85
Afficher
Sat 28 Dec 2013 09:46 ardoisebleue 84
Afficher
Wed 18 Dec 2013 19:01 ardoisebleue correction 83
Afficher
Wed 18 Dec 2013 18:58 ardoisebleue 82
Afficher
Wed 18 Dec 2013 18:49 ardoisebleue 81
Afficher
Tue 17 Dec 2013 19:07 ardoisebleue mise en page 80
Afficher
Mon 16 Dec 2013 16:33 ardoisebleue 79
Afficher
Fri 13 Dec 2013 18:11 ardoisebleue correction et mise en page 78
Afficher
Fri 13 Dec 2013 18:09 ardoisebleue 77
Afficher
Fri 13 Dec 2013 18:03 ardoisebleue correction et mise en page 76
Afficher
Fri 13 Dec 2013 17:50 ardoisebleue 75
Afficher
Fri 13 Dec 2013 15:40 ardoisebleue 74
Afficher
Wed 11 Dec 2013 18:26 ardoisebleue correction mise en page 73
Afficher
Mon 09 Dec 2013 18:32 ardoisebleue correction et mise en page 72
Afficher
Fri 06 Dec 2013 18:31 ardoisebleue correction et mise en page 71
Afficher
Fri 06 Dec 2013 17:40 ardoisebleue 70
Afficher
Fri 06 Dec 2013 16:59 ardoisebleue 69
Afficher
Fri 06 Dec 2013 16:37 ardoisebleue 68
Afficher
Fri 06 Dec 2013 16:32 ardoisebleue correction et mises en page 67
Afficher
Fri 06 Dec 2013 16:24 ardoisebleue 66
Afficher
Tue 03 Dec 2013 14:52 ardoisebleue 65
Afficher
Tue 03 Dec 2013 14:37 ardoisebleue 64
Afficher
Tue 03 Dec 2013 14:35 ardoisebleue 63
Afficher
Tue 03 Dec 2013 14:31 ardoisebleue 62
Afficher
Tue 03 Dec 2013 14:30 ardoisebleue 61
Afficher
Tue 03 Dec 2013 14:27 ardoisebleue 60
Afficher
Tue 03 Dec 2013 14:24 ardoisebleue 59
Afficher
Tue 03 Dec 2013 14:18 ardoisebleue 58
Afficher
Tue 03 Dec 2013 14:17 ardoisebleue mise en page décryptage SF2 57
Afficher
Tue 03 Dec 2013 12:02 ardoisebleue 56
Afficher
Tue 03 Dec 2013 11:19 ardoisebleue mise en page du décryptage soundfont 55
Afficher
Tue 03 Dec 2013 10:11 ardoisebleue annotation décryptage fichier SF2 54
Afficher
Tue 03 Dec 2013 09:44 ardoisebleue 53
Afficher
Mon 02 Dec 2013 19:59 ardoisebleue 52
Afficher
Mon 02 Dec 2013 19:55 ardoisebleue mise en forme de l'exemple lecture fichier sf2 51
Afficher
Mon 02 Dec 2013 19:53 ardoisebleue 50
Afficher
Mon 02 Dec 2013 19:40 ardoisebleue 49
Afficher
Thu 28 Nov 2013 15:28 ardoisebleue 48
Afficher
Thu 28 Nov 2013 15:26 ardoisebleue 47
Afficher
Thu 28 Nov 2013 15:22 ardoisebleue 46
Afficher
  • «
  • 1 (en cours)
  • 2