La conversion audio sous linux

GILBERT Louis-Marie
LETOURNEAU Christophe
LE TEXIER Nicolas
Licence T&E3
ISTIA
2006-2007
La conversion audio sous linux
Mai
- juin 2007
Responsable de projet : M. Julien ROUSSEAU
Remerciements
Nous remercions vivement Julien ROUSSEAU pour ses suggestions et ses observations qui
nous ont permis de nous guider durant nos travaux. Ses connaissances dans le domaine
informatique, et plus particulièrement sur le système d’exploitation linux nous ont été utiles
pour nous débloquer de situations difficiles.
Nous avons aussi une pensée particulière pour MM DANIEAU, DUTHIL et LASTERRA.
Même si nous travaillions sur des sujets sensiblement différents, nous oeuvrions ensemble
pour obtenir un résultat qui soit compatible. Leur acquis sur linux et leur disponibilité nous
ont été profitable pour l’avancement de nos travaux.
Une dernière pensée pour l’ensemble des étudiants et des professeurs qui étaient présent
durant ce projet : l’atmosphère de bonne humeur et le sérieux présent du début à la fin nous
ont été très bénéfique.
Licence T&E3
-2-
Mai – Juin 2007
Sommaire
Introduction ........................................................................................................................................p.4
Chapitre I : Qu’est-ce que le son ? ..................................................................... p.5
I.1 – Présentation du son .........................................................................................p.6
I.2 – Le son en informatique...................................................................................p.7
Chapitre II : Les différents formats de fichiers........................................... p.9
II.1 – Le format WAVE................................................................................................p.10
II.2 – La compression.................................................................................................p.13
II.3 – Les autres formats..........................................................................................p.14
Chapitre III : Le passage d’un format à un autre ...........................................p.17
III.1 – Pourquoi convertir ........................................................................................p.18
III.2 – Des formats différents. ...............................................................................p.18
III.3 – Comment convertir ?....................................................................................p.18
Chapitre IV : La compression par Fourier et Huffman ................................p.20
IV.1 – La compression par transformée de Fourier ...................................p.21
IV.2 – La compression par la méthode d’Huffman......................................p.26
Chapitre V : Notre application .....................................................................................p.31
V.1 – L’organisation des tâches...........................................................................p.32
V.2 – Les fonctionnalités du logiciel .................................................................p.32
V.3 – Problèmes rencontrés et solutions apportées.................................p.31
Conclusion..........................................................................................................................................p.32
Licence T&E3
-3-
Mai – Juin 2007
Introduction
1 - Conditions de réalisation.
Le projet a été réalisé dans le cadre de la licence LTE3. Il permet aux étudiants de
mettre en pratique leurs acquis et de développer de nouvelles connaissances.
Encadré par un enseignant, chaque groupe prend en charge un projet depuis sa
conception jusqu’à sa réalisation. Pendant une période d’un mois, des postes informatiques
sont mis à disposition des étudiants.
A l’issue du temps imparti, le projet donne lieu à une soutenance.
Notre groupe composé des étudiants GILBERT Louis-Marie, LETOURNEAU
Christophe et LE TEXIER Nicolas s’est vu confié le projet son temps réel sous linux, sous la
responsabilité de M.ROUSSEAU.
2 - Objectifs du projet.
Le projet avait pour but de passer d’un format sonore à un autre. Il fallait ensuite créer
une application pour changer de format. Cette application devait être programmé en langage
C.
De cette application, nous devions en faire une bibliothèque. Il fallait donc savoir
comment créer une bibliothèque sous linux.
Cette première phase accomplie, nous pouvions développer une application graphique en
C++ : orienté objet.
Nous devions ainsi : - Trouver un environnement de développement sous linux,
- Faire appel à la bibliothèque,
- Réfléchir aux options intéressantes pour une application de type
acquisition.
3 - Choix du thème.
Nous avons choisi de développer ce projet en premier lieu pour découvrir
l’environnement de linux. En effet, aucun de nous trois n’avions de connaissance sur ce
système d’exploitation. Linux étant de plus en plus utilisé dans le domaine informatique, et le
fait qu’il soit développé dans le programme de master, découvrir linux par ce projet nous a
paru une bonne introduction.
Un autre point que ce projet développe : le langage C++. Ici aussi, nous ne
connaissions aucun langage orienté objet. Nous pensions que le projet nous permettrait de
découvrir ce concept de langage par nous même et à notre propre rythme.
Un dernier aspect qui nous a fait choisir ce projet informatique plus qu’un autre est le
fait qu’il traite le domaine des sons. Nous avions au préalable quelques notions que nous
avions acquises soit par nous même, soit durant nos années d’études précédentes. Nous avions
envie de développer ces acquis et surtout de pouvoir utiliser nos connaissances,
principalement dans le domaine physique et de pouvoir les manipuler dans le domaine
informatique. Cette dualité hardware-software nous a paru utile pour nous car elle est très
présente dans le monde professionnel.
Licence T&E3
-4-
Mai – Juin 2007
Chapitre I :
Qu’est-ce que le
son ?
Licence T&E3
-5-
Mai – Juin 2007
I.1 – Présentation du son.
Afin de mieux appréhender notre projet, notre travail nécessitait une recherche sur le
comportement physique du son.
Le son est une vibration de l’air, c'est-à-dire une suite de surpressions et de dépressions de
l’air par rapport à une moyenne, qui est la pression atmosphérique. La façon la plus simple de
reproduire un son est de faire vibrer un objet.
Pour reproduire des sons, on utilise généralement des haut-parleurs. Il s’agit en fait d’une
membrane reliée à un électroaimant qui, suivant les sollicitations d’un courant électrique, va
aller en avant et en arrière très rapidement, ce qui provoque une vibration de l’air situé devant
lui, c’est-à-dire du son.
De cette façon, on produit des ondes sonores qui peuvent être représentées sur un graphique
comme les variations de la pression de l’air (ou bien de l’électricité dans l’électroaimant) en fonction
du temps. On obtient alors une représentation de la forme suivante :
Cette représentation du son est appelée « spectre de modulation d’amplitude » (modulation de
l’amplitude d’un son en fonction du temps). Le sonogramme représente par contre la variation des
fréquences sonores en fonction du temps. On peut remarquer qu’un sonogramme présente une
fondamentale, à laquelle se superposent des fréquences plus élevées, appelées harmoniques.
Licence T&E3
-6-
Mai – Juin 2007
C’est ce qui permet d’arriver à distinguer plusieurs sources sonores : les sons graves
auront des fréquences basses, et les son aigus, des fréquences élevées.
I.2 – Le son en informatique.
Après avoir étudier ce qu’était le son dans le monde physique, nous devions comprendre
comment ce déroule le passage du son de hardware à software. Pour appréhender ce
processus, nous avons cherché comment le son est codé après qu’il soit échantillonné.
I.2.A – L’échantillonnage du son.
Pour pouvoir représenter un son sur un ordinateur, il faut arriver à le convertir en
valeurs numériques, car celui-ci ne sait travailler que sur ce type de valeurs. Il s’agit donc
de relever des petits échantillons de son (ce qui reviens à relever des différences de
pression) à des intervalles de temps précis. On appelle cette action, « l’échantillonnage »
ou « la numérisation du son ». L’intervalle de temps entre deux échantillons est appelé
taux d’échantillonnage. Etant donné que pour arriver à restituer un son qui semble continu
à l’oreille il faut des échantillons tous les 100 000ièmes de seconde, il est plus pratique de
raisonner sur le nombre d’échantillons par seconde, exprimés en Hertz (Hz). Voici
quelques exemples de taux d’échantillonnage et de qualités du son associées :
Taux d’échantillonnage
44 100 Hz
22 000 Hz
8 000 Hz
Qualité du son
Qualité CD
Qualité radio
Qualité téléphone
La valeur du taux d’échantillonnage, pour un CD audio par exemple, n’est pas
arbitraire, elle découle du théorème de Shannon. La fréquence d’échantillonnage doit être
suffisamment grande, afin de préserver la forme du signal. Le théorème de Nyquist –
Shannon stipule que la fréquence d’échantillonnage doit être égale ou supérieure au
double de la fréquence maximale contenue dans ce signal. Notre oreille perçoit les sons
jusqu’à environ 20 000 Hz, il faut donc une fréquence d’échantillonnage d’au moins
40 000Hz pour obtenir une qualité satisfaisante.
I.2.B – Le codage du son.
A chaque échantillon (correspondant à un intervalle de temps) est associé une valeur
qui détermine la valeur de la pression de l’air à ce moment, le son n’est donc plus
représenté comme une courbe continue présentant des variations, mais comme une suite
de valeur pour chaque intervalle de temps :
Licence T&E3
-7-
Mai – Juin 2007
L’ordinateur travail avec des bits, il faut donc déterminer le nombre de valeurs que
l’échantillon peut prendre, cela revient à fixer le nombre de bits sur lequel on code les
valeurs des échantillons, par exemple :
Avec un codage sur 8 bits, nous aurons 28 soit 256 valeurs possibles
Avec un codage sur 16 bits, nous aurons 216 soit 65536 valeurs possibles
Nous aurons bien évidemment une meilleure qualité du son avec un codage en 16 bits,
mais aussi un besoin en mémoire plus important.
Enfin, la stéréophonie nécessite (procédé de reproduction des sons qui permet de faire
croire à l’auditeur qu’il est dans une salle de concert) deux canaux sur lesquels on
enregistre individuellement un son qui sera fourni au haut-parleur de gauche, et un son qui
sera diffusé à celui de droite.
Le son est donc représenté informatiquement par plusieurs paramètres :
La fréquence d’échantillonnage
Le nombre de bits d’un échantillon
Le nombre de voie (1 : Mono ; 2 : Stéréo ; 4 : quadriphonie)
I.2.C – Mémoire requise pour stocker un son.
Il est simple de calculer la taille d’une fréquence sonore non compressée. En effet, en
connaissant le nombre de bits sur lequel est codé un échantillon, on connaît la taille de
celui-ci (la taille est le nombre de bits).
Pour connaître la taille d’une voie, il suffit de connaître le taux d’échantillonnage, qui
va nous permettre de savoir le nombre d’échantillons par seconde, donc la taille
qu’occupe une seconde de musique. Celle-ci vaut :
Taux d’échantillonnage x Nombre de bits
Ainsi, pour connaître l’espace mémoire que consomme un extrait sonore de plusieurs
secondes, il suffit de multiplier la valeur précédente par le nombre de secondes :
Taux d’échantillonnage x Nombre de bits x Nombre de secondes
Enfin, la taille finale de l’extrait est à multiplier par le nombre de voies (elle sera alors
deux fois plus importante en stéréo qu’en mono). La taille en bit d’un extrait sonore est
ainsi égale à :
Taux d’échantillonnage x Nombre de bits x Nombre de secondes x Nombre de voies
Licence T&E3
-8-
Mai – Juin 2007
Chapitre II :
Les différents formats
de fichiers
Licence T&E3
-9-
Mai – Juin 2007
II.1 – Le format WAVE.
Le format WAVE est un pilier pour notre application. Il est par exemple utilisé comme
pivot pour les conversions de fichier. Nous utilisions ce format pour notre application car la
majorité des autres formats est protégé en écriture. Ainsi, leur structure et leur fonctionnement
ne nous étaient pas dévoilés. Il nous a donc fallu connaître la structure du format WAVE.
Le format WAVE est à la base un format de fichier développé par Microsoft, destiné à
contenir du son. Pour être plus précis, le format WAVE est un format d'encapsulage (comme
le format AVI pour la vidéo). Il ne définit pas de méthode d'encodage du son, sauf pour le
format brute que nous allons étudier ici.
II.1.A – Structure d’un fichier WAVE.
Le WAVE est un format structuré, composé d'une suite de blocs clairement
identifiables dont le rôle est plus ou moins établit. Typiquement, un bloc est composé de
trois parties :
Nom/identifiant du bloc (différencie ce bloc de tous les autres)
Taille des données du bloc (en octet)
Données du bloc
La structure globale d'un fichier WAVE est un superbloc, le bloc RIFF, qui encapsule
d'autres blocs que nous verrons au paragraphe suivant. Le bloc RIFF est appelé ainsi car
les 4 octets du champ Chunk_ID est composé des 4 caractères ASCII : R, I, F, F.
Le champ Chunk_Size correspond à la taille totale du fichier WAVE auquel on
retranche les 8 octets occupés par les champs Chunk_ID et Chunk_Size du bloc RIFF.
II.1.B – Codage des entiers.
Les entiers signés stockés dans les fichiers WAVE sont codés en little-endian
complément à 2 (le format des entiers sur les plate-forme Intel). Ceci signifie qu'un entier
stocké sur plusieurs octets sera enregistré avec l’octet de poids le plus faible d'abord.
En pratique, l'entier 12345678 en base 10 s'écrit BC614E en base 16. On complète
par des zéros pour obtenir un entier sur 32 bits (4 octets) : 00BC614E. Notre fichier
WAVE contiendra donc la suite d'octets suivante : 4E 61 BC 00 (les octets ont été
« renversés »).
Ce codage est valable pour tous les entiers d'un fichier WAVE, y compris les champs
Chunk_Size.
Licence T&E3
- 10 -
Mai – Juin 2007
II.1.C – Deux blocs principaux.
À l'intérieur des données du bloc RIFF, nous retrouvons plusieurs autres blocs. Il est
important de noter que l'ordre d'apparition de ces autres blocs n'a pas d'importance.
Nous allons traiter deux des blocs les plus importants : le bloc Format et le bloc Data.
Le bloc Format.
De manière générale, les blocs peuvent être enregistrés dans n'importe quel ordre.
Il existe une exception : le bloc Format doit toujours être placé avant le bloc Data.
Le bloc format est identifié par le Chunk_ID « fmt » (notez l'espace pour le
quatrième caractère après fmt), ou 66 6D 74 20 dans le fichier WAVE.
Ce bloc contient un certain nombre d'informations sur l'échantillonnage du son,
l'algorithme de compression utilisé, etc. Ci-dessous, la description des différents
champs :
wFormatTag (2 octets) :
Indique la façon dont le bloc Data doit être interprété.
- 00 00 indique que le format est inconnu.
- 00 01 indique qu'il s'agit de données brutes (c'est ce format qui nous intéresse).
- FF FF indique un format expérimental.
D'autres codes existent permettant de stocker des données MP3 par exemple. Dans
ce cas, le bloc format peut contenir des champs supplémentaires (en fin de bloc)
pour permettre la décompression.
wChannels (2 octets)
Spécifie le nombre de canaux enregistrés.
- 00 01 signifie qu'il s'agit d'un son monophonique
- 00 02 stéréophonique
- 00 04 quadriphonique
- etc.
Toutes les valeurs sont possibles pour ce champ, excepté zéro.
dwSamplesPerSec (4 octets)
Indique le nombre d'échantillons enregistrés par seconde et par canal. Ce champ
est exprimé en Hertz (Hz).
Licence T&E3
- 11 -
Mai – Juin 2007
On retrouve généralement des valeurs telles que 44100, 22050, 11025, 8000, etc.
Bien entendu, n'importe quelle autre valeur est acceptable.
dwAvgBytesPerSec (4 octets)
wBlockAlign (2 octets)
wBitsPerSample (2 octets)
Indique la taille en bit d'un échantillon. Pour des raisons de performances, les
échantillons sont enregistrés en les alignant à l'octet supérieur le plus proche.
Classiquement, des échantillons de 12 bits seront enregistrés sur 16 bits. Le
champs wBitsPerSample permet d'indiquer que seuls les 12 premiers bits sur les
16 sont significatifs.
Le bloc Data
Le bloc de données suit normalement directement le bloc format, mais ce n'est pas
obligatoire. La seule contrainte est qu'il soit placé après le bloc format.
Le bloc format est identifié par le Chunk_ID "data" ou 64 61 74 61 dans le fichier
WAVE.
Le bloc de données regroupe les données brutes du son (pour le format PCM, c'est
à dire non compressé). Les données sont organisées sous la forme d'une suite
d'échantillons (dont la taille est donnée par le bloc Format). Chaque échantillon est
découpé en un certain nombre de chaînes :
une chaîne pour le mono
deux chaînes pour le stéréo
etc
La figure ci-dessous montre comment ces informations s'imbriquent et se
succèdent :
Pour comprendre comment lire ces données, il faut différencier deux cas.
Tout d'abord, il y a le cas des échantillons d'une taille de 8 bits. Les valeurs
stockées sont des entiers non signés sur 8 bits.
Le second cas concerne toutes les autres tailles d'échantillons. Dans ce cas, les
données sont enregistrées sous la forme d'entiers signés en codage little-endian.
Licence T&E3
- 12 -
Mai – Juin 2007
Le codage little-endian consiste à découper un entier écrit en binaire en paquets de
8 bits, puis à renverser l'ordre des paquets (mais pas l'ordre des bits au sein des
paquets!).
Par exemple, voici un nombre binaire sur 24 bits : 00110110 10110100 01101110.
En le codant en little-endian, il devient : 01101110 10110100 00110110. Cette
conversion est nécessaire lors de la lecture et de l'écriture d'un fichier WAVE.
Notez enfin que les valeurs stockées correspondent à la position de la membrane
du haut-parleur à un instant donné. Ainsi, pour les paquets de 8 bits, 0 signifie que la
membrane du haut-parleur est complètement enfoncée, et 255 signifie que la
membrane est complètement en avant.
Les autres blocs
Il existe d'autres blocs, plus ou moins standardisés. Ce qu'il faut comprendre c'est qu'il
ne faut pas altérer ou supprimer un bloc dont on ne comprend pas la signification. Lors de
l'écriture d'un programme qui modifie un fichier WAVE, ce programme ne doit pas faire
de modifications sur des données qu'il ne comprend pas.
II.1.D – Quelques informations supplémentaires.
Voici quelques formules intéressantes qu'il est possible de calculer à partir des
informations d'en-tête :
Débit (en Kbps) : dwAvgBytesPerSec * 8 / 1000
Durée (en secondes) : Data_Size / dwAvgBytesPerSec
Nombre d'échantillons : Data_Size / wChannels / wBitsPerSamples
Taux d'échantillonnage audio (KHz) : dwSamplesPerSec / 1000
Concernant le traitement du signal, l'interprétation des données brutes d'un son WAVE
peut être effectuée grâce à une transformation de Fourier (rapide). Cette transformation
permet notamment d'obtenir une représentation graphique du son (fréquence et/ou
amplitude en fonction du temps) à partir des données brutes. Ceci sera développé plus tard
dans le rapport.
II.2 – La compression.
Une des fonctionnalités de notre application est la compression de fichier. Il existe deux
types de compression, la compression destructrice (aussi appelées Lossy) et la compression
non destructrice (aussi appelée Lossless). Notre application permet les deux. La compression
est utilisée afin de réduire l’espace mémoire utilisé par les fichiers audio.
II.2.A – La compression destructrice.
Une compression destructrice, c'est une compression qui est réalisée en perdant de
l'information. Cela signifie que si l'on décompresse le signal compressé à l'aide d'une telle
technique, on ne retrouvera pas le signal de départ.
Licence T&E3
- 13 -
Mai – Juin 2007
Parmi les techniques de compression destructrices, on a essentiellement des méthodes
qui exploitent les propriétés de l'oreille humaine. Cette dernière entend les fréquences
situées dans la gamme 20 Hz 20 kHz. Si un morceau contient des fréquences hors de cette
gamme, on peut donc purement et simplement les supprimer sans perte de qualité audio
puisque l'oreille ne les entend pas. En fait, on entend surtout correctement les fréquences
situées dans la gamme 2 kHz 5 kHz.
Ces constatations peuvent être exploitées pour réduire la taille des fichiers. On peut
par exemple décider que toutes les fréquences au dessus de 15kHz seront supprimées. On
peut utiliser aussi le principe des fréquences masquées. Si dans un groupe de fréquences,
certaines ont un niveau sonore beaucoup plus élevé que d'autres, il n'est pas nécessaire de
conserver les fréquences de niveau sonore faible puisque l’on ne les entendra pas. Par
exemple, imaginez que vous êtes dans votre jardin et que vous entendez le pépiement des
oiseaux. Un avion passe au dessus de votre tête (même très haut). Vous n'entendrez plus
les oiseaux car le son qu'ils produisent est beaucoup plus faible que celui généré par
l'avion. C'est comme si les oiseaux n'existaient plus ou avaient arrêté de chanter.
II.2.B – La compression non destructrice.
Petit rappel : une seconde de musique c'est une succession de fréquences.
Imaginons que dans la suite d'échantillons composant une seconde de musique on ait
plusieurs fois de suite la même fréquence, par exemple 10 fois. Si au lieu de stocker ces
10 points, on en stocke 1 seul et le nombre de fois où il se répète, on a besoin de coder 2
nombres et non 10.
On utilise également l'algorithme de Huffman comme méthode de codage des
informations. Cette méthode est utilisée dans tous les algorithmes de compression. Le
Chapitre IV explique cet algorithme.
II.3 – Les autres formats.
Dans cette partie, nous ne traiterons pas de tous les formats existants, car il y en a trop, mais
simplement de 3 formats courants, le MP3, le WMA et l’OGG.
II.3.A – Le format MP3.
Le MP3 (MPeg Audio Layer 3) est un format de fichier son compressé obtenu par
suppression de données. Il fut développé par l'organisation de standardisation
internationale (ISO) en 1990.
La compression Mpeg Layer-3 permet de diminuer d'environ 12 fois la taille d'un
fichier audio habituel. Le principal intérêt de ce format est d'atteindre un taux de
compression très important sans perte de qualité sonore. Après la compression, vous ne
ferez aucune différence entre le son original d'un CD et le son de ce CD compresser en
MP3.
Licence T&E3
- 14 -
Mai – Juin 2007
Pour un petit comparatif, avec une compression de 1:12, les fichiers sons ne font plus
que 4 Mo pour 3 minutes alors qu'un fichier WAVE de qualité CD atteint facilement les
40 Mo ( le tout sans dégradation sonore ).
La lecture de tels fichiers se fait via l'intermédiaire de logiciels dédiés qui permettent
le décodage (décompression) de ceux-ci.
II.3.B – Le format WMA.
Le WMA est une technique de compression des formats numériques audio. Le brevet
en a été déposé par Microsoft en 1999. Face au succès du MP3 et l'engouement des
internautes pour ce format, Microsoft se devait de réagir. Ainsi est né le Windows Media
Audio codec.
Le WMA exploite en 1er lieu les propriétés de l'oreille pour réduire la taille d'un
morceau, puis on traite l'aspect stéréo et enfin on applique des codages en terminant par le
codage de Huffman. L'utilisation de toutes les possibilités de réduction évoquées dépend
de la place que l'on souhaite accorder à 1 mn de son compressé et donc du taux de
compression que l'on va devoir appliquer. Pour l'encodage de fichiers son en WMA on
parle plutôt en terme de bitrate que de taux de compression. Le bitrate est le nombre de
bits que l'on autorise pour coder 1 seconde. On aura donc la relation suivante : plus on
veut compresser un morceau (pour qu'il prenne le moins de place possible) plus le bitrate
à choisir devra être faible.
Les fichiers encodés à l'aide du codeur WMA portent l'extension .wma. Dans sa forme
actuelle, le WMA encode des sons numériques provenant de signaux sonores analogiques
échantillonnés à une fréquence pouvant aller de 8 kHz à 48 kHz, sur 8 ou 16 bits, en mono
ou stéréo. L'encodage se fait à bitrate constant. Ce dernier peut se régler à n'importe quelle
valeur comprise entre 5 kbits/s et 192 kbits/s.
Microsoft revendique la qualité suivante : un morceau encodé à 192 kbits/s en WMA
ne peut pas se distinguer de son homologue WAVE issu d'un CD audio et une qualité
audio dite proche du CD est atteinte pour 96 kbits/s. Ceci nous donne 720 ko (à 96 kbits/s)
pour stocker 1 minute de son stéréo. A qualité audio identique, un fichier encodé en
WMA (96 kbits/s) occupe donc 25% de place en moins qu'un fichier encodé en MP3 (128
kbits/s).
II.3.C – Le format OGG.
Le ogg vorbis est un nouveau format audio libre de droit, c'est à dire que ce
format appartient à tout le monde donc vous ne payez personne pour son utilisation.
Vorbis est le nom du schéma de compression audio spécifiquement utilisé pour
créer des fichiers Ogg Vorbis. Il fait partit du projet Ogg constitué pour créer un
système multimédia libre et ouvert. Dès maintenant, Ogg Vorbis, est la première
étape fonctionnelle du projet. Ogg est l'extension de ce format audio.
Ce format a été créé pour faire disparaître tous les formats audio propriétaire, afin
de permettre à ceux qui n'ont pas les moyens de payer une licence, de pouvoir quand
même diffuser leur musique. En effet, un particulier qui écoute le mp3 ou un autre
format ne paye rien, mais les fabricants de logiciels, eux payent pour pouvoir utiliser
le format audio.
Licence T&E3
- 15 -
Mai – Juin 2007
Vorbis utilise des principes mathématiques très différents que ceux du MP3. Les
challenges de compression sont donc différents. Dans des conditions d'écoute
classiques, un fichier .ogg et un autre .mp3 encodés au même taux de Bitrate auront
une qualité d'écoute similaire, mais le ogg vorbis aura une taille plus petite que le
mp3 (et donc beaucoup plus petite que le WAVE) mais par contre le temps
d'encodage est plus long.
Vous pouvez lire le ogg avec le célèbre lecteur winamp, mais il faudra lui ajouter
un plug-in qui se trouve en téléchargement sur le net. Les musiques .ogg se trouvent
aussi en téléchargement sur des sites.
Licence T&E3
- 16 -
Mai – Juin 2007
Chapitre III :
Le passage d’un
format à un autre
Licence T&E3
- 17 -
Mai – Juin 2007
III .1 Pourquoi convertir ?
Il existe un grand nombre de formats audio. Quelque uns nous sont familiers (wave, mp3,
wma, cda), d’autres moins (ogg, midi, mp2, flac) et certains semblent même n’être connus
que de leurs créateurs : vqf, asf, m3u, ram, voc… Et la liste est loin d’être exhaustive. En
réalité, la plupart de ces formats ont été créés dans un but particulier et possèdent des
avantages aussi divers que leurs domaines d’utilisation.
Pour l’anecdote : le format MIDI, créé en 1982 pour permettre l’échange de données entre
instruments de musique électroniques, a été assez populaire (surtout dans le domaine
informatique) mais il est maintenant presque complètement abandonné. En effet, on attend
deux qualités d’un format audio aujourd’hui : une bonne qualité et un espace de stockage
réduit. Si le format midi peut offrir une qualité de son exceptionnelle (ce que beaucoup
ignorent !), il exige également un espace de stockage… exceptionnel ! Il a donc été
abandonné au profit de formats peut-être moins performants mais, en tout cas, moins
gourmands en espace mémoire (le mp3 par exemple).
D’autres formats, utilisés dans la technologie, la recherche, permettent l’enregistrement
de fréquences inaudibles pour l’oreille humaine… Là encore, où est l’intérêt pour un
mélomane ?
Devant cette grande diversité et l’impossibilité de créer des supports s’adaptant à tous les
formats, une mesure s’imposait : la conversion de formats audio.
Avant de parler de conversion, il est néanmoins important de comprendre en quoi ces
formats sont différents.
III.2 Des formats différents.
Quelques rares formas audio n’utilisent pas de compression : le wave, qui contient les
données brutes du son, ou le midi qui utilise un canal de données par instrument. Cependant,
beaucoup de formats audio sont tout simplement des fichiers wave compressés. La différence
entre ces formats réside alors dans leur algorithme de compression. Il en existe plusieurs,
malheureusement, beaucoup sont protégés par des droits commerciaux. Pour cette raison, il
nous a été impossible d’accéder aux algorithmes de codage de plusieurs formats étudiés.
Nous avons néanmoins pu étudier deux méthodes de compression, qui seront présentées
dans le chapitre suivant.
III.3 Comment convertir ?
Pour convertir un fichier audio A, il suffit de connaître son algorithme de codage
(comment il a été codé), puis de lire ce fichier et d’en extraire les données brutes pour en faire
une suite d’échantillons de sons (le corps d’un fichier wave, en somme).
Il ne reste plus ensuite qu’à re compresser le fichier grâce à l’algorithme de codage d’un autre
format pour arriver à la création d’un fichier audio B.
Attention cependant : cette conversion de format peut parfois entraîner la perte de données
et donc produire un fichier B de moindre qualité que le fichier A (et en aucun cas l’inverse !).
Par exemple, un extrait de musique classique enregistré au format wma converti au format
mp3 perdra beaucoup en qualité en raison d’une faiblesse du mp3 à enregistrer les sons ai
Licence T&E3
- 18 -
Mai – Juin 2007
Chapitre IV :
La compression par
Fourier et
Huffman
Licence T&E3
- 19 -
Mai – Juin 2007
IV.1 - La compression par transformée de Fourier.
Il s’agit ici d’une méthode de compression. On part d’un fichier au format WAV
caractérisé par son bitrate (débit binaire). Ce son est un signal échantillonné. Par une
transformation de Fourier, on va analyser son spectre. On obtiendra ainsi des valeurs dans le
domaine fréquentiel.
L’objectif de cette compression est de revenir au domaine temporel à partir de ces valeurs
de fréquences, mais avec un bitrate plus petit. Cela revient à diminuer le nombre d’échantillon
dans le fichier WAV. Au lieu de supprimer directement des données, ce qui pourrait modifier
radicalement l’intégrité du son, on utilise toutes les données pour en calculer de nouvelles.
IV.1.B - La transformation par Fourier.
Grâce à la transformation de Fourier, on peut décomposer un signal : on considère que
tout signal est le composée d’une infinité de sinusoïde ayant chacune une amplitude, une
fréquence et un déphasage.
domaine temporelle
domaine fréquentielle
Avant d’opérer sur la transformation de Fourier, il faut voir ce qui se passe lors de
l’opération d’échantillonnage (lorsque l’on enregistre le son) : on prélève (périodiquement
– période ∆) des valeurs représentatives du signal analogique. x(t) signal
analogique : x n = x(n∆)
On peut représenter le principe de l’échantillonnage par un échantillonneur à impulsions :
x(t )
x * (t )
δ ∆ (t )
On obtient un signal échantillonné x*(t)
La transformée de Fourier du signal échantillonné : F(x*(t))
1 ∞
n
x * (t ) = x(t ).δ T (t ) ⇒ X * ( f ) = X ( f ) * ∑ δ ( f − )
∆ n = −∞
∆
Licence T&E3
- 20 -
Mai – Juin 2007
⇒ X *( f ) =
1 ∞
n
X(f − )
∑
∆ n = −∞
∆
On obtient : X * ( f ) = f e
∞
∑ X ( f − nf
n = −∞
e
) avec f e : fréquence d’échantillonnage
On observe sur cette dernière équation qu’il y a une périodicité dans le signal fréquentielle
(pour différentes valeurs de n).
Cette périodicité introduit une loi qu’il faut respecter lorsque l’on acquiert du son : la
fréquence d’échantillonnage doit être au moins égale au double de la fréquence du signal
analogique. Ce principe est connu sous le nom de théorème de Shannon.
Si l'on se situe sous cette limite théorique, il y a perte d'information dans le signal.
Ce graphique est obtenu en calculant les amplitudes de chaque fréquence d’un fichier
sonore. Ce fichier sonore à une fréquence d’échantillonnage de 11025 Hz. On retrouve ici
la périodicité du signal. On se rend ainsi compte que les fréquences qui nous intéressent
sont comprise entre 0 et 11025 / 2.
Dans les futurs calculs, nous pouvons donc ne manipuler que les fréquences comprises
entre 0 et la moitié de la fréquence d’échantillonnage.
Pour pouvoir calculer les valeurs du signal dans le domaine fréquentielle, il faut
trouver la formule qui passe des valeurs temporelles aux valeurs fréquentielles.
La formule de Fourier nous donne : X * ( f ) =
∞
∑x e
n = −∞
− j 2πfn∆
n
=
∞
∑x e
n = −∞
− j 2π
f
n
fe
n
2π
fréquence d ' échantillonnage
n = −∞
On applique cette formule dans le langage C sur un fichier échantillonné. La formule
∞
On simplifie la formule par :
∑x e ω
j fn
n
en prenant ω = −
Nb échantillon
devient :
∑x e ω
j fn
n=0
n
. On s’aperçoit ici que l’on obtiendra un complexe pour chaque
fréquence.
Licence T&E3
- 21 -
Mai – Juin 2007
On utilise deux boucles for : une pour toutes les fréquences à calculer et une autre à
l’intérieur de la précédente qui parcourra tous les échantillons du fichier afin de calculer le
réel et l’imaginaire de la fréquence.
On obtient ces lignes de codes :
double omega = -2 * M_PI / pforme.Freq;
for (n = FreqMin ; n <=FreqMax; n ++) // Calcul des fréquences souhaitées
{
Fou_re[n] = 0; //Initialisation des coefficients
Fou_im[n] = 0;
for (t = 0; t < pforme.NbEchant ; t ++) //Parcours de tous les échantillons du fichier
{
Fou_re[n] += pforme.canal[0][t] * cos(omega * t * n);
Fou_im[n] += pforme.canal[0][t] * sin(omega * t * n);
}
}
Si on souhaite avoir l’amplitude d’une fréquence, on utilise la formule suivante :
Fou_Ampli[n] = fou_cos[n] + i*fou_sin[n] Il s’agit de calculer le module d’un complexe :
on insere cette ligne à la fin de la première boucle for : Fou_Ampli[n] =
pow(pow(Fou_re[n] / pforme.Freq, 2) + pow(Fou_im[n] / pforme.Freq, 2),0.5 ;
C’est la formule que l’on utilise pour afficher graphiquement les amplitudes de chaque
fréquence.
IV.1.C – La transformation de Fourier inverse.
A ce stade, nous avons les réels et les imaginaires des fréquences comprises entre 0 et
la moitié de la fréquence d’échantillonnage. La transformée de Fourier directe et la
∞
f
n
fe
f
j 2π n
1
fe
transformée inverse sont : X ( f ) = ∑ x n e
et x n =
X
(
f
)
e
df
∫
fe
n = −∞
L’utilisateur nous fournis le nouveau débit qu’il souhaite pour son fichier.
Grâce au débit, on calcul le nouveau nombre d’octet par seconde : nouveau.BytePerSec=
Debit*1000/8
La taille du nouveau fichier est : taille de l’ancien fichier * nouveau BytePerSec / ancien
BytePerSec
Le nouveau nombre d’échantillon est : taille du nouveau fichier * 8 / Nb canaux / nombre
de bits par donnée.
La fréquence d’échantillonnage devient nouveau Nb d’échantillon * nouveau BytePerSec
/ taille du nouveau fichier
Ainsi, nous faisons les mêmes calculs qu’avec la transformation de Fourier, mais en
prenant un nouveau ω. En effet, nous souhaitons diminuer le nombre d’échantillon. La
durée du fichier sonore ne variant pas, cela revient à diminuer la fréquence
d’échantillonnage.
2π
Calcul de ω : ω =
nouveau fe
La transformée dans le langage C s’opère ainsi :
Licence T&E3
− j 2π
- 22 -
Mai – Juin 2007
omega = 2 * M_PI / compresse.Freq; //nouveau w
for(t = 0 ; t < compresse.NbEchant ; t ++) //Pour chaque t : pour chaque échantillon du
nouveau fichier
{
Signal_re[t] = 0; //Initialisation du réel
Signal_im[t] = 0; //Initialisation de l’imaginaire
for(n = 0 ; n < pforme.Freq / 2 ; n ++) //Représente la somme
{
Signal_re[t] += Fourier_re[n] * cos(omega * n * t); - Fourier_im[n] * sin(omega * n * t);
Signal_im[t] += Fourier_re[n] * sin(omega * n * t); + Fourier_re[n] * cos(omega * n * t);
}
compresse.canal[t] = sqrt(pow(Signal_re[t], 2) + pow(Signal_im[t], 2)) / pforme.Freq;
//Calcul de l'amplitude (module du signal complexe obtenue)
}
Il suffit d’intégrer ces nouvelles données dans un fichier au format WAV avec un
nouvel en-tête pour obtenir un fichier compressé par la méthode Fourier.
IV.1.D – The Fast Fourier Transformation (FFT).
Nous avons vu que la transformée de Fourier que l’on utilise précédemment passe par
l’emploie de deux boucles for. La complexité du calcul s’exprime donc en
.
L'amélioration de l'algorithme est permise grâce à la factorisation récursive de la
formule générale.
L'algorithme original de Cooley-Tukey était dit radix-2. Cela signifie que la
dimension était une puissance de 2, et la factorisation à l'échelle k fait appel à 2
transformées de Fourier à l'échelle k-1. D'autres algorithmes par la suite ont d'autres radix
pour des tailles qui ne sont pas des puissances de 2.
Voici comment on arrive à la décomposition récursive :
Une autre propriété est la suivante :
On effectue donc une FFT de taille inférieure sur les échantillons pairs et une autre sur
les impairs à un facteur d'échelle près. La formule du radix-2 met en évidence une cellule
Licence T&E3
- 23 -
Mai – Juin 2007
de base qu'on appelle butterfly (on calcule simultanément 2 coefficients de la FFT en
prenant en compte la différence de signe des termes de la formule). On voit dans l'image
suivante l'utilisation de ce butterfly pour résoudre ce problème.
On peut réaliser la FFT entre 2 espaces mémoires distincts ou en place, en écrasant le
signal précédent. Dans ce cas, le résultat ne sera pas dans l'ordre et pour le retrouver, il
faut permuter les bits des indices du tableau, comme indiqué dans le schéma précédent. Si
un indice a la forme b3b2b1b0, l'indice dans la FFT correspondant est b0b1b2b3. C'est ce
qu'on appelle le bit-reversal.
Pour la transformée inverse, on procède de la même manière avec l'exponentielle
inverse. Dans les formules présentées, le facteur général de la FFT inverse n'est pas
présenté. Il est possible de l'appliquer à la transformée directe, ou même en partie à la
transformée directe et en partie à la transformée indirecte. Cela peut être judicieux - et
indispensable en fait - dans le cas d'une FFT d'entiers.
Le principal problème rencontré avec l’utilisation de la FFT es le fait qu’il ne
manipule que des données de l’ordre de 2 n . Un subterfuge consiste à rajouter à la fin du
fichier sonore des données inutiles : des échantillons qui représente une amplitude de 0V
sur l’ampli. On supprime ensuite ces données une fois la FFT inverse effectuée.
Le fait d’être forcé d’utiliser des nombres d’échantillons de la forme 2 n nous contraint
à utiliser pour le fichier compressé un débit que l’utilisateur ne peut choisir avec
précision.
IV.1.E - Remarques.
Les amplitudes des fréquences.
L’utilisation de la Transformée rapide de Fourier ne permet pas d’obtenir un rendu
graphique des amplitudes des fréquences d’un fichier WAV. Pour avoir un rendu exact, il
faut utiliser la transformée de Fourier « traditionnelle » qui est malheureusement plus
longue.
L’intensité sonore du fichier produit.
On remarque que le fichier WAV produit peut avoir une intensité sonore inférieur au
fichier original. On résout ce problème en prélevant la valeur maximale des échantillons
du fichier original et produit, puis on applique à ce nouveau fichier un accroissement
proportionnel de toutes ses valeurs.
Licence T&E3
- 24 -
Mai – Juin 2007
IV.2 - La compression par la méthode d’Huffman.
La méthode de compression Huffman consiste à diminuer au maximum le nombre de bits
utilisés pour coder un fragment d'information. Prenons l'exemple d'un fichier de texte : le
fragment d'information sera un caractère ou une suite de caractères. Plus le fragment sera
grand, plus les possibilités seront grandes et donc la mise en œuvre complexe à exécuter.
L'algorithme de Huffman se base sur la fréquence d'apparition d'un fragment pour le coder :
plus un fragment est fréquent, moins on utilisera de bits pour le coder. Dans notre exemple de
fichier texte, si on considère que notre fragment est la taille d'un caractère, on peut remarquer
que certaines voyelles sont beaucoup plus fréquentes que certaines consonnes : par exemple la
lettre ‘e' est largement plus fréquente que la lettre ‘x' par conséquent la lettre ‘e' sera peut-être
codée sur 2 bits alors que la lettre ‘x' en prendra 10.
Pour pouvoir compresser puis décompresser l'information, on va donc devoir utiliser une
table de fréquences. Deux choix s'offrent à nous : calculer une table et l'intégrer au fichier ou
utiliser une table générique intégrée dans la fonction de compression. Dans le premier cas, la
compression est meilleure puisqu'elle est adaptée au fichier à compresser, mais elle nécessite
le calcul d'une table de fréquences et le fichier sera plus important également du fait de la
présence de cette table dans le fichier. Dans le second cas, la compression sera plus rapide
puisque elle n'aura pas à calculer les fréquences, par contre l'efficacité de la compression sera
moindre et le gain obtenu par la première méthode (ratio de compression + taille de la table)
peut être supérieur à celui de la deuxième (ratio de compression).
IV.2.B - La table des fréquences d'apparition des fragments.
Cette table consiste en un comptage empirique des fragments au sein des données à
compresser. Prenons l'exemple d'un texte : nous allons analyser la phrase :
« gRRosminet et GoldenEye programment Huffman »
Pour simplifier l'exemple, nous ignorerons la casse :
Lettres
G
O
S
M
I
N
E
T
L
D
Y
P
A
H
Licence T&E3
Occurrences
3
3
1
4
1
4
6
3
1
1
1
1
2
1
- 25 -
Fréquence
4,14%
7,14%
2,38%
9,52%
2,38%
9,52%
14,29%
7,14%
2,38%
2,38%
2,38%
2,38%
4,76%
2,38%
Mai – Juin 2007
U
F
[ESPACE]
Total
1
2
4
42
2,38%
4,76%
9,52%
100%
IV.2.C - Création de l'arbre de Huffman.
L'arbre de Huffman est la structure données qui va nous permettre de donner un code pour
chaque lettre en fonction de sa fréquence.
Etape 1
Il faut commencer par trier la liste par ordre croissant de fréquences. On observe que le tri
a été fait sur la fréquence puis sur la lettre ce qui sera important pour permettre la
diminution de la taille de l'entête :
Lettres
D
H
I
L
P
S
U
Y
A
F
G
O
R
T
[ESPACE]
M
N
E
Occurrences
1
1
1
1
1
1
1
1
2
2
3
3
3
3
4
4
4
6
Fréquence
2,38%
2,38%
2,38%
2,38%
2,38%
2,38%
2,38%
2,38%
4,76%
4,76%
7,14%
7,14%
7,14%
7,14%
9,52%
9,52%
9,52%
14,29%
Nous allons maintenant construire un nœud de l'arbre pour chaque fragment et les placer
dans une liste ordonnée de noeuds. Un nœud doit avoir une structure qui suit le schéma
suivant :
Licence T&E3
- 26 -
Mai – Juin 2007
Etape 2
Nous construisons l'arbre à partir de la liste ordonnée de nœuds. Il faut prendre les deux
nœuds les moins fréquents (D et H) et de les ajouter comme fils d'un nouveau nœud qui
aura pour fréquence la somme des deux.
Il suffit de réitérer cette étape jusqu'à ne plus avoir qu'un seul nœud. Après cela, descendre
vers la gauche équivaut à un 0, et descendre vers la droite à un 1.
On en déduit le codage suivant :
Lettres
D
H
I
L
P
S
U
Licence T&E3
Occurrences
1
1
1
1
1
1
1
- 27 -
Fréquence
6
6
6
6
6
6
6
Codage
111000
111001
111010
111011
111100
111101
111110
Mai – Juin 2007
Y
A
F
G
O
R
T
[ESPACE]
M
N
E
Total de
bits
(normal |
compressé
)
1
2
2
3
3
3
3
4
4
4
6
6
4
4
4
4
4
4
3
3
3
3
336
166
111111
0000
0001
1000
1001
1010
1011
001
010
011
110
La dernière ligne du tableau nous montre qu'une fois compressée, la phrase n'occupe
même plus la moitié de l'espace original (hors entête).
IV.2.D - Compression / Décompression.
Compression
Pour la compression des données, on va donc devoir écrire un nouveau fichier contenant
deux parties : l'entête et les données compressées. L'entête : il doit contenir le nom
original du fichier, la taille originale et une table de correspondance qui permette de
reconstituer le fichier original.
Pour compresser les données, on va donc lire le fichier original fragment par fragment (ici
octet par octet) et on écrira le code Huffman correspondant dans le fichier de destination.
Les codes de Huffman ne font pas toujours un multiple de 8 bits et par conséquent ils
nécessitent d'être mis dans une zone tampon avant d'être écris dans le fichier.
Décompression
Pour la décompression, on lira l'entête du fichier, puis, pour chaque bit lu, on descendra
dans l’arbre et à chaque feuille terminale, on décodera un caractère original que l’on écrira
dans le fichier de restitution.
IV.2.E - Remarques.
taill _ compressé
taille _ normale
166
Dans notre exemple, nous avons : ρ = 1 −
= 50,6%
336
En règle générale, un fichier texte est compressé par cette méthode suivant un ratio de 30
à 60%.
On définit le ratio de compression : ρ = 1 −
Licence T&E3
- 28 -
Mai – Juin 2007
Sur de très petits fichiers ( moins de 1 Ko), l'en-tête est assez volumineux par rapport aux
informations compressées. Le fichier réduit a alors une taille supérieure au fichier
original…
Sur de gros fichiers, on peut appliquer l'algorithme de Huffman non pas caractère par
caractère mais par tranche de 2, 3 ou 4 caractères. Le problème est que la construction de
l'arbre prend beaucoup plus de temps (l'arbre est plus gros,il y 65536 doublets possibles de
caractères ASCII étendu par exemple). De même, l'en-tête prend une place considérable.
Licence T&E3
- 29 -
Mai – Juin 2007
Chapitre V :
Notre application
Licence T&E3
- 30 -
Mai – Juin 2007
V.1 - L’organisation des tâches.
Les réunions préliminaires avec notre chef de projet M .Rousseau avaient clairement
délimité trois aspects principaux de notre future application, sans perdre de vue l’objectif
principal : la conversion de formats audio en C sous Linux.
Ces trois aspects étaient :
_la recherche sur le codage informatique du son.
_la création d’une bibliothèque de fonctions.
_l’interface graphique.
Nous devions également penser à la compatibilité de notre application avec celle conçue
par un autre groupe (Romain, Benjamin et Maxime) mais il nous a paru plus judicieux
d’avancer chacun de notre côté, au moins au début.
Notre groupe étant composé de trois personnes, nous avons convenu dès le début que nous
pouvions étudier chacun un des aspects pré-cités. Nous discutions cependant beaucoup et
chaque nouvelle idée était exposée avant d’être appliquée. De même, chaque fonction de la
bibliothèque était intégrée à l’application graphique dès lors qu’elle était terminée.
M.Rousseau nous avait également demandé un rapport hebdomadaire de nos travaux, ce
qui nous permettait de prendre du recul par rapport à l’application et donc de mieux identifier
les points importants. Cela nous permettait aussi de déceler, le cas échéant, les éléments qui
s’éloignaient trop de notre projet initial.
V.2 - Les fonctionnalités du logiciel.
Nous avions pour objectif de proposer le plus de formats audio possibles. Il nous fallait
donc connaître les algorithmes de compression des formats que nous souhaitions convertir.
Cependant, comme il a été expliqué précédemment, beaucoup de ces algorithmes ne sont pas
accessibles, nous avons donc dû nous rabattre sur de petites applications disponibles dans les
paquets Linux et permettant ces conversions. Cela nous a épargné beaucoup de travail puisque
nous n’avions plus à compresser et décompresser les fichiers mais, d’un autre côté, cela a
rendu l’application plus difficile à exporter.
En effet, pour pouvoir être utilisées, ces applications doivent être préalablement installées
sur le système, ce qui est une contrainte pour l’utilisateur.
Nous n’avions néanmoins pas le choix et nous avons donc installé ces paquets. Un point
important a découlé de cette contrainte : puisque nous ne pouvions intervenir directement sur
les différents formats, nous étions obligés de convertir au préalable le fichier choisi par
l’utilisateur au format wave. Ce format s’est donc retrouvé au centre de notre application,
même si cela est transparent pour l’utilisateur (il ne sait pas, en convertissant un fichier mp3
en ogg par exemple, que l’on est passé par un fichier wave).
A l’heure actuelle, notre application permet d’ouvrir des fichiers wave, mp2, mp3, midi,
flac, ogg, wma et de créer des fichiers wave, mp2, mp3, midi, flac, ogg.
Comme nous l’avons expliqué précédemment, le format wave est très simple à manipuler.
Nous avons donc ajouté d’autres fonctionnalités qui nous paraissait, sinon utiles, du moins
amusantes :
_découpage d’un fichier son : l’utilisateur ouvre un fichier son et choisit ensuite les deux
bornes délimitant le découpage qu’il souhaite effectuer (en milli-secondes) (par exemple, en
Licence T&E3
- 31 -
Mai – Juin 2007
choisissant les intervalles 1000 et 2500, il va découper 2,5 secondes dans le fichier original).
Il peut ensuite nommer le fichier créé et l’enregistrer.
_modification de la vitesse de lecture : l’utilisateur choisit un facteur de modification,
supérieur à 0 et inférieur 2 (le facteur 1 restituant le fichier non modifié). De même , il peut
renommer son fichier et l’enregistrer.
_concaténation de fichier : l’utilisateur peut « coller » deux fichiers l’un à l’autre à la
condition qu’ils aient le même nombre de canaux et la même fréquence d’échantillonnage.
_lecture d’un fichier son : l’utilisateur peut écouter un fichier son en voyant se dérouler en
temps réel un graphique représentant les amplitudes de son fichier audio.
_compression et décompression Huffman
_compression et décompression Fourier
L’utilisateur peut compresser un fichier audio, celui-ci sera enregistré avec une extension
particulière et ne peut être décompressé que par la fonction inverse.
_modification du nombre de canaux d’un fichier audio: cette opération peut entraîner une
perte de données (et non l’inverse !) et peut donc paraître inutile. Cependant, dans le cas où
l’utilisateur souhaite concaténer deux fichiers n’ayant pas le même nombre de canaux, elle
permet d’uniformiser les deux fichiers.
V.3 - Problèmes rencontrés et solutions apportées
V.3.A - L’installation de Linux.
Au tout début du projet, nous ne parvenions pas à installer Linux (pas plus que le
groupe de Messieurs Duthil, Danieau et Lasterra). Nous avons fini par demander de l’aide
à M.Rousseau, qui a réalisé que le CD était défectueux. Il nous a donc fourni un autre CD,
valide cette fois. Il nous a également fourni un descriptif précis de l’installation qui nous a
été bien utile : en effet, nous devions installer Linux en mode expert pour partitionner les
disques, ce qu’aucun de nous n’avait fait auparavant.
V.3.B - Recherche d’un environnement de développement.
Nous devions trouver un environnement de développement offrant la possibilité
d’utiliser la bibliothèque wxWidget, bibliothèque d’objets graphiques. Après quelques
recherches sur Internet, et plusieurs tentatives ratées, nous avons trouvé un manuel
d’installation pour l’utilisation de cette bibliothèque sous Eclipse. Ce manuel était très
complet et détaillé et nous a donc permis d’installer notre environnement de
développement.
V.3.C - Codage des différents formats.
Comme nous l’avons expliqué précédemment, beaucoup de formats audio sont
protégés : nous ne pouvions donc pas créer les fichiers correspondant comme nous le
faisions avec les fichiers wave (écriture octet par octet des informations dans un fichier).
Nous avons dû utiliser des logiciels de conversion déjà existants (ffmpeg, timidity,
lame…). Cela nous a paru une contrainte, particulièrement pour l’utilisateur, mais avec le
recul, nous avons réalisé que la connaissance et la maîtrise de tous les formats audio
présentés nous aurait demandé beaucoup trop de temps.
Licence T&E3
- 32 -
Mai – Juin 2007
V.3.D - Transfert de Windows à Linux.
L’installation de Linux a présenté des difficultés : nous avons donc choisi de
commencer à travailler sous Windows pour ne pas perdre de temps. Cependant, après
l’installation réussie de Linux, nous avons trop tardé à transférer notre travail (la
bibliothèque de fonctions et l’application graphique) sur ce système d’exploitation et ce,
malgré les conseils de M.Rousseau qui nous avait prévenus que cela pouvait présenter des
difficultés. Nous pensions en effet que ce ne serait qu’une formalité et qu’il n’y aurait que
quelques modifications à apporter dans le code. C’était une grosse erreur et nous avons
perdu beaucoup de temps à adapter notre code à l’environnement Linux. L’application
graphique en particulier a été difficile à adapter, la bibliothèque de fonctions n’ayant
nécessité que peu de modifications.
V.3.E - Utilisation des threads.
Après un mois de développement, nous avons voulu améliorer l’application graphique
et, notamment, créer une fonction de lecture du son : celle-ci devait proposer l’affichage
en temps réel d’un graphique représentant les amplitudes du son. Nous avons créé cette
fonction mais nous avons réalisé que durant la durée de la lecture, toutes les autres
fonctionnalités de l’application étaient inaccessibles. Nous avons donc cherché un moyen
de corriger cela et c’est finalement le groupe de Messieurs Danieau, Duthil et Lasterra qui
nous a donné la solution : les threads. Ils en utilisaient déjà pour leur application et ont
donc pu nous expliquer leur principe. Cela paraissait la solution idéale (et c’était
assurément la solution) mais nous ne connaissions pas du tout ces objets, ni les problèmes
qu’ils pouvaient générer. Nous avons également oublié de prendre en compte le fait que le
temps initialement imparti pour le projet était terminé, et que nous ne disposions, au
mieux, que d’une ou deux semaines supplémentaires pour finaliser l’application. Quoi
qu’il en soit, nous avons ajouté les threads et l’application est devenue très instable : elle
se bloquait parfois, ou se fermait tout simplement sans prévenir. M.Rousseau nous a
expliqué que c’était sans doute dû à des conflits d’interrogations de variable : si le thread
principal (l’application) et le thread créé par l’application interrogent une même variable
au même moment, l’application « plante ». M.Rousseau nous a parlé des mutex, objet
servant à protéger une variable mais nous n’avons pas eu le temps de corriger ces défauts.
L’application finale est donc très instable.
V.3.F - Compatibilité des deux projets.
Notre application était axée sur la conversion de fichiers audio, mais nous devions
également envisager la lecture et l’acquisition de son via la bibliothèque développée par
Messieurs Danieau, Duthil et Lasterra. Nous discutions beaucoup de nos avancées et de
nos idées et nous pensions, comme eux, avancer vers le même but. Cependant, il était
difficile de confronter réellement nos applications avant un stade avancé de
développement. Quand cela a été finalement possible, nous avons réalisé que qu’elles
n’étaient pas compatibles. Malgré une bonne compréhension des projets, nous n’avons pu
déterminer la cause de cette incompatibilité : les fichiers wave créés étaient parfois lus
normalement par leurs fonctions, mais, approximativement deux fois sur trois, on
n’entendait qu’un son informe, semblable à des parasites radio. Nous avons longuement
cherché la cause de ces différences mais sans succès. M.Rousseau lui-même n’a pu
identifier le problème et nous avons dû nous résoudre à abandonner la compatibilité de
nos projets.
Licence T&E3
- 33 -
Mai – Juin 2007
Conclusion
La réalisation de ce projet a eu plusieurs points positifs.
Tout d’abord, il nous a permis d’élargir nos connaissances sur le son. Nous connaissons tous
le principe de la membrane d’un haut-parleur qui vibre pour produire du son. Il a été
intéressant de comparer ces connaissances avec les méthodes utilisées pour coder le son en
informatique. Des notions de fréquence d’échantillonnage, de compression avec ou sans perte
de données nous étaient alors inconnues. Nous avons également découvert qu’il existait une
grande variété de formats audio, et leurs avantages respectifs.
Ce projet a également été une occasion de nous préparer à la première année de Master
puisque nous avons utilisé un langage orienté objet. De plus, nous avons pu découvrir
l’environnement de Linux, que nous ne connaissions pas et qui sera lui aussi étudié.
Enfin, la conduite de ce projet nous a fait prendre conscience de l’importance de la
communication au sein du groupe, ainsi qu’avec les étudiants travaillant sur le deuxième
projet. Nos discussions nous ont permis de confronter nos idées et elles ont souvent été d’une
grande aide : en nous obligeant à expliquer un problème à une autre personne, elles nous
permettaient de prendre du recul par rapport à ce problème.
Bien entendu, les discussions avec M.Rousseau ont également été très bénéfiques.
Les problèmes d’instabilité de l’application, dues à l’utilisation des threads, sont regrettables.
Nous avons commis une erreur en intégrant une notion qui nous était totalement inconnue
alors que le temps imparti pour le projet touchait à son terme. Cependant, ce n’est qu’un
problème d’affichage ; nous aurions sans doute pu le corriger avec un peu plus de temps.
Le principal point négatif reste l’incompatibilité de notre application avec celle de Messieurs
Danieau, Duthil et Lasterra. Ce point faisait partie des éléments importants du projet et il est
frustrant de n’avoir même pas pu identifier la cause du problème.
Nous pouvons tout de même dire que l’objectif principal du projet est atteint : notre
application permet de convertir un grand nombre de formats audio. De plus, elle propose
quelques fonctionnalités originales. Finalement, la réalisation de ce projet a été agréable en
plus d’être bénéfique et l’application pourrait même être reprise et améliorée.
Licence T&E3
- 34 -
Mai – Juin 2007
Les formats audio sous linux
Projet réalisé par :
GILBERT Louis-Marie
LETOURNEAU Christophe
LE TEXIER Nicolas
Projet encadré par :
ROUSSEAU Julien
Résumé : Ce projet s’intéresse à la conversion des fichiers audio sous linux. Ce
dossier présente les bases nécessaires pour comprendre le concept de son en
informatique, la notion de compression et l’idée de format, utilisés pour le projet.
Utilisant le format WAV comme pivot, de multiples fonctionnalités ont pu être
programmées. Ce rapport présente les moyens de conversions du son : de façon
courante, via les bibliothèques et les commandes de linux ou de façon ‘manuelle’ via
la compression de Fourier et de Huffman. Ces travaux ont été rendus accessible à
travers une application graphique construite à l’aide de l’environnement Widget.
Mots-clés : formats audio ; son ; linux ; WAV ; compression ; conversion ; Fourier ;
Huffman ; Widget ; Thread
Summary : This project points out the conversion of the audio files under linux. This
file introduces the necessary foundations to understand the concept of sound in
computing, the notion of compression and the idea of format used for our project.
Using format WAV as a spindle, numerous functionalities could have been
programmed. This report introduces the means of conversions of sound: in a common
manner, via libraries and the orders of linux or in a 'manual' manner via the
compression of Fourier and Huffman. These jobs were made approachable across a
graphic application made with the aid of environment Widget.
Keywords : audio format ; sound ; linux ; WAV ; compression ; conversion ; Fourier ;
Huffman ; Widget ; Thread
Licence T&E3
- 35 -
Mai – Juin 2007