Conversion sample 16 bit vers 32 bit. pertes?
- 38 réponses
- 9 participants
- 7 267 vues
- 2 followers
indianajo
- 1
- 2
Anonyme
afone1977
afone1977
indianajo
indianajo
Anonyme
Citation : En fait, Tishmeyer conseille de passer en 32 bits pour plusieurs bonnes raisons et notament que le rendu après traitements par D plug DSP comme la compress, l'EQ, etc. sera meilleur... avec D plugs de qualité bien évidemment... a t'il encore oublié de dire qqch ou C effectivement le cas?
il a raison pour du traitement hors ligne (ce que je disait plus haut), tord pour du traitement en ligne (via les plugin en inserts, en send, les fader,les pan de la console virtuelle du soft) puisque de toute façon sauf cas particuliers (powercore, protools HD...)tous les traitements seront fait en 32 bit flottant, peu importe la résolution de tes fichiers, le rendu sera le même que ton sample de base soit en 16 bit ou que tu l'ai passé en 32 bit, ce qui ne changera rien car il n'aura de 32 bit que le nom.
Citation : par ailleurs des convertisseurs AN 32 bits pas sur que cela existe encore,
je ne pense pas non plus, de toute façon ca n'aurai pas grand intérêt, le 32 bit flottant et le 24 c'est "pareil", ils ont la même partie fixe (partie "utile" du mot binaire), la seule différence c'est que le flottant introduit 8 bit d'exposant qui permettent de s'adapter à l'échelle du signal à traiter, il en résulte qu'on ne remonte pas le bruit de quantification à chaque traitement (pas de troncature au rendu des calculs), et qu'on introduit une notion de "headroom numérique" qui fait qu'on ne peu pas saturer en interne ant que toute la chaine tourne en flottant.
Il faut bien dissocier 2 choses:
- la résolution de quantification qui défini le nombre de bit utilisé lors de la conversion d'un signal analogique en flux numérique, ici le flottant n'a aucun intérêt, en tout cas je n'en vois pas, par contre il est effectivement vivement conseillé de préférer le 24 bit au 16 lors de cette étape, pour plein de raisons.
- la résolution des calculs lors des traitements internes, et c'est là que le flottant est utile pour les raisons évoqués au dessus, il permet de conserver l'intégrité de la mantisse, et de rendre au mieu les détails des traitements.
Sinon te prends pas la tête avec le "cross post avec docks" (c'est ni doc, ni doks
)il veu juste dire qu'il a poster en même temps que moi.Edit: par contre je t'invite à lire la charte du forum, tu y verras que l'écriture sms n'est pas très bien vue.
indianajo
Anonyme
Citation : Tu es trop loin pour moi... je ne conprends pas grand chose à ce que tu me racontes.. trop technique
alors allons y par étape, tu verras, c'est pas si compliqué que ca.
Tout d'abord, la quantification:
http://www.iict.ch/Tcom/Laboratoires/digivox2000/chap/chap2/quantification.htm
En lisant ca, tu devrais comprendre le principe, et aussi comprendre pourquoi il vaut mieux enregistrer en 24 bit, plutôt qu'en 16.
Ensuite, la résolution:
En audionumérique, tout du moin en PCM (pulse code modulation) on utilise deux choses, la fréquence d'échantillonnage qui définie le nombre de point par secondes auxquels on va attribuer une valeur, et la résolution qui défini le nombre de bit qu'on utilise pour coder chaque point.
Donc, 44.1/24 bit par exemple, signifie qu'on prend 44 100 points par seconde et qu'on code chaque point avec 24 bit.
En gros, toujours pour du 44.1/24 bit, si tu prends une feuille de papier millimétré, en horizontale tu as la fréquence d'échantillonnage (44 100 divisions pour 1 seconde), et en vertical tu as 2^24 (16 777 216) lignes qui représentent chaque valeur possible.
De là, tu peux tracer la courbe qui représente au mieux les variations de tensions d'un signal analogique, et c'est ce que fait (schématiquement) un convertisseur analogique/numérique.
Après, on distingue deux choses au niveau de la résolution:
1- la résolution fixe
2- la résolution à virgule flottante
Dans les deux cas, un mot binaire est fait de la manière suivante:
- 1 bit de signe
- X bit de mantisse (la mantisse est la partie "utile" du mot binaire)
- X bit d'exposant pour du flottant
Pour du 16 bit, on a 1 bit de signe et 15 bit de mantisse
Pour du 24 bit, on a 1 bit de signe et 23 bit de mantisse
Pour du 32 bit flottant, on a 1 bit de signe, 23 bit de mantisse et on rajoute 8 bit d'exposant.
Sachant qu'un bit peu prendre 2 valeurs (0 ou 1), ca nous donne:
2^16 valeurs possibles en 16 bit soit 65 536
2^24 valeurs possibles en 24 bit soit 16 777 216 (voir exemple du papier millimétré plus haut)
On appel l'écart entre deux valeur possible le PAS DE QUANTIFICATION (voir le lien pour en savoir plus, notamment sur le bruit de quantification)
autre chose, 1 bit permet de coder 6dB
pour du 16 bit on a donc 96 dB (6x16) de plage dynamique
pour du 24 bit on a 144 dB (6x24)de plage dynamique
Pour du 32 bit flottant, on peu "déplacer" nos 24 bit sur une échelle beaucoup plus grande (envron 1500dB théoriques) grace aux 8 bit d'exposant., on peu donc coder sur 24 bit des signaux très hauts et des signaux très bas.
Voila en gros quelques bases sur le sujet, à compléter ou à reprendre en cas de boulettes.
Citation : Tu es quoi? Ingénieur du son ou quoi?...
non, pas du tout.
dogfacedgremelin
. Sauf qu'il est réelement un peut plus que passionné
perso, je le classe dans ma section pédagogie d'AF.
chaque fois que je me pose une question, il est souvant la conclusion (avec Rroland et youtou)
apprendre est une des choses les plus difficile à faire. Alors j'apprends chaque jours.
indianajo
Anonyme
Citation : Il m'arrive de de faire des traitements hors ligne dans le menu audio/traitement de cubase comme du time stretch, normalize, remove DC comp... donc mieux vaut convertir mes samples en 24/32 bits, non?
si vraiment tu empiles pas mal de traitements hors ligne sur plusieurs pistes, ca peut être effectivement moin dégradant de convertir tes pistes en 32 bit flottant.
Citation : Ca veut dire quoi ça?... que de toute facon mon sample 16 bit avant le traitement sera converti d'office en 32 bit à l'entrée du plug avant d'appliquer le traitement, puis reconverti en 16 bit à la sortie du plug?
oui sauf qu'il ne sera pas reconverti en 16 bit, il sera en 32 bit flottant à la sortie du plug, sauf dans le cas de traitements hors ligne, ou là le résultat est requantifié à la résolution du fichier.
Citation : alors autant laisser mes samples en 16 bits, comme ça j'ai pas à appliquer un dithering
et bien si, en toute fin lors de l'export au format cd (16 bit/44.1), il faudra mettre un dithering puisque comme dit au dessus, malgré le fait que tes samples de bases soient en 16 bit, une fois traités en interne (même avec un simple pan ou niveau via le fader) ils ressortent en 32 bit flottant, donc avec une mantisse de 23 bit, ce qui fait que lors de l'export en 16 bit( 15 bit de mantisse) tu vas "virer" les 8 derniers bit, donc dithering pour limiter l'effet dégradant de l'opération.
Citation : j'ai appris en lisant, qu'une règle d'or C au moins de traitement sur la chaine du signal, au moins de deterioration du signal originel (question fidélité, bruit, etc.)... du moins pour l'analogique... est ce le cas en numérique?
Non ce n'est pas vraiment le cas, en tout cas en terme de bruit, puisque justement le 32 bit flottant te permet de chainer autant d'effet que tu veux sans faire remonter le bruit de quantification.
Par exemple, en analo si tu chaines 15 equas même en bypass, bonjour les dégâts, en numérique et en flottant, pas l'ombre d'un soucis, tu récupères en sortie ce que tu avais en entrée.
Citation : A ce propos, quand j'exporte une piste solo midi pour en avoir une version audio qui me servira pour le mixage (car C conseillé de ne travailler qu'avec des pistes audio au mixage), dois-je la régler à son volume maximal pour avoir un meilleur rapport signal utile/bruit comme en analogique?
déjà il ya deux cas de figures:
- soit ton vsti lit des samples issus d'un échantillonnage (enregistrement d'un vrai instrument, d'un synthé analo, d'une BAR etc...)
- soit il génère de lui même (grace à un algorithme) un flux de données représentant un signal (genre émulation de machine existante...)
Dans le premier cas ton rapport signal/bruit est déjà défini, il sera équivalent au pus mauvais maillon de la chaine utilisé lors de l'enregistrement, donc coller le 0dBfs n'y changera rien.
Dans le second cas, si je ne dit pas de connerie, le seul bruit présent sera le bruit de quantification, donc si tu exportes ta piste en 24 bit il sera vers les -140dBfs, donc même à -40dBfs t'as encors un bon rapport signal/bruit.
Citation : Un plugin d'effet genre compress, EQ, etc.. introduit t'il du bruit comme en analogique?...
- En hors ligne sur un fichier en résolution fixe, oui, puisqu'il y a requantification au format du fichier
- En "temps réel" si le plug calcul en résolution fixe (Protools HD, tc powercore) ou sur une mantisse plus élevée (UAD etc...) et qu'il introduit un dithering pour rendre au format du soft, techniquement oui, mais on est quand même à des niveaux très bas, à mon avis il faut commencer à empiler un sacré paquet de pistes avant que ca devienne significatif.
Citation : 1 bit pour 6db?... n'est ce pas bcp plus petit que cela?
non, n'oublions pas qu'on code une tension, et que 6dB en plus correspond à un doublement de la tension, comme quand on rajoute un bit, on double le nombre de pas de quantification, et on gagne 6 dB de plage dynamique.
Je sais pas si je suis clair.
Citation : Si j'insiste, C pcq je vois qu'au niveau fréq d'échantillonage tu en connais un rayon
dans les grandes lignes, oui un peu, mais pour ce qui est de la mise en ouevre des algos que tu évoques, bof, en tout cas pas suffisemment pour te conseiller efficacement.
Tu peux aussi te fier à tes oreilles et choisir ce qui te convient le mieux.
Citation : Clair... je suis en train d'étudier ses treads même si G pas le niveau... le type est un tueur
je suis touché, mais ne me surestimez pas trop quand même, ce que je sais ets bien peu de chose par rapport à tout ce que je ne sait pas, et ce n'est vraiment pas de la fausse modestie.
Hors sujet : Citation : Et docks G été voir sur le lien CLIP WOOZ-LA RUE CHANTE RENAUD, C toi dans le clip?... Citation : Tu fais quoi comme genre de zik?...
non, c'est ben seagle (du collectif MOROVACH) et wooz, wooz étant l'artiste avec lequel je taf.
je ne suis pas musicien, je m'occupe surtout de toute la technique (prise de son, mixage, "mastering") à mon peit niveau, essentiellement en hiphop avec wooz justement, et parfois dans d'autres styles (pop/rock voir même métal ou autre...)pour des potes.
Anonyme
Anonyme
(quoi? fayot moi? 
)Citation : Redevenons sérieux (mais pas trop longtemps). Le dither ne doit être appliqué qu'une seule fois, et ce doit être la dernière opération
ben oui, c'est ce que j'ai dit, je me suis encors mal exprimé comme c'est là.
Citation : Il n'est pas tout à fait exact qu'en numérique, les traitements n'ajoutent pas de bruit, vu qu'a chaque opération on subit une nouvelle erreur de quantification
il me semblait justement (mais j'ai toujours eu un doute sur ce point) que le flottant évitait justement la remonté du bruit de quantification à chaque traitement.
Enfin même si c'est pas le cas, comme tu le soulignes, au niveau ou ca se passe, on s'en tape un peu.
Dr Pouet
Dr Pouet
Anonyme
Anonyme
En plus de ca, ca va finir en 16 bit, avec du coup un niveau de bruit de quantification qui va remonter vers les -90dBfs, alors celui qui se trouvait à -130, vraiment plus rien à secouer (déjà qu'avant
)Anonyme
Citation : Tout traitement ajoute une petite erreur. Pour que l'erreur soit constante il faudrait que la taille des nombres augmente à chaque traitement.
c'est là que je lache, et avoue mes lacunes.
Pour moi, l'erreur est "constante" dans le sens ou elle dépend du pas de quantification, donc l'erreur de quantification sera toujours comprise entre 0 et 0.5 fois le pas de quantification, et celui ci ne changeant pas, pourquoi le niveau de bruit changerait?
Pour moi il reste toujours du même ordre,non?
Y'a encors une subtilité à la con que j'ai pas du capter. Dr Pouet
Anonyme
Citation : Imaginons que l'on applique plusieurs fois de suite un gain de -6dB, ce qui revient à diviser la valeur de l'échantillon par 2
oui, on "utilisera" un bit de poids fort en moin.
Citation : Si je fais un arrondi à chaque fois :
17 -> (8,5) 9 -> (4,5) 5 -> (2,5) 3 -> (1,5) 2
Il y a le même nombre de division par deux, mais à la fin il y a un écart de plus de 0,5
On remarque aussi que pour rester exact il faut de plus en plus de chiffres
au final, j'ai quand même l'impression qu'on dit la même chose.
Dans ton exemple on voit que l'erreur est constante (et donc que le niveau de bruit n'augmente pas), il sera toujours égal à 0.5 max, ce qui se dégrade par contre, c'est le rapport signal/bruit, je sait je chippote, mais c'est pour être sûr que je comprend bien, parce que je reste quand même sur le fait que le niveau de bruit de quantification reste toujours du même ordre quelque soit le nombre de traitement qu'on empile (je parle là de théorie, car en pratique un compresseur peu faire remonter le bruit mais ce n'est pas du au principe de quantification), le signal quantifié sera toujours une approximation à 0.5 max près du signal réel, donc avec un bruit de quantification oscillant entre 0 et 0.5 fois le pas de quantification.
Dr Pouet
Anonyme
Dr Pouet
Citation : dans ton exemple, on cumule les erreurs, donc au final elle est plus importante, j'ai bon?
C'est ça. Mais comme dit précédemment, l'ordre de grandeur des erreurs même cumulées va rester faible. Et les exemples sont plutôt caricaturaux (erreurs toujours dans le même sens, petits nombres...)
Citation : Et c'est là ou il me semblait que ca n'était valable que pour des calculs en résolution fixe, et que le flottant évitait justement ce cumul d'erreurs, et qu'on se retrouvait avec une seule erreur supplémentaire
Ben non. Bien qu'on soit en flottant, le nombre de bits de mantisse est fixe, donc le nombre de chiffres permettant de représenter le nombre est fixe. Par contre on peut bouger la virgule et rajouter des zéros sans pertes (ce qui, au passage, offre un headroom fabuleux), tant qu'on dépasse pas la limite évidemment.
Voici des exemples en base 10, avec le nombre réel, puis une représentation informatique en virgule fixe et une autre en virgule flottante. Pour "émuler" protools (48 bits fixe sur une tranche mais 24 sur un bus) et les autres (32bits flottants = 24 de mantisse et 8 d'exposant), je vais simplifier et faire comme si PT était toujours en 32 bits fixes ; et imiter ça en base 10 par 4 chiffres sur PT, et 3 chiffres de mantisse +1 d'exposant pour les autres (Cubase, Logic, Live, Sonar...) En fait en réalité ce serait plutôt 7 chiffres décimaux qui correspondraient à 24 chiffres binaires.
Pour chacun, je mets d'abord le stockage informatique puis la représentation "humaine". Pour le fixe on a un nombre de 4 chiffres (qui devrait être signé, mais qui ne l'est pas dans mon exemple), pour le flottant on a 2 nombres : la mantisse sur 3 chiffres puis l'exposant sur 1 chiffre signé.
réel = 12 123 1234 12345 1,2 0,2 0,002 0,012345
fixei= 0012 0123 1234 clip! 0001 0000 0000 0000
fixeh= 12 123 1234 clip! 1 0 0 0
floti= 012 +0 123 +0 123 +1 123 +2 012 -1 002 -1 2 -3 123 -2
floth= 12 123 1230 12300 1,2 0,2 0,002 0,0123
réel = 123456789012 1234567890123 0,0000002
fixei= 0000
fixeh= clip ! clip ! 0000
floti= 123 +9 2 -7
floth= 123000000000 clip ! 0,0000002
Si je reprends mon exemple de traitement :
réel = 17 -> 8,5 -> 4,25 -> 2,125 -> 1,0625
fixe = 17 -> 9 -> 5 -> 3 -> 2
flott= 17 -> 8,5 -> 4,25 -> 2,13 -> 1,07
On peut en conclure que le format protools est un tout petit peu plus précis pour des signaux ayant un bon gain, mais est beaucoup moins précis sur les petits signaux, et n'offre pas ou peu de headroom (comparé aux 700dB de Cubase, Logic et co ;) ).
Pour finir, je crois que la dernière version de Sonar est en 64 bits flottants. Si ça s'entendait nettement, tout le monde abandonnerait immédiatement Protools, Cubase, Logic, Live et autres pour passer sur Sonar, ce qui n'est pas le cas !
Citation : -calcul en résolution fixe (ou offline sur un fichier en résolution fixe) = cumul des erreurs
-calcul en flottant = une seule erreur à la fin lors de l'export en résolution fixe
Non : il y a cumul des erreurs dans tous les cas, car presque à chaque opération il y a un arrondi. De même que si on fait bêtement :
10 / 3 = 0,333 et 0,333 x 3 = 0,999 au lieu de 10.
Mais en résolution fixe on "perd" plein de chiffres dès qu'on s'approche des limites : grands nombres = "clip" ci-dessus, petits nombres = 0 ci-dessus aussi.
(tout ça est assez peu intéressant et plutôt casse-tête, mais ça a un rapport avec l'actualité avec le bug de la sécu qui est un peu dans ce genre de problématique ;) )
Anonyme
Citation : -calcul en résolution fixe (ou offline sur un fichier en résolution fixe) = cumul des erreurs
-calcul en flottant = une seule erreur à la fin lors de l'export en résolution fixe
Non : il y a cumul des erreurs dans tous les cas, car presque à chaque opération il y a un arrondi. De même que si on fait bêtement :
10 / 3 = 0,333 et 0,333 x 10 = 0,999 au lieu de 10.
Mais en résolution fixe on "perd" plein de chiffres dès qu'on s'approche des limites : grands nombres = "clip" ci-dessus, petits nombres = 0 ci-dessus aussi.
ok, ca change juste "l'échelle" de l'erreur.
Citation : tout ça est assez peu intéressant et plutôt casse-tête
casse tête c'est clair, on a vite fait de s'y perdre.
peu intéressant, d'un point de vue pratique, c'est clair aussi, on s'en tape profondément, d'un point de vue théorique, j'aime bien, par simple curiosité, savoir comment tout ca fonctionne, et il faut bien reconnaitre que tu es souvent sur le coup.
- < Liste des sujets
- Charte
- 1
- 2