Courbes cibles en stéreo 2.0 / EQ temporelle en basse fréq

[Pio2001]

Du coup est-ce qu'une mesure de group delay sur :
- sans correction
- avec correction à phase linéaire
- avec correction à phase minimale
ne serait pas le juge de paix ?

Voici le group delay complet avant correction, au point d'écoute :



Et après correction (phase minimale), toujours au point d'écoute :



Je pense que les pics dans la moitié de droite du graphe sont faux (ils correspondent à des annulations dans la courbe de réponse). Mieux vaut ne pas en tenir compte.
La partie sous 25 Hz est également fausse. Il n'y a aucun signal à cette fréquence (les enceintes ont un passe-haut à 30 Hz).

La partie entre 30 et 200 Hz est pertinente. Pour le comparatif détaillé ces deux courbes, voir deux pages en arrière : post179578439.html#p179578439

Pour la correction à phase linéaire, je ne sais pas comment mesurer. Il y a l'astuce de lancer le signal d'un côté en enregistrant de l'autre, qui a été donnée plus haut, mais je n'ai pas le signal sur cet ordinateur et il n'est pas capable de s'enregsitrer lui-même.

[wakup2]

Le waterfall comme l'a montré JIM serait bien plus parlant

[Pio2001]

Waterfall avant correction :



Waterfall après correction :



Waterfall (fréquences graves 40 - 200 Hz uniquement) avant correction :



Waterfall (fréquences graves 40 - 200 Hz uniquement) après correction :



J'ai baissé le rise time à 20 ms afin de mettre en évidence ce qui se passe après les 20 premières millisecondes. En contrepartie, la décroissance apparaît plus irrégulière.
Le graphe est plus joli avec le rise time à 100 ms (valeur par défaut), mais on est alors aveugle à ce qui se passe durant les 100 premières millisecondes.

[wakup2]

pour le coup la il y'a un peu trop de dynamique, on est dans le bruit de fond, tu peux diminuer un peu l’échelle 50dB c'est déjà très bien

[JAVA Alive]

Pio, pour le comparo correction phase lin / phase min, tu peux utiliser la version d'éval de JRiver.
Tu fais le setup de JRiver normal (canal sortie, ASIO, etc)
Tu vas dans le DSP et tu actives la convolution, tu lui donne ton fichier impulse, il se démerde avec.
Tu actives de WDM diver.

Ensuite dans REW, tu choisis comme carte son de sortie, le WDM driver en question qui doit s'appeler JRiver WDM ou un truc dans le genre.

Ca fonctionne chez moi sous windows 7 et 10, sous Mac pas sûr.

Sinon, je veux bien faire les mesures et les publier mais il faut me dire excatement lesquelles et quel setup je dois mettre pour le faire.
Je peux même faire une comparaison d'une convolution avec quelques Q élevés qui vise à corriger des incident "pointus" avec une correction plus light.

[JIM]

Merci Pio pour ces waterfalls avec une échelle plus large. On fait bien la distinction entre bruit et signal au moins, je préfère.
En dehors de la baisse de niveau liée à l'EQ, je ne vois pas de gain notable sur l'amortissement. C'est même le contraire car la dynamique sur le mode est inférieure après correction sur la même durée mais l'EQ te permet de corriger le délai de groupe.

Tu peux afficher les waterfall en overlay par transparence sous REW, ce sera plus facile de comparer.

L'effet temporel d'une EQ IIR ou FIR conventionnelle s'arrête à la modification de la phase/délai de groupe.
En FIR par convolution avec Rephase, idem. Il est possible d'aller plus loin avec du DRC par convolution mais on ne génère plus une impulsion mais plusieurs étalées dans le temps.

Le temps d'intégration du waterfall comme du Decay fausse l'interprétation.

[thierryvalk]

Comme quoi chacun à ses habitudes.
Il me semble qu'il est commun de dire qu'un son arrivé à -60dB se fondra dans le bruit ambiant.
Et qu'a -30dB il se fondra dans les autres sons générés.
Mais cela pour des salles d'écoute et de manière générale au niveau des fréquences.

