Bonjour,
 
je travaille sur le format wav et je voudrais savoir sur quelles plage de valeurs est codé ce format en 32 bits.
J ene trouve pas l'info sur google.
 
Sont-ce des float [-1;1] ?
 
merci.

Salut,
 
Et ici?

salut
 
je suis pas sur de répondre a ta question, mais une résolution de 32 bits donne 4294967296 valeurs possibles (2^32), donc logiquement ton signal audio peut prendre comme valeur min -2147483648 et comme valeur max +2147483648.
j'ai jamais étudié de wav 32 bits, mais en tout cas pour du 16 bits je suis certain qu'il y a 65536 valeurs possibles (2^16) donc le principe doit etre le meme pour du 32 bits...

 
En audio c'est souvent du float (32 bit) qui est utilisé et non du int (32 bit) car un phénomène physique (analogique) est plus facilement assimilable en virgule flottante. Par exemple le milieu d'un sample 4 bit signé se situe entre [-1, 0] ce qui est souvent arrondi à 0.

Salut, merci pour vos reponses.
 
A vrai dire je connais deja la representation binaire des floats et des doubles, ce que je cherche, c'est comment le format wav code ses valeurs en float 32? utilise-t-il toute la plage de valeurs possible ? ou se restreint-il a l'utilisation du bit de signe + les 23 bits de fraction, pour avoir une plage entre -1 et 1, plus exploitable par les logiciels.
 
En cours de traitement du son, on se servait de tableaux [-1 et 1] justement mais du coup, on perds pas mal de valeurs du fait des 8 bits d'exposant non utilisés alors je trouve cela bizare...
 
Quelqu'un à des infos la dessus ?
 
Les valeurs que je récupère sont étrange, du style -1#QNAN.
 
Cela designe-t-il un tres petit nombre ?

A priori ton mot binaire ne suis pas le format normalisé IEEE754 des nombres à virgule flottante et NAN indique Not A Number.

arretez de fumer les gars, le wav en raw ou en pcm (le .wav est un container hein) stocke les echantillons en virgule fixe et non en flottant. (donc sous fome d'entiers )
Pour une raison simple : les convertisseurs utilisent des nombres entiers, signés (ou non, peu importe ce n'est qu'une histoire de convention). Et le raw audio est fait pour attaquer directement les convertisseurs numeriques analogiques.

Les convertisseurs audio ne depasssent pas vraiment les 24 bits de dynamique parcequ'on n'en a pas besoin, a raison de 6db par bit on arrive a environ 90db de snr en 16 bits, (il y a un offset de correction).
Je vous laisse calculer pour 24 bits...
Peu de systemes audio depassent les 100db de rapport signal a bruit, alors pourquoi mettre du flottant la ou la virgule fixe suffit !

donc maintenant si tu normalises tes valeurs (/65536 pour 16 bits signés), oui tu auras un truc entre -1 et +1, que le pc interpretera alors en float vu aue ce sera un nombre a virgule, mais ca reste de la virgule fixe pour la dynamique de tes calculs, pas de mantisse + exposant, uniquement une mantisse de taille 16,24,32... bits selon la representation.

 
 
Diviser par 65535 ne suffit pas pour normaliser.
 
Soit n un entier non signé 16 bit compris entre [0, 65535].
 
n/65535 => un nombre entre [0, 1]
 
n/65535 - 0.5 => un nombre entre [-0.5, 0.5]
 
2 * (n/65535 - 0.5) => un nombre entre [-1, 1]
 
CQFD

tu as raison mon explication de normalisation etait un peu rapide.
 
Par contre excuse moi mais tu racontes un peu n'importe quoi quand tu parles de representation des nombres en flottant pour l''audio :    
 

 
Tu as entendu parler des convertisseurs (AD ou DA)?  
C'est la source/destination actuelle de toute donnee en audio, et ils te fournissent/utilisent une valeur en entier (ou fractionnaire, cést la meme chose a la normalisation pres). Il fonctionnent actuellement dans les produits grand public ou ameliores en 16, 20, parfois 24 bits mais pas au dela.
 
Les augmentations de precision ont lieu parfois au dela de 16/20/24 bits, et certains calculs passent en double precision (32 bits), comme par exemple les bons decodeurs mp3, en effet on ameliore ainsi la qualite de decodage en renvoyant le bruit de quantification au dela de la dynamique du convertisseur. Mais nul besoin de passer au dela comme par exemple en flottant, ou sinon ce n'est plus de l'audio que l'on ecoute, ce sont d'autres applications (sonar ou autres ...).  
Et de toute facon les dynamiques offertes sont largement suffisantes, cf mon post plus haut.

Quand je parle de virgule flottante je me réfère au type de la variable même si la virgule ne bouge pas d'un chouilla. ;-)
 

 
Tu ne m'apprends rien que je ne sache déjà. Le passage au float 32 bit est essentiellement utilisé pour le post-processing.

alors on est d'accord.
PS : la normalisation utilise 65536 et non 65535, ce doit etre des puissances de 2...

 
Ma "démonstration" ne t'as pas convaincu de l'utilité de 65535. Fais le calcul ou bien corrige mon erreur ce sera encore mieux. ;-)

