Hi,
Kindle for PC/Mac use information from the extended header to determine the encryption key. This can and does include multiple metadata values including a token, asin, guid, kindle drm server, text to speech and etc metadata values.
So it could be possible that simply growing the size of the extended header region and leaving lots of blank space (500 bytes?) at the end not assigned to any specific metadata value might allow later DRM addition software to create and write its required metadata fields in the extended header region without having to rewrite all of the individual sections/offsets that make up the .mobi ebook.
I would think that using mobiunpack or mobi2mobi to print the full size and contents of the extended header region and comparing the extra space (if any in the extended header) produced by KindleGen or KindlePreviewer to Calibre would be enough to determine if a simple allocation of extra space there might do the trick.
My 2 Cents,
KevinH
Quote:
Originally Posted by Hitch
Whether or not it's some super-secret conspiracy agenda by Amazon, or whether it is a genuine technical issue having to do with, as Amazon told me, adequate space in the headers or lack thereof, has nothing to do with me whatsoever.
Hitch
|