Help convolution avec minimserver

[Nard]

1,5 Hz, c'est un quart de ton à 50 Hz il me semble puisque
50 Hz x 2^(1/24)=51,46 Hz, ce qui veut dire que c'est audiblement faux ! (Il y a 24 quarts de ton dans une octave.)

Par ailleurs, et peut-être je m'avance beaucoup, mais il me semble que toute opération de reconstruction du signal dans un dac repose sur la fonction sinc=(sin x)/x, dont la valeur tend vers 1/2^n de part et d'autre d'un échantillon, soit 1/2^15 avec 65536 taps, soit une résolution de 15 bit seulement...

[audyart]

(05-04-2020, 05:47 PM)Nard a écrit : 1,5 Hz, c'est un quart de ton à 50 Hz il me semble puisque
50 Hz x 2^(1/24)=51,46 Hz, ce qui veut dire que c'est audiblement faux !

Par ailleurs, et peut-être je m'avance beaucoup, mais il me semble que toute opération de reconstruction du signal dans un dac repose sur la fonction sinc=(sin x)/x, dont la valeur tend vers 1/2^n de part et d'autre d'un échantillon, soit 1/2^15 avec 65536 taps, soit une résolution de 15 bit seulement...

 C'est pas un résolution en fréquence au sens désaccordé  mais la "finesse" avec laquelle une correction peut se faire,
en (très) gros, à la résolution de 1,5 Hz la correction s'y ferait là avec une résolution ou une finesse max d'une octave, gasp,
au 1:10ème d'octave à 15 Hz, au 1:20ème d'oct à 30 Hz  ect  (équivalent à un smoothing en mesure )
Pour le Dac tu dois avoir raison, mais c'est pas le problème, là on fait le produit de convolution de signaux
ayant chacun au départ leur profondeur en bits, on reconstruit pas d'analogique,
le nTaps est une valeur indépendante des bits,
tu peux avoir 65536 taps en 16 bits ou en 24, 32 et même 64 bits.

[Nard]

Ah, Ok, c'est donc la précision de la correction ! Compris.

Pour ce qui est de l'influence sur la quantification par contre, j'entends aussi tes explications, et peut-être me suis-je monté la tête tout seul, il n'empêche que ça ne correspond pas aux expériences auditives subjectives que j'ai pu faire en passant par exemple de 32000 à un million de taps sur des flux high res. Il m'a semblé qu'augmenter les taps améliorait la qualité sonore jusqu'à un optimum, ce que j'imputais à une précision accrue sur la quantification et donc le niveau de bruit ou de ripple, avant de la dégrader légèrement, ce que j'imputais à l'accroissement de la charge processeur.

Un grand merci pour tes explications en tout cas, qui permettent déjà d'y voir beaucoup plus clair

[audyart]

Le nTaps n'est pas la quantité de valeurs décrites par le mot binaire, c'est la durée
quand l'impulsion est en wav, soit son nombre d'échantillons relativement à Fs.
Quand chaque échantillon est en 32 bits,
ça doit donner un plancher de bruit vers -150dB, et vers -300dB en 64 bits.

[Nard]

Bien sûr Audyart, je ne fondais pas là-dessus mon raisonnement mais sur le fait que plus le fichier de convolution contient d'échantillons, plus leur valeur tend vers zéro de part et d'autre du pic d'impulsion

[Nard]

