First off, thanks for the useful tool. I'm not sure if this is a bug in the tool or in my camera (or both), but here's what's going on.
I have a Rexing V1P dashcam with GPS logger, which saves .MOV's and can be viewed with the correct lat/lon/speed in their own viewer (sometimes; their viewer is extremely slow and buggy, thus why I want to extract the data to process it myself).
When using exiftool.exe -ee -GPSLatitude -GPSLongitude -GPSSpeed file, it saves a file with essentially the same data whether using -n or -b:
GPS Latitude : 9.18108779835543e-030
GPS Latitude : 9.18124187275098e-030
GPS Latitude : 9.18129323088283e-030
...
9.18108779835543e-0309.18124187275098e-0309.18129323088283e-030...
This data is variable length and values have no separation from each other in the binary output (no NULs, no newlines, nothing), which seems like it makes the binary output somewhat useless (at least for these tags).
The output without either -n or -b is similarly unhelpful:
GPS Latitude : 0 deg 0' 0.00" N
...
But also, this data is very wrong (basically it shows all latitudes as very near 0 and all longitudes as something in the 63°E range, while I'm in Texas at ~30°N 97°W. I expect that there's just a conversion error somewhere, or it's an offset from a reference lat/long, but I can't figure out which, and 9.18108779835543e-030 doesn't appear anywhere in the original file (as string, float, or double).
Can someone give me pointers to find the actual raw data?
Here's the actual file: https://jfr.im/gps_sample.mov (https://jfr.im/gps_sample.mov)
Unless the metadata in the file is corrupted, this looks like a conversion issue. @Phil, any ideas?
Wow. I guess it is too much to hope for a bit of consistency from these GPS devices. :(
Thanks for the sample. The encoding of the lat/lon is different than I have seen for other models. I will take a closer look at this when I get a bit of time.
- Phil
OK. Here are the relevant bytes from GPS fix in the video decode in various formats:
offset char hex long short1 short2 float double date
----------------- ---- -------- ----------- ------ ------ ---------- ----------- ----------
28 0000001c @... 40942e12 305042496 -27584 4654 5.509e-28 -1.32e+28 1979-09-01 (58%)
32 00000020 .R.. 8052c5c5 -976924032 21120 -14907 -6314 5.893e-313 1939-01-17 (67%)
This is stored in "freeGPS" metadata, which normally uses float format. But it seems as if it is stored as a long value that needs to be divided by 1e7. I'll work on adding support for this.
- Phil