Help convolution avec minimserver

[Nard]

Citation :Seul truc qui change, comme le dis Simon, la convolution fait baisser le niveau sonore (pour éviter le clipping), et donc il faut compenser en augmentant le volume de l'ampli, mais rien de méchant.

Il existe un paramètre de Minimserver à passer avec la chaîne de commande de la convolution qui permet de compenser (partiellement) cet affaiblissement du niveau.

-lavfi afir=gtype=gn

Tu peux aussi moduler le niveau global du filtre avec Rephase

[audyart]

(05-02-2020, 11:22 PM)Nard a écrit :

Citation :Seul truc qui change, comme le dis Simon, la convolution fait baisser le niveau sonore (pour éviter le clipping), et donc il faut compenser en augmentant le volume de l'ampli, mais rien de méchant.

Il existe un paramètre de Minimserver à passer avec la chaîne de commande de la convolution qui permet de compenser (partiellement) cet affaiblissement du niveau.

-lavfi afir=gtype=gn

Tu peux aussi moduler le niveau global du filtre avec Rephase

 Pour éviter le clipping, il faut accepter la nécessité d'une marge de 4dB - environ - avant convolution,
 à ne pas compenser dans le chainage numérique.

[phile]

Hello,
(la convolution avec Minim est peut-etre expliquée qqpart sur le forum mais je n'ai pas encore trouvé, d'où ce post pour info)

D'abord, un truc que je n'ai pas pigé dans le user manual de Minim et lu sur le forum Minim : il faudrait avoir un fichier de convolution pour chq sample rate : 44.1/48/88/96/176/192.
Pour ma part, vu que je voulais faire un 1er test, j'ai sorti de rePhase un unique fichier de convolution en 24/192. Et finalement il s'avère que la convolution est bien effective qqsoit le sample rate, avec cet unique fichier en 24/192.

donc voici pour info le "truc" pour les nuls comme moi  (car j'ai pataugé un peu...) pour intégrer un fichier de convolution dans Minim
1. ffmpeg upgrade.
dans stream.converter, j'avais la version basique de ffmpeg, noté simplement "ffmpeg".
Problème : dans stream.options, quand je mettais le lien vers le fichier de convolution .wav  : il se mettait en rouge disant qu'il ne trouvait pas le dossier...
Sur ce, j'ai trouvé une version plus complète (je suppose car dixit quelques fofo j'ai cru comprendre que la version ffmpeg "par défaut" est "très basique") => ici : https://synocommunity.com/package/ffmpeg
Sur cette page, donc en haut on a la dernière version => choisir et télécharger la version correspondant au processeur de son Syno (notée "6.1 x86_64" dans mon cas avec un DS415+).
On installe ce fichier .spk via installation manuelle sur le Syno (je peux expliquer si besoin)

2. il ne reste plus qu'à remplir les lignes stream.converter/options et transcode (optionnel bien sûr).
- dans stream.converter => /var/packages/ffmpeg/target/bin/ffmpeg
  là j'ai un peu ramé pour savoir où le ffmpeg upgradé était planqué...
- stream.options => convOut=-i /volume2/Data/Convol/impulse12.wav -lavfi afir=gtype=gn
  Effectivement Nard, il faut utiliser la fonction de ffmpeg "afir=gtype=gn". J'ai testé une autre fonction pour remonter le gain mais on a du clipping dès qu'on essaie de remonter le gain... mauvaise idée... donc inutile de chercher plus loin.
  "/volume2/Data/Convol/impulse12.wav" est juste l'adresse (dans mon cas) du fichier de convolution placé sur le Syno (sur un dossier différent du dossier utilisé pour stocker les fichiers de musique et scanné par Minim)
- stream.transcode > j'y ai mis => flac:wav24;192,dsf:wav24;192,aac:wav24;192,mp4:wav24;192
  car je transcode tout en wav24/192, sauf les mp3 (pour me laisser la possibilité de faire de l'avance rapide sur ce type de fichier, pb spécifique à l'interface UPNP de mon ampli je crois)

