IMHO, azw3-only files should be avoided, since only a limited number of devices and apps support them. Also, master mobi files that contain both regular mobi and KF8 segments aren't significantly larger if you use the -c2 compression option with Kindlegen 2.4 and strip off the source with the KF8 version of Kindlestrip.py.
If you need to use KF8, for example, for books that contain Hebrew or Arabic text, I'd recommend using Kindlegen 2.4 and replacing the mobi section with a warning stating that this file requires a device or app with KF8 support. (That's what I did with my English-Arabic .mobi file.)

Dreams - Jon uploaded to the other books forum, but I'll wait until it's been discussed by the moderators before I post any azw3 ebooks to the library.

Doitsu - So far as I know only Kindle Touch and Kindle Fire readers read azw3, and I agree that that's a limited number of devices. But I don't think that necessarily means that only a limited number of people read azw3 ebooks, nor that there won't be more using this format in future. After all, if Jon can go to the dark side and use a Kindle then anything can happen. I'm the ebook designer for two small presses in the UK, and need to know when we should start supplying our ebook in azw3 as well as ePub and mobi - or perhaps if we start supplying our ebooks in azw3 format. If I do I'll almost certainly use calibre.

Last edited by AlexBell; 06-01-2012 at 04:09 AM.
Reason: Added the last sentence

...So far as I know only Kindle Touch and Kindle Fire readers read azw3, and I agree that that's a limited number of devices. But I don't think that necessarily means that only a limited number of people read azw3 ebooks...

The various "Kindle for ..." reader apps also now support KF8. Still, a substantial majority of the installed devices and apps today (2012-05) don't support KF8 and these probably never will. It will be quite some time before Classic MOBI fades into a minor player.

You should also consider that the vast majority of users, unlike the population here at MR, will not understand the difference between Classic MOBI and KF8 and thus giving them a choice will only be confusing. You should post single hybrid files leaving the user with only two choices; ePub and Kindle/MOBI.

I see no problem uploading KF8 only versions. Why force people to have to download a bloated file they they have no need for 1/2 of it? Besides, in the case of The War of the Worlds we already had a good Mobipocket edition as I made it.

I see no problem uploading KF8 only versions. Why force people to have to download a bloated file they they have no need for 1/2 of it?

I find it somewhat strange that someone who doesn't even own a Kindle suggests creating .mobi files that only a small number of Kindle users (and owners of other ebook readers with .mobi support) can actually read on their devices.

BTW, you're wrong as far as the file size is concerned. For testing purposes I compiled your ePub version of “War of the Worlds” with KindleGen 2.4 and Huffdic compression (-c2). After stripping the .mobi source files both files were almost equal in size: ePub = 1.96MB; mobi = 2.11MB

For good measure, I did the same conversion in Calibre: mobi = 398KB; azw3 = 2.05MB

As the numbers clearly show, it's definitely not the mobi part that leads to overly bloated files, because in most cases you could easily include the regular mobi version without a significant increase in file-size.

I find it somewhat strange that someone who doesn't even own a Kindle suggests creating .mobi files that only a small number of Kindle users (and owners of other ebook readers with .mobi support) can actually read on their devices.

BTW, you're wrong as far as the file size is concerned. For testing purposes I compiled your ePub version of “War of the Worlds” with KindleGen 2.4 and Huffdic compression (-c2). After stripping the .mobi source files both files were almost equal in size: ePub = 1.96MB; mobi = 2.11MB

For good measure, I did the same conversion in Calibre: mobi = 398KB; azw3 = 2.05MB

As the numbers clearly show, it's definitely not the mobi part that leads to overly bloated files, because in most cases you could easily include the regular mobi version without a significant increase in file-size.

I don't use KindleGen. I use Calibre to do the conversion. So please redo your math based on Calibre's output.

In my past experience when creating mobi files, they used to be slightly larger than ePub. But sometimes the default mobi conversion implies reducing the size of all images, which results in much smaller mobi (and often much uglier).

You should also consider that the vast majority of users, unlike the population here at MR, will not understand the difference between Classic MOBI and KF8 and thus giving them a choice will only be confusing. You should post single hybrid files leaving the user with only two choices; ePub and Kindle/MOBI.

I'm not suggesting for a moment that azw3 will replace mobi in the near (whatever that means) future. And if we do start providing azw3 ebooks as well as mobi ebooks it will be a trivial task to put something up like bookname.mobi (for Kindle 3) and bookname.azw3 (for Kindle Touch and Kindle File).

Part of the reason for my initial query was to ensure that there would be minimal confusion for users of the MobileRead library.

I don't really have much of a vested interest in how it ultimately gets handled, but there's something to be said for the fact that uploading combo files means nothing has to change from the current forum setup: no new subforum... nothing. The MOBIs in the MOBI forum would just slowly start gaining KF8 functionality. Those who know and care can always do whatever they want to the file anyway... and those who don't care won't have to mess around with inevitably downloading the wrong format and getting all cranky about it. Why reinvent the wheel for stand-alone KF8 ebooks?

Also, I believe if a post has two attachments (one for mobi and one for azw3), it could possibly affect calibre's Get Books search feature.

However it turns out... I believe one ebook attachment per post should be part of the procedure.