ok, GT a la bourre tt a l'heure, desole, j'explique mon propos:
 
les entiers signes se representent sur 16 bits entre -32768 et 32767 (la representation signee est asymetrique a cause du bit de signe et/ou en fait du 0 qui est code comme un nombre positif).
A normaliser entre [-1,+1[ pour obtenir un fractionnaire.
du coup en divisant par 32768 on se ramene a cette echelle qui ne represente pas +1 de maniere exacte.
Ton approche a diviser par 32767 ou 65535  a sa logique purement mathematique, je suis d'accord mais elle ne se represente pas simplement sur un processeur.
 
la representation Q15, la plus utilisee sur les DSP :
les fractionnaires sont des representation de puissances de deux en dessous de la virgule :
premier bit (MSB) -2^0
second bit 2^-1
3ieme bit 2^-2
4ieme bit 2^-3
5ieme bit 2^-4
...
15ieme bit 2^-14
16ieme bit 2^-15
 
le plus grand nombre negatif est 0x8000 soit -2^0
le plu grand nombre positif est 0x7FFF soit 2^-1 + 2^-2 ... + 2^-15 soit encore 1-2^-15.
 
 
En extrapolant on obtient la reponse initiale du post pour du wav 32 bits :
plage de -2^31 a +2^31 - 1
soit en normalise -1 a 1-2^-31
 
et ici tu verra que le wav ne stocke pas de flottant, ou alors en trichant un peu
http://ccrma.stanford.edu/courses/ [...] aveFormat/
 
le champ BitsPerSample ne sait coder que le nombre de bits de la representation, pas son format en flottant (certes on pourrait tricher, declarer 32 bits et utiliser derriere la notation IEEE, mais on commence a developper son format là).

 
C'est bien là tout le problème!

oui, mais sur un proc tu n'as pas le choix.  
D'ou la representation en q15.
Au passage ca a qques avantages, par exemple pour la representation de la phase.
 
expliqué en details ici :
http://www.swarthmore.edu/NatSci/e [...] ml#posfrac

 
Ah bon? Sur x86 mon calcul est tout à fait valable et précis.

oui en effet, mais pour etre precis ton calcul doit etre realise en flottant, pas en virgule fixe.  
sinon explique moi commment tu representes tes donnees sur 16 bits ?
 
un x86 est un processeur a virgule flottante.
 
ce qui est tres loin d'etre le cas pour tous les cpu parceque c'est cher et ca consomme une fpu, donc on a des cpu a virgule fixe dans enormement d'equipements:
telephones, pda
ipod et autres balladeurs
lecteurs cd
set top box genre freebox
etc etc
 
et le Q15 (ou autre cadrage) est alors massivement utilise, et au passage suffit (sinon on passe en q23 ou q31) pour representer des echantillons audio.

 
Je vois pas ce qui te dérange d'utiliser un float 32 bit pour du 16 bit, la précision est suffisante.
 

 
La virgule flottante n'est pas une obligation. Tout dépend de la dynamique des valeurs utilisées.
 

 
Pour l'embarqué il est clair qu'on ne va pas coder sur du C2D ou du X2 car ce serait utiliser un bazooka pour écraser une mouche.

on tourne pas un peu en rond la ?

pour repondre a un point, utiliser un float 32 bit pour du 16 bit, oui c'est possible, ca marchera pas mal mais :
- ca pourrait ne pas rester bit exact et introduire une difference sur les resultats
- comme tu dis, ce serait utiliser un bazooka pour écraser une mouche. Si les resultats sont bon en virgule fixe, pourquoi passer en flottant ?

 
Comment te faire comprendre qu'on ne va pas inventer des PU sur un x86 pour utiliser des virgules fixes amenant un résultant imprécis alors qu'on dispose de bazooka (float, double, long double), autant s'en servir!

 
Pardon, mais pourquoi tu dis ça ? tu vois bien sur la page que tu me donne qu'il y a un bit de signe, 8 bits d'exponent et 23 autres bits de fraction
 
Bon j'ai fait un petit test, parce que vous ne m'aidez pas beaucoup a vrai dire   !
J'ai exporté en wav à partir de fruityloops (pas bien!) un son completement saturé.
FL me propose 3 format d'export : wav16, 32 float, et 32 Audition (tm)
 
Résultat :
 
Dans le fichier wav 16bits la valeur 0 = 0, minimum atteint -32767, maximum 32767.
Une valeur n'est donc simplement pas utilisée afin de préserver la symétrie.
 
wav 32float : les valeurs sont entre -1. et 1. avec 0. comme silence. Donc bien comme je l'avais suggéré plus haut. A ma grande surprise, les bits d'exponent ne sont pour autant pas inutilisés! Lorsque le son sature, FL ne clippe pas les valeurs à 1. ou -1. mais laisse dépasser celles-ci ce qui fait que l'info est toujours là, non saturée.
Lorsque je lis le fichier avec winamp (une vieille version) j'ai le comportement suivant : les bits d'exponent sont simplement ignorés et lorsqu'il y a saturation, les valeurs "repartent à zero" (modulo les bits d'exponent donc) et le son est dénaturé, trés éloigné du rendu sous FL.
Par contre Windows Media Player lui, fait un clip des valeurs à 1. et 1. donc le son rend saturé.
Mais les données étant toujours dans le fichier, elles sont encore exploitables même si seul les 24bits de fraction et signe seront joués par un lecteur.
 
Pour le Wav Audition j'ai pas eu trop le temps d'analyser mais à priori ce sont des entiers signés sur 31bits ( je ne sais pas pourquoi ) entre - 1 milliard et 1 milliard

Petite question: ton fichier est issu de quelle source?

Je l'ai dis dans le message précédent, l'export des 3 différents .wav a été fait à partir de fruity loops ou plutot FLStudio le son étudié est une sine basique générée par un VST quelconque.
Si vous avez envie de me faire des petits samples sous divers logiciels je regarderai comment ils sont foutus et si il suivent la même logique. Afin de voir comment sont gérés les valeurs min et max et le zero, faite saturer l'output et ne commencez le son qu'un peu apres le debut pour laisser un tout petit silence.

 
Pour générer un sinus basique tu n'as pas besoin d'un VST, Audacity peut générer sinus, triangle, carré dans la forme binaire que tu souhaites. En voici un sample (silence 5s + sinus@440Hz 5s 48 kHz 16 bit).

Je n'ai pas d'editeur audio ici, lorsque j'ai installé Audacity il plantait dès que je mettais play...
Je ne peux pas installer Adobe Audition sur mon portable va savoir pk. N'etant pas chez moi depuis quelques mois, je n'ai que FruityLoops sous la main.
 
Merci pour le sample je regarde comment audacity gère le 16bits et je te dis.

ok, ton sample à pour valuer nulle 0, minimum -32768 et max 32767.
Donc toutes les valeurs sont utilisées et le sample est asymétrique.
 
Ca ne m'étonne pas car c'est marqué dans les sources d'Audacity.
 
Maintenant j'aimerais bien connaitre le fonctionnement de soundforge et d'audition, en 16 et en 32.
Avis a ceux qui veulent me faire des samples.