search

exponential-decay / skeleton-test-suite-generator

DROID Skeleton Test Suite Generator (skeleton-test-suite-generator): Tool for the automated generation of digital objects based on the digital signatures documented in the PRONOM database maintained by The National Archives, UK. The skeleton-test-suite-generator serves to fill the gap that exists whereby the community requires a corpus of digital objects for the validation and evaluation of format identification tools and techniques. The tool should be used to complement a methodology whereby skeleton files are also generated manually by signature developers. The tool takes a signature specified for a digital object in PRONOM and constructs a digital object that will match its footprint. For more information, see the README.md associated with the project...
zlib License
8 stars 2 forks source link

fmt/894 (v85) #5

Closed richardlehane closed 7 years ago

richardlehane commented 8 years ago

Hi Ross the second byte sequence in this signature is a "#" (hex 23). It should appear at an absolute offset from the BOF at 128. In yours it is at offset 170, appended to the end of the first byte sequence. This seems a bit like that EOF issue I reported: where you have two byte sequences that can overlay each other, rather than being adjacent. Otherwise I'm passing all of yours for v85 (except fmt/899 and fmt/900 which you got errors printed for). ta! Rich

ross-spencer commented 8 years ago

Thanks Richard, I do need to sit down and investigate this some more. As well as fmts 899/900 which I haven't an instinct as to why those two have failed (the new PE signatures). But I'll set aside some time next week hopefully and feed back some more information.

On Thu, Jun 30, 2016 at 10:54 PM, Richard Lehane notifications@github.com wrote:

Hi Ross the second byte sequence in this signature is a "#" (hex 23). It should appear at an absolute offset from the BOF at 128. In yours it is at offset 170, appended to the end of the first byte sequence. This seems a bit like that EOF issue I reported: where you have two byte sequences that can overlay each other, rather than being adjacent. Otherwise I'm passing all of yours for v85 (except fmt/899 and fmt/900 which you got errors printed for). ta! Rich

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/exponential-decay/skeleton-test-suite-generator/issues/5, or mute the thread https://github.com/notifications/unsubscribe/AByxXOe0kIIfPju0bdZheih2Oz7szO7sks5qQ6BVgaJpZM4JCCXL .

richardlehane commented 8 years ago

edit - not an absolute 128 offset for that "#", but a range 0-128. Issue still applies as it appears at offset 170 in the skeleton file

ross-spencer commented 8 years ago

Write-up of how to fix this here: https://github.com/digital-preservation/droid/issues/115#issuecomment-250342003

ross-spencer commented 8 years ago

Hmm, it's an odd signature with the two variable offsets for byte sequences one and two starting from offsets zero and one... http://www.nationalarchives.gov.uk/PRONOM/fmt/894

richardlehane commented 8 years ago

yes, I wonder what the rationale was? a very weird signature