Pour étayer cette idée, j'ai fait l'expérience suivante en faisant générer par Rephase deux impulsions de convolution au format 32/64 bit float lines texte que j'ai ensuite chargés sous Open Office Calc pour les étudier.
(L'avantage du format texte est que la valeur numérique des échantillons est lisible en format décimal.)

Les deux impulsions partagent ces mêmes caractéristiques

• FFT de 131 072 échantillons
  
• Impulsion centrée "closest perfect"
  
• Fenêtre Blackman-Harris
  
• Optimisation extensive jusqu'à -120dB
  
• Taux d'échantillonnage de 48 000 Hz
  

La première impulsion fait 32 768 taps et la deuxième 65 536, soit 682,7 et 1 365 ms respectivement.

Ces impulsions sont optimisées à -120dB soit 20 bit soit 10^-6 ou un millionième en niveau.

J'ai donc recherché à quel échantillon on atteignait un premier niveau de -0,5 x 10^-6 ainsi que le dernier échantillon où l'on parvenait en dessus de ce niveau (tendant vers zéro).

Les valeurs sont les suivantes :
Impulsion 32k, échantillons 11 285 et 18 880
Impulsion 64k, échantillons 27 534 et 35 470

La durée de l'impulsion égale ou supérieure à -120dB est donc 7 596 échantillons, soit 158,3 ms dans le premier cas et de 7 937 échantillons, soit 165,4 ms dans le deuxième cas, soit 341 échantillons ou 7,1 ms d'écart.

Sur ces résultats, la question de savoir si la longueur du fichier de convolution ne joue que sur la précision de la correction ou si elle concerne également la précision de la quantification, reste ouverte IMHO

[moonfly]

(05-05-2020, 03:26 PM)Nard a écrit : Pour étayer cette idée, j'ai fait l'expérience suivante en faisant générer par Rephase deux impulsions de convolution au format 32/64 bit float lines texte que j'ai ensuite chargés sous Open Office Calc pour les étudier.
(L'avantage du format texte est que la valeur numérique des échantillons est lisible en format décimal.)

Les deux impulsions partagent ces mêmes caractéristiques

• FFT de 131 072 échantillons
  
• Fenêtre Blackman-Harris
  
• Optimisation extensive jusqu'à -120dB
  
• Taux d'échantillonnage de 48 000 Hz
  

La première impulsion fait 32 768 taps et la deuxième 65 536, soit 682,7 et 1 365 ms respectivement.

Ces impulsions sont optimisées à -120dB soit 20 bit soit 10^-6 ou un millionième en niveau.

J'ai donc recherché à quel échantillon on atteignait un premier niveau de -0,5 x 10^-6 ainsi que le dernier échantillon où l'on parvenait en dessus de ce niveau (tendant vers zéro).

Les valeurs sont les suivantes :
Impulsion 32k, échantillons 11 285 et 18 880
Impulsion 64k, échantillons 27 534 et 35 470

La durée de l'impulsion égale ou supérieure à -120dB est donc 7 596 échantillons, soit 158,3 ms dans le premier cas et de 7 937 échantillons, soit 165,4 ms dans le deuxième cas, soit 7,1 ms d'écart.

Sur ces résultats, la question de savoir si la longueur du fichier de convolution ne joue que sur la précision de la correction ou si elle concerne également la précision de la quantification, reste ouverte

Bonjour,
pourquoi optimisation extensive to -120 dB et pas none?

[Nard]

None = pas d'optimisation
Extensive -120dB = Étendue jusqu'à -120dB

Selon le site Rephase "optional iterative optimization for the best result with a given number of taps".

N'oublions pas que pour être mathématiquement parfaite, une convolution devrait être effectuée avec un fichier d'impulsion égal à la longueur totale du flux convolué. Comme cela serait informatiquement trop lourd, on fait un fenêtrage dont le type varie selon la forme de la fenêtre, ici Blackman-Harris. Ce fenêtrage est sans doute optimisé de façon itérative selon la doc Rephase pour assurer la plus grande précision au niveau demandé, ici -120 dB soit le vingtième bit de poids faible. Bien sûr, le temps de génération du fichier de convolution en est allongé

[phile]

Merci à vous 2 Nard & audyart pour vos échanges d'experts 
Cela m'a permis de me rendre compte que j'avais fait une erreur en jouant avec rePhase AVANT d'avoir relu le mode d'emploi de pda0 & Bear 
Erreur (que je vais effacer après postage de ce post) dans mon post plus haut (http://forum-hifi.fr/thread-11428-post-3...#pid355784) où je disais que j'avais un gap important si le fichier de convolution était trop "gros".
Pb = j'avais généré un fichier en stereo !
Le tuto de pda0&Bear spécifie bien => mono => j'ai donc ressorti de rePhase un fichier de convol conforme au tuto : 
rate = 384kHz
format = 64 bits IEEE mono (.wav)
avec taps idem précédemment = 131072

=> et là : gapless !
Enfin quasi car il reste un micro-gap (pas génant) entre la 1ère et la 2e piste d'une playlist/album (pas compris pq...), mais entre les pistes suivantes c'est gapless 

A noter que c'est gapless, 
=> avec un fichier assez gros (1Mo), un résolution assez grosse, et un CPU du Syno sur cette tâche à 1.2%
=> alors que précédemment, 
      - avec le mauvais fichier de convol, j'avais des gaps avec fichier de 1Mo & CPU à 1.2%
      - et qu'il avait fallu réduire la résolution du fichier (et sa taille à 385ko), et obtenu un CPU négligeable sur cette tâche pour obtenir des micro-gaps "peu chiant".
Pas trop compris ce micmac et l'absence de lien (je ne suis pas expert en ce domaine) entre CPU/taille de fichier/gap/pas gap... 

A noter enfin que le rendu avec ce fichier (64bits-384kHz) est plus fin & délicat qu'avec le précédent fichier (24bit-192kHz).
Ce qui confirme ce que tu disais audyart dans ce post (merci pr ce post) => http://forum-hifi.fr/thread-11428-post-3...#pid355984 ; post qui m'avais fait penser que je m'étais sans doute planté qqpart.. 
Cdt

[moonfly]

(05-05-2020, 03:49 PM)Nard a écrit : None = pas d'optimisation
Extensive -120dB = Étendue jusqu'à -120dB

Selon le site Rephase "optional iterative optimization for the best result with a given number of taps".

N'oublions pas que pour être mathématiquement parfaite, une convolution devrait être effectuée avec un fichier d'impulsion égal à la longueur totale du flux convolué. Comme cela serait informatiquement trop lourd, on fait un fenêtrage dont le type varie selon la forme de la fenêtre, ici Blackman-Harris. Ce fenêtrage est sans doute optimisé de façon itérative selon la doc Rephase pour assurer la plus grande précision au niveau demandé, ici -120 dB soit le vingtième bit de poids faible. Bien sûr, le temps de génération du fichier de convolution en est allongé

Bonjour,
j'avais posé deux ou trois questions à Mr Thomas Drugeon il y a déjà quelques temps et voici ce qu'il m'avait répondu  concernant l'optimisation je cite:

"En ce qui concerne l'optimisation, c'est là aussi à réserver aux cas ou la FIR est trop courte et où la courbe de réponse est trop éloignée de la courbe cible : l'optimisation va tenter de rapprocher la courbe de magnitude de la cible, parfois (souvent) au détriment de celle de phase, et on perd donc potentiellement la relation magnitude/phase (on peut par exemple chopper du pre ringing sur une correction purement en phase minimale).
Comme la magnitude est plus importante que la phase dans le rendu c'est un compromis valable quand on est un peu court en taps, mais pas si on en a suffisamment.
En outre la valeur en dB de l'optimisation est utilisée pour déterminer quand le processus itératif doit s'arrêter (ie quand il commence à empirer les choses plutôt que de les améliorer) en considérant la réponse dans les stopband jusqu'à -X dB. Sur une correction qui n'a pas de stopband (genre EQ ou correction de phase pure) ce paramètre n'aura aucun effet.

Si on a suffisamment de taps (genre 1sec de FIR) le mieux à mon avis est de se passer d'optimisation (c'est pour cela qu'elle est décochée par défaut depuis la version 1.2.0) et de prendre un windowing relativement doux, pour la paix de l'esprit..."