Les informations qui suivent, peuvent sans trop de difficultés être utilisées pour la modification ou l'ajout de sons aux fichiers .2DA de Baldur's Gate 2.

À la différence des Baldur's Gate, les sons associés aux animations des créatures ne sont pas référencés dans des fichiers .2DA, mais dans un fichier .ini : le fichier sounds.ini.

note sur l'édition/modification du fichier sounds.ini

Je ne connais pas de programme qui permette d'écouter, modifier via une interface graphique les sons listés dans le fichier sounds.ini.
Contrairement à son habitude, DLTCP ne gère pas du tout ce paramètre : il ne permet ni d'éditer le fichier .ini, ni d'accéder aux sons qui sont associés aux animations via l'édition des animations ou des fichiers .CRE ou .ARE.
On procèdera donc en mode manuel, avec un simple éditeur de texte comme Notepad++ ou Notepad2.

Récupération du fichier SOUNDS.ini
Ce fichier étant stocké dans une archive .bif, le plus simple pour le récupérer et l'éditer ensuite, est d'utiliser NearInfinity :
Dans NearInfinity, il suffit de sélectionner le fichier "sounds.ini" dans la liste, puis de faire un clic droit dessus et de choisir l'option "Export", puis d'indiquer enfin l'emplacement où enregistrer le fichier.
Le fichier SOUNDS.ini modifié se place dans le dossier OVERRIDE du jeu.

Si on compare une section du fichier SOUNDS.INI avec un fichier .2DA de Baldur's Gate II, on se rend compte qu'ils reposent quasiment sur la même structure, à cette différence près qu'un fichier .2da ne liste les sons que pour une créature donnée - mais avec une liste d'actions types auxquelles sont associés des sons plus grande et variée - tandis que le fichier sounds.ini d'Icewind Dale II regroupe les sons de toutes les animations de créatures :

Il faut bien comprendre qu'on agit au niveau d'une animation donnée. Si l'on change les sons associés à l'animation MBER (Ours), les sons de toutes les créatures qui utilisent l'animation de l'Ours seront modifiés en conséquence.

Dans le fichier SOUNDS.INI, chaque animation est identifiée par une section qui reprend la racine du nom des fichiers .bam de l'animation suivie d'un commentaire qui permet de savoir à quoi elle correspond. Par ex. :
[MBER] /Bear/
puis suivent les différentes lignes permettant d'associer des sons à une animation donnée, qui correspond à un mouvement type. Dans l'exemple suivant, il s'agit des animations d'attaque (att1, att2...) :

[MDKN] /Death Knight/
att1=death03a,death03b,blank
att1frame=0,0,0
att2=death03a,death03b,blank
...

[MBER] /Bear/
att1=rbear03
att1frame=0
att2=rbear04
att2frame=0
att3=rbear05
...

[MSPI] /Spiders/
att1=gspid03
att1frame=0
att2=gspid04
att2frame=0
...

À chaque type d'action (cri de guerre, attaque, blessé, mourant, inactif), un ou plusieurs sons peuvent être associés par défaut, afin d'éviter un effet de monotonie (en général notées xxxxxA, xxxxxB...). On peut aussi intercaler une référence blank, pour apporter des silences et éviter que chaque action soit sytématiquement associée à un son.

Les lignes fonctionnent par 2:

