La 1ere FFT montre le signal souce (directement à partir du WAV).
La 2e FFT montre le signal source encodé en mpeg1 Layer II. Le but de la manip est de voir ce que ce signal va devenir quand on va le passer à la moulinette de DirectSound ou Reclock @ 75 et 72 Hz.
La 3e FFT montre ce qu'il se passe lorsqu'on joue le fichier mpg sous ZP avec DirectSound comme renderer. J'avoue avoir été surpris ! C'est d'autant plus surprenant que durant toute la procédure de test, on ne sort pas du domaine digital.
J'ai refait la même manip avec foodBar2000. Résultat identique. Ne sachant pas trop qui incriminer (la méthode d'enregistrement, le mixeur de la 1010, Cool Edit, DirectX, WinME...) j'ai alors recommencé en mettant ASIO en renderer sous fooBar2000 et ...
suspens
... on obtient la 4e FFT qui est exactement comme la FFT n°2
Donc pas besoin de vous faire un dessin... Seul l'ASIO peut prétendre à un comportement irréprochable ds le domaine digital.
Je précise au passage que les FFT n'ont pas été calculées à partir de la même fenêtre temporelle car les enregistrements ont tous démarrés avec un retard différent (le tps de cliquer). Donc impossible pour moi d'avoir une référence temporelle commune entre tous les fichiers. Néanmoins, le fait de calculer la FFT sur 65536 samples (soit plus d'une seconde) filtre bien les choses.
Reste que les harmoniques et le bruit récupéré ds les aigus avec DirectSound reste quand même très inférieurs à la dynamique utile d'une salle d'écoute :
fond sonore : classiquement entre 35 et 45 dB SPL dans un environnement très calme.
Si on calibre -20 dBFS pour être rendu à 85 dB SPL, le signal max donnera 85+20 = 105 dB SPL (ce qui est déjà très fort)
La différence entre 105 dB et le fond sonore donne alors une dynamique utile pour la salle de 60 à 70 dB. Donc, avec un signal 16 bits (dynamique de 96 dB), tous ce qui est en dessous de -60 à -70 dBFS ne sera pas entendu car noyé dans le fond sonore.
En pratique, calibrer -20 dBFS à 85 dB SPL peut donner une écoute fatigante à la longue car trop forte. Et, si vous avez la main plus légère, vous allez encore réduire la dynamique utile. Donc ces considération relativisent bcp le niveau de bruit obtenu dont la fréquence max vers 3000 Hz plafonne à -102 dBFS...
Néanmoins, on a quand même le droit de se poser qq questions sur les opérations réalisées en sourdine par DirectSound et/ou le driver de la carte sur les LSB du signal... Le signal encodé (FFT n°2) est de -20 dB d'après Cool Edit. Le signal produit par DirectSound est de -25.5 dB. Soit un abaissement de niveau de 5.5 dB. Alors là, va falloir m'expliquer
Ce n'est même pas une division par deux qui correspond à 6 dB !!! Si on abaisse de 5.5 dB le signal de la deuxième FFT sous Cool Edit (sans faire de dithering), on récupère une quinzaine de raies supplémentaires mais pas tout le bruit de fond dans les hautes fréquences de la FFT n°3. J'aimerais donc bien avoir des infos sur les post-traitements réalisés par DirectSound...
Pour rappel, une division entière par 2 correspond à un décalage de ts les bits d'un cran vers la droite. On perd donc le bit de poid faible (ou LSB en anglais). Tout traitement sur les entiers se traduit par une troncature des parties décimales qui rend encore plus imparfaite la sinusoïde de départ. D'où la génération de raies supplémentaires ds le spectre (qui peuvent être largement atténuées, voir supprimées en utilisant le dithering).
La 5e FFT montre ce qu'il se passe avec Reclock @ 75Hz comme renderer. C'est kif kif avec la 3.
La 6e FFT montre ce qu'il se passe avec Reclock @ 72 Hz. On constate un décalage de la tonalité à 959.92 Hz (constante sur la totalité de l'enregistrement). Pas mal
Une compensation de 4% devrait en théorie donner 960 Hz. Donc Reclock effectue la bonne correction de tonalité pour le PAL Speedup. Je suis rassuré . Néanmoins, l'amplitude de certaines harmoniques augmente quand même un peu... Perso, ca ne m'empêchera pas de dormir vu que un, c'est du Home Cinema, deux c'est inaudible, et trois qd on voit le gain que procure une tonalité correcte, on ne se pose pas plus de question
@+
Emmanuel
. Ca viendra bien un jour. Apparement les nouvelles RME on une gestion de l'ASIO très performante :
. Alors que sous WinME, c'était absolument parfait.
