besoin aide CNA R2R 16 bits...

On Jul 15, 11:55 pm, whygee

Ah bon ?

Inverser le MSB c'est pas la meme chose qu'inverser juste le bit de poids fort !

De toutes facons, le bit de poids fort n'est pas le signe. Un entier signe est code en complement a deux.

Quand aux format (Big Endian ou Little Endian) des fichiers WAV, j'ai deja poste deux liens ou tout est decrit en detail ... ca rame !

On Jul 15, 9:15=A0pm, "GzavSnap"

Doubler le circuit electronique du CNA, au lieu d'une ligne de code pour convertir la donnee 16 bits en non-signe ? Tu coutes cher, toi ...

d=E9buts

e. Mais

Et ca forme l'esprit ...

Parce-qu'il n'a pas encore compris que c'est la bonne reponse, il s'est plante en convertissant le complement a 2 en non-signe. Tous sur UseNet demain pour la suite de l'episode ... peut-etre.

:)

On ne sait pas ce qu'il fait comme metier, mais on sait deja ce qu'il ne fait pas ;-)

=E7a me semble =E9vident... cela dit, j'ai pas test=E9.

ah ? Pour moi MSB signifie Most Significant Bit, c'est la m=EAme chose. Tu as compris Most Significant Byte ?

bon alors je vais tenter avec un mot de 3 bits,

valeur sign=E9 non sign=E9

-4 100

-3 101

-2 110

-1 111

0 000 000 1 001 001 2 010 010 3 011 011 4 100 5 101 6 110 7 111

On estime qu'il faut faire +4 pour passer d'une valeur sign=E9e centr=E9e= sur 0 =E0 une valeur non sign=E9e centr=E9e sur 4.

sign=E9 non sign=E9

-4 100 --> 000 0

-3 101 --> 001 1

-2 110 --> 010 2

-1 111 --> 011 3

0 000 --> 100 4 1 001 --> 101 5 2 010 --> 110 6 3 011 --> 111 7

Moi je ne vois qu'une chose : le MSB est invers=E9 entre sign=E9 et non s= ign=E9.

Ceci dit, Vede s'est peut-=EAtre tromp=E9 dans la g=E9n=E9ration de son f= ichier Wav, ou alors le soft de son qu'il utilise a un bug.

bienvenue sur Usenet :-)

@+

--=20

/

On Jul 16, 5:28 am, whygee

Ouch ... je viens de realiser ou est le probleme : il s'agit bien de convertir un signe en non-signe, mais *en plus* l'amplitude doit etre recentree ! Voici un resume (limpide, j'espere)

Oui, et c'est bien ce que l'on suppose depuis le debut : par exemple quand on parle d'intervertir le MSB et le LSB d'un mot de 16 bits, il ne s'agit pas d'intervertir les bits de poids fort et faible, mais bien les octets eux-memes. C'est vrai qu'en Anglais, le 'B' de Bit et Byte peuvent dependre du contexte pour etre interpretes correctement. C'est dans doute pour cela qu'on ecrit 'B' pour 'byte' et 'b' pour 'bit'.

Mais meme si tu "prouves" ta methode en enumerant tous les entiers, cela ne prouverait rien pour les entiers construits sur un nombre different de bits, sur 16 bits tu devrais enumerer 65536 valeurs, et que dire sur 64 bits ... Pourquoi ne pas partir de la definition meme du codage d'un entier signe, et construire une preuve qui fonctionne quelque soit le nombre de bits ?

ign=E9.

Oui, parce-que *dans ce cas* il faut en plus deplacer le zero, car sur un entier signe, le zero est a 0x8000 et non pas a 0x0000. Ton inversion du bit de poids fort n'est *pas* une conversion signe -> non signe, il y a aussi ce decalage du zero ...

Ce qui est trompeur est que l'on constate que les entiers negatifs ont bien le bit de poids fort a un, mais cela ne signifie pas qu'il suffit de complementer ce bit pour en obtenir la valeur absolue. Dans le cas dont on parle, pour les 16bits d'un fichier WAV, le fait qu'il faille *en plus* decaler la valeur centrale, se ramene effectivement a une inversion du bit de poids fort :-)

Mais il peut lever le doute en testant son fichier WAV 16 bits avec n'importe quel lecteur, ou en convertissant n'importe quel WAV au format

16 bits mono, avec par exemple sndrec32.exe ...

Merci, ca fait plus de 7 ans que je rode sur UseNet ...

vede a ecrit

C'est peut etre aussi un probleme de PIC, faut voir la provenance mdr

je crois que là tu es sur un probleme decomposable de determination, ton probleme est sur la sortie physique l'ideal est de bypasser les "strates"

- avant de t'obstiner à lire la SD est ce qu'une simple lecture d'un tout petit echantillon wav extrait est correcte vue à l'oscillo ?

- pour caracteriser le probleme eventuel du à la quantification, il y a aussi la possibilité de degrader la resolution numerique

8->10->12->14->16

