Sound Pixel Lab

Salut @razzortec,

Ce format est assez exotique et n'existe pas dans LinFIR.

Ceci-dit, je vais prendre le temps de l'implémenter pour une prochaine version. En attendant il doit être possible de faire une conversion, peut-être en passant par rePhase, ou alors manuellement.

Aurais-tu un exemple de ces filtres exporté via rePhase? Cela m'aiderait pour l'implémentation. Merci!

https://www.dspiy.be/forum/viewforum.ph ... b7c894c7b1

Tu as peut-être des informations ici ...

Merci

Un exemple ici

Dans mon language, c'est la voie low, 6000 taps, de 0 à 200hz, filtrage LR 150, et retard de 35 ms

Top, merci! J'ai tout le nécessaire pour ajouter le format. Ce sera pour la prochaine version. :-)

Merci Arnwald
Par contre, je pense qu'il va y avoir un autre problème.
Le filtrage FIR induit un retard qui dépand du nombre de taps et de la fréquence d'échantillonage, avec la formule:
Nombre de Taps/ 2x fréquence d''échantillonge ( Je ne vous apprends rien), ce qui dans mon cas pour la voie Low ( 6000 taps et 48 K) fait 62.5 ms Dans rephase, il est possible de décaler dans le temps l'impulse de filtrage
Exemple avec -50 ms, ce qui ramène le retard à 12.5ms J'ai une installation HC, et j'utilise le FIR sur les frontales , droite , centrale, et gauche, mais pas les surrounds
Au niveau des surrounds, je suis limité à 20 ms pour le retard,, d'ou mon besoin de limiter le retard sur les frontales.

Et après tout ça , il faut encore gèrer le décalage entre l'image et le son

Si je puis me permettre, il ne faut absolument pas procéder de la sorte.

Avec ces paramètres, rePhase va générer un filtre à phase linéaire, pour lequel la formule (n_taps - 1)/2 est effectivement valable. Pour ce type de filtres, l'énergie avant le pic est aussi importante que celle qui se situe après. Décaler le milieu de 50 ms revient à tronquer une grosse partie de cette énergie, et on s'expose à des artefacts massifs de magnitude et de phase.

C'est exactement pour cela que j'ai développé LinFIR à l'origine: en plus de devoir utiliser Windows, l'impossibilité de visualiser directement le résultat final m'horripilait et de nombreux raccourcis sont faits sur les aspects de traitement du signal, poussant certains utilisateurs à générer des filtres aberrants.

La loi (n_taps - 1)/2 n'est valable que pour les filtres à phase linéaire, et il est tout à fait possible de générer un filtre FIR phase minimum pour lequel le pic est le plus proche possible de 0, et donc d'avoir une latence très courte.
Dans LinFIR cela se fait au moyen du curseur de causalité:
- 0 -> phase linéaire
- 1 -> phase minimum
- toute autre valeur intermédiaire -> un compromis entre la linéarité de phase et le délai

Exemple pour 3 valeurs de causalité (0, 0.5 et 1): On voit bien qu'à mesure que l'on tend vers le filtre phase minimum, les rotations de phase s'accumulent, mais le délai de groupe moyen diminue (le pic se décale à gauche).

Les causalités par défaut ne sont pas choisies arbitrairement. Pour les crossovers je privilégie la phase linéaire pour faciliter la sommation des hauts parleurs et leur comportement temporel, et c'est aussi le choix qui limite au maximum le pre et post ringing (ils s'annulent entre hauts parleurs). Pour la correction de magnitude, la causalité par défaut est à 1, ce qui correspond à un filtre purement minimum phase. La raison est simple: un haut parleur est lui même un système dont le comportement dominant est phase minimum, et quand on corrige la magnitude avec un filtre lui même phase minimum, on redresse la phase. Corriger la magnitude avec un filtre FIR phase linéaire est un non sens, on introduit du pre-ringing, du délai, et on se prive de la correction de phase "gratuite".

Il faut toutefois faire attention à un point: quand plusieurs filtres sont actifs dans LinFIR, le comportement général du filtre total sera celui qui a le délai le plus long (si on a une correction phase minimum et un crossover phase linéaire, ce sera ce dernier qui imposera le délai).

