Cpcdos
Messages postés425Date d'inscriptionsamedi 11 juillet 2009StatutMembreDernière intervention28 octobre 2016
-
4 août 2011 à 17:56
Utilisateur anonyme -
5 août 2011 à 20:19
Bonjour , voilà j'ai besoin d'aide , c'est pour chercher en inverse
cet a dire que à la fin , la variable bt me donne "175"
et je voudrais retrouver "500" dans la variable Freq grâce a 175 (l'inverse)
ucfoutu
Messages postés18038Date d'inscriptionlundi 7 décembre 2009StatutModérateurDernière intervention11 avril 2018212 4 août 2011 à 18:19
bt = CByte((127 * Math.Sin(i1 * (2 * pi * Freq / SRate)))+ 128)
où
tu connais bt,i1 et SRate ===>>
175 = CByte((127 * Math.Sin(540 * (2 * pi * Freq / 8000)))+ 128)
ce qui te fait une équation à une seule inconnue, qui est frécisément Freq
Equation de surcroît du premier degré !
De l'algèbre simple, quoi, avant de parler de développement
____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP
Cpcdos
Messages postés425Date d'inscriptionsamedi 11 juillet 2009StatutMembreDernière intervention28 octobre 20161 4 août 2011 à 19:28
Je vous remercie pour votre réponse
mais SI je remplace l'inconnue Freq par ce que je dois trouver , "500" , je trouve
bt = 2
[i]
enfaite il faut que je révise mes maths , pourtant j'ai passé mon brevet /i
ucfoutu
Messages postés18038Date d'inscriptionlundi 7 décembre 2009StatutModérateurDernière intervention11 avril 2018212 5 août 2011 à 10:10
Je commencerais personnellement à vérifier la valeur de PI en mode debug.
Mais ce n'est pas tout !
Comment peut-on raisonnablement espérer retrouver une donnée exacte (un integer au départ) à partir d'un résultat de type byte, lui-même obtenu par des opérations utilisant des décimales ? ===>> car alors que ce résultat était avec décimales, sa transformation en byte fait disparaître ces décimales.
Cette "affaire" ne génêrerait dans la plupart des cas qu'un delta d'erreur insignifiant. Tel n'est pas le cas lorsqu'un sinus est utilisé.
____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP
ucfoutu
Messages postés18038Date d'inscriptionlundi 7 décembre 2009StatutModérateurDernière intervention11 avril 2018212 5 août 2011 à 10:24
Pour être plus "visuellement" pratique :
entre toto 1.1 et titi 1.5, on a une différence de 36%
La différence entre cbyte(toto) et cbyte(titi) serait de 100% puisque cbyte(toto) 1 et cbyte(titi) 2
!
Bref... je vais aller à la pêche à l'éperlan (on y est plus raisonnable autour de moi, entre pêcheurs sages et réalistes)
____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP
ucfoutu
Messages postés18038Date d'inscriptionlundi 7 décembre 2009StatutModérateurDernière intervention11 avril 2018212 5 août 2011 à 11:28
bein merci de ton aide , je vais essayer de trouver une solution
Hé bien, moi, je vais te dire ce que tu "peux faire" ===>>
Abandonner cette démarche de réversibilité de de qui n'est pas réversible.
ou alors :
Accompagner ton "fichier wav" d'un autre fichier contenant les vraies valeurs (et dans l'ordre) pour retransposer en fichier "originel"
Et même ainsi : Pi, déjà, n'est pas un nombre fini, ce qui fait que :
- dans un sens (vers des bytes) tu auras un résultat utilisable dans ton fichier .wav
- dans ton fichier annexe, tu ne sauras y mettre la correspondance "finie" de valeurs "non finies". Tu ne pourras donc même pas utiliser parfaitement ces valeurs. Et alors ? que vas-tu faire ? Chercher la valeur "approximative" entière la plus proche ? ===>> bonjour les dégâts !
Ah mais !.....
Que faire alors pour tout retrouver parfaitement ?
Ben, ma foi ... heu .... re-heu..... hmm ... re-hmmm ... conserver en "parallèle" le vrai fichier, tel qu'il était ... et .... M O U A R F !
___________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP
Bonsoir,
Je vais préciser ce que je t'expliquais plus haut :
Souvent (dans les fichiers midi par exemple) on stocke un grand chiffre comme le tiens en le décomposant sur plusieurs bytes.
exemple byte1 : 63
byte2 : 28
byte3 : 4
puis on fait la conversion :
(byte1 * (256 * 256)) + (byte2 * 256) + byte3
dans ce cas : 4128768 + 7168 + 4
soit : 4135940
Il est facile de renverser le calcul dans l'autre sens pour obtenir les 3 bytes à écrire dans ton fichier compressé à partir de ta fréquence (Freq).