- utiliser un vrai wav de test 50 100 300 1000 3000 5000 10k 20k Hz pour eventuellement determiner simplement à l'oreille la bande foireuse

Rvl

Bonjour =E0 tous

c'est un 18F452 que j'ai trouv=E9 un matin dans la bal de ma copine ;O]

le .wav est nickel, la lecture SD aussi (d'ailleurs =E7a fonctionne avec des fichiers 8bits/16Khz)

si =E7a continue c'est ce que je ferais...

comme vous l'aurez tous remarqu=E9 j'ai quelques difficult=E9s avec la manipulation des bits ;O]

bon je m'y remet, et vous tiens au jus, vede ;O]

On Jul 16, 4:06=A0pm, vede

Euh ... et si tu demandais a ta copine ?

(desole, je vais effacer mon message ... oops, trop tard ;-)

ce dessin conforte mon opinion, et cela revient bien =E0 inverser le bit de poids fort. et puis c'est tout :-)

=2E

apparemment =E7a reste encore parfois ambigu.

a

de bits,

=2E.. une preuve par r=E9currence, =E7a suffirait ? J'ai fait au plus simple, j'allais pas =E9crire un recueil de maths. on est entre =E9lectroniciens ici :-)

e,

la "preuve" que vede veut, c'est que =E7a marche, pour =E7a, pas besoin de remonter =E0 l'axiomatique de Peano ou la th=E9o= rie des nombres...

n sign=E9.

c'est pourtant n=E9cessaire, non ? comment pourrait-on faire sans ajouter un offset ? Sans ce d=E9calage, les samples vont reboucler par le mauvais c=F4t=E9.

on fait pas de DSP ici, donc on s'en fout un peu de la valeur absolue, l'essentiel c'est que tout sample en entr=E9e corresponde =E0 ce que la s= ortie attend.

d'ailleurs, c'est parfois traitre, la valeur absolue...

bon.

n

myst=E8re... j'esp=E8re qu'il nous tiendra au courant de ses d=E9couvertes :-)

Le ":-)" indique un ton farceur assum=E9, ce n'est donc pas une remise en cause de ton exp=E9rience :-)

@+

yg

--=20

/

vede a écrit :

suggestion: si le fonctionnement en 8 bits est correct, commence les tests avec un seul bit supplementaire, puis avec 2, puis avec 3... etc ... (commencer avec le msb) quand est-ce que les problemes surviennent?

On Jul 16, 4:06=A0pm, vede

grrr ... je crois que tu est sourd :

Oui, mais c'est la méthode la plus rapide... à moins que le taux d'échantillonnage soit faible. Car il ne suffit pas d'enlever le bit de signe dans ce cas!

Mais Jean-Christophe... C'est quesqu'on te dit depuis le début ! C'est signé positif/négatif avec un silence symétrique... d'amplitude ... après je décroche. Non, habituellement je suis soft... mais sur ce coup ... je pense qu'il est préférable d'évoluer sur un circuit différent. Vede, tu dois repenser ton montage avec un pont de résistance 15bits et utiliser le bit de signe pour commuter la tension en négatif... un peu comme un pont diode de redressement... mais avec 2 transistors et deux diodes. Nous ne some plus en linéaire sur de coup. Il faut donc trouver une astuce pour adapter le circuit au format... car la conversion en temp réel sera de toute façon ... trop longue. Si tu as le plan d'un générateur de fonction/sinus (ceux que l'on utilisait pour créer un courant alternatif), et si tu l'adapte en 14 bits (résolution sur une demie periode) tu aurras plus de chance d'avoir un résultat plus propre. D'autre part, essai de faire fonctionner le montage sur 1 seul byte, le MSB ou le LSB. Tu mets le second au silence. ça marchera pas mieux... mais je suis curieux de savoir le bruit que ça fera. De mon côté je vais regarder ! ;-) Peut-être que tu as inversé les deux bytes de donnée. ça arrive souvent... le pointeur de début doit être décallé.

Heu... Bref ! ... le plus important c'est de participer !

vede se fendait de cette prose :

Tu as essayé de jouer un wav 8 bits sur l'octet poids fort ? (ou poids faible si tu étais en poids fort ?)

--
LeLapin

. a

de bits,

...

e,

rie des nombres...

n sign=E9.

ortie attend.

n

Bonsoir =E0 tous,

et merci pour vos contributions

bon j'ai t=E9st=E9 les exemples de Jean Christophe

avec des variables *non signees* : Mmc_Fat_Read(mymsb) ' read MSB Mmc_Fat_Read(mylsb) ' read LSB data =3D mymsb ' conversion 8 bits vers 16 bits data =3D (data * $100) + mylsb ' concatenation if data >=3D $8000 then data =3D $FFFF - data ' conversion end if mymsb =3D data DIV $100 ' deconcatenation mylsb =3D data MOD $100 ' deconcatenation PORTD =3D mymsb ' ecriture CNA PORTB =3D mylsb ' ecriture CNA

et (declare les variables en non-signe)

