『漫游』酷论坛>動畫下載區>[重要]以後不回答集成 ..

風之殤@2005-11-09 10:41

ED的HASH就是ED的下載URL

如果不會就去ED區看教學 學會不要5分鐘
引用

weilai@2005-11-10 14:43

講到 ED HASH
這裡說一個個人的小故事

幾天前下了個 死神51集 結果後半段有壞禎(畫面移動變水彩畫面)
後來再用emule找了同版本的下了回來 (這次檢查同一時段是好的...好家在^^)
用 LinkCreator 分別對兩個檔案做 Hash
竟然一樣
用 FlashSfvcht 生成 sfv
不一樣
(做一次 Hash 或 sfv 就清一次File Cache)

證明了 ED HASH 不比 CRC32/md5 可靠
引用

風之殤@2005-11-10 15:04

引用
最初由 weilai 发布
講到 ED HASH
這裡說一個個人的小故事

幾天前下了個 死神51集 結果後半段有壞禎(畫面移動變水彩畫面)
後來再用emule找了同版本的下了回來 (這次檢查同一時段是好的...好家在^^)
用 LinkCreator 分別對兩個檔案做 Hash
竟然一樣
用 FlashSfvcht 生成 sfv
不一樣
(做一次 Hash 或 sfv 就清一次File Cache)

證明了 ED HASH 不比 sfv/md5 可靠


我是反過來 CRC有次一樣 但ED不一樣

EM他有個完整HASH 檔有多大就有成比例的超長HASH值

近來CRC與其加在檔名裡遠不如用ED HASH去比

SFV也不如BT文件好用 BT文件檢查完故障後順便可以下載修復
引用

Airkou@2005-11-10 15:40

ed hash果然有很多诡异的问题....
记得下的avc编码的0080....把字幕提出后加了点特效重新合成MKV,结果播放到到XX时间就出问题无法继续播放,检查字幕语法没问题后又重新合MKV，结果一点问题都没有了...而2者的ed hash相同

还有一回,,BT下载EVA1-10....下载完成后BT检验100%....可是放到em中其中有6,7,8话的ed hash和发布贴中的不相同,但crc32相同,...后来关机→开机重新ed hash...竟然相同了

看来PC硬件也影响ed hash的正确性,机器不稳定ed hash可能出错
引用

josfight@2005-11-10 23:41

..............樓上的,演算法的問題和硬體無關,請勿誤導他人,謝謝.

這種演算法造成的問題基本上只有計算機天才能理解,毫無理論根據的臆測就免了.(當然我也不太行,所以別管這問題:P)
引用

sunnycard@2005-11-11 00:39

引用
最初由 josfight 发布
..............樓上的,演算法的問題和硬體無關,請勿誤導他人,謝謝.

這種演算法造成的問題基本上只有計算機天才能理解,毫無理論根據的臆測就免了.(當然我也不太行,所以別管這問題:P)


貌似是數學人才懂......學電腦的就是學電腦XD

再者現代的密碼學其實是數學，不能算得上是電腦學了....
引用

marxian@2005-11-11 00:42

对于ed的hash，恐怕不是软件算法有问题，而是使用者看错了。
引用

Airkou@2005-11-11 02:02

引用
最初由 josfight 发布
..............樓上的,演算法的問題和硬體無關,請勿誤導他人,謝謝.

這種演算法造成的問題基本上只有計算機天才能理解,毫無理論根據的臆測就免了.(當然我也不太行,所以別管這問題:P)

我又没说ed hash演算法的問題和硬件有关！我说的是ed hash结果和硬件有关！硬件问题会使ed hash值不正确！偶同学的一台机器ed hash就经常出错,从光盘上COPY大点的文件也会错几个字节,后来发现是老主板IDE控制器的问题,把驱动换成winXP自带的标准IDE驱动就正常了,不过HDD性能明显下降
引用

ikarigendou@2005-11-11 02:44

咔咔, 最近刚学了数据通讯中的CRC算法...只可惜, 这个题考试还是算错了一点..

不知道和这里面的CRC是不是相同:) 算法应该是一样的吧, 不过计算过程很复杂, 手算要疯掉的.

其实就是这样的

数据+CRC码/ divisor 假如除尽就是正确的除不尽就是错的...


假设[POPGO][My_ZHiME][CHS]05(25A98CB3).avi
25A98CB3 是校验码那么她就是:
0010 0101 1010 1001 1000 1100 1011 0011
然后把这个加到myzhime 这个片所有数据的后面然
假设我们按照IUT32 标准来算
那么divisor 就是100000100110000010001110110110110(太长了,可能不对)

