Discussion :

[lauxley]

Merci de répondre si vite,

Et quel est ton problème exactement ?

En faite je crois que j'ai un peu de mal à passer de la définition stricte des mots à leur sens réel

Qu'est-ce que tu appelles "intensité globale du son" ?

Euh .. le volume ?
mais pas celui définit par le client (dans le sens logiciel)
Dans un fichier son donné, même si le client touche pas au volume, le son peu être plus ou moins fort.

désolé si je n'utilise pas les bons termes au bon moment, j'essaye d'être le plus clair possible.

[pseudocode]

En faite je crois que j'ai un peu de mal à passer de la définition stricte des mots à leur sens réel

Dans le domaine du traitement du signal, les definitions ne sont de toutes facons pas tres claires. Donc, pas de panique.

Euh .. le volume ?
mais pas celui définit par le client (dans le sens logiciel)
Dans un fichier son donné, même si le client touche pas au volume, le son peu être plus ou moins fort.

Le "volume" n'a pas grande signification pour une suite d'octets.

Generalement on parle de puissance RMS: PRMS = Racine( Somme[echantillons^2] / NombreEchantillons)

Attention: les echantillons sont les "octets" de ton fichier, et pas les coefficients de fourier.

[lauxley]

Es ce que tu es en train de me dire que toute mon implémentation de la FFT n'a servie à rien ?
Bon j'essaye ça tout de suite, et je te tiens au courant.

Edit : Vu que je fais un Vumeter, le nombre d'échantillon dois être egal à 1 non ?
(analyse en temps réel quoi)

[pseudocode]

Es ce que tu es en train de me dire que toute mon implémentation de la FFT n'a servie à rien ?

La FFT ça sert surtout à obtenir la densité spectrale, c'est a dire une information sur les amplitudes en fonction des fréquences.

[lauxley]

Apparement ça mets pas à jour le thread d'edit un message, donc je répète ma question :

Vu que je fais un Vumeter, le nombre d'échantillon dois être egal à 1 non ?
(analyse en temps réel quoi)

[pseudocode]

Vu que je fais un Vumeter, le nombre d'échantillon dois être egal à 1 non ? (analyse en temps réel quoi)

Avec un seul échantillon on ne peut pas estimer grand chose.

Tu dois en prendre autant que tu peux, en respectant ta contrainte de "temps réel" (temps de acquisition+calcul+affichage)

[lauxley]

oula, encore un concept que je ne comprends pas trop.

autant que je peux ?
le nombre d'octets lu en un temps donné ne dépends pas du bitrate ?

en tout cas merci de m'apporter des réponses.

[edfed]

le temps reel en ordi, c'est une illusion, ça n'existe pas...
en traitant les données en fonction du frame rate, on donne l'illusion de temps reel.
mais en fait, il y a une periode Z correspondant au frame rate.

[lauxley]

Oui je suis bien daccord, d'où ma question,
car d'après pseudocode je ne dois pas lire un nombre d'octets dependant du framerate (ou bitrate ici), mais "autant que je peux".

[pseudocode]

oula, encore un concept que je ne comprends pas trop.
autant que je peux ?
le nombre d'octets lu en un temps donné ne dépends pas du bitrate ?

Si bien sur... mais pour calculer ta puissance instantanée, tu dois quand meme faire le calcul sur PLUSIEURS echantillons.

- Si tu n'en prend qu'un seul, l'estimation de la puissance va etre très fausse (la moyenne d'une seule valeur n'est pas représentative)
- Si tu en prend trop, elle va l'etre également (la moyenne de trop de valeurs va applatir les pics)

Il faut avoir suffisament d'echantillons pour que ton VuMeter se comporte comme tu le veux. Par exemple, si tu veux raffraichir ton VuMeter 5 fois par seconde, il te faut 200ms d'echantillons... A toi de choisir le bitrate pour que le nombre d'echantillons reste raisonnable (temps de calcul, occupation mémoire, ...)

@edfed: "Temps réel" ne veut pas dire "instantané". Ca signifie "avoir une contrainte de temps", par exemple "a traiter en moins de 100ms".

[edfed]

yes, and to help more the original poster, i can say:
the ideal sample lengh is 512 samples.

heu escusez moi, je me suis laissé emporter, un peu d'humour lourd ne fait pas de mal..
en audio, la taille de l'echantillon ideale est de 512 samples. 2^9 echantillons.
pour du stereo 16 bits (de base), ça correspond à 44100/512 seconde, 2048 octets, c'est le top de l'optimisation.

