MobileRead Forums - View Single Post - KindleUnpack (MobiUnpack): Extracts text, images and metadata from Kindle/Mobi files

R. Scot Johns · 05-26-2014, 03:23 PM

An anomaly is an unknown deviation from the common expectation, and can be caused by any number of random factors along the chain, such as a signal fluctuation during transmission that causes a loss of data, or a user error. It does not inherently imply a bug exists, since a bug is something which generally has a consistent cause that can be repeated, traced and fixed. I use the term anomaly in the sense that there is an unknown variable, which is why I asked if anyone else has seen it occur. Apparently the answer to that question is no, which makes it even more of an anomaly than before. Of course, I'm inherently a philosopher, not a programmer, so I tend to use terms differently than others do quite often.

As for "compressed" versus "uncompressed" the answer should be obvious. Kindlegen applies compression to input images (assuming you do not use the -C0 option in the command line). The resulting "compressed" images are sent to standard resolution devices, and I presume these are what end up in the mobi7/mobi8 images folders on extraction. The original source images remain "uncompressed" (i.e. not resized in either resolution or file size), and these I assume are contained in the .azw3 file as well as the kindlegensrc.zip, deriving now from those stored in the HD CONTAINER if I understand correctly.

I've asked Aaron to post the file in question, but whether he will or not is up to him.

I don't really need the DumpMobiHeader script, as you've answered my question sufficiently. For practical purposes of content creation all I needed to know was where the images exist, and in what form, in order to control the file size for distribution.

Thanks!

05-26-2014, 03:23 PM	#736
R. Scot Johns Author/Illustrator Posts: 14 Karma: 2952 Join Date: Mar 2012 Location: Boise, ID Device: iPad 2 & 3, Kindle Paperwhite, Kindle Fire 1 & 2, HD7 & HD8.9, RazrMax	An anomaly is an unknown deviation from the common expectation, and can be caused by any number of random factors along the chain, such as a signal fluctuation during transmission that causes a loss of data, or a user error. It does not inherently imply a bug exists, since a bug is something which generally has a consistent cause that can be repeated, traced and fixed. I use the term anomaly in the sense that there is an unknown variable, which is why I asked if anyone else has seen it occur. Apparently the answer to that question is no, which makes it even more of an anomaly than before. Of course, I'm inherently a philosopher, not a programmer, so I tend to use terms differently than others do quite often. As for "compressed" versus "uncompressed" the answer should be obvious. Kindlegen applies compression to input images (assuming you do not use the -C0 option in the command line). The resulting "compressed" images are sent to standard resolution devices, and I presume these are what end up in the mobi7/mobi8 images folders on extraction. The original source images remain "uncompressed" (i.e. not resized in either resolution or file size), and these I assume are contained in the .azw3 file as well as the kindlegensrc.zip, deriving now from those stored in the HD CONTAINER if I understand correctly. I've asked Aaron to post the file in question, but whether he will or not is up to him. I don't really need the DumpMobiHeader script, as you've answered my question sufficiently. For practical purposes of content creation all I needed to know was where the images exist, and in what form, in order to control the file size for distribution. Thanks!