fp4=fopen("mssgeoriginal.txt","w+b");//check routine output for comparison.
fwrite(message,4,14,fp4);
avec message un tableau de long contenant des constantes (et pas accédé jusque la)
message[0]=0xB5620106;
message[1]=52;
etc…
le hic c que quand je regarde le fichier ecrit, l’ordre des octets pour le long est inversé :
ex:
060162B5
pour la première case par exemple.
je c que c un truc little endian/big endian.
j’utilise devc++ sous windows pour developper mais je c pas ou je peux régler le paramètre pour que le compilateur me traite mes nombres en little ou big endian (peu importe le principal c qu’il garde cette convention pour toutes les fonctions…)
qqun aurait une idée ou ce trouve ce fameux paramètre ?
(ou alors une autre fontion pour écrire un long en binaire brut dans un fichier)
Vu que ça dépend du processeur, je doute que le compilateur puisse produire un exécutable travaillant en big endian, et fonctionnant sur ta machine (je présume que c’est du Windows, donc x86, dont little endian)
Tu as ntohs/ntohl (network to host short/long) et htons/htonl (host to network short/long) qui te permettent de faire mumuse avec ça.
fp4=fopen("mssgeoriginal.txt","w+b");//check routine output for comparison.
fwrite(message,sizeof(char), 4 * 14,fp4);
enfin bon, je pense pas…
EDIT: Ha ben non, ça marche pas… mais je viens de voir qu’il existe une instruction ASM pour convertire une valeur de big endian en litlle endian (BSWAP).
Ca ne répond pas à son problème :??:
Il faut que, par exemple le chiffre 0xABCD qui est stocké comme 0xDCBA en little endian soit stocké sous la forme original 0xABCD, il faut donc swaper les bits.
Les bytes plutôt? Mais l’instruction X86 BSWAP le fait.
Mais bon comme je suis pas un dieu en assembleur (loin de la) je ne peux pas le faire. Si tu arrives à nous pondre une fonction avec de l’assembleur à l’intérieur qui inverse les bytes d’un entier tout bête :whistle:
Bah je ne suis pas sous windows, mais sous debian…
et pour le problème des indiens (moi je dit indiens pas endian), la fonction htonl() marche tres bien…
le seul soucis ke j’ai encore, c’est pour connaitre la taille des frames
1 frame = header(4 octets) + Data(??? octets)
donc voila, faut parcourir le fichier et a chaque fois k’on trouve les bits de synchronisation du header on lit le bitrate pour calculer la durée de la frame?
ou y’a un moyen de savoir la taille des data mp3 ??
Le problème du big/little endian n’a rien à voir avec le fait que tu sois sous Windows ou Linux mais sur un cpu x86 ou ppc par exemple.
Pour connaitre la taille de la trame, je lit le fichier jusqu’à trouver la première trame valide, si c’est du CBR, je calcule la taille en utilisant le bitrate et le taux d’échantillonnage, la, vu que je connais la taille de la trame, je seek à la prochaine trame et je la compare avec la trame courante, si elles sont identique, ça rulez, pas besoin de continuer à parser le fichier.
Si c’est en VBR, la faudra tatouiller le header VBR ou VBRi comme je te l’ai indiqué, tout se trouve dedans, tu n’as rien à calculer.
Pour la frame sync, tu DOIS bien checker comme il faut, les 11 bits mais aussi check tous les bits invalides genre si tu as 01 au mpeg_id, c’est pas bon (à toi de voir le degré de tolérance).