Windows : JPlay FEMTO & Audiophile Optimizer & Fidelizer Pro & Process Lasso

[zaurux]

Pour MinorityClean, j'en profite pour partager une excellente tentative d'explication et de vulgarisation de StreamFidelity, forumeur allemand mais surtout concepteur de PC audiophile (fisaudio / griggaudio.de).
L'explication est fondée sur le peu d'élément partagé par le développeur de MC (et de BugHead). Il n'y a pas d'éléments objectif de vérification. Quel est le principe.. mais dans tous les cas, il y a bien un impact audio.

StreamFidelity a écrit :...
Avant d'en venir à la question proprement dite, je voudrais faire une petite excusion sur les horloges. Prenons l'exemple d'une horloge OCXO (Oven Controlled Crystal Oscillator) qui, selon Wikipedia, est décrite comme suit : Un oscillateur à cristal logé dans une chambre chauffée et à température contrôlée. Les cristaux oscillants utilisés dans les oscillateurs à quartz sont soumis à une dépendance thermique faible, mais pour des applications précises, significative de la fréquence du circuit oscillant, ce que l'on appelle aussi la dérive thermique. En contrôlant la température du cristal et du circuit oscillant à une valeur supérieure à la température ambiante, la fréquence du circuit oscillant peut être stabilisée et ainsi une précision plus élevée peut être obtenue que sans chauffage.

Un oscillateur à quartz doit donc d'abord se stabiliser jusqu'à ce que la température correcte soit atteinte. Nous avons aussi l'installation avec un CPU. Avec le CPU, la fréquence de l'horloge est importante. C'est la vitesse à laquelle l'unité centrale fonctionne. Il est généralement mesuré en gigahertz (GHz) - des milliards de cycles par seconde. Une unité centrale de 2,4 GHz fonctionne donc avec 2,4 milliards de cycles par seconde. Il en va de même pour la mémoire principale.

Cela nous amène à la façon "présumée" dont MinorityClean fonctionne : "Présumée" parce qu'il n'y a pas de recherche scientifique indépendante, mais seulement des preuves éparses de la part du développeur. Celui-ci dit que MinorityClean agit comme un stabilisateur de bit. L'état interne de l'unité centrale est remplacé par l'état interne de la puce mémoire au lieu de la norme d'alimentation de la carte mère. Le développeur écrit que le PC est basé sur la lecture et l'écriture de la mémoire. La fiabilité est améliorée lorsque l'état interne de l'unité centrale correspond à la mémoire. Il recommande d'utiliser des CPU avec un cache de CPU élevé (L3).

Dans une correction de bogue pour les versions MC73-77, le développeur est entré dans les détails. Au lieu de stabiliser les bits à 16 secondes / 16 secondes, il les a écrits à 3 secondes / 16 secondes. Je suppose que les différentes secondes se réfèrent à la mémoire et au cœur du processeur respectif. Les 16 secondes représentent le temps de référence. C'est là que chaque noyau est traversé. Pour un processeur i9-9900K, il s'agit de 8 cœurs et 16 threads (avec hyper-threading activé). Le développeur donne le calcul suivant :

8C16T CPU
16 x 16 = 256 sec (+ 40sec)
réglé après 6 minutes

MinorityClean a donc besoin d'un temps d'initialisation dépendant du CPU.

Sur la page d'accueil de MinorityClean, le développeur lui-même parle d'une durée de rodage de 4 à 8 heures. Pourquoi si longtemps ? Je suppose que c'est à cause du matériel. Le processeur et la mémoire oscillent tous deux dans la gamme des GHz. Il faut juste du temps pour qu'il soit stable. Mais je n'ai pas à attendre aussi longtemps chaque fois que j'allume le PC audio. Le long temps de rodage fait référence à ma connaissance (et à ce que mes oreilles me disent) de l'utilisation d'une nouvelle version MC.

Traduit avec http://www.DeepL.com/Translator (version gratuite)

https://www.aktives-hoeren.de/viewtopic.php?f=30&t=11148&sid=c6c4af89ddf4701356ccef01c57716f9&start=120