Content Kindle Comic Converter - Convert comics/manga to MOBI/EPUB

[jhowell]

Originally Posted by axu2

And does anyone remember when pdoc covers started being read by Kindles?

I believe that was added in firmware version 5.15.1, released about two years ago.

[oncpnda]

Is there any chance you can add an option to allow splitting/table of contents using the old method with ComicInfo.xml?

<Pages>
<Page Image="0" Bookmark="Cover" />
<Page Image="1" Bookmark="Characters" />
<Page Image="3" Bookmark="Ch 1" />
<Page Image="67" Bookmark="Ch 2" />
<Page Image="117" Bookmark="Ch 3" />
<Page Image="165" Bookmark="Bonus Chapter" />
<Page Image="171" Bookmark="Back Cover" />
</Pages>

The reason I ask is because using the folder structure
1. gets rid of the ability to use unicode in the chapter name for special characters
2. forces chapter order to be alphabetical rather than number based.

For example, if I have a book with the following:

1. Cover
2. Characters
3. Chapter 1
4. Chapter 2
5. Bonus Chapter
6. Back Cover

Then the order due to OS folder limitations will be

Back Cover
Bonus Chapter
Chapter 1
Chapter 2
Characters
Cover

If I want to preserve the order, then I have to add arbitrary numbers in front of the folder name, which doesn't look great imo.

0 Cover
1 Characters
2 Chapter 1
3 Chapter 2
4 Bonus Chapter
5 Back Cover

I know there were issues with the Image="#" causing indexing problems when there were split pages and other factors, but I was able to just change the Image="#" to account for that.

[axu2]

When you say old method, did an older kcc version work how you described?

Chapters for manga with file size split are automatically removed since the logic of chapters being split across files got messy.

[oncpnda]

Yes, I don't remember which version of KCC it was, but it was from maybe before 2019.

I would put the chapters in the ComicInfo.xml file and when I converted it to a .mobi, I would get selectable chapters on both Calibre and Kindle. You can see the attached screenshots.

I had to upgrade to the latest version of KCC because the one I had stopped working on Mac OS 15.1, but after trying to convert the same book with the same ComicInfo.xml, there were no chapters or table of contents being generated.

An example .xml file is also attached.

[axu2]

Thank you for the report, I have merged a fix. It has been broken since 5.6.4.

KCC had a ComicInfo.xml list index out of range issue when files were chunked. I fixed this issue by disabling ComicInfo.xml bookmarks when no split occured, but I actually disabled bookmarks entirely. Whoops. Fixed now.

Also changed the mobi header from EBOK to PDOC for these devices:

ProfilesKindlePDOC = {
'KO': ("Kindle Oasis 2/3/Paperwhite 12/Colorsoft 12", (1264, 1680), Palette16, 1.8),
'K11': ("Kindle 11", (1072, 1448), Palette16, 1.8),
'KPW5': ("Kindle Paperwhite 5/Signature Edition", (1236, 1648), Palette16, 1.8),
'KS': ("Kindle Scribe", (1860, 2480), Palette16, 1.8),
}

This makes cover upload on MTP kindles way easier and is the only way to get covers on colorsoft. No need to copy a thumbnail file anymore. Or leaving kindle plugged in during conversion.

These devices all can run the earliest kindle firmware that you mentioned that read PDOC covers directly from file.

Let me know if this change might cause issues.

Test build with fixes here: https://github.com/ciromattia/kcc/pull/767

[axu2]

I put out a pre-release version of KCC 7.0.0 with an enhanced page crop algorithm. Please try it out. It also includes the colorsoft, cover, PDOC replacing EBOK, and comicinfo.xml fixes.

[JaneDoe1908]

Hi all! I've looked for a solution to this, but can't seem to find a fix. My 80mb cbz file converts to an epub with the same size (give or take a few mb) and then the mobi exports to 197mb. I've selected "disable processing" If I don't the file exports at almost 250mb. I also don't have stretch/upscaling selected since I resized the files in my cbz to the exact dimensions of my kindle (to make the cbz smaller) So I don't think that it is an upscaling issue. Someone mentioned using KindleUnpack, which I did, but the extracted mobi file gets corrupted or something in the process. This is also just with certain cbz files. Some converted to mobi with exactly the same size as the cbz, and some almost double in size. Has anyone maybe found a solution to this? Or am I doing something wrong? Thanks!

[Homer55]

when processing double spread images, KCC rotates them or divide them by two or both. Is there a way that the double spreads do not rotate and then are shown divided by two? I ask becuase I like to read in landscape mode in order to be able to see better the dialogue and when a double spread is shown, the page is shown like a, well, rotated double spread and I have to rotate it to normal in order to be able to see the complete image and then rotate it back to landscape when reading the separated pages.

