LinFIR - Mesures et égalisation FIR/IIR

[Arnwald]

Hello,

Je suis très heureux de vous annoncer la sortie de LinFIR 1.4.11. Je travaille depuis quelques temps sur une refonte de l'interface, et elle est enfin terminée. La colonne de gauche est maintenant un ensemble de cartes, une pour les réglages DSP cibles et une par haut-parleur, bordée de sa couleur, et chaque graphique a sa propre carte. Les onglets, boutons et titres ont le même aspect partout, et toutes les fenêtres secondaires suivent le même style, en thème clair comme en thème sombre. Le but était d'avoir quelque chose de plus lisible et intuitif, où l'on trouve ce dont on a besoin plus facilement. Au passage, j'ai ajouté le glisser-déposer pour réordonner les haut-parleurs et les graphiques.

En plus de la refonte, il y a quelques nouveaux outils. Auto-level, à côté de Auto-align delays, règle les gains pour que la réponse sommée soit aussi plate que possible sur toute la bande passante du système, crossovers compris. Et une correction du centre de rotation pour les mesures hors axe : si l'axe de votre table tournante n'était pas au niveau du baffle, les mesures hors axe sont décalées et la mesure polaire est un peu faussée. Vous indiquez donc où se trouvait l'axe, et LinFIR reconstruit les réponses hors axe comme si l'enceinte avait tourné autour de son baffle.

J'ai aussi passé beaucoup de temps sur le moteur de calcul. Le déplacement des curseurs avec plusieurs haut-parleurs est plus léger, le tracé des graphiques coûte une fraction de ce qu'il coûtait en ressources CPU, et le CQT et le Burst Decay du spectrogramme sont jusqu'à 13 fois plus rapides. Parmi la longue liste de corrections : l'Auto EQ s'arrêtait après sa première étape, les niveaux de splicing near-field pour les évents et radiateurs passifs étaient plusieurs dB trop bas. La sauvegarde et la fermeture sont aussi bien plus fiables qu'avant.

Le changelog complet : https://demaudio.com/doc/linfir/release-notes.html


Arnaud

[pvrx]

Bonsoir Arnaud,

Cette nouvelle version est effectivement plus agréable à utiliser, et son ergonomie a progressé.
J'ai notamment apprécié la nouvelle ergonomie du bandeau de gauche, plus net, qui fait gagner beaucoup de temps, puisqu'on passe pas mal de temps à naviguer visuellement du bandeau de gauche à un graphique ou à une fenêtre de paramétrage.
Une remarque de détail concernant la fonction "Niveaux automatiques".
Sur un de mes essais, je me suis retrouvé avec des niveaux respectifs de -26, -35 et -38dB environ sur les gains des trois voies. Je les ai recalés "à la main" de 26dB.
Ca ne change sans doute rien aux calculs de LinFIR, mais à quoi correspondent ces gains par voie ?

Pascal

[Jean Fourcade]

