Get long from binary file (midi) problem.
Alan -
In an Intel CPU, bytes are stored from least-to-most significant. So the
4 bytes you're interested in indeed have a value (as a long integer) of
&h06000000.
The opposite is true in Motorola and some other platforms, where the byte
order is reversed. This is the famous "little-endian / big-endian" issue.
Since the file format is apparently the opposite of what you need, you
have to invert the bytes yourself. There are a half-dozen ways to do that,
but probably simplest is to have a parallel UDT that has all non-byte fields
as static byte arrays. Reverse the order of the bytes and LSet the whole
mess into your structure.
--
Jim Mack
MicroDexterity, Inc
PO Box 5372
Plymouth, MI 48170-5372
http://www.microdexterity.com
Fax: +1 734-453-8942
Quote:
> According to several resources I have looked at, the midi file format
> starts with the "chunk" type (4 characters "MThd") followed by the 32bit
> size of the data ( supposedly as value of 6), followed by the 3 integer
> values for the format, number of tracks, and delta time, respectively.
> An example of the header in the midi file similar to like this (in
> hex):
> 4D 54 68 64 00 00 00 06 00 01 00 05 01 80
> As one can see, the second grouping of 4 bytes appears to have a value
> of 6.
> I created a structure for the chunk header and declared a variable as
> follows:
> Type ChunkHeaderStructure
> sType as string*4
> lSize as long
> end type
> dim ChunkHeader as ChunkHeaderStructure
> I open the midi file (i.e. InFile) for binary read access and do the
> following statement:
> Get Infile, ,ChunkHeader
> The results are as follows:
> ChunkHeader.sType = "MThd"
> ChunkHeader.lSize = 100663296 (&H6000000.... interesting!)
> Can anybody please let me know why this is and why it is not working
> correctly?