trk file segment counts

[danhicks]

For ~~reasons~~ I decided to write my own `trk` parser in R. (Basically I was getting weird encoding errors in the Python parser and I'm much more comfortable debugging in RStudio.) Here's the repo: https://github.com/dhicks/alpineR

Also FWIW this is my first time messing around with raw hex data, so please let me know if I'm using the terminology wrong or missing something basic.

I have two track files I'm using to test the parser, the 2021 track (`test_data/track_20210417_094737.trk`) and the 2022 track (`test_data/track_20221223_103047.trk`). In both cases, it seems like I have to double the number of segments reported at the start of the TrackSegments section, because each "real" segment (containing data: -1 metadata entries followed by n locations) seems to be preceded by an "empty" segment (8 bytes of 0, apparently indicating 0 metadata entries and 0 locations if interpreted as a TrackSegment). For example, the 2021 track reports 1 segment, but there are actually 2: one empty, one with the location data. The 2022 track reports 2 segments (which matches what I see in the app), but there are actually 4: empty, before lunch, empty, after lunch.

To make this more concrete, here's a Google Sheet showing how I/my parser are interpreting the first 24 bytes of the TrackSegments section of the 2021 file, starting from offset 259: https://docs.google.com/spreadsheets/d/ ... sp=sharing

Is this the right way to think about how to parse TrackSegments?

[Psyberia-Support]

Hi danhicks and thank you for your interest in this application.

I've checked and there is only one segment in the 2021 track, and two in the 2022 one.

I guess the problem comes from line 13 of metadata.R

Code: Select all

if (n_entries < 1) {

If "n_entries" is "0", then the number of extensions and metadata version are following. I guess this is your 8 bytes.
If "n_entries" is "-1", then in this case your condition is correct.
In fact, there is a distinction between a "null" metadata (size of "-1"), and an "empty" metadata (size of "0"), which can still have extensions and a version.

Note that I'm not sure you can ever encounter a null metadata in those files, it's just that the app uses this metadata structure in a lot of places where nulls make sense.

[danhicks]

Thanks for the clarification!