View Single Post
Old 01-13-2012, 07:52 PM   #30
KevinH
Guru
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 953
Karma: 410248
Join Date: Nov 2009
Device: many
Hi DiapDealer,

At least I know why stripping out the SRCS section causes problems. I could not figure out where in the palm db or first mobi header they could store information that indicates where the K8 version started without having to manually load and examine each section looking for the boundary. And everything I can find in the K8 header is relative to its own starting section number.

The only place they could add info and not mess up the old mobi format was if they stored the extra info in new metadata fields.

And sure enough, that is what they did!

If you look in the old mobi's *.opf you will see unknown metadata key 121 whose value is the section number of the BOUNDARY section! You will also see a metadata key 129 that is actually the ascii string "kindle:embed:0001" and metadata key 125 which appears to be a count of something and metadata key 131 which always seems to be 0.

If you look in the K8 *.opf file you will see they have removed metadata key 121, metadata key 129 is still "kindle:embed:0001", metadata key is 131 is still 0 and now metadata key 125 has been set to 0.

So if we actually remove the SRCS section (it is the last section before the BOUNDARY section), then we need to change at least metadata key 121 in the old mobi exth data to point to the new boundary section. We should also figure out what the other new metadata values are used for just in case.

If I get time over the weekend, I will revert to the previous kindlestrip_v130.py and try to have it fix the metadata 121 value in the old mobi header to reflect the removal of the SRCS and see if that does the trick.

This does explain why simply zeroing the size of the SRCS entry works, it does not change the section number of the BOUNDARY SECTION.

Take care,

KevinH
KevinH is offline   Reply With Quote