void WriteCna(void) { unsigned char msb, lsb; // 8 bits unsigned int n; // sample 16 bits // lecture d'un sample WAV 16 bits mono Mmc_Fat_Read(msb); // MSB Mmc_Fat_Read(lsb); // LSB// concatenation n =3D ( ((unsigned int)(msb)) 0x7FFF ) n =3D 0xFFFF - n; // deconcatenation avec cast implicite msb =3D n >> 8; // MSB lsb =3D n & 0xFF; // LSB // ecriture sur le CNA PORTD =3D msb; // ecrit le MSB vers le CNA PORTB =3D lsb; // ecrit le LSB vers le CNA

}

sans succ=E9s.... Le fichier audio n'est m=EAme pas reconnaissable =E0 l'oreille...

alors qu'en ne faisant aucun traitement cad envoyer les octets tels quels sur les ports, ou en utilisant le simple traitement mymsb =3D mymsb xor $80 on "reconnait" le fichier =E0 l'oreille... mais noy=E9 dans un gros bruits et compl=E9tement distordu et amput=E9...

le fichier audio dit une suite de mots entrecoup=E9s de silence...

bon voil=E0, je continue =E0 chercher... vais repartir sur un compl=E9ment par 2... sinon avec un fichier avec un signal 100Hz carr=E9... et un =E9diteur h=E9xad=E9cimal...pour d=E9coder, voir, tenter... je vous tiens au jus,

vede ;O]

On Jul 16, 5:03 pm, whygee

:op Ce que je precise est que complementer le bit de poids fort n'est PAS une conversion signed->unsigned ! Cela marche dans ce cas, parce-qu'EN PLUS de cela il faut recentrer le zero (sinon le CAN ecrete) mais bon, on y est.

Ce serait plus solide, mais bon, maintenant qu'on est d'accord ...

Un electronicien sans des bases de maths, ca va pas loin ... C'est pas grave de ne pas connaitre les maths, parce-que ca s'apprend. Ce qui est plus grave est de ne pas savoir raisonner sur des concepts. Mais bon, je m'arrete la, sinon on va dire que je ronchonne ... ( comment ca : on le dit tout le temps ? ;-)

rie des nombres...

Et laissons Godel de cote, sinon il va encore nous casser la baraque ;-) D'ailleurs ca fait un moment que je lui dis (a Vede, pas a Godel) d'ou vient le probleme, mais il semble sourd: peut-etre que son CNA a explose ?

n sign=E9.

Rrrrrrrrrooogntudjjuuuuuuuuuuuuuuuuuuuuuuuuuuuu !!! OUI : complementer le msb resoud bien le probleme du WAV 16 bits. NON : ce que tu decris n'est PAS une conversion 'signe -> non signe', c'est une conversion 'signe -> non signe' *SUIVIE* d'un ajout d'offset. Fais la manip sur ton PC (en Basic, Pascal, C, ce que tu veux) et tu verras. Ou alors regarde la definition d'un entier signe (complement a 2) avec un stylo et une feuille de papier, Tudjiuuuuuuuuuuuuuuuu !

Tout a fait.

ortie attend.

Y'a pas de DSP du tout : on veut corriger le probleme du repli de l'amplitude, qui est justement du au fait que le WAV 16 bits est en entier signe !

Non ?

Moi aussi ... je n'ai pas pu fermer l'euil la nuit derniere ...

Je ne l'avais pas mal pris, j'en ajoutais juste une couche :->

On Jul 16, 5:29=A0pm, "GzavSnap"

.

Excuse-moi mais je ne comprends pas ta reponse :

J'ai eu le meme probleme avec des fichiers RIFF/WAV entre les formats 8 et 16 bits, et je trouve plus rapide (et surtout bien moins couteux) de convertir chaque sample

16 bits avec une ligne de code, plutot que de doubler l'ensemble de la circuiterie electronique du CNA !

Maintenant, si tu parles de rapidite au sens "temps reel", avec un uC d'aujourd'hui et une bande passante de 20 KHz en audio, on a bien le temps de convertir ces 16 bits a la volee. A la rigueur on peut aussi convertir le fichier entier en amont. Et pour une appli vraiment realtime, on ne va pas se gonfler a utiliser un format 16 bits WAV qu'il faudra trafiquer de toutes facons, autant utiliser des le depart du 16 bits non-signe tel que l'attend le CNA.

On Jul 16, 6:42 pm, vede

C'est du Madonna ?

Ah ben merdalors, il vient d'ou ton fichier WAV ? Tu l'as genere toi-meme ? Tu est bien sur de son format ?

Un signal carre ne t'aidera pas a voir les repliements, tandis-qu'avec un signal triangulaire, ce ce sera plus facile pour suivre les valeurs 16 bits.

As-tu un bon editeur hexa ?

"Thiernesse Vincent" a écrit dans le message de news: 4a5df95b$0$23472$ snipped-for-privacy@news.orange.fr...

j'allais soulever le même point...

c'est pas la peine de dépanner le truc avant de s'être penché sur cette question...et d'abandonner l'idée...