Strange, I never got an email from the system alerting me of a response. Good that I came to have a look (something to remember for the future should I not respond)
In other words *somehow* choosing the "guess" overrides the detection of the two extents, providing an actually "more accurate" result than the "proper" parsing of the boot info table
The image with the boot info-table triggers IsoBuster to read all its sectors, to be able to determine if the checksum matches.
While doing this, since all blocks are read anyway, IsoBuster checks for MBR/BPB signatures in every block, and it seems to find them in the second block of this image, hence why the two extents.
It should not make a difference, since it's still one file with a correct length, it just happened to be split up in two extents.
The file without the table, does not trigger IsoBuster to read every sector (there is no need), hence no MBR or BPB is found, hence why no extents are created.
When I have time to implement the checkboxes in the GUI (options) I plan to also allow the boot info-table size data without verifying the checksum. That will be faster, as not all sectors need to be read. It will also have the same effect then as the image without the info-table, because not all sectors will be read. The size may be wrong then, but it's up to the user to put checksum checking on or not.
Maybe an added column with...
I'm not adding columns. Implementation is then for all objects in all situations and this only makes sense for boot images, a minute part of the functionality.
I contemplated putting something in the properties window as well for this, but have not done so (yet).
I still have to try creating test .iso's with the old isolinux versions, will do and report.
Yes, do some tests if you can. Cheers.