1

Context: I am parsing Riff/Wave files. There is documentation identifying the FourCC values within Riff chunks. Here are the more important chunks for wave files.

FourCC ID for two .wav specific chunks:

 Chunk ID   "fmt " (0x666D7420)
 Chunk ID   "data" (0x64617461)

So, these fmt values should be equal:

 string "fmt "
 Hex "666D7420"
 int "1718449184"

And, these data values should be equal:

 string "data"
 Hex "64617461"
 int "1684108385"

Now, when I read in valid .wav files, the FourCC fmtChunkID fmt int is always:

 fmt int:
 int "544501094"

And data int is always:

 data int:
 int "1635017060"

Question: Why doesn't the documented Hex value match the int I am returning from the stream? I'm guessing I don't understand something about the Hex to Int conversion.

Extra: I found .wav parser code online that has the suspect fmt value "1718449184". But I find more with fmt value "544501094". Finally, search Google for "1718449184 AND 544501094"; nothing.

Thank you for the help.

Chadd
  • 636
  • 7
  • 30

1 Answers1

2

Endian. See 0x20746d66 in decimal. (0x20746d66 is a reversal of the bytes of 0x666d7420.)

In file formats, every byte must be in the correct place. If you casually read them in and out of memory, depending on your CPU vs the File Format, you can get the byte orders swapped.

Read up on "Big Endian" and "Little Endian". Some will on about it at great great length, but it's actually very easy, and important to understand if you ever are dealing with file formats, network traffic, interfacing to hardware, & many other places.

david van brink
  • 3,604
  • 1
  • 22
  • 17
  • 1
    David, I suspected endian order was related but was told otherwise by a more experienced programmer. I'll look into this and mark your answer when I've got it reading correctly. Thank you! – Chadd Apr 04 '13 at 23:51