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

[DiapDealer]

It definitely worked for me ... with the sample file provided by Aaron. I haven't tested on lots of devices but all the images in the azw3 show up for me in KindlePreviewer, the KindleforPC app, and on the first generation Kindle Fire HD.

[KevinH]

Hi,

Thanks for testing it.

Only with the Applescript? What if you it without the Applescript? Hmm, that is really strange and you might say anomalous behaviour!

The Applescript might refer to an older version of python? I have aMac and I will load that Applescript up with the latest v66 version with the new mobi_split.py and see if I can duplicate your issue.

I should have some free time later tonight to check with your testcase. I am running Mac OS X 10.9.3 with the very latest TCL and Python 2.7.6 version from ActiveState to work around the large number of broken python pieces in Mavericks.

KevinH

[NiLuJe]

FWIW, output looks okay with Mavericks' stock Python (2.7.5 on 10.9.3) when running KindleUnpack (0.65) the usual way (and no specific flags passed).

Does the AppleScript thingy does things differently? (Or uses different defaults?)

[AaronShep]

Kevin, I never learned to use KindleUnpack without the AppleScript, but I can look at that a little later. I tend to avoid the command line when possible

Also, would your revised splitter code be needed in KindleStrip as well? I know everyone's saying that's not needed anymore, but since I only use Kindlegen through Previewer, it is still very handy for me.

[KevinH]

Hi,
The very very latest version of Kindlestrip simply zeros out some sections and does no section removal or shifting so that version should still work.

[KevinH]

Hi AaronShep,

Okay I grabbed Paul's Applescript (gotta love that icon!) and ran it stock with just the new mobi_split.py file put in KindleUnpack v0.65.app/Contents/Resources/ to update it.

I ran it on your test case and all images were successfully unpacked and copied to their correct location.

So I can't recreate what is happening to you here.

Since you are on Mac OS X 10.6.8 you must have multiple system Pythons installed alongside your latest Python 2.7.6 version and my guess is that an earlier version is being found first by the Applescript and not the very latest Python 2.7.6

One way to check is to open Terminal.app and type the following command and hit return:

which python


On my machine this reports the following
/Library/Frameworks/Python.framework/Versions/2.7/bin/python


and then type the following and hit return

echo $PATH


On my machine this looks as follows (this comes from installing ActiveState's Active Python community addition under Mac OS X 10.9.3)

/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin


That should show you which version of python is found first on your system.

Alternatively you could type in the following and then hit return

/usr/bin/env python

You should see something like the following:

ActivePython 2.7.6.9 (ActiveState Software Inc.) based on
Python 2.7.6 (default, Feb 27 2014, 14:06:06)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>


To exit from this simply enter the following and hit return

quit()

Please let me know what you find out.

KevinH

[AaronShep]

Kevin, I had the latest Python from Python.org. I've now installed the latest Python from ActiveState, and the Terminal command now provides an exact match to the info on your machine. But the mobi8 image files are still empty.

So, I switched from Snow Leopard to a Mavericks installation, installed the latest ActiveState Python, and tried again. This time the images showed up (even though the Terminal command persisted in showing 2.7.5, even after reboot).

So, it is likely a Python bug on Snow Leopard, and I don't think it's worth pursuing. I don't personally need the same images to show up for both mobi7 and mobi8. The fix you already figured out was the important one, and I appreciate your work.

Aaron

[pdurrant]

I have a vague memory that when run from AppleScript, the command line is some strange default, not what you see in terminal, and probably uses the built-in python no matter what your defaults are in terminal.

I'll try to get a new AppleScript wrapper up tonight.

[KevinH]

Hi,

Just to tie up loose ends, here is an official KindleUnpack_v067 release that has all of tkeo's fixes from v66a, plus the fixes for mobi_split.py that corrects the bug of losing images in azw3 generated by splitting mobis.

Please note: This does NOT include tkeo's epub 3 patches as those are still under review.

Also note, for planning purposes:

I have plans to add page-map.xml creation during unpacking from either a separately provided .apnx (provided alongside the input file) OR from recent kindlegen mobis that include the PAGE section.

Once those features are in the tree, I will incorporate all of the epub3 changes on top.

Anyway attached is KindleUnpack_v067 plus a unified diff to show all of the changes since the v066 release.

Hope this helps,

KevinH

[msg7086]

Hi,

I have some trouble when extracting some comics from azw3 format.

I got the message

Warning: Section xxx does not contain a recognised resource
(... a lot)

Error: Referenced image 2 was not recognized as a valid image in <img height="1200" src="kindle:embed:0002?mime=image/jpg" width="844"/>
(... a lot)

Any ideas on how to deal with this?

Thanks.

===== EDIT =====

Found the reason. Seems that the awz3 files copied from KPW are not completed version, but only with covers and title. Downloading from the amazon website by 'via USB', however, results the full file.

[KevinH]

That is strange.

My bet is that the version from KPW somehow was referencing HD images?

That "Section xxx does not contain a recognized resource" is probably seeing the new HD Container version of the images which it will ignore.

Does KPW support HD images? If so, the version specifically downloaded to it probably strips out the low res versions of the images which seems to be confusing the hell out of KindleUnpack.

I will add some code to look for CONT sections and unpack HD images as well just in case.

KevinH

[AcidWeb]

AFAIK only Fire use new HD images.

[AaronShep]

Originally Posted by KevinH

Just to tie up loose ends, here is an official KindleUnpack_v067 release that has all of tkeo's fixes from v66a, plus the fixes for mobi_split.py that corrects the bug of losing images in azw3 generated by splitting mobis.

Will there be an AppleScript version with these corrections? I can't seem to find one posted.

Thanks again for everyone's work on this.

[KevinH]

Hi,
Paul is the expert in that. Unfortunately, what I know about Applescripts wouldn't fill up a thimble.

That said, I think you can just simply copy all of the .py files from the lib sub directory of the latest KindleUnpack and store them inside the Applescript app inside Contents/Resources/ to replace their namesakes.

[KevinH]

Hi All,
I am looking for testers for an experimental version (alpha/beta) of KindleUnpack that will unpack a Mobi 8 (kindlegen generated) PAGE section to create a page-map.xml file in the epub.

It will also create a new sub directory called HDImages/ and populate it with the HDContainer Images (but it won't replace the normal res images yet). To get an epub with these HD images you would have to unpack the epub and manually replace the normal res versions with their HD versions.

So if you work converting epubs with page information, or use HD Images, I would live to get feedback as to whether it works for you or not.

Please let me know if you are willing to test it, and I will post it.

Thanks,

KevinH