Sur cet exemple j'ai introduit un passe haut et un passe bas, on peut voir que si l'un est totalement phase linéaire et l'autre totalement phase minimum, la convolution des deux donne un filtre qui a quand même de l'énergie avant le pic.

Merci Arnwald pour tes conseils

En reprenant les réglages que j'ai fait voici 4 ans, le décalage de l'impulse vers la gauche n'est en réalité que de 35 ms

Ce qui donne avec rephase ceci.
Soit juste une augmentation du déphasage au dela de la fréquence de coupure (courbe rouge en pointillé)

Et avec LINFIR ceci, le décalage de 35 ms correspond à une causality de 0.56 ( à peu près) Soit aucune modification dans la magnitude, et un déphasage de quelques degrés

L'intégration des tables tournantes basées sur les Pololu Tic et Grbl est bientôt terminée. ;-)

L'étape d'après c'est la commande par Arduino

@Dagda c’est déjà fait, mais pour Grbl (Audiomatica Medusa). :-)

Et voilà, la version 1.3.5 est disponible (d'ici une heure ou deux pour Windows)!

J'ai intégré les tables basées sur les Pololu Tic et les Arduino faisant tourner Grbl. Les mesures angulaires peuvent donc être entièrement automatisées avec un seul clic. :-)

J'ai aussi intégré le format C array pour l'export des filtres FIR.

@+!

Hello, je viens de repérer un bug regrettable : la bibliothèque USB que j'utilisais ne s'est pas liée en statique dans le bundle. Ça fonctionnait sur mes machines, mais le bundle compilé plantait au lancement.

Le crash est corrigé avec la v1.3.6 et la bibliothèque est désormais compilée en statique directement dans le bundle de l'application.

Si vous avez rencontré ce crash sur Mac, merci de retélécharger LinFIR depuis le site web : https://linfir.demaudio.com/

La mise à jour correspondante pour Windows sera en ligne d'ici environ une heure.

Désolé pour le désagrément. :-)

Y'a même le service après vente !

Arnwald a écrit : ↑08 juil. 2026, 20:05
J'ai aussi intégré le format C array pour l'export des filtres FIR.

@+!

Merci, je regarderais à mon retour de vacances

Arnwald a écrit : ↑09 juil. 2026, 08:58
Désolé pour le désagrément. :-)

Merci à toi plutôt !

Hello!

Les mises à jour se sont un peu enchainées ces derniers jours, et elles apportent des améliorations substantielles.

Le comportement des axes lors du zoom sur les graphiques a été amélioré. Dans certains cas, les graduations ne s'affichaient pas ou manquaient de cohérence dans leur espacement. J'ai entièrement repensé le calcul de leur affichage pour offrir une transition plus fluide entre les ordres de grandeur.

J'ai mis à jour le backend de la bibliothèque audio afin de résoudre (espérons-le) des problèmes persistants sous Windows (cet OS est vraiment pénible lorsqu'il s'agit d'accès matériel et de jitter causé par le DPC). N'hésitez pas à me signaler si vous rencontrez des soucis.

