Quote:
Originally Posted by Notjohn
I think you're expected to use iTunes to get the file onto the device, not sideload it yourself.
|
Ah, sorry that I wasn't clear: that's what I meant by "sideloading". With an iOS device, I suppose "true" sideloading would involve direct file system manipulation, and possibly jailbreaking.
Quote:
Originally Posted by DaleDe
Check AZK in our wiki. An AZK is a zipped archive. It is likely that they unzipped it. |
I did see that wiki entry--it's actually the most thorough analysis of the .azk format anywhere on the internet, and was very helpful!
However, what I see on the iPad is not simply an unzipping of the .azk archive. Here's what the contents of my .azk look like if I open it up:
(Note that I trimmed the quantity of files or the post would be 3 pages long.)
Code:
└── book
├── frags
│** ├── gz_frag0.jsonp
│** ├── gz_frag1.jsonp
│** ├── gz_frag10.jsonp
│** ├── gz_frag100.jsonp
│** ├── gz_frag101.jsonp
│** ├── gz_frag102.jsonp
│** ├── gz_frag103.jsonp
│** ├── gz_frag104.jsonp
│** ├── gz_frag105.jsonp
│** ├── gz_frag106.jsonp
│** ├── gz_fragmap.jsonp
│** ├── gz_skeleton0.jsonp
│** ├── gz_skeleton1.jsonp
│** ├── gz_skeleton10.jsonp
│** ├── gz_skeleton11.jsonp
│** ├── gz_skeleton12.jsonp
│** └── gz_skeleton13.jsonp
├── kcrManifest.jsonp
├── metadata.jsonp
├── mimetype.json
├── mobilocations
│** ├── gz_mobilocations0.jsonp
│** ├── gz_mobilocations1.jsonp
│** ├── gz_mobilocations10.jsonp
│** └── gz_mobilocations11.jsonp
├── output.json
├── rawManifest.jsonp
└── resources
├── resource0
├── resource1
├── resource10
├── resource100
├── resource101
└── resource102
So I take the .azk and load it onto my iPad, via iTunes. Because it's iOS 5, I can use iFunbox to look at the file structure and see what my book looks like now that K4iOS has processed it. This is what I see:
Code:
└── my_book_title
├── book.kcr
├── gz_fragment555.jsonp
├── gz_fragment556.jsonp
├── gz_fragment557.jsonp
├── gz_fragment558.jsonp
├── gz_fragment559.jsonp
├── gz_fragment560.jsonp
├── gz_fragment561.jsonp
├── gz_fragment562.jsonp
├── gz_fragment563.jsonp
├── gz_fragment564.jsonp
├── gz_fragment565.jsonp
├── gz_fragment566.jsonp
├── gz_fragment567.jsonp
└── resources
├── 1004544089
├── 621764591
├── 624248723
├── 689149105
├── 716323204
├── 760635517
├── 768981550
├── 769084276
├── 874920377
├── 884243033
├── 885818391
├── 966245230
├── 975879832
└── 98527426
(Again, I removed some of the files because there were a lot.)
So, it's more than a simple unzip, there's some sort of processing that's done on these files.
On a related note, this is the directory structure of one of the books that I synced down straight from the Amazon cloud:
Code:
└── B00AFR4CK2_EBOK
├── book.kcr
└── resources
├── 1198181274
├── 1213596095
├── 1381148118
├── 1508313587
├── 15464168
├── 1716487958
├── 1866276677
├── 1983956603
├── 2059389305
├── 242373662
├── 308183104
├── 517793479
├── 582929403
├── 657402086
├── 808580617
└── toc.ncx
Similar, but not quite the same as what came out of K4iOS's processing of the .azk file. Does anyone know what that file type is? Other books that I synced down from Amazon came as straight-up .azw files...what is this directory with the .kcr manifest thing? Is this documented anywhere?
All that said, I did download the latest Kindle Previewer for Windows and gave that a spin. I loaded in the generated .azk via iTunes, it processed correctly (and shows the cover image in the library, again) but when I tried to open it I get the "Please delete and re-download this book" error. So, same thing as Previewer for OSX. If it's an azkcreator bug, it's common across the platforms.
Any other ideas?
I may start hacking apart my file to see if something in it is foiling azkcreator or the K4iOS .azk conversion process...