Ici, l'on parle de basses fréquences : voir les courbes de Fletcher.
Et dans une pièce à vivre.

Du DRC ne va générer qu'une seule implulse, toute la différence est dans la manière d'interpréter la mesure, d'appliquer des corrections non extravagantes et de limiter leurs effets nons désirés.

[Pio2001]

Pio, pour le comparo correction phase lin / phase min, tu peux utiliser la version d'éval de JRiver.

Pas si simple. JRiver est disponible pour Linux Debian Jessie. Moi j'ai Linux Mint Debian, et c'est rarement compatible avec quoi que ce soit. Je ne pense pas que je vais me lancer là-dedans.
Grosso modo, une correction à phase linéaire va corriger l'amplitude et laisser la phase - donc les délais - inchangés.

Sinon, je veux bien faire les mesures et les publier mais il faut me dire excatement lesquelles et quel setup je dois mettre pour le faire.

Pour cela, il faudrait identifier chez toi une résonance susceptible de provoquer des problèmes temporels. Un bon gros pic dans le grave. Et on commencera par regarder s'il est à phase minimale.
Pour cela, fais une mesure sans correction à ton point d'écoute avec REW (choisis la mesure la plus lente, on ne sait jamais). Affiche le group delay sans lissage. Clique sur le bouton "Controls" (l'engrenage), puis sur "Generate minimum phase".

En dehors de la baisse de niveau liée à l'EQ, je ne vois pas de gain notable sur l'amortissement. C'est même le contraire car la dynamique sur le mode est inférieure après correction sur la même durée mais l'EQ te permet de corriger le délai de groupe.

Les deux sont liés. Le gain surle délai de groupe apparaît au tout début du waterfall.
Sur la résonance à 55 Hz, on voit une chute sur les tranches 2 à 6, et à 70 Hz, la tranche 3 est une véritable falaise, par rapport aux tranches correspondantes sur le waterfall sans correction.
Grosso modo, on voit que la correction temporelle n'agit que sur les 50 premières millisecondes.

Tu peux afficher les waterfall en overlay par transparence sous REW, ce sera plus facile de comparer.

On ne voit plus rien : le waterfall vert masque complètement le rose.

L'effet temporel d'une EQ IIR ou FIR conventionnelle s'arrête à la modification de la phase/délai de groupe.

Cette affirmation n'est pas très claire. Les effets temporels découlent à la fois de la courbe de réponse et de la courbe de phase, et d'une façon pas du tout triviale.
Par exemple une brusque variation dans la courbe de réponse va étaler temporellement la fréquence en question. Et la courbe de phase va déterminer si l'étalement est plutôt devant ou derrière l'impulsion principale.

Le temps d'intégration du waterfall comme du Decay fausse l'interprétation.

J'ai expérimenté un peu avec les paramètres.
Le fenêtrage à gauche (rise time) a un effet totalement différent du fenêtrage à droite (window), car la réponse impulsionnelle démarre brusquement et décroit ensuite régulièrement.

