Discussion :

[tintin72]

Bonjour,

J'essaie d'ouvrir et de lire le header
d'un fichier midi comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
ifstream file("monfichier.mid", ios::in | ios::binary);
if(!file.is_open())
  cout << "impossible d'ouvrir le fichier !"<< endl;
 
char data1[4];
DWORD data2;
WORD data3;
WORD data4;
WORD data5;
 
for(int i = 0; i < 4; i++)
  file.read((char*) &data1[i], sizeof(char));
 
file.read((char*) &data2, sizeof(DWORD));
file.read((char*) &data3, sizeof(WORD));
file.read((char*) &data4, sizeof(WORD));
file.read((char*) &data5, sizeof(WORD));
 
file.close();
 
for(int i = 0; i < 4; i++)
  cout << data1[i] << endl;
 
cout << data2 << endl;
cout << data3 << endl;
cout << data4 << endl;
cout << data5 << endl;

La 1ere variable data1[4] contient bien les données attendues,
par contre après ce n'est plus du tout le cas.
Pourquoi ?
Y a t-il un pointeur à déplacer après chaque appel de read ?


D'avance merci.

[yan]

Salut.
Est tu sure de la taille de WORD et DWORD

[tintin72]

Est tu sure de la taille de WORD et DWORD

Oui, j'ai regardé plusieurs docs sur le sujet.

note: J'ai également testé avec d'autres fichiers (au cas où), mais
le résultat est le même.

[yan]

tu compile avec quoi?
et est tu sur de l'entête?

[tintin72]

tu compile avec quoi?

Mingw

et est tu sur de l'entête?

Oui, à moins d'avoir mal lu:

http://www.sonicspot.com/guide/midifiles.html

[yan]

All data values are stored in Big-Endian

peut être es ce le problème.
Je sait jamais qu'elle endian est utilisé sur un PC.
Tu trouvera facilement des méthodes de conversion sur le net.

[tintin72]

Je crois que c'est ça effectivement.
Moi aussi je sais jamais quel endian est utilisé sur un PC,
mais apparement les cpu x86 sont little endian.

Merci pour ton aide.

[JolyLoic]

Normalement, tu n'as pas besoin de le savoir.

Règle d'or pour lire/écrire des données binaires : On écrit uniquement des unsigned char. Pour convertir de types plus long vers un buffer d'unsigned char, on n'utilise pas de cast (qui poseraient entre autre les problèmes d'endianness de la machine), mais uniquement des opérateurs arithmétique (décalage de bits et masquage) qui donnent le même résultat dans tous les cas.

[tintin72]

Cela voudrait dire que mon code n'est pas bon ?
(même s'il donne maintenant les valeurs attendu grace à ntohl/ntohs)
Sur le net j'ai vu beaucoup d'exemples utilisant read de cette façon.
Pourrais tu me donner un exemple d'utilisation avec des unsigned char ?

[yan]

Cela voudrait dire que mon code n'est pas bon ?
(même s'il donne maintenant les valeurs attendu grace à ntohl/ntohs)
Sur le net j'ai vu beaucoup d'exemples utilisant read de cette façon.
Pourrais tu me donner un exemple d'utilisation avec des unsigned char ?

Ce n'est pas qu'il est pas bon, c'est qu'il n'est pas valide partout.
Il me semble que ntohl/ntohs ne sont pas standard.

[tintin72]

Ah ok.
La solution serait alors que je fasse ma propre fonction ou macro
qui effectue la convertion pour que mon code soit portable.

[yan]

si je comprend bien ce que pense JolyLoic,
il faut lire octet par octet et les assemble avec les operateur binaire.
Par exemple pour un float codé sur 4 octet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
unsigned char buf[4];
file.read(buf,4);
 
unsigned int tmp(0);
tmp = buf[0]<<24  /*decalage de 3 octet*/
         || 
         buf[1]<<16  /*decalage de 2 octet*/
         || 
         buf[1]<<8   /*decalage de 1 octet*/
         || 
         buf[1];
 
float res = *reinterpret_cast<float *>(&tmp);
}

Je me suis peut être planté quelque part....

[Obsidian]

Moi aussi je sais jamais quel endian est utilisé sur un PC,
mais apparement les cpu x86 sont little endian.

???

Si c'est sur PC, c'est forcément du compatible x86 (ou x86_64), et donc du little endian, non ?

[nicroman]

Bah... cherchez pas à savoir.... et detectez le au runtime....

De plus, l'indianness ne sert qu'aux IOs (fichiers, réseau,...) le reste du code s'en fiche éperduement la plupart du temps...
(bon sauf pour les textures, entre RGBA et ABGR )