Re: Disparition du MiniDSP NanoDigit 2x8

[JulBont]

On peut se référer au temps de latence.

[JulBont]

Qui est normalement durée d'impulsion / 2.

[Notepi]

mais il me semble que Notepi sur-échantillonne à donf

X4 avec JRiver, limité à 384 kHz par rePhase.
Ce qui donne :
44.1 ==> 176.4
48 ==> 192
88.2 ==> 352.8
96 ==> 384
176.4 ==> 352.8
192 ==> 384
Mon interface RME ADI-2 DAC FS accepte le 768 kHz.

Il n'y a pas de sujet avec mes mesures, je ne montre pas mes mesures...

La "touche mono numérique" fonctionne parfaitement avec 131072 taps. (1-2-2-9 dans Dôme acoustique)

Cordialement, Dominique.

[moonfly]

mais il me semble que Notepi sur-échantillonne à donf

X4 avec JRiver, limité à 384 kHz par rePhase.
Ce qui donne :
44.1 ==> 176.4
48 ==> 192
88.2 ==> 352.8
96 ==> 384
176.4 ==> 352.8
192 ==> 384
Mon interface RME ADI-2 DAC FS accepte le 768 kHz.

Il n'y a pas de sujet avec mes mesures, je ne montre pas mes mesures...

La "touche mono numérique" fonctionne parfaitement avec 131072 taps. (1-2-2-9 dans Dôme acoustique)

Cordialement, Dominique.

Bonjour,
vous pourriez aussi mettre la sortie de Windows en mono pour vos essais,
en fin de compte en écoute avec JRiver vous utilisez combien de taps et de FFT ?

[Notepi]

Avec un driver ASIO Madiface de la RME ADI-2 DAC FS, les basses couches de Windows sont shuntées.
Faire "la touche mono numérique" avec les fichiers de configuration des corrections par convolution, et changer dans JRiver en moins de 0.5 s et confortable et pertinent.
Quand les fichiers de configuration sont fait, on n'y touche plus !!!

En écoute normale je suis à 1 M de taps et FFT Length à 2 M, avec une optimization extensive.
En comparaison de deux réglages je suis à 131072 taps, FFT Length à 4 M, avec une optimization None.

Cordialement, Dominique

[jimbee]

3) 64 bits ou 32 bits ne change rien à la lecture sous REW qui travaille en 16 bits

Peut être un peu mieux que 16 bits s'il arrive à un plancher à -150 dB ?

[Vous devez être inscrit et connecté pour voir cette image]

[luiscrepy]

3) 64 bits ou 32 bits ne change rien à la lecture sous REW qui travaille en 16 bits

Peut être un peu mieux que 16 bits s'il arrive à un plancher à -150 dB ?

[Vous devez être inscrit et connecté pour voir cette image]

Tu as peut-être raison, je n'ai pas la même expertise que toi ; mais alors je veux bien que tu m'explique çà :
[Vous devez être inscrit et connecté pour voir cette image]

[JulBont]

Je pense que le système d'exploitation joue un rôle.

Par exemple, je n'ai pas le même decay selon que REW fonctionne sous Windows 7 ou sous Windows 10.

Jimbee, tu es en Windows 7 ? Et toi, Luis, en Windows 10 ?

Quelles sont vos versions de REW ?

[luiscrepy]

Et ce n'est pas un bug de la fenêtre des infos, car le fichier créé sous Rephase est sérieusement détérioré une fois arrivé dans REW.
Cela pourrait bien être une réduction de 32 à 16 bits ?

Et là, je ne crois pas que Windows puisse y être pour quoi que ce soit.

La preuve en images
[Vous devez être inscrit et connecté pour voir cette image]

[Vintage02]

Je pense que le système d'exploitation joue un rôle.

Par exemple, je n'ai pas le même decay selon que REW fonctionne sous Windows 7 ou sous Windows 10.

Jimbee, tu es en Windows 7 ? Et toi, Luis, en Windows 10 ?

Quelles sont vos versions de REW ?

Les gars les ressources nécessaires au fonctionnement d'un Windows 7 par rapport aux Windows 10 ne sont pas les mêmes !!... Un PC performant en Win7 deviens souvent une bouse en Win10 ... La quantité mémoire doit être plus importante en W10 ... la nature du disque dur va aussi énormément jouer sur les performances sur avec les dernières maj de Win10 ...

