JAVA Alive a écrit: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.
JAVA Alive a écrit: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".
JIM a écrit: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.
JIM a écrit: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.
JIM a écrit: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.
JIM a écrit: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.