Utiliser du 96K est utile pour du filtrage IIR.
On arrive a calculer des coef de filtre IIR qui correspondent à peu près à ce qu'on attend d'un filtre classique analogique tant
que la fréquence de coupure est loin de Fs/2 . Quand on s'en rapproche ca se passe plus mal.
On a bien un filtre , mais ses caractéristiques sont pas forcement celles qu'on veut.
Avec une Fs a 96K pas de pb pour toute la bande audio.
Pour du FIR, cela a beaucoup moins d’intérêt.
|
Modérateurs: Modération Forum Installations, Modération Forum DIY, Le Bureau de l’Association HCFR • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 3 invités
Et si l’on rajoutait du FIR au DSPiy ?
- tcli
- Messages: 4075
- Inscription Forum: 23 Nov 2009 22:40
- Localisation: Complètement à l'ouest
N'oublions pas le gain au niveau bruit en augmentant l'échantillonnage (voir video de Jipihorn), et pour les traitements cela permet de minimiser les défauts induits par ses derniers .
Bon après à l'oreille
Bon après à l'oreille
- Cobrasse
- Messages: 5864
- Inscription Forum: 17 Aoû 2008 13:02
Ok, j'avoue ma totale ignorance sur le filtrage IIR. Je vais essayer de m'informer.
- Pacapona
- Messages: 347
- Inscription Forum: 02 Jan 2014 19:33
- Localisation: CH
tcli, est ce qu'on peux avoir un retour ou un conseil pour l’implémentation d'un convolueur, basé sur ton expérience autour de xbmc ? à quel endroit tu inseres les routines dans la chaine audio linux?
- maxidcx
- Membre HCFR Contributeur
- Messages: 3105
- Inscription Forum: 25 Avr 2007 10:50
Quelques choses de peut être plus palpable :
DSP = calcul numérique
Calcul numérique / par un processeur = calcul approximatifs (voir pblm de représentation des nombres en machine et tout ce qui en découle : accumulation d'erreur etc ....)
Ça plaide en faveur d'un max de bits sur la source et d'encore plus de bits pour les calculs intermédiaires.
De la même manière pour le fréquentiel:
DSP = traitement de grandeurs discrètes dans le temps dans le domaine fréquentiel (filtrage) -> approximations et accumulation d'erreurs car on n'a pas une infinité de valeurs par période (monde réel).
Comme l'explique mieux que moi TCLI, l'expression théorique d'un IIR est sensible aux rapprochement de Fc et Fs/2. Avec Fs=2xFs-origine, toute Fc est exprimable sur la bande d'origine (0 à Fs/4) en IIR sans artefact.
Donc en faisant les traitement à 96khz on ne fait que s'assurer que l'on introduit aucune dégradation involontaire du signal d'origine à 44/48khz et donc par Shanon que l'on ne dégrade pas de manière collatérale le signal de la bande audio 20~20khz. Rien de plus.
Pour les adeptes des sources "studio master" 96khz, il faudrait faire les traitements à 192khz pour respecter la même logique, ce qui a peu d’intérêt vu que l'on exprimera jamais des filtres hors de la bande des 20khz.
96khz est donc (a mon sens) un excellent compromis glogal.
La récupération d'un max de bits de précision (16->24) lors du process d'upsampling à 96khz est par contre à mon avis bien plus important. Rien que pour cela, l'upsampling d'une source 44/48 en 96 peu se justifier avant de passer à la moulinette du DSP.
DSP = calcul numérique
Calcul numérique / par un processeur = calcul approximatifs (voir pblm de représentation des nombres en machine et tout ce qui en découle : accumulation d'erreur etc ....)
Ça plaide en faveur d'un max de bits sur la source et d'encore plus de bits pour les calculs intermédiaires.
De la même manière pour le fréquentiel:
DSP = traitement de grandeurs discrètes dans le temps dans le domaine fréquentiel (filtrage) -> approximations et accumulation d'erreurs car on n'a pas une infinité de valeurs par période (monde réel).
Comme l'explique mieux que moi TCLI, l'expression théorique d'un IIR est sensible aux rapprochement de Fc et Fs/2. Avec Fs=2xFs-origine, toute Fc est exprimable sur la bande d'origine (0 à Fs/4) en IIR sans artefact.
Donc en faisant les traitement à 96khz on ne fait que s'assurer que l'on introduit aucune dégradation involontaire du signal d'origine à 44/48khz et donc par Shanon que l'on ne dégrade pas de manière collatérale le signal de la bande audio 20~20khz. Rien de plus.
Pour les adeptes des sources "studio master" 96khz, il faudrait faire les traitements à 192khz pour respecter la même logique, ce qui a peu d’intérêt vu que l'on exprimera jamais des filtres hors de la bande des 20khz.
96khz est donc (a mon sens) un excellent compromis glogal.
La récupération d'un max de bits de précision (16->24) lors du process d'upsampling à 96khz est par contre à mon avis bien plus important. Rien que pour cela, l'upsampling d'une source 44/48 en 96 peu se justifier avant de passer à la moulinette du DSP.
- Tazz28
- Messages: 2802
- Inscription Forum: 03 Nov 2008 23:47
- Localisation: Dreux
Merci pour ces précisions!
J'ai trouvé un bon document ou ceci est exliqué;
Investigations in Upsampling from 48 kHz to 96 kHz and applied Filters http://www.acourate.com/freedownload/SRCFilterInvestigations.pdf
Mais j'ai encore de la peine a comprendre comment avec l'ajout de Zéro on peut avoir plus d'infos... J'investigue...
J'ai trouvé un bon document ou ceci est exliqué;
Investigations in Upsampling from 48 kHz to 96 kHz and applied Filters http://www.acourate.com/freedownload/SRCFilterInvestigations.pdf
Mais j'ai encore de la peine a comprendre comment avec l'ajout de Zéro on peut avoir plus d'infos... J'investigue...
- Pacapona
- Messages: 347
- Inscription Forum: 02 Jan 2014 19:33
- Localisation: CH
Bonjour à tous....
Projet très interessant, qui risque fort de m'interesser:
j'ai quelques connaissances de développeur en C,C++ et assembleur.
Je cherche un moyen d'implémenter des fonctions DSP dans un petit boitier....
Le raspberry pi peut être interessant, maintenant que l'I2S fonctionne.
Mais le BBB a sans doute plus de potentiels, sauf que... communauté plus petite... c'est un peu le hic.....
Je trouve l''analogie avec l'image parfaitement exacte: mon explication pour faire simple:
Une image disons 100x100 scalée en 200x200 est parfaitement dégeulasse : en effet, en l'absence d' "aliasing" , les pixels deviennent des gros carrés de 2 par 2. Evidemment, pour rejoindre ce qui a été dit, sur un petit écran ca se voit pas....
Pour remettre cela à un contexte audio:
Si l'image du son est simplement scalée, effectivement, on peut avoir un effet mitigé.
Heureusement, tout comme en image, lorsque l'on double la fréquence, on passe par des algorithmes qui vont lisser le son, exactement comme pour les images : on ne va pas bêtement reproduire les amplitudes en double.
Alors après la question c'est pourquoi doubler cette résolution? Après tout, 44khz, c'est assez.
Tout à fait..... Si on ne retravaille pas le signal ensuite:
En son comme en image, les programmes de traitement de signal fonctionnent mieux quand ils ont plus d'informations:
Exemple parfaitement applicable à l'audio: imaginez que vous souhaitez appliquer un filtre qui va lisser l'image... chaque pixel doit tenir compte de ses voisins. Sur une image de 100x100 il y a 7 voisin, sur l'image "agrandie" 200x200 cela fait 7x4=28 voisins dont vous pouvez modifier la profondeur pour faire du lissage.
au passage, Le fait de passer le signal en 24 bits améliore aussi également le potentiel des étapes de calculs, et pour le coup, c'est sans perte de qualité.
en effet, 16bits, c'est 65536 valeurs possibles pour l'amplitude.
24 bits c'est 16777216 valeurs possibles.
Hors passer de 16 bits à 24 bits ne requiert pas d'opération compliquée, même pas de multiplication.
Je m'explique:
Passer de 16 à 24 bits, c'est pour nous humain x256
Mais pour un microprocesseur ca se fait par décalage d'octets, et ca coute rien ou presque en temps machine.
Exemple:
prenons un volume au hasard, exemple: 14365
en hexadecimal ca vaut: 381D
pour multiplier par 256, il suffit 'd'ajouter' visuellement 2 '0' à la fin:
381D00
Et voila....
En espérant que ces quelques explications ont apporter de l'eau au moulin...
Projet très interessant, qui risque fort de m'interesser:
j'ai quelques connaissances de développeur en C,C++ et assembleur.
Je cherche un moyen d'implémenter des fonctions DSP dans un petit boitier....
Le raspberry pi peut être interessant, maintenant que l'I2S fonctionne.
Mais le BBB a sans doute plus de potentiels, sauf que... communauté plus petite... c'est un peu le hic.....
Je trouve l''analogie avec l'image parfaitement exacte: mon explication pour faire simple:
Une image disons 100x100 scalée en 200x200 est parfaitement dégeulasse : en effet, en l'absence d' "aliasing" , les pixels deviennent des gros carrés de 2 par 2. Evidemment, pour rejoindre ce qui a été dit, sur un petit écran ca se voit pas....
Pour remettre cela à un contexte audio:
Si l'image du son est simplement scalée, effectivement, on peut avoir un effet mitigé.
Heureusement, tout comme en image, lorsque l'on double la fréquence, on passe par des algorithmes qui vont lisser le son, exactement comme pour les images : on ne va pas bêtement reproduire les amplitudes en double.
Alors après la question c'est pourquoi doubler cette résolution? Après tout, 44khz, c'est assez.
Tout à fait..... Si on ne retravaille pas le signal ensuite:
En son comme en image, les programmes de traitement de signal fonctionnent mieux quand ils ont plus d'informations:
Exemple parfaitement applicable à l'audio: imaginez que vous souhaitez appliquer un filtre qui va lisser l'image... chaque pixel doit tenir compte de ses voisins. Sur une image de 100x100 il y a 7 voisin, sur l'image "agrandie" 200x200 cela fait 7x4=28 voisins dont vous pouvez modifier la profondeur pour faire du lissage.
au passage, Le fait de passer le signal en 24 bits améliore aussi également le potentiel des étapes de calculs, et pour le coup, c'est sans perte de qualité.
en effet, 16bits, c'est 65536 valeurs possibles pour l'amplitude.
24 bits c'est 16777216 valeurs possibles.
Hors passer de 16 bits à 24 bits ne requiert pas d'opération compliquée, même pas de multiplication.
Je m'explique:
Passer de 16 à 24 bits, c'est pour nous humain x256
Mais pour un microprocesseur ca se fait par décalage d'octets, et ca coute rien ou presque en temps machine.
Exemple:
prenons un volume au hasard, exemple: 14365
en hexadecimal ca vaut: 381D
pour multiplier par 256, il suffit 'd'ajouter' visuellement 2 '0' à la fin:
381D00
Et voila....
En espérant que ces quelques explications ont apporter de l'eau au moulin...
- camelator
- Messages: 38
- Inscription Forum: 19 Mai 2013 18:28
|
Retourner vers Filtrage actif, Equalisation et Processeurs |