Closed halleysfifthinc closed 7 months ago
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...)
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!
Haha, no worries, as I will probably take the 5 minutes to ignore these two bytes as well :) Thanks for reporting!
Fixed in #310 Thanks @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: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.