Version imprimable
Bonjour tout le monde ! :D
Dans les logiciels de traitement de fichiers audio (Audacity, ...), lorsqu'on ouvre un fichier (mp3 par exemple), une sorte de spectre du son s'affiche : voir ici
J'aimerais savoir à quoi correspond ce spectre et comment il est possible de l'obtenir. :mrgreen:
Merci d'avance ! :ccool:
Ce n'est pas du tout un spectre, mais l'amplitude du signal audio en fonction du temps.
Yann
Ok merci ! :ccool:
Mais comment je peux obtenir cette amplitude juste en parcourant le fichier (sans lire le son) ? :calim2:
Cela dépend du format de fichier.
Dans un fichier wav tu peux avoir différent type d'encodage. Le PCM par exemple (qui est aussi le format des CD) utilise une quantification non uniforme afin de mieux encodé les faibles amplitude... Si la quantification était uniforme, tu aurais exactement l'info affichée dans ton graphe. L'ADPCM fait une prédiction de l'échantillon suivant en fonction des échantillons précédents et c'est l'erreur entre le vrai signal et cette prédiction qui est codé.
Pour les fichiers MP3, c'est beaucoup plus compliqué. Les format cités ci-dessus restent dans le domaine temporel : on ne regarde que l'évolution de l'amplitude au cours du temps. Pour le MP3, on regarde pour chaque échantillon sa composition fréquencielle (est ce qu'il y a plus d'aigu ou de grave...). Le spectre est découpé en un certain nombre de bande de fréquence. On regarde en suite la quantité d'information qu'il y a dans chaque bande de fréquence et on leur attribut un nombre de bit (128, 192...kb/s) en conséquence. Si tu n'a pas d'aigus, beaucoup de médiums, et un peu de basses, tu vas accorder beaucoup de bits pour les médiums, un peu pour les graves et pas pour les aigus...
Mais bon... en ppe, c'est le boulot du codec d'interpréter le contenu du fichier et de te donner cette amplitude...
Merci de ta réponse !
En fait je ne travaillerai qu'avec des fichiers mp3.
Donc si j'ai bien compris, avant de pouvoir faire un graphique comme dans Audacity (= amplitude du signal en fonction du temps), il faut que je récupère le spectre des fréquences ?
Mais ensuite, comment je m'en sert pour avoir l'amplitude du signal en fonction du temps ?
Désolé si je ne comprend pas très bien, mais je débute dans le traitement sonore :oops:
Signal -> amplitude temporelleCitation:
il faut que je récupère le spectre des fréquences ?
Spectre -> fréquence
En fait si tu as un codec qui te permet de savoir la valeur d'un échantillon à un instant t, tu as exactement ce que tu veux obtenir.Citation:
Mais ensuite, comment je m'en sert pour avoir l'amplitude du signal en fonction du temps ?
D'accord, je pense avoir compris cette fois !
Je vais faire quelques recherches du côté des codec (car je fais une application en C++) et je posterai si j'ai des problèmes ! :mrgreen:
Je pense que tu dois pouvoir trouver de tonnes de librairies qui te permettront d'ouvrir et de manipuler toute sorte de fichiers audio. Une des plus réputée, je croie, est clam, mais je suis sur qu'il y en a pleins d'autres...
Yann
Je confirme : ce que tu montres, ce n'est pas le spectre, mais le signal lui-même, c'est peu ou prou directement ce qui est envoyé sur les haut-parleurs.
Le spectre (bonjour la FFT pour l'avoir), c'est la séparation du signal en ses composantes fréquentielles, c'est à dire les "barres vu-mètre" avec en général à gauche les basses, et à droite les aigus.
OK merci pour vos réponses !
Je vais essayé de comprendre comment CLAM (qui a l'air d'être très puissante) fonctionne, même si cela va être dur étant donné que je n'ai trouvé qu'une doc doxygen ...
Bonjour tout le monde ! :D
Bon j'ai un peu avancé. Finalement je n'utiliserai pas CLAM mais libsndfile et je ne gèrerai que les sons wav (enfin pour l'instant).
Grâce à cette bibliothèque, je peux récupérer un tableau avec les amplitudes (voir lien plus haut). J'ai donc quelques questions à vous poser :
* J'obtiens un tableau de 5151744 entiers pour un son de 53.664s et de fréquence 48000Hz. Est-ce normal ?
* Dons mon tableau j'ai des nombres positifs et négatifs qui peuvent aller jusqu'à 10 chiffres. Est-ce normal ?
De plus si vous pouviez me donner quelques informations sur ces nombres (unité, utilité, ...) et me dire comment m'en servir pour avoir le graphique que je souhaite ... :mrgreen:
Merci d'avance ! :ccool:
Je suppose que ton fichier est en stéréo. La fréquence de 48kHz est la fréquence d'échantillonnage. cela veux dire qu'il y a 48000 échantillon par seconde. 48000*53.664=2575872... Comme il y a deux vois, ça fait bien 5151744 échantillon au total.
pour les valeurs positives et négatives sur 10 chiffres cela me parait étrange. En principe, les fichier audio sont codés sur 16bit (comme le CD) ou éventuellement 24bits. En 16bits tu devrais avoir de valeurs entre -32768 (-2^15) et 32767(2^15-1). En 24bits, les valeurs devraient être comprise entre -8388608 et 8388607. On est encore loin des 10 chiffres... Pour y arriver, il faut que les échantillons soient codé en 32 bits. Ils auraient alors des valeurs comprises ente -2147483648 et 2147483647. Cela me parait très bizarre que les échantillons soient codé sur 32 bits...
Yann
Oui cela m'a paru également bizarre les nombres à 10 chiffres.
Je sais pas si tu connais le C++, mais voici comment j'obtiens ces valeurs :
Je n'ai fait que reprendre le début de cette fonction !Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
EDIT : j'ai trouvé la source du problème ! J'utilisais des int alors qu'il faut utiliser des short ! Maintenant j'ai des valeurs comprises entre -32768 et 32767 !
Après lecture rapide du tuto :
- sf_read_short pour lire des entiers 16 bits.
- sf_read_int pour lire des entiers 32 bits.
Le reste n'est que normalisation du signal, aucune inquiétude à avoir... Il peut même être préférable, si c'est pour afficher, de n'utiliser que des valeurs 32 bits afin d'utiliser des mots-machine qui seront plus rapides à traiter, malgré leur taille double de celle d'origine.
Tu n'aurais pas la deuxième partie de ton vecteur qui est tout le temps à 0? Il faut se méfier de "int" dont le format dépend de la machine. Je pense que maintenant c'est 32bit sur la plupart des machines. Il faut essayer avec un vecteur de short à la place d'int et voir ce que ça donne...
Yann
Ah ok! c'était simplement une normalisation...
Salut à tous et merci de vos réponses (que je n'ai pas vu au début car j'éditais ma dernière réponse :oops:).
Donc oui l'utilisation des short résout le problème (j'ai bien des valeurs en 16 bits) ! :ccool:
Maintenant, pour tracer mon graphique, je n'ai plus rien à faire, j'ai tout ce qu'il me faut ? :mrgreen:
Te manque juste de bonnes formules de calcul pour afficher tout ça à l'écran de façon agréable (sauf si tu possèdes un écran 2575872 x 65536 pixels, bien entendu :mouarf:), et ensuite balancer tout ça dans un bitmap à l'écran.Citation:
Envoyé par Electroniktor
Mdr ! Ben je pensais faire un histogramme sur 800 pixels en prenant mes valeurs toutes les (nombre_de_valeurs / 800) cases !
Je vais voir ce que cela donne ...
Tu peux parfaitement tomber sur un graphe "plat" alors que tu as du son, ou quelque chose de complètement aberrant en représentation graphique.Citation:
Envoyé par Electroniktor
Dans l'idéal, il te faudrait faire un min/max sur chaque bloc (avec une moyenne en plus si possible), et tracer 3 traits de différente intensité afin de mieux voir l'amplitude du signal réelle. Faire une réduction d'image "normale", donc...
Une autre solution est de tracer toute ta courbe, mais en n'avançant sur l'axe horizontal que tous les N échantillons. C'est plus long à tracer, mais c'est un beau rendu en général si tu fais ça en cumulatif (on ne dessine pas un pixel, on augmente l'intensité lumineuse du pixel "précédent").