azw3 vs mobi vs prc/pdb on a Kindle

[NiLuJe]

Note that you probably get much larger files because KindleGen actually produces dual mobis, which bundles both the KF7 and the KF8 parts (... and the source).

I'm not familiar with the new Sigil workflow, but I know we have a tool in the Kindle Format forum whose sole purpose is trimming that down so you only end up with the part you care about (which will most likely be KF8, unless you have a specific attachment to the layout and feel of the KF7 renderer).

[rashkae]

I won't say that mobi is better than azw3 by fiat. Mobi has just about everything you need to read prose fiction. And indeed, in many cases, the limited formatting allowed by mobi limits the bad formatting that publishers like to inflict.

However, since the question was asked, some things that azw3 supports that Mobi does not:

Margins: both left and right. People have been faking something that resembles a left margin by nesting paragraphs in indented blocks.. But anything that uses different margins for some types of text, (block quotes, usually) will benefit from AZW3.

Float elements. Most often used for a drop cap. (where the text actually flows along side the drop cap, not just large letter.

Customizable font sizing. em for the win.

Ever since the Kindle touch ( and maybe on older models, somehow, I don't know.) Images in AZW3 files can be zoomed and panned. Great for maps, and what not. Kindles are the best e-ink readers I've seen for handling large, high resolution images smoothly.

I haven't tested this since the Kindle touch, but turning *back* oages on AZW3 viewer was much, much faster than mobi files.

[JSWolf]

Offset margins both left & right and custom font sizes are the two mostly used features that Mobi does not support. (IMHO), when the text is supposed to be offset both left & right, it looks awful when it's just offset to the left.

[eschwartz]

Originally Posted by dhdurgee

K3W = Kindle 3 Keyboard - WiFi model - S/N: B008 xxxx
KT2 = Kindle Touch 2(Basic - 7th generation) - S/N: 90C6 06xx

Dave

Just say K3 and stop confusing people.

Originally Posted by notimp

edit2: As for the larger azw3 files. Amazon promoted .azw3 as a container for both .mobi and .kf8 for its entire format life. When you think of .azw3 the way current Kindles see them, you are actually thinking of .kf8 in the .azw3 wrapper. .azw3 mostly becomes that much "bigger", because there are both the .mobi and the .kf8 version of a book embedded in one .azw3 file.

Amazon used it as a transition technology (to get away from .mobi and .prc which had a legacy of being "rather open").

Calibre has an option to only package the .kf8 file in there (actually it is its default .azw3 setting for some time now), which almost halfs its filesize.

Um, not really?

Amazon always delivers split *.azw (MOBI) or *.azw3 (AZW3).
kindlegen generates dual-MOBI (has both) and names it *.mobi

So, no.
*.azw3 has never ever been a container for mobi7.
And they have never used *.kf8 as a file extension.


AZW3 is legitimately somewhat bigger than MOBI on average.

It makes up for it by properly supporting CSS, by supporting separate files internally, by supporting properly defined covers... Just try cracking one open in calibre's Editor.

I like being able to update the cover without doing a MOBI-to-MOBI conversion.
ToC support is also better.




Basically, AZW3 is more polished than MOBI. It is feature-comparable to EPUB.

MOBI predated EPUB altogether, and in many ways is just an ancient, lousy format.


I will agree that KFX has not brought anything new to the table.

Originally Posted by notimp

Name the features you are talking about that get lost in your opinion. .azw3 (.kf8) has brought less new stuff to the "playing field" than you might expect.

And as .css formating conventions go - it was mostly hit and miss anyhow. You can argue, that once people accepted azw3 as the new default, they optimized their .css sheets for it - but thats all minor stuff in comparison (think floating text around objects, marginally better alignment options for some objects, stuff like that).

But lets not draw this out beyond its purpose here... Look at both, decide for yourself. The usage with JBPatch is a fringe case anyhow. (And in the end you almost always want hyphenation - so...)

For me its more about the story behind it (azw3 (kf8) by no means was that much better "featurewise" - it mostly served another purpose... ).

If the ePub 3.0 featureset became more widely used, the story might have been different.

Yes, that enhanced CSS support is put to good use, as mentioned above. Just because you don't think CSSis useful, doesn't mean everyone else agrees.

MOBI was dramatically behind EPUB on that front, and AZW3 caught up.

[JSWolf]

Oh and ePub 3 has nothing to do with this. So please stop mentioning it.

One other advantage KF8 has over Mobi is that you can edit KF8 using Calibre's eBook editor.

[notimp]

Nice oneliners! And so demanding...

epub3 - conceptually was the format that should be able to match the industries print publishing standards - in layout options.

It turned out that the industry wasnt interested in the slightest, they'd rather stick to their - remove all formating, then slap an existing Indesign css preset over it with no real interest in actually starting the layout process "for real" - model. Its maybe one of the worst models out there - but hey, its the industry standard - and everything else is perceived to only drive additional expenses.

epub 3.0 instead was used as a driver for a new copy protection scheme that didn't take, because the delivery infrastructure was pretty bad (segmented) to begin with. Thats the technical wording for, they couldnt do an over night auto delivery rollout like Amazon did with .kfx. Without anyone in the blogosphere noticing.

Editing in .kf8 instead of .epub is something that people in here usually do? I dont know much about the motivations of people switching from Sigil to the Calibre editor to be entirely honest. More convenient I suppose?

[notimp]

@eschwartz:

I was under the distinct impression, that kindlegen created those dual packaged (kf8 and mobi) azw's (might not have been called azw3...) for quite some time. Should I be wrong?

(edit: Wait, let me use a comment JSWolf made back in 2013 to underline my point- https://www.mobileread.com/forums/sho...3&postcount=21

Shocking - I know...)

If Calibre packages the combi format as .mobi and not .azw I was wrong about that.

Also - if this community resorted to in fact treating .kf8 as a production standard, I am suddenly much less confused about the fond relationship you guys seem to have with Amazon formats.

In my circles I never recommended anything other than using ePub as the production format - treating both kf8 (azw3) and mobi as "end formats" only.

I understand the want to f.e. replace a cover in an azw3 without having it wander through the calibre conversion (i.e. replace every descriptor with calibre1-100) treatment - but have never realized to what extent you guys may actually have used it.

Hand editing the .css equivalent int .kf8 files was something I presumed most people wouldnt do - because of the obvious implications to the workflow (who produces a .kf8 separately from the .epub equivalent?), and that the internal structure of the file is much nicer than .mobi was - has implications for preservation -- but usability wise it really doesnt matter that much.

Then again - there is a discussion to be had if the .mobi interpreter in Kindles not recognizing pagemargin or even the text alignment tag for the default paragraph formating was a good or a bad thing.

Also - I'm happy that .azw3 exists as a reverse engineered format (in fact - I would be much happier if .kfx could ever reach that state - but also if Amazon would stop to arbitrarily invent file formats to get an advantage over the general public, or even publishers for starters) and if the format is that much more accessible and structured - that is a good thing from a creators point of view (allthough authoring still is and should be done in .epub ) - but if you look at the actual formating options we have lost on the device level - since JBPatch doesnt work anymore - I am not sure if I would have taken it as a tradeoff If someone had offered it to me.

Of course Amazon doesnt ask.



edit2:

Kindlegen never produced ".azw" files. It only produced .mobi files. Which at the time Amazon used to distribute as .azw - by arbitrarily renaming the file extension.

see: https://kdp.amazon.com/community/thr...threadID=44548

Those .mobi files always were the "combi files" we are talking about here, and not .mobi files in the sense of the file format before amazon "enhanced and renamed it".

So .mobi colloquially mostly was used for "real .mobi" files. .azw for Amazons "combi format". And .azw3 only for .kf8 as a stand alone.

I thought of .azw3 being the combi format as well, allthough thats actually wrong. I'm sure I used it correctly back in the day - but today, thats a definite slip up.

[JSWolf]

Originally Posted by notimp

Editing in .kf8 instead of .epub is something that people in here usually do? I dont know much about the motivations of people switching from Sigil to the Calibre editor to be entirely honest. More convenient I suppose?

If you buy an eBook from Amazon, remove the DRM (or it comes with no DRM), then you download the KF8 to load into Calibre. You then can edit it if you've found something you want to change like say the generic cover for a real cover.

[notimp]

I always convert those to ePub to do the changes - but thats more of a habit I suppose. In both of our cases Calibre also stores the original file as an untouched copy - which frankly is the most important step.

But yes - I understand why you would do it.

As you see I come more from the "production side" of things - where it makes very little sense to treat Amazons file formats with any additional attention for detail.

(It only would be a "value add" for Amazon - and honestly, why should we become more invested into something that by definition was created to be "something proprietary for them"...)

You make sure, that most of your .css stylings make it through the automated conversion, and thats it. Any additional time you put into them, essentially is lost.

[eschwartz]

Originally Posted by notimp

@eschwartz:

I was under the distinct impression, that kindlegen created those dual packaged (kf8 and mobi) azw's (might not have been called azw3...) for quite some time. Should I be wrong?

(edit: Wait, let me use a comment JSWolf made back in 2013 to underline my point- https://www.mobileread.com/forums/sho...3&postcount=21

Shocking - I know...)

If Calibre packages the combi format as .mobi and not .azw I was wrong about that.

Which part of this was confusing?

Originally Posted by eschwartz

Um, not really?

Amazon always delivers split *.azw (MOBI) or *.azw3 (AZW3).
kindlegen generates dual-MOBI (has both) and names it *.mobi

So, no.
*.azw3 has never ever been a container for mobi7.
And they have never used *.kf8 as a file extension.

I ask only so in the future, I can avoid accidentally not being as clear as I should be....

Addendum: calibre can create MOBI, AZW3, or dual-MOBI. dual-MOBI is an option in MOBI Output settings, and follows kindlegen's precedent (of backwards compatibility in the filename) in naming the file *.mobi

Also - if this community resorted to in fact treating .kf8 as a production standard, I am suddenly much less confused about the fond relationship you guys seem to have with Amazon formats.

In my circles I never recommended anything other than using ePub as the production format - treating both kf8 (azw3) and mobi as "end formats" only.

Actually, as an end-user I recommend always treating the conversion originals as a gold standard.
Conversion processing can only ever get better over time, and conversion is inherently lossy.

If I was advising an ebook producer, I would say use EPUB as a master copy. It is well-supported as kindlegen input, and AZW3, in addition to being a weird binary format, has the whole "what are filenames" mentality.
EPUB has more support in ebook editing and creation tools, too.

calibre's Editor is the ONLY tool that handles AZW3.
But it takes a while to decompile and recompile the Palm database wrapper every time you open or click Save.
And it doesn't handle MOBI, even though Amazon requires both for upload.

So it is just stupid to work in a format that isn't really designed for editing.
One-shot fixes by consumers is still a handy crutch to have, though.

I understand the want to f.e. replace a cover in an azw3 without having it wander through the calibre conversion (i.e. replace every descriptor with calibre1-100) treatment - but have never realized to what extent you guys may actually have used it.

Lots. You wouldn't believe how many stupid publishers with stupid non-covers there are...

Hand editing the .css equivalent int .kf8 files was something I presumed most people wouldnt do - because of the obvious implications to the workflow (who produces a .kf8 separately from the .epub equivalent?), and that the internal structure of the file is much nicer than .mobi was - has implications for preservation -- but usability wise it really doesnt matter that much.

Then again - there is a discussion to be had if the .mobi interpreter in Kindles not recognizing pagemargin or even the text alignment tag for the default paragraph formating was a good or a bad thing.

It is in the format, not the interpreter.
Again, I would say that having the option is only a good thing.

And it means that converting from AZW3 to EPUB produces much better results (internally!) than converting from MOBI to EPUB.
(conversion == either calibre or KindleUnpack)

I do know that people will sometimes convert to MOBI in order to "lose" formatting they don't like, then back to their preferred reading format.

[Tarana]

With a Kindle Keyboard or Kindle Touch, you will not notice ANY difference between the formats. I certainly haven't. No change in justification, lettering, letter sizes. Nada. However, as some have reported on here, you will see some additional options on newer models such as the Paperwhite. In some cases, you get more type sizes, which is good for me-with mobi, some of the books go from normal to giant and nothing much in between. AZW3 resulted in some stepping in the sizes. Drop caps also seems to work better in AZW3 on a newer device.

I have not done a comparison on justification or other functions...just haven't noticed it as an issue for me, I guess.

[dhdurgee]

Thank you all for your feedback on this topic. It sounds as if there are enough improved features in the kf8(.azw3) format to make it worthwhile to use it over the other formats even with the increased file sizes. This is especially true if hyphenation is added to the documents. I am submitting a query in the Sigil forums to see if a plugin similar to the Calibre one can be added there.

Thank you again for your feedback.

Dave

[JSWolf]

Originally Posted by dhdurgee

Thank you all for your feedback on this topic. It sounds as if there are enough improved features in the kf8(.azw3) format to make it worthwhile to use it over the other formats even with the increased file sizes. This is especially true if hyphenation is added to the documents. I am submitting a query in the Sigil forums to see if a plugin similar to the Calibre one can be added there.

Thank you again for your feedback.

Dave

You don't want to hyphenate ePub. Most ePub rederers (such as ADE/RMDSK) will not properly display the hyphens and if ou need to make changes to the ePub, the hyphens will get in the way. Also searching breaks with the hyphens.

What you should do is after you've finished with the ePub and converted to KF8, you can use the Hyphenate This! plugin for Calibre to hyphenate the KF8 and then you can load the hyphenated KF8 onto your Kindle and it will work and the ePub is still good to go if for any reason you need or want it.

[dwig]

Originally Posted by Tarana

With a Kindle Keyboard or Kindle Touch, you will not notice ANY difference between the formats. I certainly haven't. No change in justification, lettering, letter sizes. Nada. ...

Correct. Also, converting from one of the older, more limited formats will not auto-magically add any enhancements. A conversion to a newer format will offer the possibility of manually making edits that may be desirable.

[dwig]

Originally Posted by eschwartz

...
MOBI predated EPUB altogether, and in many ways is just an ancient, lousy format.
...

Ancient, yes, but I wouldn't call it "lousy". MOBI was arguably the best of the early ebook formats. It certainly was the best survivor and had a much more desirable feature set than the other dominant format of that era, the Apportis DOC (also known under various later names such as PalmDOC), which was only slightly more advanced that TXT.

MOBI is an early implementation of the original Open EBook specification, which was based on a subset of HTML3.2 and didn't specify a container, only the format of the source documents. MOBI files were compiled into a binary file which allowed them to get past the limitations in the PalmOS's PDB (Palm DataBase) format. EPUB was born as v2 of the OEB spec with a standardized wrapper (specialized ZIP archive). It is based on a newer iteration of HTML with its companion CSS. MOBI did get "out of date" in terms of its feature set.