Le curseur de causalité de LinFIR est basé sur le filtrage homomorphique (en calculant le cepstre : https://fr.wikipedia.org/wiki/Cepstre ) pour séparer la composante causale et anticausale d’un signal. La proportion gardée entre les deux permet de passer d’un filtre phase linéaire à un filtre phase minimum (donc avec rotations de phase).

Le comportement de RePhase est accessible avec une option dans les réglages, mais je le déconseille fortement, on s’expose aux artefacts.

D’ailleurs, la tendance qu’a RePhase à cacher le résultat final (et les artefacts liés à de mauvais choix de conception de filtre) est une des raisons qui m’ont poussé à concevoir LinFIR avec un retour visuel direct du résultat. Pas de courbe théorique, on voit directement tout.

Merci pour ces explications sur le traitement du centrage de l'impulsion.

Chacun défend l'approche ergonomique et technique de son logiciel, et c'est tout à fait légitime. En revanche, présenter rePhase comme un outil qui « calcule mal » ou qui inciterait à faire de mauvais choix me semble réducteur. rePhase ne fait que calculer exactement ce que l'utilisateur lui demande.

Vous indiquez que rePhase tend à cacher le résultat final, contrairement à LinFIR. Certes. Mais du point de vue de l'utilisateur, c'est paradoxalement l'inverse qui se produit : en supprimant l'affichage de la cible théorique, LinFIR masque le fait qu'il n'arrive pas à appliquer la consigne demandée par l'utilisateur.

rePhase révèle immédiatement ce problème. À vouloir éviter d'afficher des filtres virtuels hors d'atteinte, on prive l'utilisateur d'un indicateur d'écart indispensable au diagnostic.

Concernant le calage du pic de l'impulsion dans la fenêtre, l'utilisateur ne progresse pas à aveugle sous rePhase : le logiciel affiche précisément les artefacts éventuels introduits par le fenêtrage. Caler l'impulsion autour de 25 % (comme le pratique jlo présent sur ce forum) est une méthode à phase mixte très courante et largement documentée.

Quelle que soit la rigueur mathématique des algorithmes employés si le budget de taps ne permet pas d'atteindre la résolution fréquentielle demandée, le filtre réel s'éloignera de la consigne.

En ce qui me concerne, l'absence d'affichage de cet écart entre la cible et le filtre calculé reste un point rédhibitoire.

[Arnwald]

Merci pour ces explications sur le traitement du centrage de l'impulsion.

Chacun défend l'approche ergonomique et technique de son logiciel, et c'est tout à fait légitime. En revanche, présenter rePhase comme un outil qui « calcule mal » ou qui inciterait à faire de mauvais choix me semble réducteur. rePhase ne fait que calculer exactement ce que l'utilisateur lui demande.

Vous indiquez que rePhase tend à cacher le résultat final, contrairement à LinFIR. Certes. Mais du point de vue de l'utilisateur, c'est paradoxalement l'inverse qui se produit : en supprimant l'affichage de la cible théorique, LinFIR masque le fait qu'il n'arrive pas à appliquer la consigne demandée par l'utilisateur.

rePhase révèle immédiatement ce problème. À vouloir éviter d'afficher des filtres virtuels hors d'atteinte, on prive l'utilisateur d'un indicateur d'écart indispensable au diagnostic.

Concernant le calage du pic de l'impulsion dans la fenêtre, l'utilisateur ne progresse pas à aveugle sous rePhase : le logiciel affiche précisément les artefacts éventuels introduits par le fenêtrage. Caler l'impulsion autour de 25 % (comme le pratique jlo présent sur ce forum) est une méthode à phase mixte très courante et largement documentée.

Quelle que soit la rigueur mathématique des algorithmes employés si le budget de taps ne permet pas d'atteindre la résolution fréquentielle demandée, le filtre réel s'éloignera de la consigne.

En ce qui me concerne, l'absence d'affichage de cet écart entre la cible et le filtre calculé reste un point rédhibitoire.

Parler de résultat théorique pour un filtre FIR n'a pas grand sens, puisque par définition le filtre a une réponse impulsionnelle finie. Pour un brickwall on afficherait une porte, pour une correction de phase ou de magnitude une réponse plate. Deviner le résultat final à partir de cette perfection théorique n'a jamais rendu le travail plus intuitif.

Le seul cas où une cible est réellement utile est la correction de magnitude, quand on vise une courbe précise. Dans ce cas, la cible s'affiche en superposition lorsque la fenêtre de configuration du filtre est ouverte et au premier plan (capture ci-jointe).



Et ce n'est de toute façon pas le seul retour: LinFIR affiche directement le résultat sur la magnitude, et l'onglet FIR permet de visualiser la réponse réelle du FIR lui-même, avant son application à la réponse impulsionnelle du haut-parleur. L'écart entre l'intention et le filtre réalisé est donc visible à chaque étape, sans qu'il faille le deviner.

Décaler le pic d'un filtre à phase linéaire n'est pas une vraie méthode à phase mixte. On tronque un filtre symétrique, et on introduit des oscillations de Gibbs.

Le traitement du signal impose toujours un compromis temps-fréquence. Ce qui sera « gagné » en pre-ringing et en latence via cette méthode sera perdu en lobes. Et si on fenêtre plus agressivement pour les réduire, alors on perd la résolution fréquentielle et le filtre devient moins efficace.
Le curseur de causalité de LinFIR travaille directement sur la causalité du filtre pour conserver sa réponse en magnitude. La transformation cepstrale ne tronque rien : elle redistribue l'énergie dans le temps. La troncature au nombre de taps s'applique ensuite, comme pour n'importe quel FIR, mais son effet se voit directement sur le résultat.

C'est un choix assumé pour faire du traitement du signal propre. Le compromis est la linéarité de phase, ce qui est expliqué dans la documentation.
Je ne vous oblige pas à utiliser LinFIR, mais merci de vérifier le fonctionnement du logiciel avant d'en décrire les limites.

[Jean Fourcade]

Je ne vous oblige pas à utiliser LinFIR ...

Me voilà rassuré

Bonne suite dans le développement de LinFIR.

[razzortec]

Bonjour
Dans mon HC , j'utilise un PC sous W10, et depuis la mise à jour, en 1.41.1, je n'ai plus accès à l'onglet réglage ( ça tourne en boucle puis plus rien), alors que j'avais aucun problème avec la 1.39
Aucun problème avec W11

Bonne journée

[razzortec]

J'ai passé le PC sous W11, meme s'il avait pas les prérequis nécéssaires, et depuis plus de problèmes

[pvrx]

@razzortec

Bonjour !
Si tu as déjà effectué des mesures directement avec LinFIR, pourrais-tu préciser ta config de mesure (micro, carte son, loopback ou autre, paramétrage carte son et settings de LinFIR) ?
Personnellement, avec ma carte son Motu M2, je n'y suis jamais parvenu, alors que dans REW ça fonctionne parfaitement en ASIO.
Merci d'avance !

Pascal

[pvrx]

Bonjour à tous !

J'ai cessé de "jouer" avec LinFIR pour passer aux actes.
J'ai produit un première mesure avec le mid, WYSIWYG (micro à 3 mètres, hauteur 2,40m), c'est magique :

Puis avec l'aigu (fenêtrage à 6ms), mais j'ai dû oublier un fichier de calibration quelque part, d'où un léger tilt en haut de bande... Niveaux très décalés, un trou au raccord :

Mid + aigu brut.jpg (57.74 Kio) Vu 300 fois

Après correction sur les niveaux et en décalant le delay du mid (ou de l'aigu, je ne me rappelle plus) de 0,2ms :

Mid + aigu recalés.jpg (55.97 Kio) Vu 300 fois

J'ai ensuite ajouté la voie grave, en élargissant la fenêtre à 50ms pour y voir plus clair dans le bas, mais ça fait réapparaître les réflexions (80 et 255Hz) puis égalisé à la main son niveau :

Step 4.jpg (50.81 Kio) Vu 300 fois

C'est donc plutôt prometteur.

Quelques remarques/suggestions :
1. Les mesures initiales utilisées ont été effectuées avec REW, puis exportées en Wav normalisé pour importation dans LinFIR, Alignement des niveaux à la main pour respecter les écarts entre voies. Travaux manuels... Quand comme moi on ne sait pas utiliser la fonction de mesure directe avec LinFIR, c'est une galère.
2. Comportements parfois déconcertants de LinFIR : les nombreux paramètres accessibles (Kaiser beta, guard tolerance, intensité...) ne sont pas indépendants, et nécessitent le recours itératif au bouton "aligner les retards". Quand on observe la step, par exemple, la modification du curseur d'intensité sur la phase de 1% seulement modifie brutalement la step, et on doit réaligner.
Suggestion : donner la possibilité pour cette fonction de "génération auto" comme elle existe pour les EQ IIR.
3. Autre suggestion : serait-il possible d'insérer dans la documentation technique des copies d'écran illustrant l'effet de la modification d'un paramètre sur le résultat ? Je pense notamment à la réalisation d'un "bon" raccordement en phase des HP à la jonction, qui a été pour moi le sujet le plus laborieux.

Pascal

[Arnwald]

Salut! :-)

Je viens de mettre en ligne la version 1.4.12, et elle apporte beaucoup de nouveautés.

LinFIR est maintenant disponible sur les distributions Linux x64 (distributions post 2020), via un package .deb, .rpm ou .AppImage. Faute de matériel adéquat (une machine avec chacune des distributions visées), je n'ai pas pu tout tester. Donc n'hésitez pas à me faire remonter tous les problèmes rencontrés pour que j'apporte les correctifs nécessaires.
Les packages sont téléchargeables ici:
https://demaudio.com/linfir/

J'ai corrigé un défaut ennuyeux de la correction de phase: dans certains cas la polarité du haut-parleur pouvait être inversée à cause d'une ambiguïté mathématique sur un offset de plus ou moins pi. C'est maintenant corrigé, et le filtre généré ne provoque plus d'inversion.

Les boutons Auto-align delays et Auto-level restent maintenant actifs plutôt que de faire des alignements en "one-shot". Cela permet de tout aligner automatiquement quand on change des paramètres sans avoir à revenir cliquer dessus. Ils se désactivent automatiquement si l'on change manuellement les délais ou les gains, ou si l'on clique à nouveau sur les boutons.

Les crossovers FIR peuvent maintenant être synchronisés entre hauts-parleurs, ce qui évite d'avoir à jongler entre les fenêtres d'un passe haut et d'un passe bas pour reporter un changement de paramètre.

Le style de la documentation a aussi été entièrement revu. Elle est plus lisible et la navigation est plus simple.

Pour tout le reste, c'est noté dans les release notes: https://demaudio.com/doc/linfir/release-notes.html

Bonne journée,

Arnaud

[moonfly]

le problème sous Linux c’est la compatibilité avec les cartes son, la mienne par exemple ne fonctionne pas sous Linux
quelques renseignements en dessous :
http://linuxmao.org/Cartes%2Bson?struct ... omparatifs

[razzortec]

@pvrx

J'ai une carte son Steinberg UR 22 MK2, un micro ECM 8000 calibré

Réglages LINFIR

reglage carte son.png (153.86 Kio) Vu 218 fois

[pvrx]

Belle mise à jour, merci !

Je complète mon petit CR supra, concernant l'export vers HFD.
Lors de mes premiers essais, l'export des filtres et corrections IIR vers HFD semblait normal, mais HFD plantait souvent lors de l'upload vers le DSP.
Je me suis aperçu qu'en limitant le Q des EQ à 6 et le gain à 6dB, l'upload se faisait correctement.
Je ne connais pas les conditions aux limites pour ces exportations d'EQ, et j'ai donc posé la question au support Hypex, la doc HFD étant muette sur ce point. Je suis en attente de réponse.

Pascal

[Dagda]

Jamais eu ce genre de soucis.... L'ergonomie de HFD est moisie mais jamais de problème de Q trop fort et de gains supérieur à 6dB (ou -6dB) ...

Étrange.

D.

[pvrx]

Bingo !
Enfin réussi à faire des mesures avec LinFIR !
Le paramétrage des settings audio est cependant différent de celui utilisé par razzortec, que je remercie au passage pour son message.

C'est déjà ça.
Mais il faut quand même être capable d'importer correctement des mesures provenant d'autres logiciels, ne serait-ce que pour utiliser en intérieur une mesure (en plan de sol, par exemple) effectuée dans de bonnes conditions en extérieur et recalée sur le plan temporel.
Possible aujourd'hui, mais du taf manuel...

Pascal

[Sensunda]

Bingo !
Enfin réussi à faire des mesures avec LinFIR !

Je t'avais donné la résolution du problème précédemment ... Mais le fait que tu es un warning sur la sortie de référence montre que tu ne fais pas dans les règles de l'art .

[pvrx]

J'étais sans doute passé à côté de quelque chose.
Mais alors, pourquoi ça marche avec mes settings ?

[Sensunda]

Car je suppose que LINFIR sort le son sur les 2 canaux de la carte son .

Mais j'aurai mis le canal 2 en sortie de référence. Et câblé en conséquence de la carte son !

[pvrx]

Bonjour à tous !

Problèmes d'import/export, suite et fin ?
Me posant pas mal de questions sur ce que REW met (ou pas) dans ses exports Wav, j'ai regardé à quoi ressemblaient dans REW les mesures réimportées.
J'ai découvert que pour celles-ci les pics d'impulsion étaient tous exactement superposés à t=0 !
Autrement dit, les références temporelles avaient disparu dans l'opération.
Face à ces Wav, LinFIR ne pouvait évidemment les traiter correctement, et affichait des positions de pics fantaisistes.
Il y a dans LinFIR (fenêtre "Gérer les RI" / compensation de retard) une case permettant de créer pour chaque voie un offset sur la position des pics.

Retard 1.jpg (84.4 Kio) Vu 8 fois

Cette compensation n'accepte que des valeurs positives, qui décalent le pic vers la gauche.
On peut donc rétablir avec précision l'ordre et l'espacement des trois impulsions.
Voici la position des pics d'impulsion de référence (mesure REW micro à 3 mètres, hauteur micro 2,40m) :

Et dans LinFIR après recalage :

En principe, ça répond bien à mon souci.
L'importation en Wav normalisé ne préserve pas les niveaux respectifs. En réalité, ce n'est pas bien grave. C'est très facile à régler en créant des offsets de niveau dans le DSP après une mesure, qui fera apparaître une réponse en escalier :

Escalier.jpg (56.08 Kio) Vu 8 fois

Pascal