- Informations sur le Son

principe
- Informations sur le Son
I. MODELISATION DES SONS : (fichier au format Wav)
· Pour numériser le son, on mesure à intervalles de temps réguliers (fréquence
d'échantillonnage), les variations de l'onde sonore que l'on quantifie selon une certaine échelle
de valeurs possibles (sur 8 bits = 255 valeurs possibles, sur 16 bits = 65535 valeurs possibles).
Plus la fréquence d'échantillonage (de mesure) est élévée et plus l'échelle de quantification est
grande, meilleure sera la modélisation.
· Dans le schéma ci-dessous, l'abscisse représente le temps à découper et l'ordonnée la grandeur
physique à quantifier selon une échelle de valeurs.
· Bien sûr, le choix de la fréquence d'échantillonnage et la profondeur de la quantification ont
une influence directe sur le volume des données numérisées et la fidélité de la numérisation : un
équilibre est à trouver entre taille du fichier numérique et qualité du son.
· La carte son de l'ordinateur doit permettre des enregistrements sur 16bits à 44,1 kHz et en
stéréo (qualité CD audio), mais nous n'utiliserons guère cette qualité, car elle exige 10 Mo par
minute.
Tableau comparatif : taille des données / qualité numérisation
Taille des fichiers pour 1 mn d'enregistrement (échantillonnage en PCM)
8 bits mono 8 bits Stéréo 16 bits mono 16 bits stéréo
8000 Hz
(voix) 7 kb/s 420 Ko 15 kb/s 900 Ko 15 kb/s 900 Ko 31 kb/s 1860 Ko
11025 Hz
(voix,mus.) 10 kb/s 600 Ko 21 kb/s 1260 Ko 21 kb/s 1260 Ko 43 kb/s 2580 Ko
file:///L|/principe.htm (1 sur 5)06/11/2005 00:59:35

principe
22050 Hz
(musique) 21 kb/s 1260 Ko 43 kb/s 2580 Ko 43 kb/s 2580 Ko 86 kb/s 5160 Ko
44100 HZ
(musique) 43 kb/s 2580 Ko 86 kb/s 5160 Ko 86 kb/s 5160 Ko 172 kb/s 10320 Ko
En bleu, les échantillonages les plus usités (qualité moyenne, mais taille réduite)
En rouge, l'échantillonage qualité CDAudio
· Les données audionumériques sont codées sans compressions au format PCM (Pulse Code Modulation). Les
fichiers obtenus sont de type AIF (Macintosh) ou WAV sous Windows.
· Les formats WAV peuvent être compressés, format ADPCM par exemple, mais il faut vérifier que la carte et les
pilotes supportent ce codage.
II. STRUCTURE D'UN FICHIER WAV: (ici tada.wav)
· Comme pour toute modélisation (cf image BMP en 256 couleurs), le format de données obtenu comprend
- des octets d'en-tête permettant une identification, 44 octets pour un fichier WAV
- une structure les organisant,
- le codage des données.
· Il s'agit d'un fichier RIFF (Resource Interchange File Format), formé de chunks, c'est-à-dire de blocs
hiérarchisés :
1. chunk RIFF avec son étiquette CkId "RIFF" suivie de la taille du chunk 27796
2. chunk de format avecson étiquette CkId "fmt " suivie de la taille du chunk 16
3. chunk de données avec son étiquette CkId"data" suivie de la taille du chunk 27760
file:///L|/principe.htm (2 sur 5)06/11/2005 00:59:35

principe
Le chunk de format nous indique la modélisation suivante : 22050 HZ, 8bits, mono pour le fichier tada.wav (son
très bref, à peine plus d'une seconde, et de qualité moyenne).
· L'entête mesure 58 octets, et s'étend donc de l'adresse 00h à l'adresse 3Ah.
- Les fichiers WAV utilisent le format RIFF ; définition du format RIFF :
Octets 1 à 4 : Caractères 'RIFF' [52h 49h 46h 46h] identifiant le format.
Octets 5 à 8 : Longueur du groupe de données au format WAV =
[30h.00h.01h.00h] = 00010030h = 65584 octets,
(le reste du fichier, car 65584+8 = 65592 octets).
Octets 9 à 16 : Caractères 'WAVEfmt ' identifiant le format WAV.
- Les octets 17 à 56 définissent les paramètres du format 'WAV' :
Octets 17 à 20 : [10.00.00.00] = 00000010h = 16 = nombre d'octets
utilisés après pour définir le format.
Octets 21 à 22 : [01.00] = 0001h = 1 = numéro de format du fichier
(pas de compression, format PCM classique).
Octets 23 à 24 : [01.00] = 0001h = 1 : nombre de canaux : ici, mono.
Octets 25 à 28 : [11.2B.00.00] = 00002B11h = 11025, fréquence
d'échantillonnage (en Hz), c'est à dire le nombre
file:///L|/principe.htm (3 sur 5)06/11/2005 00:59:35

principe
d'échantillons pas seconde.
Octets 29 à 32 : [11.2B.00.00] = 00002B11h = 11025, nombres d'octets par
seconde, ce qui revient au même car un échantillon mesure
un octet et l'on est en mono.
Octets 33 à 34 : [01.00] = 0001h = 1 = Produit du nombre de canaux par le
nombre d'octets par échantillon (ici 1x1=1).
Octets 35 à 38 : [08.00.00.00] = 00000008h = 8 bits par échantillon (valeurs
possibles : 8, 12 ou 16).
Octets 39 à 50 : [66.61.63.74][04.00.00.00][00.00.01.00] = 'fact', 4, 65536.
Champ sur lequel je n'ai pas de précision ; je pense
que 'fact' annonce des informations, que les 4 octets
suivants indiquent la taille de ces infos (4 octets),
et que dans ce cas, l'info est le nombre d'échantillons,
lequel est repris après par 'data', soit 65536.
- Les octets 51 à 58 définissent les données du "WAV" :
Octets 51 à 54 : 'data' : annonce l'arrivée des données.
Octets 55 à 58 : [00.00.01.00] = 00010000h = 65536 : taille des données.
- Les 65536 octets suivants : valeurs numériques successives des échantillons, oscillant autour de la
valeur moyenne 80h, selon l'amplitude et le signe du signal d'entrée. Il ne faut pas oublier qu’un
octet est signé en java, nous devons faire une conversion pour récupérer les valeurs des échantillons.
· Les données du son, les échantillons, sont alignés les uns après les autres dans l’axe des temps (dans l’ordre où ils
arrivent dans le temps). En stéréo, les canaux sont multiplexés (entrelacés). Ce multiplexage offre deux
avantages : lecture/écriture des deux canaux en une seule opération disque (évite surtout les déplacements de têtes
du disque) et l’augmentation aisée du nombre de canaux tout en restant dans la norme du format (par exemple un
format quadriphonique).
Exemple de stockage des samples pour un son stéréo 8bits ou 16 bits stéréo:
· Codage des échantillons :
Le codage est différent en 8 bits et en 16 bits. En 16bits, le mot est conforme à un entier signé 16bits
(-32768, +32767) centré sur zéro. En 8 bits, l’octet est en fait un BYTE (0 - 255) centré sur 128.
Pour transformer ce BYTE en entier signé par exemple, il faudra lui retrancher la valeur 128. Nous
aurons alors un entier (-128 à +127) centré sur zéro correspondant ainsi au signal réel (devant être
file:///L|/principe.htm (4 sur 5)06/11/2005 00:59:35

principe
traité).
Retour à la page d'accueil
file:///L|/principe.htm (5 sur 5)06/11/2005 00:59:35