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

[mbmr]

Not sure why people are asking the OP for updates, they wont come, all this plugin is is a GUI wrapper around apprentice alfs script

[pdurrant]

Originally Posted by mbmr

Not sure why people are asking the OP for updates, they wont come, all this plugin is is a GUI wrapper around apprentice alfs script

Not so. KindleUnpack has nothing at all to do with DRM and is completely separate to Apprentice Alf's scripts.

[DiapDealer]

And in addition:

1) this thread isn't about a plugin.
2) updates tend to happen fairly quickly when someone points out an issue/bug.

[AcidWeb]

I'm still trying (and failing horribly) to find a way to optimize KindleSplit algorithm... Creating MOBI8 when book have hundreds of images still take way too long.

[DiapDealer]

Wondering where we are at with the latest proposed changes (not tkeo's latest experimental epub 3 stuff) to remedy what quiris brought up in post #693.

Are all the proposed changes limited to the kindleunpack.py file (posted by tkeo in post # 704 as kindleunpack.py.v064b.zip)?

I've got a minor quibble with how the current version (v064) is manifesting the cover image in the opf file, but don't really want to submit any patches until I know where we are.

[KevinH]

Hi DiapDealer,

As far as I know, we are still waiting to hear back confirmation from the original bug reporter that the fix works with all of his test cases. But I am not sure they actually will report back.

The proposed changes are all in that one file. So why don't you post your new patches against that version of kindleunpack.py and I will include them into an official new release this weekend.

That way we are all starting from the same point moving forward.

Thanks,

KevinH.

[DiapDealer]

OK. The two small changes I've included have nothing to do with the kindleunpack.py file, so everything will be relative to the current (v064) version posted.

The patch I've attached affects the mobi_k8resc.py file and the mobi.opf.py file. Should be able to patch with the typical "patch -p1 < KindleUnpack.patch" method (starting from just outside the 'lib' directory of the source).

The change to mobi_k8resc.py simply eliminates the 'properties="cover-image"' attribute/value from the cover image's <item> entry in the <manifest> section of the OPF file. "properties" is not a valid/recognized attribute for the 'item' tag in ePub 2. An ePub won't validate with it in there.

The change to mobi_opf.py has to do with the guide section of the OPF file. I may have given you this patch before. The current version is putting the entire title of the ebook (from the EXTH) into the "title" attribute of the cover page's <reference/> entry in the <guide> section. That may not ever cause an issue, but it's typically just a static value of "Cover" (although it doesn't really matter what's there). It just doesn't make sense to me to put the entire title of the book there. *shrugs*

Originally Posted by KevinH

As far as I know, we are still waiting to hear back confirmation from the original bug reporter that the fix works with all of his test cases. But I am not sure they actually will report back.

For what it's worth, I had books that were behaving in exactly the same manner (getting the same error) as the bug reporter's and the proposed fixes to kindleunpack.py worked with those problem books.

[tkeo]

Originally Posted by DiapDealer

The change to mobi_k8resc.py simply eliminates the 'properties="cover-image"' attribute/value from the cover image's <item> entry in the <manifest> section of the OPF file. "properties" is not a valid/recognized attribute for the 'item' tag in ePub 2. An ePub won't validate with it in there.

Could it be not deleted but commented out? Such like,

#ref += '" properties="cover-image' # for epub3

BTW, It's in 'mobi_opf.py' not in 'mobi_k8resc.py', I think you just take mistake filenames in your post.

[DiapDealer]

Originally Posted by tkeo

Could it be not deleted but commented out? Such like,

I have no problem with it being commented out as opposed to removed.

BTW, It's in 'mobi_opf.py' not in 'mobi_k8resc.py', I think you just take mistake filenames in your post.

Oops! You're right. The patch file is correct, but I flip-flopped the filenames when describing the changes.

[KevinH]

Hi All,

Okay, I started with official v0.64 added in tkeo's kindleunpack.py version 0.64b, and added on top of that DiapDealer's patch (tweaked to comment out but not remove the properties line).

So here is v0.65 of KindleUnpack:

Changes since official v0.64

- bug fixes for broken or missing RESC section (tkeo)

- bug fixes to maintain epub2 compatibility and make "title" property not be the full title of the book (DiapDealer)



At some point soon we should probably think about how to address epub3 vs epub2 features in some sane way since kindlegen seems to be moving to adopting epub3 compatibility faster than actual epub devices.

Ideas on how best to do that welcome.

Thanks everyone!


KevinH

[pdurrant]

Originally Posted by KevinH

So here is v0.65 of KindleUnpack:

Now added to the first post, and the AppleScript updated too.

[EbokJunkie]

Guys, have question about cover images.
I ran kindleunpack on multiple azw3 files and noticed that cover files come only in mobi7 folder but not in mobi8 folder. I'm trying to recreate mobi from existing azw3 but missing cover spoils the idea.
Is there any way to make cover file to appear in mobi8 folder?

Added
Found one instance when cover was both in mobi7 and mobi8...go figure

[DiapDealer]

Originally Posted by EbokJunkie

Guys, have question about cover images.
I ran kindleunpack on multiple azw3 files and noticed that cover files come only in mobi7 folder but not in mobi8 folder. I'm trying to recreate mobi from existing azw3 but missing cover spoils the idea.
Is there any way to make cover file to appear in mobi8 folder?

Added
Found one instance when cover was both in mobi7 and mobi8...go figure

In every AZW3 I've checked (created with kindlegen and/or calibre) the cover image is identified, copied to the mobi8 folder, and included in a cover page (xhtml) in the resulting epub.

I'm sure it's possible that the RESC section of some AZW3s may be constructed in such a way (or damaged) that tkeo's new code can't identify the cover image, but I would think that would be the exception rather than the rule.

How were your existing AZW3s created (the problem ones)?

[EbokJunkie]

That's weird. Went to work, rebuilt azw3 that failed to add cover to mobi8 at home and found cover in mobi8 folder. Used v65 on both occasions. Will try again at home this evening.

Added:
I had Python 2.7.2 at home and 2.7.3 at work. Uninstall 2.7.2, install 2.7.6 (latest) - and voila, cover miraculously emerged in mobi8.

[tkeo]

Hi,

I've found a bug with regard to K8 RESC section extraction. Most mobi and azw3 files which have RESC sections are able to be extracted. But in some portion of files, the extraction of the RESC section is failed. In this case, the description in the RESC is ignored and treated as K8 format with no RESC section.

I think I have injected the bug into v0.64b. I am investigating and fixing it.

I am sorry for reporting the bug just after an official update, I had not checked enough.