[KevinH]

Hi,

Yes, that script was designed with Kindlegen and Calibre in mind. Kindlegen allocates a full section of up to 8192 (or 4096?) bytes of nulls when it creates its headers. Calibre does the same to match what Kindlegen does. Simply run DumpMobiHeader_v14.py or later to see all of the extra null bytes that pad out the header section after the full title field.

As I am away from my workstation please run DumpMobiHeader on your sample files to verify if the headers are properly sized and padded.

The reason kindlegen does this is to make sure there is enough space in the header section to add in the DRM key info (and there can be multiple keys) and the extra EXTH metadata needed to store the DRM key info all on the fly when downloading.

The dual-meta mobi editor uses this fact to add and remove EXTH info but keeps the entire section size exactly the same. By doing it this way, you do not need to update the palm section table offsets at all nor change the size of the section table at all. I can just replace the entire header section with the new one.

As a safety check, I verify that all I am replacing at the end of the header are these extra padding null bytes and that I have not grown the header section in any way. I did this because some very very old mobis left no extra space. Everything since Kindlegen 1 adds this padding.

So I think that any metadata editing program should be careful to keep the required extra padding (ie size the header to allow additions without the need to resize.) just like Kindlegen and Calibre do.

Hope this helps.

KevinH