Vos "decay" ne seront pas les mêmes sur 2 PC identiques, l'un avec Win7 et l'autre avec Win10 ....

De plus on retrouve plus souvent des Win7 32 bits alors que Win101 a généralisé le 64 bits ... Certains processeurs sont moins à l'aise avec le 64 bits ...

[JulBont]

Luis,

Change ton format de sortie dans Rephase et passe le en 16 bits LPCM au lieu de 32 bits LPCM pour voir...

[luiscrepy]

Bon, j'explique autrement, soit vous êtes bouchés ou c'est moi qui ai perdu mes facultés de raisonnement...
voici deux convolutions créées avec Rephase, l'une en 32 bits et l'autre en 16 bits
j'importe les deux dans REW et elles sont presque identiques. REW les a bien réduites à 16 bits il me semble !

[Vous devez être inscrit et connecté pour voir cette image]


ou alors les lutins de windows les ont converties de 32 à 16 bits pendant les quelques secondes où elles ont été stockées sur le SSD. Mais çà, ça m'étonnerait car si je l'ouvre avec Audacity, on me dit bien que c'est du 32 ou du 16 bits.

PS: j'ai failli envoyer avant de te lire, mais je vois qu'on est sur la même longueur d'onde.

[JulBont]

J'ai l'impression que c'est REW qui procède à un "lissage" sans préavis de ta courbe si le format est supérieur à 16 bits.

L'écart est sans doute important en très basse fréquence, sans doute beaucoup moins en moyenne et haute fréquence à mon avis.

Pour en avoir le cœur net, il faut maniper dans tous les sens...

[luiscrepy]

J'ai l'impression que c'est REW qui procède à un "lissage" sans préavis de ta courbe si le format est supérieur à 16 bits.

L'écart est sans doute important en très basse fréquence, sans doute beaucoup moins en moyenne et haute fréquence à mon avis.

Pour en avoir le cœur net, il faut maniper dans tous les sens...

On est très loin d'un lissage !
on est très près d'un calcul systématique en 16 bits quelque soit la "richesse" du fichier d'origine. Tout au moins lorsque le fichier d'origine est une impulsion.

[JulBont]

Oui, c'était un euphémisme, c'est pour ça que j'ai mis le mot lissage entre ""...

[luiscrepy]

Après quelques essais supplémentaires, il semblerait qu'il y ait une opération qui réduise la résolution pour l'affichage de la courbe SPL, ça ressemble à ce que donnerait une conversion en 16 bits, mais c'est peut-être autre chose. Rephase est capable d'enregistrer la réponse en amplitude de son calcul si on l'enregistre au format .frd La résolution de 32bits est conservée pour les infos d'amplitude. En l'important dans REW, on peut alors faire un simple affichage (et non un calcul de la courbe de réponse en fonction de l'impulsion) et on retrouve alors à l'écran la vraie courbe SPL 32bits Rephase
Cela n'est pas vrai pour les autres fenêtres car le gain procuré par le 32 bits est visible
L'exercice se fait sur un brickwall à 20 Hz, sur des filtres plus ordinaires, cela ne se verrait probablement pas.

on commence par les courbes SPL, sachant que la courbe bleue est celle qui devrait aussi s'afficher pour la rouge, la verte devrait se trouver entre les deux, là où Rephase la plaçait. La marron est juste, comme dans Rephase.
[Vous devez être inscrit et connecté pour voir cette image]

La résolution 16 bits est visible en zoomant fort,
[Vous devez être inscrit et connecté pour voir cette image]

[jimbee]

Bon, j'explique autrement, soit vous êtes bouchés ou c'est moi qui ai perdu mes facultés de raisonnement...
voici deux convolutions créées avec Rephase, l'une en 32 bits et l'autre en 16 bits
j'importe les deux dans REW et elles sont presque identiques. REW les a bien réduites à 16 bits il me semble !

Bonjour,

En voici trois où se voit bien le recul du plancher en fonction de la profondeur en bits:

[Vous devez être inscrit et connecté pour voir cette image]

[JulBont]

On manipule des multiples de puissance de 2 sur une échelle de lecture logarithmique, ce n'est pas très intuitif alors merci pour la démo...