• une qui indique les refs des fichiers .wav (sans l'extension) associés à un mouvement:
  damage=death07a,death07b,blank,death08a,blank
  
  
• la seconde qui se rapporte aux frames (images) de l'animation et permet de synchroniser le son à un moment de l'animation, via une valeur qui indique à partir de quel n° de frame le son doit être joué.
  Ce réglage sera possible pour chaque son associé à un mouvement - mais il n'est guère utilisé dans le jeu. En général les sons se jouent en même temps que l'animation, à partir de la première image, et cette valeur est simplement égale à 0. On se retrouve donc souvent avec une suite de 0, qui peuvent dérouter au premier abord :
  damageframe=0,0,0,0,0
  
  C'est dans le cas où le son intervient à un moment précis de l'animation que cette seconde ligne prend tout son sens, en permettant d'indiquer cet instant via le n° de frame auquel il intervient. Ce cas de figure se produit par exemple dans l'animation de chute, où le son ne commence à être lu qu'à la fin de l'animation, lorsque la créature touche le sol :
  
  [MDH1] /Half Dragon (black)/
  ...
  fall=bf_md01a,bf_md02a,bf_md03a
  fallframe=15,15,15
  
  Dans cet exemple, si l'on consulte l'animation de chute du Demi-Dragon (MDH1SL), on constate que la frame n°15 correspond bien au moment où la créature commence à toucher le sol dans sa chute.
   
  On remarque à ce titre que les sons utilisés lorsqu'une créature tombe à terre sont dans le jeu de trois types, selon qu'il s'agit de créatures lourdes ou légères - mais rien n'empêche de créer les siens:
  bf_lg01 à 06  - large
  bf_md01 à 05 - medium
  bf_sm01 05 - small

Différents mouvements associés à des sons dans IWD2 :

att1= (cris d'attaque 1)   : xxxx3, xxxx4 ou xxxx5
att2                             : xxxx3, xxxx4 ou xxxx5
att3                             : xxxx3, xxxx4 ou xxxx5
att4                             : xxxx3, xxxx4 ou xxxx5
btlcry= (cri de guerre) : xxxx1 ou xxxx2
damage = blessé : xxxx6 ou xxxx7
death = mourant : xxxx8 ou xxxx9
fidget = "nerveux", tics, ponctuations sonores hors combat - rarement utilisé car occupant vite l'espace sonore, quand la créature est près de nous et "marmone dans son coin"
selected = sélectionné
fall = tombe (mort ou endormi).

Lorsqu'on ne souhaite pas associer de son à un évènement type, il suffit de le laisser vide :
fidget=
fidgetframe=

Conventions sur l'appellation des fichiers .WAV
Les fichiers WAV associés à une animation, sont nommés d'une manière particulière qui permet de savoir, sans avoir à les lire, à qui ils se rapportent et le mouvement qu'ils illustrent:
[nom de la créature + n°+ variante] (5 lettres+1 numéro à 2 chiffres+lettre = 8 caractères maxi)
djwol01a, djwol01b, djwol02a
Cette syntaxe n'a rien d'obligatoire vis à vis du moteur du jeu (si ce n'est sa longueur de 8 caractères), c'est une simple convention, une facilité pour s'y retrouver parmis des milliers de fichiers WAV.
Par convention (...et par expérience !), autant respecter cette manière de nommer les fichiers : quand on travaille sur un grand nombre de fichiers, autant savoir que tel type de référence signifie toujours telle chose, et c'est ainsi qu'ont fonctionné les développeurs.
Chaque chiffre correspond donc généralement à un type d'évènement particulier :

xxxxx01 : cri de guerre, cri d'attaque
xxxxx02 : variante cri de guerre

xxxxx03 : porte un coup
xxxxx04 : porte un coup
xxxxx05 : porte un coup

xxxxx06 : touché / blessé
xxxxx07 : touché / blessé

xxxxx08 : mourant
xxxxx09 : mourant

xxxx10: déplacement ?
xxxx11: passif

Ajouter des sons pour de nouvelles animations

Si l'on a jouté de nouvelles animations à IWD2 (voir l'article "Ajouter des animations manquantes à IWD2"), il va falloir ajouter ou modifier une section propre à cette animation dans le fichier SOUNDS.INI.
Dans le cas du remplacement d'une animation existante, il suffira de modifier la section appropriée.

Son nom reprendra nécessairement la racine du nom (4 lettres) des fichiers .bam qui lui sont associés.
Si par exemple j'ai repris l'animation du Trocopotoca de Planescape Torment, et que je l'ai mis à l'emplacement, inutilisé, du Voydanoï (0xE7F9 Umber Hulk, Vodyanoi). En  consultant le fichier animate.src, je sais que cette animation est connue par le jeu sous le nom de :
// Umber Hulk, Vodyanoi
0xE7F9=MUM2WK
En ne conservant que la racine du nom, on obtient : MUM2
Il suffit de se rendre à cette section dans le fichier sounds.ini, et de le modifier à sa manière :

[MUM2] /Trocopotoca (PST)/
att1=TROCO03a,TROCO03b
att1frame=0,0
att2=TROCO04a,TROCO04b
att2frame=0,0
att3=
att3frame=
att4=
att4frame=
btlcry=TROCO01,TROCO02a,TROCO02b,blank
btlcryframe=0,0,0
damage=TROCO07,TROCO08
damageframe=0,0
death=TROCO09,TROCOA10
deathframe=
fidget=
fidgetframe=
selected=TROCO01
selectedframe=0
fall=bf_lg01a,bf_lg02a,bf_lg03a
fallframe=12,12,12

Malheureusement, de même que certains emplacements d'animation potentiellement utilisables ne fonctionnent pas, certaines références d'animations inutilisées n'ont pas de sons : on aura beau indiquer des sons à jouer, des sons standard seront joués dans le jeu !
En voici quelques-unes que j'ai rencontrées :

MIGO (0x7F04 Golem, Iron_BG2)
NPIR (0x7F24 Pirate)
NSAI (0x7F2A Sailor)
MTRO (0x7F00 Troll)
MGCL (0x7F0B GREATCAT_LEOPARD)
MGCP (0x7F0A GREATCAT_PANTHER)
MDJL (0x7F06 Djinni w/ LEGS)

Patch 2.01 FR:  Télécharger

Le patch français d'Icewind Dale 2, pour les rares personnes qui disposent encore des versions CD, et leur éviter d'avoir à le chercher à droite et à gauche.

Note : Ce patch est intégré d'office aux versions dématérialisées d'Icewind Dale 2, comme celle vendue par GoG. Il n'est nécessaire de l'installer que pour les versions CD du jeu.

Dialog.tlk _ FR:  Télécharger

Les fichiers dialog.tlk & dialogF.tlk d'Icewind Dale 2 en français, avec les modifications du patch 2.01,  pour ceux qui auraient une version anglaise et souhaiteraient la passer en français (notez que vous n'aurez bien entendu pas les voix - fichiers wav - en français, mais seulement tous les textes et l'interface)
...il peut être aussi utile aux moddeurs qui auraient bidouillé ce fichier, et veulent revenir à une installation originale sans devoir tout réinstaller !

Dialog.tlk _ ENG:  Télécharger

Le fichier dialog.tlk en anglais (version 2.01). Il peut être intéressant de le consulter pour comparer la traduction française avec. 

Là aussi, les versions dématérialisées comme celle de GoG permettent d'avoir accès au téléchargement du jeu dans différentes langues, dont, bien entendu, l'anglais.

Dale Keeper II v.1.0.0.5:  Télécharger

Dans la catégorie des programmes permettant d'éditer les sauvegardes des jeux de la série Baldur's Gate, créés par Aaron O'Neil,  Dale Keeper II permet donc de modifier les sauvegardes d'IWD2, de convertir un PJ en fichier .chr ou .cre
Ceux qui savent manipuler NearInfinity ou DLTCEP n'y trouveront peut-être guère d'intérêt, en revanche sa facilité d'utilisation et sa rapidité d'accès sont très utiles pour modifier rapidement des sauvegardes.

Merci à Aaron O'Neil