Hi Doitsu,
Quote:
Originally Posted by Doitsu
The PW2 only creates an .azw3r file if an .apnx was copied to the .sdr folder prior to opening the ebook for the first time. (It also creates an addional .mbp1 file in .sdr folders of mobi7 files.) However, it seems that it cannot create an .azw3r/.mbp1 that contains valid page number references from the reverse-engineered .apnx files.
|
That is very strange. When I compare the data stored inside the .azw3r file it is obviously created directly from the apnx file. It has every single offset value and it has the exact same pagemap itself.
To make this more specific. The apnx file that was created had the following pagemap and page offsets (in hex).
pagemap string: (2,r,1),(5,a,4)
page starting offsets: 0x13f, 0x783, 0x1591, 0x22d2, 0x3239, 0x4051, 0x4d9b, 0x5d0b, 0x6b23, 0x786d
The azw3r file has the following data in it (in hex and strings)
Code:
00000000: 0000 0000 001a b126 0200 0000 0000 0000 .......&........
00000010: 0101 0000 0002 fe00 0017 616e 6e6f 7461 ..........annota
00000020: 7469 6f6e 2e63 6163 6865 2e6f 626a 6563 tion.cache.objec
00000030: 7401 0000 0000 fffe 0000 0861 706e 782e t..........apnx.
00000040: 6b65 7903 0000 0131 0300 0004 4542 4f4b key....1....EBOK
00000050: 0001 0100 0000 0b01 0000 0000 0100 0001 ................
00000060: 3f01 0000 0783 0100 0015 9101 0000 22d2 ?.............".
00000070: 0100 0032 3901 0000 4051 0100 004d 9b01 ...29...@Q...M..
00000080: 0000 5d0b 0100 006b 2301 0000 786d 0100 ..]....k#...xm..
00000090: 0000 0201 0000 000a 0100 0000 0a03 0000 ................
000000a0: 0f28 322c 722c 3129 2c28 352c 612c 3429 .(2,r,1),(5,a,4)
000000b0: ff
You can easily see the page map identically stored near the end of the azw3 file as (2,r,1),(5,a,4).
You can also see the exact same set of page offsets in the azw3r file starting at location 0x59 reproduced here:
0000013f 01
00000783 01
00001591 01
000022d2 01
00003239 01
00004051 01
00004d9b 01
00005d0b 01
00006b23 01
0000786d 01
So each offset is properly found and stored along with a single byte type identifier of some sort.
In a similar way, I can find the number of page names (10 = 0xa) and the length of the pagemap string all properly stored as well.
So your PW2 does seem to be properly consuming that apnx file and parsing and storing that information in the azw3r file.
So we are very very close. It must be something else in the apnx.key before the page offsets, and pagemap that is confusing the hell out of your PW2.
It would be nice to see a a working azw3r file to compare it against to see if it is something simple we can fix in the apnx generatiion routine to make it work.
Thanks for testing and reporting back.
Take care,
KevinH