Get statement - Please help me understand how this works

I'm looking into reading file contents. I've searched the web and started using Open, Seek & Get statements in my code. Now this does what I want it to - except it is very slow for multiple reads within each file.

So I did more research and I think it would pay if I read each file once into an array (which I will call 'buffer' from now on) and then do multiple reads within the buffer.

The only catch is that I need an alternative to 'Get' to use on the buffer. I would write the function myself but I cant get my head around how 'Get' works.


To give a real life example, say I have a file and the extract below gives me a lngGetHeader = 53691465.

Please Login or Register  to view this content.

when I try to read the same data from the buffer/array instead (extract below), I get 51?!

Please Login or Register  to view this content.

I know I am doing something wrong but I'm not sure what. Do I need to read multiple bytes from this position to get the long variable?

To help others to help me, I have created a test XLSM

As an example, opening a Jpeg, results in FFD8 FFE1 (which is correct - that's the magic number for a jpeg) for both methods

Please Login or Register  to view this content.

Using a long in the same scenario results in -503326465, which has a hex value of FFFF FFFF E1FF D8FF

Originally Posted by Kyle123

Using a long isn't really what you're after (or I doubt it is anyway). To tread the first Byte in a file, lngGetHeader should be a byte, if you change it to a byte then your code works as expected.

Is the long value what you are expecting? i.e is the correct value 53691465?

Hi Kyle, good to hear from you again.

Good call! You are correct - In real life I am not seeking a single byte result nor am I checking the first byte in the file. (In the previous posts I tried to strip out anything that might distract and thus condense my question down to its essentials)

So I'll explain what I am really doing. I am searching music files for a certain header. The original code achieved this by using GET to read parts of the file as a long variable (just like the code in my first post).

So I think I that I will need a long result. However when I use a buffer, I am only reading the first byte at the Read Position. I assume that the original code is reading multiple bytes from the Read Position? But if that is the case, how come the values are so different?

Originally Posted by Kyle123

As an example, opening a Jpeg, results in FFD8 FFE1 (which is correct - that's the magic number for a jpeg) for both methods

Thanks Kyle. Is there anyway I can avoid the For/Next loop and the Hex values in method 2?

If we use JPEG as example on my code in the OP, I get a long of -520103681. This in Hex is E0FFD8FF. If I open the same file in a Hex editor I get FF D8 FF E0 (reverse order of course). So I'm happy with that. I just need a way to get the result of -520103681 using method 2. If that's possible.

Originally Posted by Kyle123

No, you can't use method 2 without looping, it's a byte array - why do you not want to loop?

OK that well cant be helped. It's no big deal - Speed was my only concern why I wanted to minimise looping if possible.

Originally Posted by Kyle123

Ok, I still don't really get what you want. The first bit of data isn't a long?

I have difficulty communicating. My fault not yours. I'll try again.

The method 1 (in my code on the OP) returns a long variable. Somehow this long represents 4 consecutive bytes in the file - exactly how this works I am not sure! (To illustrate by example - in the case of a JPEG, the first four bytes in the file have the hex values: FF D8 FF E0 ; And method 1 reads these as a long of -520103681 ?!)

The method 2 (in your example) returns a string of hex values.

Unfortunately I need method 2 to return a long variable - with same value as method 1. How can I do this?

(The reason why I need method 2 to return the same long as method 1 is because: Each long variable found is tested against another sub function to see if the long variable is the information that I am looking for. This function only accepts a long argument, not a string of hex values)


UPDATE: Solved.

The solution was staring me in the face. :slaps forehead: I overlooked the nuisance of Little Endian. In the case of the JPG - the hex values of FF D8 FF E0 - I needed to place them in reverse order then convert to long. i.e. FF D8 FF E0 -> &HE0FFD8FF -> Clng(&HE0FFD8FF) => -520103681 = Method 1 variable of -520103681

Thanks Kyle. I couldn't have made this connection without your help. +1

The thread is now solved but in case anyone with the same problem (unlikely!) stumbles across this thread looking for a quick solution, here it is:

Replace this part of the code:

Please Login or Register  to view this content.

With the extract below

Please Login or Register  to view this content.

I have written a custom function to replace GET for longs. See below.

Please Login or Register  to view this content.

You have permission to do what you want with the above function (yes, including commercial use) however: a) I would appreciate it if you didn't pass this off as your own work and b) blanket disclaimer - I offer no guarantee that it will work. You use it entirely at your risk. I accept no liability whatsoever and I do not take any responsibility for any damage/s - real or imagined - that you may incur etc.

Something may be wrong with my alternative GET function.

Before abandoning the previous method, I ran the full code (original version) on over 3000 files. At the same time, I also ran the full code (new version). And compared the end results for each file. The end results were the same for both methods on all but 3 files. But I want 0% margin of error for this project.

Have I made a wrong assumption somewhere on my fnlngBufferEquivalentToGETLong?


nvm - I have started a new thread for this. http://www.excelforum.com/excel-prog...ary-level.html