Suis partant mais je ne crois pas (?) être équipé pour le faire .
A priori, on perd une octave en haut, mais je pense que cela dépend des algos d'interpolation et de lissage utilisés. La restitution éventuelle de l'octave perdue devrait renseigner sur le traitement subit pas le signal -> Manipe a faire !
PB

Bonjour à tous,

Je viens de lire avec attention ce sujet et je voudrais être sur de ne pas me tromper.

L'Oversampling en audio est-il la même chose que le sur-échantillonnage (supersampling) ?

Amicalement.
Yves

Oui, bonnet blanc et . . .

Salut Philbob,
Si tu pouvais nous en donner un petit exemple , ou un lien sur une doc qui détaillerait un peu ...ou même un exposé détaillé d'ailleurs ...
Merci d'avance.

bonjour
cela se fait facilement sous audacity en ouvrant le .wav 44/16
on choisit la fréquence d'échantillonnage (Préférences)
on peut même choisir l'algorithme d'interpolation
puis en exportant en choisissant "autres formats non compressés"
on peut également modifier le format d'échantillonnage (16, 24 ou 32 bits).

Bonsoir

En GNU ya ça https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html

Mais n'empêche que convertir une source du 44.1 vers le 48 ou 96 etc c'est toujours rajouté des "sample" qui sont égaux à 0
et qui posent ensuite le problèmes des Hautes fréquence créer donc filtre FIR etc

Comme souvent j'ai peur que le pire est l'ennemi du bien ou inversement

Bonne lecture

Bonjour,
J'ai trouvé ceci qui me parait utile mais je ne parle pas l'Italien.Il y en a un je crois....
http://www.sillanumsoft.org/Download/ThesisVA.pdf
S'il existe une traduction, je suis preneur. La question se pose aussi en métrologie non ?
Merci et bonne lecture.
PB

Non, le but du jeu est précisément d'insérer un "sample" de valeur "plausible" en fonction de ceux existants.
Mais ça reste une valeur "inventée" par le logiciel/algorithme de "ressampling" !

en fait je pense qu'il y a deux problèmes c'est premièrement quel algorithme et deuxièmement comment l'appliquer.

pour ce qui est du choix de l'algorithme

donc si je comprend ce qui est dit ici:

http://hal.inria.fr/docs/00/06/44/82/PDF/actesAPMEP.pdf

l'idée est que l'on peut assimiler notre signal à un signal périodique si on le regarde sur une fenêtre de temps réduite.
donc
-choix de la taille de la fenêtre?
-recouvrement entre deux fenêtre?

et après on applique la transformée de Fourier.

après comment appliquer l'algorithme au fichier source.

premièrement en différé:
on prend notre fichier, on le mouline et après on le joue.

donc admettons que on utilise un simple lecteur pour le lire.
le problème c'est que l'on veut qu'il sorte notre fichier comme on le souhaite.
cependant le lecteur est aussi pourvu d'un processeur (ce processeur peut être là pour appliquer des algorithmes de corrections d'erreurs), bref on ne sait pas exactement ce qu'il fait.
Il faudrait pouvoir le désactiver.
Si on utilise un ordi, j'ai encore moins d'idée sur ce que en pratique font le logiciel "player" et/ou la carte son.

deuxième choix en temps réel:

alors là il faut en plus que le processeur pédale suffisamment vite pour les calculs qu'on lui demande.


maintenant pour ce qui est de l'analyse de Fourier, elle est aussi appliquée en audio avec les formats de compression:

http://www.cours.polymtl.ca/inf3610/Cours/Materiel/Chap1/dsp-mp3.pdf

donc dans la chaine de traitement numérique on peut avoir plusieurs "process" et essayer de plus ou moins les "maitriser" sachant que aussi bon qu'il soit, on ne veut pas attendre un demi-heure de traitement entre chaque morceau d'un CD.

est-ce qu'il faut mieux un bon mp3 avec convertisseur qui oversample avec un algorithme qui ne pose pas de problème de traitement avec ce format de fichier ou un fichier flac mal décompressé à la volé vers notre convertisseur non-os?

mon exemple est caricaturale mais je pense que il peut y avoir des situations paradoxales.


à vous de voir..
mystère et boule de gomme...

hervé.

