Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Techniques du Son
Agrandir
Techniques du Son
Forums thématiques
Techniques du Son
Actu 601 601
Articles 625 625
Médias 4 911 4,9k
Tutoriels Tutos 93 93
Forums 17 012 17k

Sujet [FAQ] Toutes les réponses à vos questions existentielles sur le 24 bits et le 96 kHz

  • 562 réponses
  • 93 participants
  • 186 510 vues
  • 128 followers
1 [FAQ] Toutes les réponses à vos questions existentielles sur le 24 bits et le 96 kHz
Ce thread a pour but de centraliser les informations sur l'intérêt des résolutions élevées en audio, par exemple 24 bits/96 kHz. Je commence par un auto-quote :


La quantification

Le 24 bits est plutôt quelque chose d'intéressant, puisque la hausse de résolution dans ce cas augmente la dynamique sur les enregistrements, ce qui peut être très utile lorsqu'on enregistre avec des préamplis qui ont un niveau de sortie en dessous de 0 dB... C'est complètement inutile par contre sur des instruments virtuels ou du tout numérique, entre autres puisque les séquenceurs (et donc les plug-ins) fonctionnent en interne avec du 32 bits à vigule flottante...


Les fréquences d'échantillonnage

Pour la question de la fréquence d'échantillonnage, l'intérêt pratique d'aller à 88.2 ou 96 kHz, bien qu'il existe, est beaucoup plus faible que celui du 24 bits, ce qui explique que des professionnels recommandent peu souvent à des home-studistes de lâcher le 44.1 kHz, mais demandent toujours du 24 bits.

Ensuite sur un enregistrement seul, à moins d'avoir une oreille d'extra-terrestre, il est impossible d'entendre ou même de visualiser sur un spectrogramme une différence notable dans le domaine de l'audible entre quelque chose d'enregistré avec un microphone et un bon préampli/une bonne carte son en 44.1 kHz et en 96 kHz. Si différence il y a, c'est que la qualité des convertisseurs n'est pas la même.

