Conversion sample 16 bit vers 32 bit. pertes?
- 38 réponses
- 9 participants
- 6 938 vues
- 2 followers
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.
Anonyme
Dr Pouet
Est-ce que tu sais comment se répartissent les 48 bits fixes entre headroom (au dessus de zéro dB) et "signal utile" (en dessous de zéro dB) ?
Anonyme
Te v'la bien avancé
JM
Anonyme
Dr Pouet
- < Liste des sujets
- Charte