Kindle K2/DX/DXG 3.2.1 升级 3.4.2 教程

一直没有中文教程，于是写个。本来发在mydoo.cn，貌似管理员不见了一直没审核，想想干脆放这里算了= =

本教程理论上 Kindle 2, Kindle 2i, DX, DXi, DXG 通用，非 DXG 机型需自行修改以下全部 .bin 文件，详细请先参见后半部分。
本教程文字部分遵循CC BY-NC-SA 4.0 协议，二进制文件版权归属 Amazon。
原方法来自 newman@MobileRead，诸多 hack 研究感谢 Yifan Lu, NiLuJe, knc1 等菊苣。
原方法需要一定的 Unix 基础进行自行改动，较为繁琐；本教程全部打包为现成文件提供下载，简化升级流程。
本教程不提供任何保证，因升级引起的变砖、损坏、爆炸、股票浮动、世界大战、地球毁灭等后果请自行负责。

相比于3.2.1，升级3.4.2好处：
1. 3.2.1内置浏览器不支持大量https网站，自3.4.1开始完整支持TLS1.1加密，可以正常使用大部分https网站（国内访问屏蔽或者2013后一批次仅允许Amazon与wikipedia访问等问题无解）。
2. 解决2016年3月22日之后访问 Kindle Store 时的一些问题。
3. 自3.4开始的固件支持 Kindle Format 8 (KF8/AZW3) 格式。
4. 原生字体渲染有所改进。
5. Notes and Marks的一系列改进。
6. 修复了注音符号显示等各种小问题问题。

相比于3.2.1，升级3.4.2坏处：
无。3.2.1原来就有的开启3G时耗电快、破音等问题并未改善，也未加剧。

总结起来，如果在使用3.2.1，非常推荐升级；如果在用官方2.5.8，请自行斟酌。

所需文件点我下载

文件列表：
busybox
fb.modes
update_fb_modes.bin
update_kindle_3.4_3.4.2_B006-my-log.bin
update_kindle_3.4_B006-my-log.bin
update-06-576290015-611680021.bin

升级准备：
1. Kindle DXG，已越狱并安装3.2.1版本固件。具体教程很多，请自行搜索，很多地方都有，例如：http://bbs.mydoo.cn/thread-32419-1-1.html
2. 卸载一切其他 Hack，包括但不限于汉化、字体修改等，恢复出厂设置。由于本固件使用 Kindle 3 固件移植，而 Kindle DXG 硬件规格略低，需要移除一切增加系统负担的修改，非常重要！

升级步骤：
1. 从3.2.1升级到3.3
将 Kindle 连接 PC，并将 update-06-576290015-611680021.bin 文件拷贝至 Kindle 盘下的根目录内，从 PC 正常移除 Kindle。按照 Kindle 常规流程升级（ Home 界面按下 Menu 按键，选择 Settings，再按下 Menu按键，选择 Update Your Kindle）。升级顺利完成后，检查系统版本（ Home 界面按下 Menu 按键，选择 Settings，看右下角版本号 ）。

2. 从3.3升级到3.4
将 Kindle 连接 PC，并将 busybox 文件与 update_kindle_3.4_B006-my-log.bin 一同拷贝至 Kindle 盘下的根目录内，从 PC 正常移除 Kindle。按照 Kindle 常规流程升级。升级顺利完成后，检查系统版本。如果升级失败，连接 PC，在根目录下查看 my-upgrade.out 与 my-upgrade.err，里面会有错误原因。如有问题回报请附上这两个文件。Kindle 根目录下 swapfile 为升级时临时使用的文件，升级成功后可以删除。

3. 从3.4升级到3.4.2
将 Kindle 连接 PC，并将 busybox 文件（和上一步同样的文件，已复制过的可以不用重新复制）与 update_kindle_3.4_3.4.2_B006-my-log.bin 一同拷贝至 Kindle 盘下的根目录内，从 PC 正常移除 Kindle。按照 Kindle 常规流程升级。升级顺利完成后，检查系统版本。如果升级失败，连接 PC，在根目录下查看 my-upgrade.out 与 my-upgrade.err，里面会有错误原因。如有问题回报请附上这两个文件。Kindle 根目录下 swapfile 为升级时临时使用的文件，升级成功后可以删除。

4. 升级 fb.modes 及 KF8 支持
到上一步位置，Kindle 应该已经顺利升级到3.4.2，但中途用于 Kindle Format 8 的 fb.modes 文件与 webreader 设置没有升级，需要进行处理。我已经将处理打包成升级文件。将 Kindle 连接 PC，并将 fb.modes 文件与 update_fb_modes.bin 一同拷贝至 Kindle 盘下的根目录内，从 PC 正常移除 Kindle。按照 Kindle 常规流程升级。升级后 Kindle 连接 PC 的根目录下会有原来旧版 fb.modes 的备份（ fb.modes-old ），可以留着。由于 yifanlu 菊苣的 kindleupdate 源代码里也有这个文件，不留着也没关系……