[axu2]

Originally Posted by JaneDoe1908

I resized the files in my cbz to the exact dimensions of my kindle (to make the cbz smaller) So I don't think that it is an upscaling issue. Someone mentioned using KindleUnpack, which I did, but the extracted mobi file gets corrupted or something in the process.

Don't resize things yourself, KCC does that already.

Don't modify the mobi, KCC has done all mobi processing needed already.

There might be something wrong with your source file if it only happens to certain files. Feel free to provide a minimal test file that can replicate the issue.

Originally Posted by Homer55

Is there a way that the double spreads do not rotate and then are shown divided by two?

There is currently no way to do that, asked here: https://github.com/ciromattia/kcc/issues/441

You could modify the python code to remove the rotate code.

[JaneDoe1908]

[QUOTE=axu2;4467696]Don't resize things yourself, KCC does that already.

Don't modify the mobi, KCC has done all mobi processing needed already.

There might be something wrong with your source file if it only happens to certain files. Feel free to provide a minimal test file that can replicate the issue.

Thanks for the reply! I only resized the cbz to save space on my hard drive. The large mobi export happened even before then. I also don't modify the mobi at all. I take the exported mobi file and use Calibre to sideload. And it works perfectly. My only issue is KCC gives me mobi files almost twice the size of the cbz file. And it happens to about 90% of my files

[jackm8]

Originally Posted by JaneDoe1908

I resized the files in my cbz to the exact dimensions of my kindle (to make the cbz smaller)

If you're doing it that way, you may look into creating kfx comic files, instead of using this program. It's certain to keep the file sizes the same size as your sources. The process isn't the easiest thing, but it offers some extra goodies like panel view, if it's set up properly in Kindle Create.

You need to have Calibre installed. KFX Plugin in Calibre. Kindle Previewer, and Kindle Create.

Unpack images from cbz. Use Kindle Create to create KPF comic file. Use command line to convert KPF into fixed page KFX.

Template that I use:

calibre-debug -r "KFX Output" -- "replace.KPF" "replace.KFX" -d -p 0

-p isn't needed for comics but does no harm. Only thing that needs replacing is replace.

[axu2]

Originally Posted by JaneDoe1908

I only resized the cbz to save space on my hard drive. The large mobi export happened even before then.

What was the original cbz size before you resized it? And what happened to the sizes after running the original through kcc? Some suspicion that your reduction makes it hard for kcc to handle.

Originally Posted by JaneDoe1908

My 80mb cbz file converts to an epub with the same size (give or take a few mb) and then the mobi exports to 197mb.

When it converts to EPUB, is KCC set to output MOBI or EPUB? EPUB is an intermediate format, if you are observing an EPUB size in file explorer while converting to MOBI you may be looking at an intermediate value that isn't the true size. Try selecting EPUB output instead and see if that's the same result.

Originally Posted by JaneDoe1908

I've selected "disable processing" If I don't the file exports at almost 250mb.

This causes kindlegen to reconvert all files, multiplying export time and reduce quality. Do not use with MOBI and disable processing.

[kript96]

I was reading in a post on reddit someone talking about how mobi generated by kcc are limited to a 1080p resolution, which results in a "softer" image on scribe with its higher resolution. I always thought it was just for the layers on it but this makes sense now. Is there a way to take full advantage of the scribe resolution just using KCC?

[axu2]

Originally Posted by kript96

I was reading in a post on reddit someone using kcc paired with Mapaki to get an azw3 file that should have an higher final resolutions than mobi. I didn't know that mobi limited the resolution to 1080p "losing" ppi on the scribe so i was curious, is there a way to take full advantage of the scribe resolution just using KCC?

kindlegen and Send to Kindle limit the image height to 1920. So effectively 1440x1920 for a full screen image.

the Scribe is 1860x2480.

the other tool mentioned uses a third party way to generate azw3 files without resolutions restrictions in go, which is different than the official Amazon kindlegen that kcc uses. So the final files may behave differently.

more discussion here: https://github.com/ciromattia/kcc/issues/460

Unfortunately, kcc doesn't use that third party go library to generate azw3 manga. Open to pull requests! But kcc is written in python so that might complicate things.

[kript96]

I tried the method described on reddit and compared the same volume, the pages looks the same except sharper, I think it's pretty worth it specifically for the scribe. The only problem is that it's not as easy to move around pages like with a mobi, and obviously is a slower process to convert volumes using both tools.