en fait, si je résume, on revient au problème : Qui fait quoi
Avec dans l'ordre :
- Les lecteurs (CD, disque dur....)
- Un programme éventuel de traitement de la donnée son
- Le process de mise en forme en sortie du PC (USB) ou du lecteur CD (SPdif)
- Le récepteur USB éventuel
- Le récepteur SPDIF
- Le DAC proprement dit.

Sachant que l'on peut ajouter des processes aux récepteurs !

Et quelles specs pour le transfert de données (couche data) et éventuellement si elles existent, les couches session et application entre chaque process.

J'avoue qu'un petit synoptique serait bienvenu avec les flux serait le bienvenu.

PB

En fait c'est qui fait quoi sur quoi et à quelle date.

Si on prend un enregistrement d'aujourd'hui, celui-ci va être fait avec un convertisseur analogique numérique pouvant enregistrer un fichier 96kHz/24-bit (le convertisseur ayant sa propre chaine de traitement interne).

Après si il y a plusieurs voies il y aura très probablement un mixage numérique (avec le traitement qui va avec).
...un ou deux effets vont peut être artificiellement ajoutés...ainsi que des sons de synthèse..

Puis le signal va être certainement égalisé pour générer un fichier 44kHz/16-bit .

Donc déjà il aura subit pas mal de traitement.

Le plus simple serait de lire le fichier et générer directement les trois signaux (data bck et ws) nécessaires au fonctionnement du dac.

Maintenant, c'est peut être pas la meilleure solution..

Un PC offre bien plus de possibilités mais il y a plus d'un élément complexe..à commencer par l'alim et les éléments de refroidissement...le bus de données..les mémoires caches...l'OS (gestion des processus, de la mémoire, des interruptions, des fichiers..interface graphique..etc..)..les pilotes des périphériques, le firmware,...


difficile de faire un schéma d'ensemble

hervé.

Oui, bon.
Il manque 2dB à 20KHz que l'on pourrait rattraper en suréchantillonnant les wav 44Khz -obtenus à partir de CD ripés- de 44 à 88Khz ce que les convertisseurs à base de 1543 devraient être capables d'accepter.
On récupèrerait alors les 2dB perdus.
Il semble que la difficulté soit d'acheminer ce 88Khz jusqu'au 1543

Ca devrait donc se limiter à un problème de driver USB ? Non ?
Ou simplement de convertisseur USB -> SPDIF supportant ce débit ?
Ou encore, trouver sur un PC un autre tuyau de sortie supportant 88 x 16 x 2 (stéréo) 2,816 Mbs.
Ca ne fait "que" 352 Kos . . . un port Ethernet peut être . . . protocole de "streaming" ? ? ?

Tout ça pour 2db

Bonne nuit.

Yves.

Après lecture très enrichissante des documents joint

J'ai vérifier un détail de ma sortie SPdiff sur ma carte son à base de CMI9880
elle indique un Sample rate maxi de 96Khz pour les sorties lignes
mais le même teste sur la sortie SPdiff m'indique 48 Khz maxi
je pige pas tout là , je vérifierai demain

ca aurait pu être une solution pour gaver le CS8412 et le TDA1543 qui suit
avec du 88.2 Khz via baudline et récupérer le signal en sortie du converto
sur l'entrée ligne vu qu'elle accepte jusqu'a 96 Khz

Bonne nuit

peine perdue , après lecture du net
j'ai trouvé les caractéristiques du Spdiff

celle-ci Caractéristiques du SPDIF

S/PDIF permet de coder des données audio stéréo ou multicanaux (AC3, DTS, MPEG2, etc.).

Le standard S/PDIF supporte les fréquences d'échantillonnage suivantes :

44.1kHz pour un CD
48 kHz pour une cassette DAT
32 kHz pour un DSR



reste a explorer les formats USB

Bonjour,

Juste histoire de fixer les idées:

Le problème des lecteurs CD vient de Fe qui est trop proche de la fréquence audible.
Les mélanges des fréquences (Fe, 2Fe, 3Fe) avec le signal sonore donnent naissance à des
fréquences indésirables dans le spectre audio.
Pour éviter cela: on doit filtrer passe bas à Fe/2 en sortie du convertisseur. Mais là, c'est
pour l'élaboration du filtre qu'on est coincé. Une coupure raide entre 20kHz et 22.05kHz
demande un filtre d'un ordre élevé qui va faire tournicoter la phase et faire onduler le niveau
dans la bande audio. En pratique, on ne fait pas cela.