ensuite, le spectre affiché à un instant T peut etre maximisé en fonction de la valeur de chaque FFT calculées dans la periode Z (Z etant l'echantillon de temps discret).

avec 512 samples, on peu couvrir 512 frequences ( bandes de frequence en fait ) ça donne une bonne presision au delire.

j'attend les contradictions avec impatience.

[lauxley]

Oki merci, je comprends mieux.
J'ai fait des test avec un nombre d'octets en dur, et effectivement, en tatonnant j'arrive à une valeur qui donne de bons résultats.

Donc merci énormement !

J'en proffitte pour poser une autre question, car vous avez l'air de bien maitriser le sujet
Ques ce qu'on appelle saturation, dans le même contexte ? es ce qu'on peut la calculer ? ou es ce juste une valeur fixé arbitrairement ?

[edfed]

la saturation, c'est quand on arrive à la valeur maximum.

pour du 16 bits signé, les valeurs de saturation sont 32767 et -32768

en electronique, c'est quand le signal de sortie ne peu plus croitre, car il atteint la valeur des rails d'alimentation du montage.

la saturation est preferable au rebouclage, en numerique, le rebouclage, c'est quand on additione un chiffre > 0 à la valeur max, ça donne un nombre negatif ou inferieur au nombre de depart.

la technologie mmx possede des instructions prenant en compte la saturation, ce qui optimise considerablement la vitesse de calcul, à verifier pour les prescott ( SSE, SSE2, SSE3, SSSE etc..).

donc, pour ton analyseur de spectre, je te conseille de forcer le compilateur à utiliser ces instructions , si c'est possible.

[lauxley]

Bonjour

J'ai une question pour vous (eh oui, encore).
Lorsque je récupère un octet, si je l'affiche en tant que float (sur 4 octets)
sa valeur est a peu près comprise entre 1.06 et -1.06 (j'ai pas pu tester avec un fichier "saturé"), je vois pas à quoi correspondent ces valeurs.

[quote]PRMS = Racine( Somme[echantillons^2] / NombreEchantillons)[quote]

Es ce qu'on mets "l'echantillon" au carré pour se débarasser des valeurs négative ?
Dans ce cas un echantillon de valeur -x a la même puissance qu'un echantillon de valeur x ?
Ou alors dois je caster l'echantillon avant de faire le calcul ? en unsigned int par exemple ?
ou alors même ajouter ValeurMax (à peu près 1.06 ici) pour avoir une valeur comprise entre 0 et 2*ValeurMax ?

Merci d'avance.

[pseudocode]

Bonjour

J'ai une question pour vous (eh oui, encore).
Lorsque je récupère un octet, si je l'affiche en tant que float (sur 4 octets)
sa valeur est a peu près comprise entre 1.06 et -1.06 (j'ai pas pu tester avec un fichier "saturé"), je vois pas à quoi correspondent ces valeurs.

Comment tu fais pour convertir "un (seul) octet" en un float de "4 octets" ?

Es ce qu'on mets "l'echantillon" au carré pour se débarasser des valeurs négative ?

Non on le met au carré parceque c'est un calcul de surface (approximation d'une integrale par la methode des rectangles).

[lauxley]

oué j'ai buggé

Lorsque je récupère un échantillon, si je l'affiche en tant que float (sur 4 octets).
Mon buffer est un float*, à chaque fois que je dois lire un échantillon, j'incrémente son adresse. *buffer++.

[pseudocode]

Lorsque je récupère un échantillon, si je l'affiche en tant que float (sur 4 octets).
Mon buffer est un float*, à chaque fois que je dois lire un échantillon, j'incrémente son adresse. *buffer++.

Hum... il faudrait que tu te renseignes sur le format de tes données d'entrée (8bits/16bits, mono/stereo, ...)

[lauxley]

En faite j'ajoute un fonction à un module déjà existant.

Dans une autre fonction le buffer est traité de la sorte :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
	int16_t  *p_buffs;                    /* int16_t converted buffer */
	int16_t  *p_s16_buff = NULL;                /* int16_t converted buffer */
 
	float *p_buffl = /* Original buffer */
		(float*)p_buffer->p_buffer;
	p_s16_buff = (int16_t*)malloc(
	      nb_read * p_effect->i_nb_chans * sizeof(int16_t));
	p_buffs = p_s16_buff;
    /* Convert the buffer to int16_t  */
    /* Pasted from float32tos16.c */
    for (i = p_buffer->i_nb_samples * p_effect->i_nb_chans; i--; )
    {
        union { float f; int32_t i; } u;
        u.f = *p_buffl + 384.0;
        if(u.i >  0x43c07fff ) * p_buffs = 32767;
        else if ( u.i < 0x43bf8000 ) *p_buffs = -32768;
        else *p_buffs = u.i - 0x43c00000;
 
        p_buffl++ ; p_buffs++ ;
    }

Si j'applique cette fonction je suis sur que les données seront en 16bits ?
(je capte le but mais vraiment pas la méthode oO)

Sinon p_effect->i_nb_chans me donne le nombre de channels (donc mono ou stereo).

[user 56gt8]

Sous delphi tu as FFTreal , très populaire dans le monde audio delphi:

*présentation :http://ldesoras.free.fr/prod.html
*produite: http://ldesoras.free.fr/src/FFTReal-2.00.zip

cette librairie est très performante pour de l'audio en temps réel

Pour une application classique il y a
http://www.lohninger.com/sdlindex.html dans la suite sdl_math il y a une
fft très facile à utiliser (FFT real aussi mais un peut moins)
Par contre très lent (pas utilisable pour du temps réel) et grosse conso cpu.
En version démo la fft est limitée à un buffer de 512 échantillons (ca suffit) , mais par contre tu as toutes les options de fenêtrage intégrée sans rien à coder.

[lauxley]

C'est pas du Delphi,
c'est du bon vieux C, bien de chez nous