Amazon’s missed opportunity
The Kindle finally got library support yesterday. This was an ability that Amazon could have had at launch, except (for some reason known only to them) they didn’t want it.
As I was thinking about Amazon’s decisions to limit what the Kindle could do, I was reminded about an upgrade Amazon could have had if they wanted. They passed on the opportunity to upgrade the Kindle file format before it launched.
As you probably know, the Kindle file format is virtually identical to Mobipocket (Amazon bought Mobipocket in 2005). Aside from a few extra twists in the DRM, Kindle does everything the exact same way as Mobipocket. This would be fine except that Mobipocket is based on an old version of HTML. When the Kindle launched on 2007, that HTML support was an antique and it’s only getting older.
Amazon has always maintained that the 2 formats are not the same, so they really could have added support for a better file. Sure, keep support for Mobipocket, but also give the new device a chance to really pull ahead of the pack. The original Kindle had the hardware to support the format, too, so it was really just matter of writing the code.
Amazon can’t update the file format now; it’s far too late. There are millions of still functioning K2 and original Kindles out there that Amazon don’t and can’t provide updates for.
But if they had, do you know what it would have meant?
Amazon could have released their own variation of an Epub file before anyone else.
P.S. Did you know that Amazon have been hiding Epub inside some Kindle ebooks since last September? It’s been debated ever since the detail was discovered, and the consensus is that Amazon is getting ready for a switch to Epub or, in my opinion, some other kind of improved file. They could have taken that step back in 2007, but didn’t.
P.P.S. If you want to look for the Epub contents of a Kindle ebook, here’s how. Take a recently released Kindle ebook and try to open it with WinZip or some other utility. Often times this app will find the beginning of the ZIP file and open it for you.
image by Chris Walters of BookSprung
Tom April 22, 2011 um 1:54 am
Let’s consider Kindlegen, the official tool for generating .azw files for submission to Amazon’s KDP platform. You can indeed feed it ePub source files, but only if you trust the tool to convert to Kindle format in some optimal fashion (you should not) and are too lazy to read the spec for Kindle format and prepare your source files accordingly, so that conversion is not necessary and you control the results explicitly.
So, yes, it looks like Kindlegen now saves source files in the .azw file (I have to take that on faith as I haven’t been able to verify this using the method you describe above – you don’t mention a specific title that one could check – I can’t unzip any of the .azw’s I’ve generated myself, and have not found the requisite YouTube video that demonstrates this phenomenon. ).
But what kind of source files are these likely to be if the source was not even ePub in the first place? Are you suggesting now that kindlegen looks at the kindle-mobi source files, removes the special mbp tags, and transforms it into valid ePub source before storing it in the azw file? That is some crazy tool!
Much more likely is that they store the original source files without any transformation. So if your source was ePub, it stores that. If it was kindle-mobi, it stores that.
There are a couple of good reasons for Amazon to start doing this:
– storing source in the .azw allows Amazon to regenerate an .azw file that was corrupt due to some bug in Kindlegen. Not only could they analyze the specific source code that resulted in the problem in order to fix the Kindlegen bug, but once they had a fix, they could regenerate the .azw without going back to the submitter and saying, "Gosh, we are really so sorry, but your .azw didn’t compile correctly and we don’t know why. Could you please dig out your source files and try this new kindlegen tool? We think it might fix the problem, but we just can’t be sure. So sorry to bother you."
It could ALSO be a way to pave the way to a new format, be it Kindle-mobi v.2 or ePub 3, or whatever. Having access to the source would let them generate kindle-mobi v1 for delivery to devices which will not be updated to read the latest supported formats.
But again I don’t think we can conclude that ePub is the direction all of this is heading. They are just taking a useful feature of ePub (that it contains its own source) and mapping it to .azw in a way that is backward-compatible and also doesn’t require any changes to their server side workflows.