升级检查：
上述步骤全部完成后，理论上 Kindle 已经到了完整的3.4.2版本。可以通过如下方式进行检查：
1. 检查系统版本号，应该是 3.4.2 (2687240004)。
2. 确保 Kindle 被成功注册（可能需要联系亚马逊官方客服进行注册），然后开启3G，使用 Kindle 内置的 Experimental Web Browser 打开 wikipedia，确认可以浏览（即可以使用基于TLS的https）
3. 前往 Amazon 官方网站或我上传的国内镜像下载 Kindle Format 8 的书籍 sample，解压后将各文件夹里的 *.mobi 文件拷贝至 Kindle 中，并在 Kindle 中打开以测试 KF8 / AZW3 支持是否正常。除了 MultimediaSample 可能出现音频爆音之外，其他无音频的 sample 应该正常显示。

其他注意事项：
由于3.2.1->3.3->3.4->3.4.2多次跨越版本号，部分原先使用旧版越狱方式的可能在某次升级后失效，表现为拷贝 .bin 文件进入设备后， Update Your Kindle 按钮仍不可按，重启强行升级失败。请自行查询新版越狱方式，或下载我这里备份的越狱文件升级尝试。其中 kindle-jailbreak-0.13.N-r13188.tar.xz 适用于3.3及以上版本。

---

 

DXG 用户可以无视本部分。
以上方法适用与 Kindle 2, Kindle 2i, Kindle DX, Kindle DX Internetional, Kindle DX Graphite。但是由于所有的 bin 文件对应本人的 DXG ，如需用在其他非 DXG 设备上，请按照以下方式修改四个 .bin 文件：
update_fb_modes.bin
update_kindle_3.4_3.4.2_B006-my-log.bin
update_kindle_3.4_B006-my-log.bin
update-06-576290015-611680021.bin

使用一款 Hex Editor 打开 .bin 文件，以 HxD 为例（下载）：
打开 .bin 文件，选中 0x0C 位置对应的字符（位置见左下角的 offset ，亦可见下图）：

根据自己使用的 Kindle 设备，将此处的 09 修改为其他数字：

Kindle 2  : 02
Kindle 2i : 03
Kindle DX : 04
Kindle DXi: 05
Kindle DXG: 09

例如您的设备是 Kindle DX，此处应改为04：

然后保存。

对四个 .bin 文件都进行如下处理，然后再按照上一部分教程进行升级即可。

LAVFilters – tMod: Update for HW decoder options

DOWNLOAD link is here:
LAVFilter-tMod

As WMV files cannot be decoded by DXVA2 decoder on my Sandy Bridge laptop, but can be decoded by QuickSync, and as MPDN is advancing as a great player, I’d like use DXVA2(native) in players which can use madVR, and DXVA2(copyback) in MPDN, then QuickSync for those WMV3 videos. And I’m sure still someone would like to use CUVID for MPEG-4, but after DXVA2 native and copyback. So I changed the DXVA2(native) to other HW fallback mechanism, and implemented a new fallback system. Now LAVFilters-tMod can try all four HW decoders. You can set the 1st/2nd/3rd/4th HW decoder, and LAVFilters will try from the 1st HW decoder, and fallback to the next one if it fails.

For example, if you configure LAV Video as above, it will try to use DXVA2-native, then DXVA2-copyback if fails, then QuickSync if fails again, then CUVID. If all of them fails, LAV Video will fallback to software decoders, i.e., WMV DMO for wmvs (if turned on) and avcodec for others or WMV DMO fails. You can also use other sequences, e.g. CUVID->QuickSync->DXVA2….

LAVFilters tMod

Actually I’ve been building LAVFilters before it has a video decoder, but I haven’t put it here because they were built for my own use with minor changes that I thought no one cares. But since my builds are public in nmm-hd, and they were mentioned in the official thread of doom9 recently, I think I should give some INFOs to avoid misusing them.

If you still want to use LAVFilter tMod after reading the following introduction, the DOWNLOAD link is here:
LAVFilter-tMod

---

LAVFilters tMod builds were NOT built from official sources. They were patched for my own needs. The differences are:

0. No official coding signature, of cause.

1. Support reading Matroska Tags as media tags. But I didn’t do a mkv-tag to normal metadata mapping, but simply convert mkv-tags into lower case, which in most cases equal to metadata. You can get most tags correctly, like ‘TITLE’, ‘ARTIST’. It is good enough for me, so currently I don’t have any plan on doing a full mapping or something like matroska_convert_tag in FFmpeg.