Le problème de Luis est autre, il n'arrive pas à afficher correctement une impulse importée supérieure à 16 bits sur le graphe SPL de REW.

[luiscrepy]

Merci Jimbee, ta démonstration m'a incité à aller plus loin, car on ne peut effectivement pas parler de conversion à 16 bits dans REW même pour l'affichage du SPL. Je ne comprends alors toujours pas l'information "16 bits" délivrée par REW en bas à gauche. Je ne comprends pas non plus pourquoi la différence est aussi énorme entre REW et Rephase pour l'affichage de la courbe d'amplitude.
[Vous devez être inscrit et connecté pour voir cette image]

[luiscrepy]

Petite question qui me vient à l'esprit. Si je parle de 128k octets, cela veut bien dire qu'il y en a 131072. Dois-je dire 128k taps, 131k taps ou 131072 taps ? Si je mets une convolution de 758 taps dans mon OpenDRC, çà marche très bien. Nulle obligation donc de mettre une puissance de 2. çà me fait tout drôle d'écrire 131k taps comme j'aurais écrit 80k€.

[jimbee]

 Je ne comprends alors toujours pas l'information "16 bits" délivrée par REW en bas à gauche.  

Elle ne concerne que la carte son,16 bits en Java et 24 bits au mieux en Asio.

Si je parle de 128k octets, cela veut bien dire qu'il y en a 131072. Dois-je dire 128k taps, 131k taps ou 131072 taps ?

En 16 bits il y aura déjà 2 octets par taps, et 4 octets en 32 bits...

[luiscrepy]

 Je ne comprends alors toujours pas l'information "16 bits" délivrée par REW en bas à gauche.  

Elle ne concerne que la carte son,16 bits en Java et 24 bits au mieux en Asio.

Si je parle de 128k octets, cela veut bien dire qu'il y en a 131072. Dois-je dire 128k taps, 131k taps ou 131072 taps ?

En 16 bits il y aura déjà 2 octets par taps, et 4 octets en 32 bits...

Merci pour ces précisions.
Cordialement,
Luis

[moonfly]

Bonjour,

il y a ça qui pourrait être intéressant en bricolant un peu

[Vous devez être inscrit et connecté pour voir ce lien]

[Vous devez être inscrit et connecté pour voir cette image]

[moonfly]

Bonjour,

il y a peut être ça qui pourrait aller en remplacement:

[Vous devez être inscrit et connecté pour voir ce lien]

[Vous devez être inscrit et connecté pour voir cette image]

[etmo]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

[Notepi]

Bonjour

Je voudrai revenir sur cette courbe réalisée par etmo, avec mes paramètres de filtrage.

[Vous devez être inscrit et connecté pour voir cette image]

Dans mes expériences passées, plus j'augmentais le nombre de taps, meilleure était la qualité dans les aigus.
Ceux qui ont utilisés rePhase le savent, quand on augmente le nombre de taps, la valeur de FFT length augmente aussi.
J'avais poussé l'idée au maximum avec 1 M de taps et FFT length à 2 M, optimization extensive.

Les courbes de etmo m'ont fait réfléchir, je m'étais focalisé sur les aigus, n'ai-je pas laissé passé quelque chose sur le grave ?
J'ai recommencé une série de tests à l'écoute avec 131072, 65536, 32768 et 16384 taps, mais en gardant FFT length à 4 M, optimization None.
J'ai retenu 32768 taps pour le grave à l'écoute, et je n'ai rien perdu dans les aigus : La qualité dans les aigus c'est FFT Length, ce n'est pas le nombre de taps.

