Strict expectations of C3D parameter block header

[halleysfifthinc]

I am the developer/maintainer of C3D.jl, a Julia library for reading C3D files. I'm currently working on adding initial support for editing and writing C3D files, and I'm testing that other applications/software can properly open and read the files I've written.

Unfortunately, an initial test file I wrote wasn't being read by ezc3d. I've determined that y'all are requiring the first 2 bytes of the parameter header to be 0x5001. Based on my reading the C3D spec, those values are undefined/ignored:

The first two bytes of the parameter record are normally only meaningful if they are the first word of a file – this is because the original ADTECH file format required the first byte of a file to point to the first parameter block and the second byte to define the data format of the file. So the first two bytes of the parameter record must be ignored when they are not the first two bytes of the file. [Emphasis added] Reference

Given that a proper header section is required by the C3D spec, the parameter section can never be at the beginning of the file and so the values of the first two bytes can be ignored.

I changed my code to follow suit (and my test file is now successfully read by ezc3d), but thought I would note that any consistency in those values seems to be only convention, and not required by the spec.

[pariterre]

Hi there! Even the first two bytes can be problematic. Qualisys does not define them even though they are required by the standard. So you basically have to choose between following the standard or allowing for loading non-compliant files. The worst is those who skip entire mandatory sections such as POINTS in the parameters. This causes multiple problem as the frame rate is, for instance, based on the POINT:RATE value (which is non-existant in these files...)

[halleysfifthinc]

Agreed; some manufacturer's are frustratingly lax in their adherence to the standard. However, as I mentioned, those two bytes actually aren't required by the standard, and are fully redundant to information given in the C3D header and/or parameters (when they exist). (My library has always ignored those bytes and is [successfully] tested against all of the sample files on the c3d.org website.)

In any case, I fully understand that whether or not to accommodate files/manufacturers with non-compliant characteristics is very much a fuzzy line that entirely depends on the developer's mood :sweat_smile: . Feel free to close!

[pariterre]

Haha, no worries, as I will probably take the 5 minutes to ignore these two bytes as well :) Thanks for reporting!

[pariterre]

Fixed in #310 Thanks @halleysfifthinc