2. Support trying DXVA2(native), then other HW decoder if DXVA2(native) fails, and then SW decoder if fails again. If you need either DXVA2(native) or other HW decoder, leave them as-is, and tMod would perform identical to the vanilla build. I need this mainly because I was using DXVA2(native) when I do not use DirectVobSub, but I wanted CUVID/QuickSync/DXVA2(copy-back) if the video comes with subtitles. But if you had already been using XySubFilter for a while, you definitely don’t need this feature.

Because of this change, tMod used to be not safe to replace MPC-HC’s internal LAVFilters (when opening the LAV Video setting page from Options, it’ll crash). But now I use some other method, and you can replace MPC-HC’s LAVF with tMod safely. All settings will be converted to tMod’s with no mass in your registry.

3. You can find git revision number anywhere the version number exists. This might be useful for bug reporting.

4. The priority of output colorspace is somewhile different from vanilla builds. (x:y:z below refers to YUV)
For 8-bit 4:2:0 input, tMod prefers
4:2:0-8bit > 4:2:0-10bit > 4:2:0-16bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > RGB-8bit > 4:4:4-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit, instead of official
4:2:0-8bit > 4:2:0-10bit > 4:2:0-16bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit > RGB-8bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > 4:4:4-8bit
For 10-bit 4:2:0 input, tMod prefers
4:2:0-10bit > 4:2:0-16bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > RGB-8bit > 4:4:4-8bit > 4:2:0-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit, instead of official
4:2:0-10bit > 4:2:0-16bit > 4:2:0-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit > RGB-8bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > 4:4:4-8bit
……
The rules are changed for all 4:2:0, 4:2:2 and 4:4:4 input colorspaces. The key principal is to use as few chroma-subsampling and YUV<->RGB conversion as possible (this takes YUV->RGB conversion into account), and always prefers highest bit-depth when conversion is needed.

Anyway, if you use madVR, this change is never useful. But if you are using EVR or some renderers that do not support high bit-depth input, this change gives you a way to prefer NV12/YV12 for 4:2:0 8-bit input, while use RGB32 for 4:2:0 10-bit input, which avoids yuv420p10->yuv420p8->RGB chains, but only do yuv420p10->RGB conversion once. The best quality is always preserved. But if you’re using an old machine that cannot handle RGB32 before the renderer, you may want to untick RGB32 box in output colorspace, which actually you should also do in vanilla builds.

5. Some colorspace conversion inside LAV Video does not have custom optimization and uses libswscale routine. I changed the prefered kernel from Bilinear to Bicubic, which has a better quality.

6. The priority of ALAC was raised in the selection of audio stream based on quality for it’s a lossless codec.

7. YV16 output colorspace is added. Actually it has been in LAV Video for a long time, but was hidden for future use. However madVR can deal with it with no pain….

8. Changes from MPC-HC, like exhibiting Matroska attachments through DSM resource bag API, so you can view them in MPC-HC/MPC-BE.

9. For some reason one Matroska file may contain only one hidden edition, but the chapter is not hidden. Vanilla builds shows the non-hidden chapter, but tMod hidden them. I do this because when the only hidden edition is used, everything in the edition section should be hidden, except for the video/audio/subtitles streams. I usually use a hidden edition with chapters to regenerate the long looping Menu Video of Blu-ray Discs. The chapter is invisible but accessible, but one do not need to read the edition info. And this is what I understand from Matroska specs.

10. Some other minor changes that does not affect end users.

avs4x26x 0.10.0 ( x265, AviSynth+, x64, DGSourceIM, etc. )

After the silence of nearly one year.

Download links ( source codes are here): avs4x26x

 

Changelog since 0.9.1:

1. Fix automatically invoking Source Filter for media input files with AviSynth+, using the same patch from BugMaster for x264.