Points + =>
- ca marche nickel.
- un seul fichier de convolution suffit
- le transcoding marche comme d'habitude, en fonction de ce qui est noté sur la ligne stream.transcode
- coût limité au micro UMIK.
- c'est une solution ultrasimple et qui fait le job (le NAS suffit : il stocke et fait la convol avant envoi). Pas besoin d'utiliser de softs tiers (JRiver ou autre sur un NUC/ordi en sus du NAS), mais bon ca c'est fonction des besoins de chacun, pour ma part Minim seul & Hifi-Cast sur tablette android me suffit)
- ca pompe 0% environ de CPU supplémentaire au NAS (bon point, je n'y aurais pas cru à priori)

Bref voilà donc.
J'avais zappé que la convolution pouvait etre intégré à Minim...
ca marche nickel, c'est simple et efficace et gratos.
Quelques jours d'usage pour en voir les limites s'il y en a, mais ca semble faire le job.
Cdt

[audyart]

(05-03-2020, 10:15 PM)phile a écrit : Pour ma part, vu que je voulais faire un 1er test, j'ai sorti de rePhase un unique fichier de convolution en 24/192. Et finalement il s'avère que la convolution est bien effective qqsoit le sample rate, avec cet unique fichier en 24/192.

Bonjour,

 Il est préférable de générer le fichier en 32 bits, les convolvers font le calcul avec cette résolution, au minimum.
 Comme la profondeur d'information véhiculée par une impulsion n'est pas homogène avec la fréquence,
diminuant fortement dans le grave, la résolution effective équivalente est inférieure, grosso modo il faut des
impulsions en 32 bits pour traiter des flux en 24 bits, impulsions en 24 bits pour des flux en 16 bits.

crd.

[phile]

Merci pour ce rappel !
Etant allé un peu vite semble-t-il, je vais refaire tests (et relire le tuto de pda0 & Bear).
Cdt

[Nard]

Concernant le nombre de taps, il me semble qu'il en faut 65536 pour obtenir une vraie résolution de 16 bit, 131072 pour 17 bit, 262144 pour 18 bit, 524288 pour 19 et 1048576 pour 20 bit.

Soit 2^n taps pour une résolution de n bit.

Si quelqu'un pouvait confirmer ?

Bien entendu, cela augmente la charge CPU (faiblement) et la latence (durée de lecture de la moitié du fichier de convolution, dépendant de sa longueur et de la fréquence d'échantillonnage du flux audio) il y a donc éventuellement un compromis à trouver.

Toutefois, la latence peut être annulée par une lecture anticipée, je pourrai indiquer les instructions à donner à ffmpeg pour cela une fois de retour chez moi, ça ne devrait plus tarder

[audyart]

(05-04-2020, 01:38 PM)Nard a écrit : Concernant le nombre de taps, il me semble qu'il en faut 65536 pour obtenir une vraie résolution de 16 bit, 131072 pour 17 bit, 262144 pour 18 bit, 524288 pour 19 et 1048576 pour 20 bit.

Soit 2^n taps pour une résolution de n bit.

Si quelqu'un pouvait confirmer ?

 Non, la longueur (n)-> durée) utile est fonction image de la longueur d'onde (->période)
 pour une efficacité de correction donnée, à Fs constante.
 Cad, s'il faut 2000 taps utiles à une correction - filtrage - eq- dans la zone des  1kHz, il en faut
 20000 pour la même efficacité si la correction est vers 100 Hz.
Si la Fs est double -> x2 taps.

[Nard]

Bonjour Audyart, j'ai trouvé l'information suivante, plus explicite, qui rejoint ce que tu indiques :

The number of taps or filter length defines the frequency resolution of the FIR filter. The resolution is samplerate/taps. So a 64k filter @ 44.1 kHz samplerate gives a frequency resolution of 0.6729 Hz. A 128k filter thus gives 0.336 Hz frequency resolution. The high resolution is definitely overkill for the mid to high frequency range but good for the low frequency range.

Toutefois, et sans remettre en cause ces infos, n'y a-t-il pas un lien direct entre résolution en Hz et précision de la quantification ?

[moonfly]

(05-04-2020, 01:38 PM)Nard a écrit : Concernant le nombre de taps, il me semble qu'il en faut 65536 pour obtenir une vraie résolution de 16 bit, 131072 pour 17 bit, 262144 pour 18 bit, 524288 pour 19 et 1048576 pour 20 bit.

Soit 2^n taps pour une résolution de n bit.

Si quelqu'un pouvait confirmer ?

Bien entendu, cela augmente la charge CPU (faiblement) et la latence (durée de lecture de la moitié du fichier de convolution, dépendant de sa longueur et de la fréquence d'échantillonnage du flux audio) il y a donc éventuellement un compromis à trouver.

Toutefois, la latence peut être annulée par une lecture anticipée, je pourrai indiquer les instructions à donner à ffmpeg pour cela une fois de retour chez moi, ça ne devrait plus tarder

Bonjour,
perso sur mes correction avec Rephase je suis à 65536

[audyart]

(05-04-2020, 02:29 PM)Nard a écrit : Toutefois, et sans remettre en cause ces infos, n'y a-t-il pas un lien direct entre résolution en Hz et précision de la quantification ?

 Je ne pense pas qu'il y ait un lien.
 Avec une résolution de 1,5 Hz (65536 taps à 96k) c'est normalement tranquille,
 sauf égalisations pointues dans l’extrême grave.