posted on Jun, 28 2010 @ 02:54 PM
reply to post by slank
Yup, after all, its all 0s and 1s at the end of the day.
For example, one of the records has the hex values as follows:
What does it mean? (Rhetorical question)...
As an example, in order to decipher the hex as numerics, we need to know what the 'type' is, maybe whether they are lo/hi bytes or hi/low bytes - we
need to know what data values they are supposed to be representing. In order to do that you need a file definition otherwise it is all guesswork.
You can work out an algorithm by 'en clair' data comparison however, in order to do that you have to have data in the readable form which, at the
moment, does not appear to be available per se. The 'demo' Db is available but you need to be able to run it to see the data in readable form in
order to work out the algorithm/presentation.
In the example above, I am pretty sure that a007 is lo/hi byte for 1952, which would suggest that the following bytes are month/day/time in some form,
however, I have not experimented enough to work out the conversion.
The hex characters above 'probably' represent the data:
1952/7/29 10:0 10 106:17:20W 35:52:20N 3333 NAM USA
Some will be numeric representation (e.g. the year), some will be foreign keys (e.g. NAM). The character delimiters can be ignored.
Fill your boots...