Le brusque démarrage a pour effet que le rise time (partie du fenêtrage antérieur à l'impulsion analysée) va produire sur le waterfall une bosse au début qui est une image du fenêtrage lui-même, et qui va masquer le signal. On le voit très nettement sur les waterfall postés par Ohl. La grosse bosse qui précède la décroissance est bien visible.
Quand on diminue le rise time, cela a deux effets. Le premier, bénéfique, est de faire disparaître cette bosse pour laisser apparaître l'information présente immédiatement après l'impulsion. C'est ce que j'ai fait (10 ou 20 ms de rise time). Le second, négatif, est que la fenêtre d'analyse est coupée de plus en plus brutalement du côté gauche (côté antérieur), ce qui ajoute du bruit aléatoire à la mesure, car la partie analysée du signal se retrouve tronquée à des hauteurs différentes pour chaque tranche au lieu d'être atténuée progressivement par une fenêtre propre. Le spectre de ces troncatures s'ajoute au graphique et le waterfall devient désordonné. Les miens ci-dessus souffrent beaucoup de ce problème.
Ce ne sont que des imprécisions dans le calcul du graphe. Dans la réalité, la décroissance est bien plus homogène. On le voit en ajoutant 100 ms au rise time et en retranchant 100 ms à la window. Le temps d'analyse de chaque tranche reste le même, mais la courbe redevient lisse, car le "fenêtrage à gauche" est de nouveau progressif : le signal est atténué en douceur sur 120 ms au lieu de 20.

L'autre paramètre de fenêtrage, "window", n'a pas d'effet négatif sur le début ou la fin du waterfall, car il englobe la partie décroissante de l'impulsion analysée. Il est toujours du côté où il y a le moins d'énergie, c'est-à-dire le côté qui contibue le moins au graphique.

[Pio2001]

Edit : désolé, j'ai écrit "time range" alors que je voulais dire "rise time". C'est corrigé.

[wakup2]

Sur la résonance à 55 Hz, on voit une chute sur les tranches 2 à 6, et à 70 Hz, la tranche 3 est une véritable falaise, par rapport aux tranches correspondantes sur le waterfall sans correction.
Grosso modo, on voit que la correction temporelle n'agit que sur les 50 premières millisecondes.

Cela ne fait que 3 longueur d'onde a 55Hz, très très limite pour reconnaître une note.

[Pio2001]

Au niveau du group delay, on passe de 95 à 50 ms. Cela fait 45 ms de différence. En soi, à ces fréquences là, c'est vrai que c'est difficile à entendre sur un signal musical.

Mais si on fait la même correction à phase linéaire au lieu de minimale, cela fait du pré-echo, et ça, c'est tout-à-fait audible.

[wakup2]

Tout a fait d'accord

[JAVA Alive]

Bon, voici un premier jet.

Pour faire ces tests, j'ai fait une mesure au point d'écoute sans correction, une autre avec correction phase lin, une autre avec correction phase min.
La correction est la même : -12db / Q=6 / F=42hz qui correspond à mon plus gros pic de résonance.
Le micro n'a pas bougé d'un cm d'une mesure à l'autre.

La mesure sans correction

La mesure avec correction phase min

La mesure avec correction phase lin

Sur cet exemple, qui ne vaut pas démonstration du cas général, on voit quand même nettement que la correction à phase minimale corrige aussi la phase du signal à 42hz. Cette résonance de la pièce est bien à phase minimale.

Ca se voit d'ailleurs très clairement dans la correction prédictive de rephase. Quand on bouge le potar de la correction et qu'on a choisi "min phase", on voit bien la courbe de phase se redresser.

Dites-moi si vous voulez d'autres graphes.

[Pio2001]

Bonjour JavaAlive,
Tu as dû inverser phase minimale et phase linéaire. La courbe bleue doit être celle à phase linéaire car elle a la même phase que l'originale.

Il n'est pas sûr que l'ensemble soit à phase minimale car la courbe de phase est plus plate avant correction qu'après.

Pour ce qui est des problèmes temporels, ils seront probablement plus flagrants entre 44 et 48 Hz, là où la courbe penche le plus. Ceci n'ayant pas été corrigé, il ne doit guère y avoir de changement dans le group delay. Vu les courbes de phase, il devrait re moins bon après qu'avant.


Est-ce que tu entends une différence entre les deux corrections ?
Et est-ce que tu peux poster le fichier mdat avec les trois mesures ?

[JAVA Alive]

Salut Pio,


non, non, je ne crois pas m'être gouré sur phase min et lin.
Il ne faut pas trop regarder ce qui se passe en dehors des 30-50hz, même si j'avoue que ce qui s'y passe m'interroge un poil.
Mais à 42hz et autour, c'est bien la correction à phase minimale qui redresse la pente à un quasi plat, la phase lin est quasi identique à l'original.

Voici les fichiers :

Test min-lin.zip

Les 3 mdat

(173.22 Kio) Téléchargé 229 fois