Quel est donc l'intérêt de ces fréquences d'échantillonnage élevées alors ? Dans une chaine de traitements numériques, bien que les ingénieurs/développeurs mettent des filtres anti-aliasing dans leurs produits (repliement au dessus de la demi-fréquence d'échantillonnage, voir théorème de Shannon/Nyquist), il y a toujours un peu de repliement qui se fait, surtout si certains rigolos n'ont pas mis du tout de dispositifs anti-aliasing, comme sur certains synthétiseurs numériques (ce qui peut être parfois intéressant au niveau sonore, mais très grave sur une simulation d'amplificateur guitare). Augmenter la fréquence d'échantillonnage permet de repousser la limite en fréquence du repliement, et donc de rendre les traitements plus propres. Mais là encore, il est probable que vous ne puissiez pas entendre de différence flagrante...

Enfin, le 48 et le 96 kHz sont des fréquences utilisées plutôt en vidéo. La conversion de fréquence d'échantillonnage étant moins complexe du 88.2 au 44.1 que du 96 au 44.1, il est généralement conseillé de bosser en 88.2, sauf si vous avez vraiment confiance en votre logiciel de conversion. Travailler en 48 par contre est une grosse connerie, parce que ça apporte presque rien au niveau théorique, et que la conversion 48 vers 44.1 peut être source de bordel supplémentaire par rapport au 44.1 direct...


96 kHz et 24 bits dans un home-studio ???

Pour terminer ce monologue, une remarque très importante, discuter des fréquences d'échantillonnage et de la quantification optimales c'est bien, mais il faut déjà avoir du matos derrière, et réaliser des mixages à la hauteur, pour que l'intérêt des résolutions supérieures soit pertinent dans vos projets personnels ! Ne pas savoir mixer correctement ses morceaux et bosser avec du 24 bits/96 kHz me semble être une aberration...

Petite astuce aussi pour savoir si se prendre la tête dans votre cas vaut le coup : faites un enregistrement + mixage avec du 96 kHz/24 bits. Exportez le résultat en WAV, puis convertissez le en 44.1K/16 bits. Modifiez la fréquence d'échantillonage sur tous vos enregistrements et à l'intérieur du projet, puis faites à nouveau un export. Comparez les deux sur votre système d'écoute habituel. Si vous n'entendez pas de différences notables et intéressantes, arrêtez de vous prendre la tête :mrg: Ou allez acheter du meilleur matos... Autre cas : si "les deux sonnent aussi mal", retournez bosser le mixage, en 44.1K/16 bits bien sûr :oops2:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape

Afficher le premier post
201

Citation : Une dernière question, pour rester dans le sujet. Qu'est-ce serait l'idéal dans mon cas, peut importe le poids, ou quoique ce soit, pour mes montages vidéo?


Citation : Format audio source : 96000 Hz - 24 bits - Stéréo
Format audio du projet : 48000 Hz - 32 bits en virgule flottante - Stéréo

Ce qui est sûr, c'est que je vais continuer de travailler en 96khz, je fais du time stretching, la question ne se pose même pas.


:?!:
Pourtant ces infos semblent montrer que Premiere travaille en interne en 48kHz. Donc logiquement il doit convertir les fichiers dans ce "format" avant de les manipuler. Ne serait-il pas alors meilleur d'enregistrer directement en 48kHz pour éviter une conversion ?

Côté nombre de bits, prends 24 :
- ça laisse plus de marge pour régler les gains des préamps lors de la prise
- c'est le format natif des convertisseurs, autant profiter de leur précision, et de toute façon un convertisseur travaille toujours en virgule fixe
- la conversion 24bits fixe vers 32 bits flottants n'induit aucun perte ; ça offre simplement plus de souplesse au logiciel pour faire les calculs (= headroom sur les bus internes)
- je crois qu'aucun convertisseur ne sait faire du 32 bits. Ca ne servirait de toute façon à rien car les 8 derniers bits ne stockeraient que du bruit électronique (car ça correspond à une plage de -144dB à -192dB, or aucun appareil électronique n'a un bruit de fond aussi faible).

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

202
C'est logique, sauf que j'étire souvent mes sons, et des fois, beaucoup! Alors je pense même à travailler en 192khz... Et étirer un son en 48khz donne un son horrible.

Mais merci, je vais rester en 24 bits.
203
Bonjour,

Je m'immisce un peu au milieu de la discussion. :??:


Je ne suis pas technicien du son, juste "compositeur" et je souhaite poser une question précise (qui paraitra peut-être naïve aux pros :| ) :

Y a-t-il un intérêt à travailler avec un VST utilisant des samples en 24 bit (par rapport à des samples en 16 bit)?

merci
204
Ben oui, c'est toujours mieux, surtout si le VST a des samples différents selon la vélocité, et que ces samples ne sont pas tous normalisés :clin:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape

205
Ok, merci! :bravo:

On m'a également dit que les samples en 24 bit étaient plus "lourd" et que la configuration devait suivre. Qu'en est-il? La différence est-elle si grande?
206
Ben si chaque échantillon est codé en 24 bits au lieu de 16 bits, ça veut dire que le poids total en octets de l'ensemble des samples est multiplié par 1.5

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape

207
Je ne sais pas si cela a été précisé je n'ai pas eu le courage de lire tout le topic, mais quant à l'intérêt de bosser à une fréquence d'échantillonnages élevé j'aurais voulu apporter ma petite contribution.

Déjà dans l'absolu bosser à 88.2 khz plutôt que 44.1khz permet de diviser la latence par deux. En effet votre carte son estime la taille du buffer en sample , 64 minimum en général. Mais 64 samples passe deux fois plus rapidement en 88.2 que en 44.1.

Ensuite, en sois c'est vrai qu'entre écouter du 44.1 et du 88.2 il peut être très dur d'entendre une différence. par contre dé que l'on commence à travailler dans le domaine temporel il peut être intéressant d'avoir une fréquence d'échantillonnages élevé.

un petit exemple:
Mettons qu'un fichier de 1 seconde soit enregistré avec une fréquence d'échantillonnages de 10 hz, cela tombe bien car on veut pouvoir étudier les fréquence de 0 à 5hz.
Si l'on timestretch ce fichier pour qu'il soit deux fois plus rapide ce ne seront plus que 0.5 secondes qui seront codé en 10hz.
Si l'on désire maintenant faire la manip inverse, étirer le fichier par un facteur de 2 nous récupérerons un fichier de 1 seconde mais qui ne sera plus codé que sur 5 sample. Et on ne pourra étudier les fréquence que de 0 à 2.5 hz ce qui n'est plus convenable.
le timestretch est un exemple, mais vibrato, chorus, phaser peuvent aussi induire ce genre de pertes si le procédé utilisé inclut une ligne de retard à temps variable.

Voila je n'ai aucune source pour avancer ça, mais cela parait logique.




edit: je viens de voir que le coup du timestretch avait déjà été abordé, au temps pour moi :D
208

Citation : Déjà dans l'absolu bosser à 88.2 khz plutôt que 44.1khz permet de diviser la latence par deux. En effet votre carte son estime la taille du buffer en sample , 64 minimum en général. Mais 64 samples passe deux fois plus rapidement en 88.2 que en 44.1.



l'ennui c'est que c'est traiter un certain nombre de samples par seconde qui provoquera des clics, donc les clics apparaitront pour une latence deux fois moindre en 88.

209
Exactement, le coup de la latence plus courte est une erreur assez répandue, car le nombre d'échantillons et donc le nombre de calculs étant doublé, on double la taille du buffer compté en échantillons, et on se retrouve avec la même latence, à peu de chose près.

JM
210
Oui dans tout les cas c'est le nombre de sample traité par seconde qui détermine le seuil à partir duquel il y a apparition de clics.
Mais clics mis à part, je voulais préciser que c'était avec la frequence d'échantillonnages la plus haute que théoriquement la latence était la plus basse.



Citation : on double la taille du buffer compté en échantillons



Je capte pas bien, un buffer est généralement compté en échantillons. Toucher à la frequence d'échantillonnage est distinct de la taille du buffer, toujours compté en un même nombre de sample.

doubler la frequence d'échantillonnage réduit la latence, je peux vous donner un exemple concret. Après ce qui est sur c'est que cela demandera le double de calcul et que cela n'est pas plus avantageux que de diviser la taille du buffer.