Master en 192/24 d'un WAV en 44.1/16
- 113 réponses
- 21 participants
- 11 472 vues
- 20 followers
Afficher le sujet de la discussion
Pour montrer l'intérêt du sur-échantillonnage je n'ai pas besoin de la norme AES17 : Il suffit de montrer que la puissance totale du bruit de quantification ne dépend pas de la fréquence d'échantillonnage, qu'en sur-échantillonnant au-delà de la bande d'intérêt cette puissance réduite à la bande utile plus étroite est plus faible et que l'on gagne des bits effectifs en sous-échantillonnant.
Quant à la mise en forme du bruit de quantification, elle est effective si l'on place une modulation sigma-delta (qui augmente l'efficacité du sur-échantillonnage).
Un sinus parfait ne contient aucune harmonique.
Un sinus généré analogiquement peut contenir des harmoniques à cause des non-linéarités des appareils qui constituent la chaîne.
Un sinus numérique ou quantifié engendre une raie et un bruit uniforme blanc si le nombre de bits effectifs est suffisant et si la fréquence d'échantillonnage n'est pas choisie de manière à provoquer des erreurs de quantification systématiques.
Un signal audio réel contient suffisamment d'aléas pour que l'erreur de quantification soient très proches d'un bruit uniforme (très proche i.e. que les tests statistiques ne fassent pas la différence, alors un instrument de mesure...).
Et si par mégarde on produit en synthèse un signal trop faible pour considérer le bruit comme uniforme, on ajoute une perturbation ==> dithering.
Ça c'est la fft de la sinusoïde quantifiée sur 16 bits à 44,1kHz :
Un doute sur la présence d'harmonique ? Voici la fft de l'erreur de quantification :
Il n'y a rien qui dépasse, on est bien devant le spectre d'un bruit blanc.
Tu dis qu'il est normal d'observer des harmoniques ? Ok mais alors d'où viennent-elles ?
Je n'aime pas user de ce genre d'argument, mais mon job est de concevoir et de spécifier des algorithmes de traitement du signal numérique sur des cibles diverses (logiciel, FPGA, etc.) jusqu'à la gestion des quantifications. Le produit fini (en tout cas pour la partie numérique) se comporte au bit près comme le simulateur MatLab.
Cet outil permet justement de vérifier que tout se passe correctement avant la mise en production, en faisant la passerelle entre le calcul théorique sur une feuille de papier et le produit final.
Là pour le coup on peut regarder les normes : Le script que j'ai posté (et que tu peux consulter) génère un sinus avec la fonction de base en float (IEEE Standard 754) puis réalise une simple quantification sur 16bits.
J'avoue ne pas avoir vérifié si la quantif est conforme à la norme IEEE (la bascule sur la valeur médiane) mais ça n'a pas d'importance sur la répartition de l'erreur qui reste dans 2^-16.
EraTom
2282
AFicionado·a
Membre depuis 13 ans
Ben sur les SNR la conclusion est la suivante :
L'erreur d'interpolation due à la décimation de 48kHz vers 44.1kHz est complètement négligeable si l'on part de 24bits pour atteindre 16bits.
Monter à une fréquence multiple de la fréquence cible n'apporte absolument rien de significatif dans ce cas.
Pour le filtre :
Donner une fréquence de coupure "à -3dB" ou un truc dans le genre donne une indication mais ne permet pas de définir un filtre.
Pour définir un filtre (passe-bas) il faut établir un gabarit qui donne :
- La plage de gain dans la bande passante / utile ;
- La plage de gain dans la bande atténuée ;
- La largeur (en fréquence) dans laquelle la courbe de gain passe de la bande utile à la bande atténuée.
La fréquence de coupure à -x dB c'est juste un seul point de passage dans la bande de transition.
En général, un filtre présente un phase quasi-linéaire dans la bande passante. C'est dans la bande de transition que le saut arrive (à moins de concevoir un filtre spécifique). Et dans la bande atténuée... Ben en s'en moque.
L'erreur d'interpolation due à la décimation de 48kHz vers 44.1kHz est complètement négligeable si l'on part de 24bits pour atteindre 16bits.
Monter à une fréquence multiple de la fréquence cible n'apporte absolument rien de significatif dans ce cas.
Pour le filtre :
Donner une fréquence de coupure "à -3dB" ou un truc dans le genre donne une indication mais ne permet pas de définir un filtre.
Pour définir un filtre (passe-bas) il faut établir un gabarit qui donne :
- La plage de gain dans la bande passante / utile ;
- La plage de gain dans la bande atténuée ;
- La largeur (en fréquence) dans laquelle la courbe de gain passe de la bande utile à la bande atténuée.
La fréquence de coupure à -x dB c'est juste un seul point de passage dans la bande de transition.
En général, un filtre présente un phase quasi-linéaire dans la bande passante. C'est dans la bande de transition que le saut arrive (à moins de concevoir un filtre spécifique). Et dans la bande atténuée... Ben en s'en moque.
marc34.o
1959
AFicionado·a
Membre depuis 15 ans
EraTom
2282
AFicionado·a
Membre depuis 13 ans
Citation de marc34.o :
Je ne dis pas que la norme est inutile mais que pour confronter des calculs théoriques à une mesure il faut que les conditions de celle-ci correspondent aux hypothèses de la démonstration théorique, sinon qu'est-ce que l'on teste ?Les normes sont faites pour que tout le monde fasse la même chose et qu'on puise comparer les mesures. On peut choisir de ne pas les respecter, mais alors dans ce cas la, si on mesure sans filtre AES17, l'oversampling n'augmente plus le SNR si on le mesure une bande passante large, puisque l'over sampling ne fait que déplacer l'énergie du bruit vers le haut. Donc quelqu'un qui mesure sans filtre dira que l'oversamplig n'améliore rien du tout, alors qu'on sait très bien que dans la réalité l'oversampling permet d'augmenter la qualité, puisque la bande passante de nos oreilles est limitée. Pas très cohérent comme raisonnement donc si on n'utilise pas le filtre AES17.
Pour montrer l'intérêt du sur-échantillonnage je n'ai pas besoin de la norme AES17 : Il suffit de montrer que la puissance totale du bruit de quantification ne dépend pas de la fréquence d'échantillonnage, qu'en sur-échantillonnant au-delà de la bande d'intérêt cette puissance réduite à la bande utile plus étroite est plus faible et que l'on gagne des bits effectifs en sous-échantillonnant.
Quant à la mise en forme du bruit de quantification, elle est effective si l'on place une modulation sigma-delta (qui augmente l'efficacité du sur-échantillonnage).
Citation de marc34.o :
Euh... Non.Je comprend pas trop ce que tu veux dire. Un sinus, même généré numériquement, engendre des harmoniques, aussi faibles soient elles.
Un sinus parfait ne contient aucune harmonique.
Un sinus généré analogiquement peut contenir des harmoniques à cause des non-linéarités des appareils qui constituent la chaîne.
Un sinus numérique ou quantifié engendre une raie et un bruit uniforme blanc si le nombre de bits effectifs est suffisant et si la fréquence d'échantillonnage n'est pas choisie de manière à provoquer des erreurs de quantification systématiques.
Un signal audio réel contient suffisamment d'aléas pour que l'erreur de quantification soient très proches d'un bruit uniforme (très proche i.e. que les tests statistiques ne fassent pas la différence, alors un instrument de mesure...).
Et si par mégarde on produit en synthèse un signal trop faible pour considérer le bruit comme uniforme, on ajoute une perturbation ==> dithering.
Ça c'est la fft de la sinusoïde quantifiée sur 16 bits à 44,1kHz :
Un doute sur la présence d'harmonique ? Voici la fft de l'erreur de quantification :
Il n'y a rien qui dépasse, on est bien devant le spectre d'un bruit blanc.
Tu dis qu'il est normal d'observer des harmoniques ? Ok mais alors d'où viennent-elles ?
Citation de marc34.o :
Si ce n'est pas un a priori infondé ça... Parce que MatLab n'est pas un outil numérique "réel" ?Ce n’est pas une simu venant de matlab ou autres logiciels de ce type. On est bien dans un monde numérique réel, même si tout cela peut paraitre virtuel.
Je n'aime pas user de ce genre d'argument, mais mon job est de concevoir et de spécifier des algorithmes de traitement du signal numérique sur des cibles diverses (logiciel, FPGA, etc.) jusqu'à la gestion des quantifications. Le produit fini (en tout cas pour la partie numérique) se comporte au bit près comme le simulateur MatLab.
Cet outil permet justement de vérifier que tout se passe correctement avant la mise en production, en faisant la passerelle entre le calcul théorique sur une feuille de papier et le produit final.
Là pour le coup on peut regarder les normes : Le script que j'ai posté (et que tu peux consulter) génère un sinus avec la fonction de base en float (IEEE Standard 754) puis réalise une simple quantification sur 16bits.
J'avoue ne pas avoir vérifié si la quantif est conforme à la norme IEEE (la bascule sur la valeur médiane) mais ça n'a pas d'importance sur la répartition de l'erreur qui reste dans 2^-16.
Danguit
3348
Squatteur·euse d’AF
Membre depuis 18 ans
FuBiGa
368
Posteur·euse AFfamé·e
Membre depuis 15 ans
EraTom
2282
AFicionado·a
Membre depuis 13 ans
trazom
1819
AFicionado·a
Membre depuis 20 ans
EraTom
2282
AFicionado·a
Membre depuis 13 ans
marc34.o
1959
AFicionado·a
Membre depuis 15 ans
EraTom
2282
AFicionado·a
Membre depuis 13 ans
- < Liste des sujets
- Charte