KindleUnpack (MobiUnpack): Extracts text, images and metadata from Kindle/Mobi files

[DiapDealer]

Glad it's working for you. The association should really be made already by default, but I think at least one version of OS X shipped with that functionality "broken" for some reason.

[barndog1946]

Iam using WIndows 7 64bit. ActiveState Python 2.7 64bit. Downloaded mobi_unpack.pyw. Unzipped it. When I try to use it I get error mobi_unpack.py not found error 2. Can someone help me sort this out? Where should I put the lib files? I know nothing about Python. Just trying to learn about the internals of the mobi files.
Duh follow original INSTRUCTIONS WORKS FINE!

No help required

[DiapDealer]

Originally Posted by barndog1946

Iam using WIndows 7 64bit. ActiveState Python 2.7 64bit. Downloaded mobi_unpack.pyw. Unzipped it. When I try to use it I get error mobi_unpack.py not found error 2. Can someone help me sort this out? Where should I put the lib files? I know nothing about Python. Just trying to learn about the internals of the mobi files.

Once unzipped, you can move the whole folder structure anywhere, but all files/folders must stay in the same relative position to each other. In other words, the 'lib' folder MUST stay in the same folder as the Mobi_Unpack.pyw file. Move everything or move nothing, so to speak. And make sure you fully extract everything from the original zip file you downloaded (Mobi_Unpack_v047.zip). Then just double-click Mobi_Unpack.pyw

[axda]

Found a problem not sure if its cause by kindlestrip or mobiunpack_v0.47.

I created a simple mobi file with kindlegen, then kindlestrip before using mobiunpack to unpack it.

Unpacking fails if the "Split combination Mobi Files" is selected while a "raw" mobi without kindlestrip always works with the split option.

[KevinH]

Hi,

Exactly what version of kindlestrip are you using? The only one that works correctly for the new kindlegen is the kindlestrip_v133.py.

All of the earlier versions did not know there was a pointer to and record count of the Source zip file stored inside the mobi header and so they did not properly remove that pointer or record count.

[axda]

Originally Posted by KevinH

Hi,

Exactly what version of kindlestrip are you using? The only one that works correctly for the new kindlegen is the kindlestrip_v133.py.

All of the earlier versions did not know there was a pointer to and record count of the Source zip file stored inside the mobi header and so they did not properly remove that pointer or record count.

its the kindlestrip v133 with kindlegen 2.4

looks like a common issue, have tried several mobis all the same result.

[KevinH]

Hi,

The bug is in Mobi_Unpack in the file mobi_split.py. The test for srcs > 0 ignores the fact that the srcs value is unsigned and therefore tries to unpack it even when it should not.

Here is the fix:

--- mobi_split.py~	2012-03-01 18:16:17.000000000 -0500
+++ mobi_split.py	2012-04-17 14:53:18.000000000 -0400
@@ -241,7 +241,7 @@
         # check if there are SRCS records and delete them
         srcs = getint(datain_rec0,srcs_index)
         num_srcs = getint(datain_rec0,srcs_count)
-        if srcs > 0:
+        if srcs != 0xffffffff and num_srcs > 0:
             self.result_file7 = deletesectionrange(self.result_file7,srcs,srcs+num_srcs-1)
             datain_rec0 = writeint(datain_rec0,srcs_index,0xffffffff)
             datain_rec0 = writeint(datain_rec0,srcs_count,0)

Using any good text editor, edit the file lib/mobi_split.py and go to line 244 and replace

if srcs > 0:

with

if srcs != 0xffffffff and num_srcs > 0:

being careful to make sure you do not mess up the indentation level (whitespace at the beginning of that line).

If it would help, I can post a pre-release version of Mobi_Unpack_v049 - with that fix. We are waiting for Calibre to support the .azw3 file extension for standalone mobi8 mobi files before releasing.

Thanks for the bug report.

KevinH

[axda]

thanks, its working now.

[ATimson]

I don't know if the problem is a bad book or a problem in the script, but unpacking the KF8 version of this free book with v0.47 errors:

Command = "python mobiunpack.py"
Mobi Path = "<deleted>"
Output Path = "<deleted>"
Options = ""


Please Wait ...

Traceback (most recent call last):
  File "lib\mobi_unpack.py", line 1082, in <module>
    sys.exit(main())
  File "lib\mobi_unpack.py", line 1070, in main
    unpackBook(infile, outdir)
  File "lib\mobi_unpack.py", line 956, in unpackBook
    process_all_mobi_headers(files, sect, mhlst, K8Boundary, False)
  File "lib\mobi_unpack.py", line 806, in process_all_mobi_headers
    guidetext = k8proc.getGuideText()
  File "<deleted>\lib\mobi_k8proc.py", line 346, in getGuideText
    [pos, idtext, filenum, seqnm, startpos, length] = self.divtbl[fileno]
IndexError: list index out of range

[KevinH]

Hi,

Its a bug in Mobi_Unpack.py. Already fixed in version Mobi_Unpack v049 which should be released by the end of the day or early tomorrow.

So please hang on.

KevinH

[KevinH]

See later post for even newer version ...

Hi,

There have been a few bugs that needed fixing:

- better handling of StartOffset metadata to prevent problems
- better support for splitting files when no SRCS exists

and adding support for .azw3 files (added in the newest calibre)

Please give Mobi_Unpack_v049 a try and let me know what if any problems you run into.

KevinH

[jhowell]

I tried version 0.4.9 of Mobi-Unpack on some KF8 files that failed with the previous version and they all unpacked without error and appeared to yield a reasonable result.

One thing I did notice, that also seems to apply to the previous version, is that cover images that appear at the start of the KF8 book when viewed with Kindle Previewer or Calibre’s e-book viewer do not appear at the beginning of the corresponding EPUB produced by Mobi-Unpack. The cover image is present, but not linked into the flow of the book. I’m not sure if this behavior is intended or not.

[KevinH]

Hi,

It should be properly specified in the epub's content.opf file. If not that is a bug.

Can you unzip one of your created epubs and check the content.opf for the proper metadata for the cover and let me know what is wrong and I can try to fix it.

[jhowell]

I’m afraid that I am not knowledgeable enough about the EPUB format to determine if the file is formatted correctly. Here is what I am seeing.

As an example I downloaded a free sample from Amazon. (Turing's Cathedral: The Origins of the Digital Universe, ASIN: B005IEGK5C) The original KF8 file has a cover that is displayed as the first thing in the sequence of the book. It doesn’t display in the EPUB created by Mobi-Unpack.

The content.opf contains an entry in the manifest that refers to the cover image:
<item id="cover_img" media-type="image/jpeg" href="Images/image00008.jpeg" />

There is also a smaller sized version of the cover referenced in content.opf as:
<meta name="Cover ThumbNail Image" content="Images/image00090.jpeg" />

And in the manifest as:
<item href="Images/image00090.jpeg" id="item18" media-type="image/jpeg" />

Neither of these jpeg files is referenced anywhere else in the EPUB (including the xhtml files) and they are not displayed as part of the book content. Also checking with Sigil shows these files as not reachable.

[ATimson]

I think the "problem" here is that the Kindle app will display the cover image specified in the cover <meta> tag when you open a book. With an ePub, you need to specifically include a separate HTML page with the cover in the spine in order for it to appear when you open the book in most readers.

That said, my understanding of [url=http://blog.threepress.org/2009/11/20/best-practices-in-epub-cover-images/]ePub cover best practices[/i] is that you shouldn't be showing the cover when you open the book - tell the reading software how to find the cover, but let it decide whether or not to display it.