2. Support x265, x264 and x262. That is why we change the name from avs4x264 to avs4x26x. Actually avs4x264mod already supports x265 by simply using --x264-binary, but now if your output file is *.265/*.h265/*.hevc, avs4x26x will launch “x265.exe” even without --x26x-binary or -L. Still, “x264_64” for other output for backward compatibility.

Note that x265 introduce another method: x265 input output. This would not be supported for the x264/x265 recognition. Either avs4x26x input.avs --output output.265 or avs4x26x input.avs -Lx265 output.265 or avs4x26x input.avs --x26x-binary x265 is OK. But if you write avs4x26x input.avs output.h265, x264_64 is implied.

3. Support automatically invoke DGSourceIM, if DGSource failed for “*.dgi” input

4. Since x265 does not support avs input yet, x64 version is reasonable for those who want to use x64 AviSynth with x64 x26x. Now here comes the x64 version, to be used with x64 avisynth.dll.

 

Recently I’m preparing for my wedding ceremony, x264-tMod might be delayed for several weeks.

x264 rev2431 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod,
and on BitBucket: https://bitbucket.org/astrataro/x264_tmod.

Ad: new binary host is http://tmod.nmm-hd.org.

Download: x264_rev2431_tMod.7z

Updates:
Only regular updates as always. Find more details on official x264-devel mail-list.
Nothing changed in tMod

x264 rev2409 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod,
and on BitBucket: https://bitbucket.org/astrataro/x264_tmod.

Ad: new binary host is http://tmod.nmm-hd.org.

Download: x264_rev2409_tMod.7z

Updates:
Only regular updates as always. Find more details on official x264-devel mail-list.
Nothing changed in tMod, except for some minor patch updates for x264 plain branch.

Edited on UTC 11:30 17 Mar 2014:
fixed a bug (patch/audio-support) that Matroska video length was not written after encoding, causing total length not available in MediaInfo or other players and editors. Thanks to reekilynn for reporting.

Edited on UTC 06:00 18 Mar 2014:
Automatically invoke AutoLoadPlugins() if available when using avs demuxer to open non-avs scripts. For AviSynth+. Patch from BugMaster.

x264 rev2389 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod,
and on BitBucket: https://bitbucket.org/astrataro/x264_tmod.

Ad: new binary host is http://tmod.nmm-hd.org.

Download: x264_rev2389_tMod.7z

Updates:
1. x264-audio is too broken to be used, so set default acodec to “none” to avoid errors. Currently only “none” and “copy/raw” (in full version) are available.
2. <patches/ntsc-fps correction> Added an option --no-fps-correction to disable automatic fps correction. For those who need to use non-standard fps like 2997/125 and don’t want it to be corrected to 24000/1001.

x264 rev2377 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod,
and on BitBucket: https://bitbucket.org/astrataro/x264_tmod.

Ad: new binary host is http://tmod.nmm-hd.org.

Download: x264_rev2377_tMod.7z

Updates:
1. Removed all audio codecs, except for --acodec copy/raw. x264 officially uses l-smash mp4 muxer, but I still keep x264-audio stuffs, though many does not function correctly as in previous versions (after libav/ffmpeg’s API updates). You may still build your own x264-tMod with qtaac/faac/lame/lavc support.
2. <patches/decoder> Added an option to select decoder of lavf. Only works for --demuxer lavf. For example, --demuxer lavf --decoder libvpx-vp9 uses libvpx to decode vp9, while by default lavf uses native vp9 decoder (implies --decoder vp9). Currently only vp9 (vp9/libvpx-vp9) and utvideo (utvideo/libutvideo) are tweakable. If QSV or some other decoders were added in lavf, one might select them to boost decoding mpeg-2, vc-1, h.264, etc.
3. Many other patches updated for x264, as now I use official branch as code base instead of x264_l-smash.

avs4x264mod 0.9.1

Download links ( source codes are here): avs4x264mod-0.9.1-git-r64(105c53a).7z

0.9.1:
1. Prefers to use VapourSource for vpy input, as it is a native VapourSynth source filter. Put VapourSource.dll in AviSynth’s auto-load folder, or else x264 would try AVISource/HBVFWSource as before. Keep in mind that unlike HBVFWSource which will automatically imply –input-depth 16, with VSImport x264 wouldn’t know if the vpy output clip is 8-bit or not, so it is needed to manually set --input-depth depth if depth is not 8.
2. Prefers to use LSMASHVideoSource/LWLibavVideoSource as source filter than FFMS2 for many input formats, e.g., mp4/mov/mkv/m2ts/…. Still able to fall back to FFMS2 if LSMASH/LWL fails.

x264 rev2359+704 tMod

Sources on GitHub: https://github.com/astrataro/x264_tMod,
and on BitBucket: https://bitbucket.org/astrataro/x264_tmod.

Ad: new binary host is http://tmod.nmm-hd.org.

Download: x264_rev2359+704_tMod.7z

Updates:
1. Removed some audio codecs, either not work or not proper to be put here. --acodec copy still works, so let it be.
2. <patches/AVS> Prefers to use VapourSource for vpy input, as it is a native VapourSynth source filter. Put VapourSource.dll in AviSynth’s auto-load folder, or else x264 would try AVISource/HBVFWSource as before. Keep in mind that unlike HBVFWSource which will automatically imply –input-depth 16, with VSImport x264 wouldn’t know if the vpy output clip is 8-bit or not, so it is needed to manually set --input-depth depth if depth is not 8.