这样算下来会疯掉的吧....以上是无责任乱猜:D 还请真正达人来讲一下
我们只学了两中 checksum 和 CRC 不知道hash 的算法是怎样的
引用

風之殤@2005-11-11 10:00

CRC算法別去用人腦想吧.......

参考
http://www.pediy.com/tutorial/chap6/Chap6-2-4.htm

反正在這邊只公佈ED的HASH 不會有CRC
引用

白马狗熊@2005-11-11 10:39

引用
最初由 風之殤 发布
CRC算法別去用人腦想吧.......

参考
http://www.pediy.com/tutorial/chap6/Chap6-2-4.htm

反正在這邊只公佈ED的HASH 不會有CRC


呵呵 看了看这个教程, 和我说的没什么区别.只不过他写的是generator 我说的CRC checker.

不过有一点我没说就是, 假如每次除的时候, 第一个bit1 的话就用divisor除, 假如是0 的话就用0 去除.这样才对. 关键就是计算量太大了,手算会疯掉的..考试时之算16bitdata 加CRC bit我都算错了.1部200MB的动画的话是在太恐怖了
引用

Galaxy001@2005-11-11 12:58

常用BT hash FTP文件的人飘过。
不过一般ED的hash我也信。

哪有那么多巧合的？

其实我一直用DIO版MPC，没遇到过问题。
不过我有KMP,VLC,Bsplayer,Nero等3类播放器随时待命。
引用

cbax_0@2005-11-11 16:06

引用
File Hash, Part Hashes & Hashset
For every file shared in the network an unique identification value is created using the mathematical crypto algorithm MD4. This value is called file hash and is contained in every standard eD2k link, e.g.

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E|/

where 6744FC42EDA527B27F0B2F2538728B3E is the file hash making this file uniquely identified all over the network.
This File Hash is calculated by dividing the entire file into parts of 9.28 MB. For each of the parts a Part Hash is calculated using the same MD4 algorithm. These Part Hashes, called Hashset, are then used to calculate the final File Hash. For example a 600 MB file would be divided into 65 parts each with its own Part Hash which are then used to create the final File Hash.
To make sure that eMule always receives the correct Hashset a special link can be created containing this, e.g.

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E|p=264E6F6B587985D87EB0157A2A7BAF40:17B9A4D1DCE0E4C2B672DF257145E98A|/

where the p= value denotes the Hashset. Each Part Hash is divided by a ":". This file has a size of 12043984 Bytes (=11.49 MB) which means it has one full 9.28 part and the rest left to 11.49 MB resulting in two Part Hashes.
引用

mcv@2005-11-12 14:20

引用
最初由 ikarigendou 发布
咔咔, 最近刚学了数据通讯中的CRC算法...只可惜, 这个题考试还是算错了一点..

不知道和这里面的CRC是不是相同:) 算法应该是一样的吧, 不过计算过程很复杂, 手算要疯掉的.

其实就是这样的

数据+CRC码/ divisor 假如除尽就是正确的除不尽就是错的...


假设[POPGO][My_ZHiME][CHS]05(25A98CB3).avi
25A98CB3 是校验码那么她就是:
0010 0101 1010 1001 1000 1100 1011 0011
然后把这个加到myzhime 这个片所有数据的后面然
假设我们按照IUT32 标准来算
那么divisor 就是100000100110000010001110110110110(太长了,可能不对)

这样算下来会疯掉的吧....以上是无责任乱猜:D 还请真正达人来讲一下
我们只学了两中 checksum 和 CRC 不知道hash 的算法是怎样的

完全不用那么复杂，硬件上用LFSR一下子就能算出CRC的校验位。就是把数据一位的输入LFSR，全部进去之后LFSR内存储的就是校验码。稍微修改一下LFSR结构就可以变成校验操作。如果高速场合以及软件实现的话，有并行CRC算法可以用。总之，不需要用除法这种恐怖的东西。

引用
最初由 weilai 发布
講到 ED HASH
這裡說一個個人的小故事

幾天前下了個 死神51集 結果後半段有壞禎(畫面移動變水彩畫面)
後來再用emule找了同版本的下了回來 (這次檢查同一時段是好的...好家在^^)
用 LinkCreator 分別對兩個檔案做 Hash
竟然一樣
用 FlashSfvcht 生成 sfv
不一樣
(做一次 Hash 或 sfv 就清一次File Cache)

證明了 ED HASH 不比 CRC32/md5 可靠

据我所知，ED的hash算法就是MD5
引用

zhangyou306@2005-11-12 20:15

收到，感谢提醒
引用

«123»共3页

| TOP