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

[KevinH]

Good point. I have spent no time grokking the kfx codebase but I would like a standalone python version that does not require all of calibre that will take a no dm kfx and convert it to something as epublike as possible. If that already exists, great. If not, I would like to use whatever code we have to "unpack" a kfx into an epub or fixed layout epub if that is what it takes.

[DiapDealer]

Originally Posted by KevinH

Good point. I have spent no time grokking the kfx codebase but I would like a standalone python version that does not require all of calibre that will take a no dm kfx and convert it to something as epublike as possible.

Oh absolutely. Same here. I'm just completely ignorant as to whether any of the existing routines in KindleUnpack will be helpful or not in that regard. If it turns out they will; great.

[jhowell]

I intended kfxlib to work outside of calibre, but it hasn't been fully tested that way. The basic method of converting KFX to EPUB would be something like:

    import logging
    from kfxlib import YJ_Book

    book = YJ_Book(kfx_file, logging)
    epub_data = book.convert_to_epub()

[KevinH]

Thanks! I will make time to play with it over the weekend.

Kevin

Originally Posted by jhowell

I intended kfxlib to work outside of calibre, but it hasn't been fully tested that way. The basic method of converting KFX to EPUB would be something like:

    import logging
    from kfxlib import YJ_Book

    book = YJ_Book(kfx_file, logging)
    epub_data = book.convert_to_epub()

[pdurrant]

I'm afraid I haven't had time to do much development of any kind, so I'm happy just to observe at this point.

[AcidWeb]

I still need Python 3 code that can efficiently extract AZW3 part of image heavy dual MOBI files.
Current implementation in mobi_split.py need minutes for ~500mb file.

Consider this post as code bounty. I can pay over PayPal. Contact me for details.
Any result of this bounty will be released with GPLv3 license.

[KevinH]

Don't extract them. Simply remove the old mobi parts leaving the remaining records and adjust the header.

[AcidWeb]

I don't have sufficient knowledge about MOBI structure to do it.

[KevinH]

It is all documented in the KindleUnpack code and in the DumpMobiHeader code.

[tkeo]

Originally Posted by AcidWeb

I still need Python 3 code that can efficiently extract AZW3 part of image heavy dual MOBI files.
Current implementation in mobi_split.py need minutes for ~500mb file.

Consider this post as code bounty. I can pay over PayPal. Contact me for details.
Any result of this bounty will be released with GPLv3 license.

Is it not enough to comment out or delete lines from 317 to381 in mobi_split.py?

[droopy]

I've just installed KindleUnpack into my Calibre. Even though I have an AZW4 title selected, "Unpack AZW4" is greyed out and not responsive to a mouse click.

update: I also have DeDRM installed.

[DiapDealer]

Originally Posted by droopy

I've just installed KindleUnpack into my Calibre. Even though I have an AZW4 title selected, "Unpack AZW4" is greyed out and not responsive to a mouse click.

update: I also have DeDRM installed.

This is the thread for the stand-alone KindleUnpack python script. The Calibre plugin version's support thread can be found at:

https://www.mobileread.com/forums/sh...d.php?t=171529

[odamizu]

Thank you DiapDealer and KevinH for updating KindleUnpack to 0.83 along with Sigil and Calibre plugins.

I like pdurrant's lovely drag & drop AppleScript very much, so I'm attempting to expand my experience with AppleScript applets and see if I can update it myself.

I downloaded KindleUnpack python scripts from KevinH's GitHub. I then opened the existing 0.81 AppleScript with "Show Package Contents" and copied all the files from KindleUnpack "lib" folder into the AppleScript's "Resources" folder, overwriting any pre-existing file with the same name. I then opened the AppleScript with Script Editor, navigated to Bundle Info and updated the Name and Short Version to 0.83. Then I compiled (hammer icon), ran the script (play icon), and saved everything.

Also, each file seems to exist as a .py and .pyc. The files I copied over from KindleUnpack GitHub folder were all .py, so the .pyc files were not overwritten, though after I saved the AppleScript the date modified on all the .pyc files changed to today's date. I have no idea what this means.

When I dragged an azw3 onto the finished AppleScript, it appeared to run properly and produced a folder with the unpacked Kindlebook. However, I don't really know what I'm doing here, so any feedback on whether I'm missing anything would be greatly appreciated. Thank you!

[pdurrant]

Originally Posted by odamizu

Thank you DiapDealer and KevinH for updating KindleUnpack to 0.83 along with Sigil and Calibre plugins.

I like pdurrant's lovely drag & drop AppleScript very much, so I'm attempting to expand my experience with AppleScript applets and see if I can update it myself.

I downloaded KindleUnpack python scripts from KevinH's GitHub. I then opened the existing 0.81 AppleScript with "Show Package Contents" and copied all the files from KindleUnpack "lib" folder into the AppleScript's "Resources" folder, overwriting any pre-existing file with the same name. I then opened the AppleScript with Script Editor, navigated to Bundle Info and updated the Name and Short Version to 0.83. Then I compiled (hammer icon), ran the script (play icon), and saved everything.

Also, each file seems to exist as a .py and .pyc. The files I copied over from KindleUnpack GitHub folder were all .py, so the .pyc files were not overwritten, though after I saved the AppleScript the date modified on all the .pyc files changed to today's date. I have no idea what this means.

When I dragged an azw3 onto the finished AppleScript, it appeared to run properly and produced a folder with the unpacked Kindlebook. However, I don't really know what I'm doing here, so any feedback on whether I'm missing anything would be greatly appreciated. Thank you!

It sounds like you did the right things. The .pyc are cached compiled versions of the .py files and will be overwritten by new versions when the updated .py files are run.

[odamizu]

Originally Posted by pdurrant

It sounds like you did the right things. The .pyc are cached compiled versions of the .py files and will be overwritten by new versions when the updated .py files are run.

Thank you! This is exciting

Was it necessary for me to compile and run the AppleScript after copying over the files? Or would copying the new files into the AppleScript have been sufficient?

And thank you, pdurrant, as always, for your wonderful AppleScripts. I love them so. I have tried to learn to write AppleScripts, but I don't get far before hitting a wall in my inadequate brain