Le sonogramme de directivité a également été mis à jour :
- Il est désormais possible de normaliser le tracé par rapport à la valeur maximale de l'axe à 0° (au lieu de la valeur maximale globale).
- Il est aussi possible de normaliser chaque fréquence sur l'axe à 0° afin de visualiser la directivité intrinsèque de votre pavillon/guide d'ondes/etc., sans que la réponse en fréquence du haut-parleur n'affecte les niveaux relatifs entre les fréquences.
- Une option de normalisation avec la moyenne des valeurs entre + et -10° est aussi disponible, pour limiter l'influence des changements brusques de niveau près du 0°.
- L'affichage intègre maintenant les courbes d'angle à -6 dB pour mieux visualiser le diagramme de directivité. Une amélioration qui m'a demandé beaucoup de travail est l'extraction de la distorsion harmonique après la déconvolution de Farina.
Pour l'expliquer rapidement : après avoir déconvolué le sweep enregistré avec l'inverse du sweep de mesure (le sweep brut), les harmoniques sont projetées dans le temps négatif (avant la réponse impulsionnelle principale/linéaire). Elles sont espacées de manière logarithmique (hn,..., h3, h2, h1), et plus le sweep est long, plus le délai entre les impulsions d'harmoniques est important.
L'extraction de la distorsion harmonique se fait en fenêtrant chaque harmonique. Cependant, leur niveau peut être faible par rapport au bruit, et inclure trop de silence bruité dans la fenêtre pollue le spectre harmonique.
J'ai donc mis en place un algorithme qui détecte le début et la fin de l'harmonique à partir de son enveloppe. Le résultat offre une estimation bien plus propre. En dehors de cela, la documentation et la détection des périphériques audio ont également été améliorées. J'ai aussi amélioré le spectrogramme, il est calculé plus rapidement et est mieux défini quand on zoome.

Comme toujours, vos retours, suggestions ou signalements de bugs sont les bienvenus.

PS : Je travaille sur un algorithme génétique pour optimiser les guides d'ondes. Le diagramme de directivité ci-dessus est le résultat direct d'une optimisation : j'ai imprimé en 3D la géométrie optimisée et je suis très content du résultat.

Il s'appuie sur ce générateur et simulateur de guides d'ondes :
https://github.com/m3gnus/waveguide-generator/tree/main
Il existe un fil de discussion sur DIYAudio où l'auteur publie ses mises à jour :
https://www.diyaudio.com/community/thre ... st-8340567
Je pense vraiment que son travail mérite d'être connu, c'est une excellente alternative à AKABAK, que je trouve abominablement lent et dont l'interface est datée (pour le dire poliment). Ah, et Windows only (moins je touche à cet OS, mieux je me porte )...

je suis aussi les liens donné plus haut depuis le début, c’est intéressant. Concernant AKABAK et son ancêtre ABEC pour améliorer le temps de calcul des simus j’ai un serveur :

https://i.dell.com/sites/csdocuments/Sh ... -sheet.pdf

Bonjour,

La distorsion affichée en fonction du temps, c'est la première fois que je vois cela, et cela peut-être très instructif, merci pour ça . C'est possible aussi en fréquentiel je suppose ?

Sensunda a écrit : ↑24 juil. 2026, 11:01 Bonjour,

La distorsion affichée en fonction du temps, c'est la première fois que je vois cela, et cela peut-être très instructif, merci pour ça . C'est possible aussi en fréquentiel je suppose ?

Hello, bien sûr. Il est possible de la visualiser en pourcentage de la fondamentale, en niveau relatif (toujours par rapport à la fondamentale) ou en niveau absolu.

La distorsion est récupérée via le domaine temporel. La déconvolution du sweep de Farina a cette propriété de projeter les harmoniques en temps négatif. L'interprétation en domaine temporel n'est pas forcément évidente, mais on peut par exemple visualiser une forte résonance de distorsion: un pic de distorsion en domaine fréquentiel pour une harmonique donnée peut se visualiser par une traine marquée en domaine temporel.
Mais l'intérêt principal pour moi était de visualiser la qualité de l'extraction des harmoniques: si les impulsions de distorsion sont noyées dans le bruit, il faut revoir la mesure, car l'estimation de leur spectre ne sera pas fiable...

À ce sujet je planche toujours sur des méthodes de filtrage du bruit pour éviter qu'il ne soit amplifié par la déconvolution... Le fenêtrage automatique a déjà considérablement amélioré les choses, mais on peut probablement faire mieux.

Arnwald a écrit : ↑24 juil. 2026, 08:58 J'ai mis à jour le backend de la bibliothèque audio afin de résoudre (espérons-le) des problèmes persistants sous Windows (cet OS est vraiment pénible lorsqu'il s'agit d'accès matériel et de jitter causé par le DPC). N'hésitez pas à me signaler si vous rencontrez des soucis.

Bonjour Arnaud,

Peux-tu expliciter de quoi il s'agit ?
Merci !

Pascal