Le plus simple: sur échantillonner (x4 ou x8) puis filtrer à Fe/2
(soit 44.1*8/2 = 176.4 kHz). L'écart entre 20kHz et Fe/2 est suffisamment grand
pour qu'un simple passe bas d'ordre 2 soit efficace.
Seule contrainte: inventer le signal entre deux échantillons d'origine.
Sur le TDA1541, la doc indique que le signal est interpolé de manière linéaire.
On peut imaginer d'autres modes de reconstitution du signal, mais ce n'est que
du signal inventé.

Temps réel et temps différé:

Il est faux de vouloir opposer le temps réel au temps différé. Ces deux notions
cohabitent dans un lecteur CD ou sur un "player" de PC.
En effet, les infos lues sur un CD (ou sur un HDD) ne sont pas rigoureusement cadencées.
Il y a des temps de latence difficilement prévisibles (erreurs de lectures, accès concurrentiels...)
Pour éviter les à-coups, les données sont stockées dans une FIFO et relues à cadence fixe cette fois ci.
La cadence de sortie imposée constitue la contrainte temps réel de l'affaire.
Sur mon Philips 371, le décodeur SAA7210 est équipé d'une ram de 16384 mots de 4 bits qui fait office de
FIFO. En clair, il y a de quoi stocker 2048 échantillons stéréo 16 bits.
Cela signifie qu'à chaque instant, on peut connaitre tout ou partie des 2048 échantillons stockés.
Donc, on est bien dans le cas d'une production sonore en temps différé. Sur les lecteurs CD d'auto radio,
cette FIFO permet de stocker au moins 1 à 2 secondes de signal pour pallier les mauvaises conditions
de lecture (vibrations en particulier).
Autre aspect de cette lecture en temps différé: Cela rend possible l'utilisation de filtres FIR qui
nécessitent de connaitre le signal à l'avance. C'est d'ailleurs ce rôle de filtrage FIR (et de sur échantillonnage)
qui est confié au SAA7220.

Compression versus fichier brut

La reproduction sonore des fichiers compressés passe avant tout par la reconstitution du signal non compressé,
puis de sa conversion en analogique ou de sa mise à un autre format numérique.
Si la compression est avec pertes, on a beau sur échantillonner, ce qui est perdu est perdu!
La décompression se fait soit en soft (codecs sur PC) soit en hard par des composants spécifiques (lecteurs MP3).
Le ré échantillonnage, s'il existe, peut être soft (logiciels spécialisés) ou hard dans une carte son de PC.
En revanche, je ne suis pas certain que dans le cas d'une carte son on ait "la main" sur ce qui est réellement fait.

Traitement des données binaires:

Il est parfaitement possible de pré traiter un fichier wav pour appliquer un filtre par exemple.
L'opération de lecture, et d'écriture d'un morceau de 3 mn prend moins d'une seconde.
Le temps de traitement dépend du traitement! Un ajustement de niveau ou un effet d'écho
ne prennent qu'environ 1/10 de seconde. Un filtre FIR est plus gourmand (dépendant du nombre
de coefs du filtre). Un rééchantillonnage avec interpolation prendra quelques secondes.

Pour finir:

Sur un PC avec un OS classique, impossible de garantir un débit sonore temps réel. Nécessité d'avoir recours
à une carte son qui bufferise et débite le signal à cadence fixe. Faible maitrise de ce qui est réellement
fait dans la carte son (sur échantillonnage systématique?)

Compression de fichier: oui mais sans pertes sinon stocker en format brut.

Sur-échantillonnage: Difficile de trancher! Pour avoir testé avec et sans sur un lecteur CD, la différence
ne saute pas aux oreilles. Sans sur-échantillonnage (et donc sans grand filtrage passe bas) il y a toujours
le risque de produire des fréquences hautes (inaudibles) mais qui transiterons dans l'ampli et qui peuvent
êtres sources d'intermodulations....

Pré traitement soft: oui mais les fichiers créés seront dédiés à une seule chaine de reproduction.