Hey Ross
I just did a rebuild of the suite for v104 PRONOM and am getting fresh issues with fmt/1190. This format was causing problems last release that I'd thought I'd fixed for siegfried by allowing the Position attribute to start from 0 rather than 1 but there seems to be another issue.

For reference, here's the signature:

This is how siegfried parses that:

Because there are two ByteSequence elements, both with a BOFoffset Reference attribute, siegfried interprets it as two sequences that are both anchored off the beginning of the file. Those min/max offsets it interprets as being relative to the start of the file.

The container generator seems to parse it differently, with the first sequence relative to the BOF and the second sequence relative to the first (so the min/max offsets for the second sequence are calculated from where that first sequence ends).

Siegfried doesn't match the skeleton file because the second sequence appears past the max offset if you calculate it from the BOF but if you calculate it from the end of the first sequence it should match.

I suspect the container generator's interpretation matches the intent of the author of this signature (because of the Position 0, Position 1 business) but on the other hand there are examples in the DROID signature file where you legitimately have multiple byte sequences anchored from the BOF so I don't want to change the way siegfried parses that as it will break those. Also, if you want to have two sequences relative to each other, you'd expect this to be two SubSequence elements within a single ByteSequence & not two ByteSequences.

Aaargh!