11年的花开物语的音乐资源真难找,绝大部分bt资源都死掉了,我还是悲剧的内网用户,BT下载真悲剧。基本只能靠长效种子的服务器来下载,那些活着的服务器经常都不给我一点资源,就算是1kb也行啊。
下载多个剧场版种子,已经接近一个星期0速度了,观察到不同bt任务情况
比较两个文件大小,两个文件大小完全一致,这两个很大概率是同一个文件。
用HxD打开,观察,坑爹。。。那个下载到95.6%的tak文件居然没有文件头,用播放器打开,提示不识别文件,超悲剧。而那个只下载了43.5%的tak文件,有文件头,用播放器打开也听得到音乐。
拖到文件尾,发现两个文件的尾部都下载好了,而且两个文件尾一模一样,没错了,这两个是同一个文件。
确认这两个是相同文件之后,修复的办法就是用那个只下载43.5%的文件来给那个95.6%的文件来补缺。bitcomet对文件未完成部分看起来只是单纯填充0。tak是无损压缩格式,既然是压缩文件,那正常文件内容不会有一大片0的区域,那存在一大片0的区域就一定是没下载的地方。
熟悉python,写个python脚本 来帮我找哪里有一大堆0,把那个下载到95.6%的tak文件复制出来然后重命名为1.tak,而下载到43.6%的文件复制后重命名为2.tak,以便于区分。一定要复制一份新的来操作,避免损坏原文件。
然后写了个python脚本 来查找这两个文件中哪里里连续存在大于等于16个0字节的区域
import os
f1 = open(r"C:\Downloads\bing\1.tak", 'rb')
f2 = open(r"C:\Downloads\bing\2.tak", 'rb')
log1 = open('1.log', 'w')
log2 = open('2.log', 'w')
def print_empty_seg(f, logf, block_size=16):
empty_has_start = False
empty_start = 0
empty_end = 0
while True:
data = f.read(block_size)
data = list(data)
r = sum(data)
if r == 0 and not empty_has_start:
empty_has_start = True
empty_start = f.tell() - len(data)
s = str(empty_start) + ' '
logf.write(s)
print(s, end='')
elif r > 0 and empty_has_start:
empty_has_start = False
empty_end = f.tell() - len(data)
s = str(empty_end) + '\n'
logf.write(s)
print(s, end='')
if len(data) < block_size:
break
if empty_has_start:
s = str(f.tell()) + '\n'
logf.write(s)
print(s, end='')
logf.flush()
print_empty_seg(f1, log1)
print_empty_seg(f2, log2)
f1.close()
f2.close()
log1.close()
log2.close()
运行后输出两个log文件
log文件中,每行第一个数字是未下载区段的开始偏移,第二个数字是结束偏移。
1.log 文件内容
2.log 输出内容
观察到。。。这两个文件都同时缺了 59713472-59713488 和 89140576-89140579 两端,心里一凉。。。用HxD打开看看
用HxD打开这个下载了95.6%的文件,跳转到59713472
发现这一行全为0,但是上面和下面都有数据,又打开那个下载到43.5%的文件,也跳转到59713472这里观察。
发现这个下载到43.5%的文件,跟之前的95.6%的文件数据一样,猜测,这里应该就是16个0字节,原本就有着16个0字节。
接着看89140576偏移处。
观察到也是一样的,也猜测原来文件也是这样的。。。
这样的话, 59713472-59713488 和 89140576-89140579 就应该不是未下载段了。不过就算是,也完全没办法。。。
--------分界点1
这样的话,那个下载95.6%的文件只有 0-14096 区段是未下载区段了,刚好,那个下载了43.5%的文件正好有对应的数据。
正好,再写个python脚本把 2.tak 的 0-14096 的数据写到 1.tak 中
f1 = open(r"C:\Downloads\bing\1.tak", 'rb+')
f2 = open(r"C:\Downloads\bing\2.tak", 'rb')
d = f2.read(14096)
f1.write(d)
f1.close()
f2.close()
执行后,1.tak处理完了
用播放器打开,听了一遍,没啥问题。然后搜索一下tak文件的特性,看到
每一音频帧都可以校验,突然想起以前好像用过tak的相关工具将tak转换为wav格式,好像还附带查错功能。
去到tak的官网 http://thbeck.de/Tak/Tak.html
找到了一个工具
下载后解压后打开,找到这 Tak.exe
打开后使用这功能
添加刚刚修复好的文件 1.tak
然后点击 Test
呃。。。仍然是损坏文件了。。。
目录下多了个文件,打开
发现这里坏了。。。
试试把 2.tak 也检查一下看看
不出所料也是坏的
但是看看日志
虽然坏了很多地方,但是,可以发现,跟1.tak坏的地方并不一样,错开了。说明还可以继续修复。
那些数字是说第几个帧开始,连续损坏多少个帧,Tak不开源,不知道确切的文件偏移地址。
就用土方法,这1.tak文件大小是85.0M
用百分比公式来大概猜测文件偏移。并且观察到,1.tak和2.tak的损坏区间之间隔着很大的距离,所以下面的偏移不精确也没关系
结束偏移= (71656+5512)/34489140 * (8510241024)=199422.298882489
随便取个整,200000
修改一下脚本再执行
f1 = open(r"C:\Downloads\bing\1.tak", 'rb+')
f2 = open(r"C:\Downloads\bing\2.tak", 'rb')
d = f2.read(200000)
f1.write(d)
f1.close()
f2.close()
再用Test执行一次看看
文件修好了!!!
分界线2
上面操作犯了个愚蠢的错误,本来可以更快处理好的
就是没有 去 1.tak 和 2.tak 的 14096 偏移观察一下
1.tak 的 14096 偏移处
2.tak 的 14096 偏移
观察之后可以发现,准确点应该是 2.tak 的 0-14096+4 区段的内容到 1.tak
之前过于高兴忘记了观察。加上 偏移 4 之后,再使用 tak.exe 进行检查,校验通过了
f1 = open(r"C:\Downloads\bing\1.tak", 'rb+')
f2 = open(r"C:\Downloads\bing\2.tak", 'rb')
d = f2.read(14096+4)
f1.write(d)
f1.close()
f2.close()
bk 来自搜索到的320Kbps版本cd
tak log cue 来自以下两个磁力
magnet:?xt=urn:btih:FLIOE5OOJPBTUPRHXOTAEXMHCMEKXE6C
magnet:?xt=urn:btih:RKKPXG3UZ5RFOLIEKMTDKIQZJ6HOQ4KC
顺便加上修好的文件的链接。。。这张cd很难找了。。。
顺便打了一个包。
「花咲くいろは HOME SWEET HOME」主題歌「影踏み」/nano.RIPE(tak+cue+jpg+log)