Je ne vous cache pas que je suis bien content d'avoir encore amélioré mon écoute.
Mais je note une perte de 5 ou 6 Hz dans le grave avec 32678 taps.
Que feriez vous ?
- Essayer d'autre valeurs entre 32768 et 65536 taps ? Je restais sur des puissances de 2.
- Essayer une optimization extensive ? (je vais faire l'essai très vite).
- Modifier la coupure à -3 dB du passe-haut pour rattraper ?

Merci pour votre aide.

Cordialement, Dominique

[moonfly]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

Bonjour,
tu utilises  Windows, Linux, Apple ?

[etmo]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

Bonjour,
tu utilises  Windows, Linux, Apple ?

Le but étant d'éviter l'utilisation d'un ordinateur. Sinon effectivement cela pourrait fonctionner.

[moonfly]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

Bonjour,
tu utilises  Windows, Linux, Apple ?

Le but étant d'éviter l'utilisation d'un ordinateur. Sinon effectivement cela pourrait fonctionner.

Bonjour,
tu écoutes de la musique avec quoi alors ?

[etmo]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

Bonjour,
tu utilises  Windows, Linux, Apple ?

Le but étant d'éviter l'utilisation d'un ordinateur. Sinon effectivement cela pourrait fonctionner.

Bonjour,
tu écoutes de la musique avec quoi alors ?

Musique et film :
source PC et/ou Samsung Frame 55
Pour la partie audio voir le schéma joint.
et la présentation suivante :

[Vous devez être inscrit et connecté pour voir ce lien]

Mon problème n'est vraiment pas urgent mais je pense surtout à la maintenance et la réparation.
Mon précédent système à duree 25 ans sans modification fondamentale. Celui ci plus évolué devrait pouvoir en faire au moins autant au niveau usage.

Fichiers joints

Schéma_Installation.PDF Vous n'avez pas la permission de télécharger les fichiers joints.(115 Ko) Téléchargé 6 fois

[jimbee]

je note une perte de 5 ou 6 Hz dans le grave avec 32678 taps.

32678 taps, mais avec quelle Fs?
à résolution fréquentielle constante, nTaps est relatif à la fréquence d'échantillonnage,
32 kTaps à 48 kHz = 128 kTaps à 192 kHz

[Notepi]

Je fais un upsampling x4 du signal qui arrive.
44.1 ==> 176.4 kHz
48 ==> 192 kHz
88.2 ==> 352.8 kHz
96 ==> 384 kHz.

Il faudrait utiliser un nombres de taps différents pour chacun des 4 cas ?
J'ai validé 32 ktaps à 176.4 Hz.

Cordialement, Dominique

[jimbee]

Il faudrait utiliser un nombres de taps différents pour chacun des 4 cas ?
J'ai validé 32 ktaps à 176.4 Hz.

Cordialement, Dominique

Pour une même résolution / définition nTaps/Fs = constante,  = temps (s)
32 ktaps à 176.4 Hz fait 8 ktaps à 44,1 kHz ce qui n'est pas énorme,
l'optimisation + type de fenêtre* dans rePhase peut prendre alors sens aux plus basses fréquences
pour le passe haut. ( optimisation moderate + hann pour ph butt5 à 31 Hz / 8ktaps/ 44,1 kHz)

[moonfly]

Il manque le filtrage. Pour l'instant le seul qui pourrait le remplacer est un DDRC 88D

Mais le prix pique un peu surtout quand il faut trois filtres pour 24 canaux.

Bonjour,
tu utilises  Windows, Linux, Apple ?

Le but étant d'éviter l'utilisation d'un ordinateur. Sinon effectivement cela pourrait fonctionner.

Bonjour,
tu écoutes de la musique avec quoi alors ?

Musique et film :
source PC et/ou Samsung Frame 55
Pour la partie audio voir le schéma joint.
et la présentation suivante :

[Vous devez être inscrit et connecté pour voir ce lien]

Mon problème n'est vraiment pas urgent mais je pense surtout à la maintenance et la réparation.
Mon précédent système à duree 25 ans sans modification fondamentale. Celui ci plus évolué devrait pouvoir en faire au moins autant au niveau usage.

Bonjour,
perso comme j'aime bien bricoler j'aurais fais un peu plus simple de manière à pouvoir modifier, essayer des trucs différents etc...et dans quelques années il y aura du matos, des logiciels encore plus performants pour encore peut être pouvoir améliorer la qualité d'écoute.

[Notepi]

Jimbee, j'ai bien compris le principe que je vais appliquer.
Je vais commencer par comparer, sur une source à 44.1 kHz upsamplée à 176.4 Hz :
32768 taps, FFT length = 4 M, optimisation none
avec
32768 taps, FFT length = 2 M, optimisation extensive.
Dans le 2eme cas, la réponse corrigée suit bien la réponse cible.
En fonction des résultats, j'aviserai sur ce qu'il faut faire.

Peut-on utiliser un nombre de taps qui ne soit pas une puissance de 2 ?

Cordialement, Dominique