引用:

原帖由 tainey 于 2016-7-31 15:39 发表
posted by wap, platform: iPhone
因为bba用的是56k猫…

早期是用背后的通信串口输出，所以要一整天。
用BBA来dump只需要25分钟。
并没有任何dump工具使用那个56k的Modem。

引用:

原帖由 coldiori 于 2016-8-9 13:33 发表
posted by wap, platform: Windows
所以这个组织的dc gdi镜像有数据偏移，需要人工修正。

跟这个没关系，dask说的是让部分yamaha光驱变开发机用光驱的固件，受限于那种yamaha光驱的批次，可用性几乎为0.
你说的redump现在的特定固件，是为了让光驱认出一张99分钟的CD TOC后，能够单独发指令控制光驱电机停转和再转，并且再转后，不会去重新加载TOC。和dask说的那种固件不是同一个。

数据偏移问题，是因为redump不正确地使用了gdi这种格式定义。gdi最初定义的时候，要求没有把数据轨和首根音频轨之间的pregap部分略去（其实是352800字节，也就是150扇区的内容为0x00的数据），约定了是要求使用gdi的软件，自己补上这部分数据(因为都是0)。而redump把这部分略去的内容写进了首根音频轨的头部，却依然用了"gdi"作为后缀。对大多数游戏可能不会爆发问题，因为，只不过是所有音轨都偏移了2秒钟而已，但DC有一个很特殊的数据轨定义，就是把一部分数据放到最外圈也就是最后一轨，以加速数据的读取，这数据轨因为之前音轨的2秒偏移，就这样也被往后挤偏移了352800字节，等于里面所有数据都废了。。。

redump坚持这样才是一个gdi应有的状态，不愿意改，实际按我的理解是被人指出了数据存储方法方式不正确，碍于面子不愿意改，期望之后以自己的dump量的增长，让这种改动成为事实标准，所以才变成了现在2种有微妙差异的gdi遍布网络的状况。

[ 本帖最后由 SONIC3D 于 2016-8-9 21:49 编辑 ]