&主题：我哭晕了，移动硬盘对拷，都才40MB/s的速度
泡网分: 0.219
帖子: 1004
注册: 2017年05月
那么，3.6T的内容，要拷贝多久啊！
作者相关热贴：
微信扫一扫分享
&浏览：655&&回帖：21 &&
泡网分: 14.649
帖子: 3896
注册: 2010年02月
sars02 发表于
那么，3.6T的内容，要拷贝多久啊！用ghost，或acronis的复制分区，无视文件碎片，直接达到速度上限
泡网分: 0.219
帖子: 1004
注册: 2017年05月
gimer 发表于
两个移动硬盘对拷吗？你可以试试一块硬盘换个USB口。因为一个USB根hub下面带宽共享，互相会有影响。现在的电脑基本上都有两个以上的USB根hub，只要换到另一个，速度可能有提升。
还可以拆移动硬盘接到SATA上。速度会好很多。
如果是因为硬盘本身碎片，或者小文件问题，拷贝无解。3ks，2个USB还真的靠在一起的
不过机器老，好像没有其他蓝色的USB口子了
泡网分: 13.03
帖子: 2380
注册: 2008年12月
拷贝量大的话，楼主需要个拷贝机，大约可以达到100MB/sec以上的速度。
一个不方便的是不同容量的盘拷贝还无法做到类似ghost的效果(实际是扇区到扇区的拷贝)。
本帖由安卓客户端发布
泡网分: 7.903
注册: 2011年07月
两个移动硬盘对拷吗？你可以试试一块硬盘换个USB口。因为一个USB根hub下面带宽共享，互相会有影响。现在的电脑基本上都有两个以上的USB根hub，只要换到另一个，速度可能有提升。
还可以拆移动硬盘接到SATA上。速度会好很多。
如果是因为硬盘本身碎片，或者小文件问题，拷贝无解。
泡网分: 3.467
帖子: 3297
注册: 2012年08月
sars02 发表于
关于驱动，我特地baidu到intel 官方网站下载的OK，我去搜搜那个app唱歌，现在已经下了2TB了，还要努力，感觉速度慢可以买一个nec芯片的pci-e转usb扩展卡，那个驱动问题少。
泡网分: 0.219
帖子: 1004
注册: 2017年05月
铁血神弓 发表于
你一定事usb3.0的驱动没装好，所以俺才坚持用内置硬盘抽取盒跑满速度。
另外ktv歌库你是安装买家送的exe文件没？听说不支持win10，难道要装64位的win7还是32位的winxp？
还是直接手动搜索歌曲播放，再选择声道？关于驱动，我特地baidu到intel 官方网站下载的
泡网分: 0.219
帖子: 1004
注册: 2017年05月
铁血神弓 发表于
你一定事usb3.0的驱动没装好，所以俺才坚持用内置硬盘抽取盒跑满速度。
另外ktv歌库你是安装买家送的exe文件没？听说不支持win10，难道要装64位的win7还是32位的winxp？
还是直接手动搜索歌曲播放，再选择声道？网络机顶盒，荣耀pro，加载歌吧这个app，就可以了
泡网分: 16.894
精华: 1帖子: 2898
注册: 2009年10月
用ghost之类的工具吧。会快好多。
泡网分: 14.993
帖子: 3423
注册: 2008年06月
25个小时而已，也不算夸张。
泡网分: 3.467
帖子: 3297
注册: 2012年08月
sars02 发表于
没办法啊！KTV歌库，3.6T的容量，不得不用4T硬盘啊！你一定事usb3.0的驱动没装好，所以俺才坚持用内置硬盘抽取盒跑满速度。
另外ktv歌库你是安装买家送的exe文件没？听说不支持win10，难道要装64位的win7还是32位的winxp？
还是直接手动搜索歌曲播放，再选择声道？
泡网分: 0.219
帖子: 1004
注册: 2017年05月
zhfreal 发表于
用fastcopy之类的软件，分别试下两个移动硬盘的读写速度呢管它呢，反正再慢也得考呗
泡网分: 3.457
帖子: 5033
注册: 2011年12月
Netweaver 发表于
小文件多了。建议存储文件全部压缩 用的时候才解压。我是不怎么用的那种小文件直接打包成iso，现在windows都直接挂载成光驱，很方便
泡网分: 36.18
帖子: 3797
注册: 2002年10月
干嘛哭？这很正常呀，你选的路。
别哭了，出去转悠或者搬砖吧。
泡网分: 0.88
注册: 2012年05月
sars02 发表于
是U3的啊！蓝色的插口
难道是一个移动硬盘不是U3的？用fastcopy之类的软件，分别试下两个移动硬盘的读写速度呢
泡网分: 3.82
帖子: 3758
注册: 2011年04月
yanw 发表于
可能是你中间的机器有点问题，我在联想家X1C笔记本上有USB3口连两个移动硬盘，对拷速度基本在90M/S左右机械硬盘拷歌四五十M正常，不过也用不了多久吧，不在家的时候扔在家里拷就是了又不是天天对拷
泡网分: 6.979
帖子: 17644
注册: 2012年02月
小文件多了。建议存储文件全部压缩 用的时候才解压。
本帖由安卓客户端发布
泡网分: 0.219
帖子: 1004
注册: 2017年05月
zhfreal 发表于
大硬盘这速度有点蹊跷，是不是u3接口的？插的口是不是u3的？是U3的啊！蓝色的插口
难道是一个移动硬盘不是U3的？
泡网分: 0.219
帖子: 1004
注册: 2017年05月
zhaoleslie 发表于
很久很久。
所以，硬盘不要搞太大……没办法啊！KTV歌库，3.6T的容量，不得不用4T硬盘啊！
泡网分: 30.619
帖子: 4799
注册: 2003年02月
sars02 发表于
那么，3.6T的内容，要拷贝多久啊！可能是你中间的机器有点问题，我在联想家X1C笔记本上有USB3口连两个移动硬盘，对拷速度基本在90M/S左右
泡网分: 0.88
注册: 2012年05月
大硬盘这速度有点蹊跷，是不是u3接口的？插的口是不是u3的？
泡网分: 42.963
帖子: 14339
注册: 2004年08月
很久很久。
所以，硬盘不要搞太大……
本帖由安卓客户端发布
&版权所有：&&&&几百 MB 的文件，解压后达到几个 GB，这是怎么做到的？
我的图书馆
几百 MB 的文件，解压后达到几个 GB，这是怎么做到的？
高压缩文件是如何实现的？
加刘景长，中二病MAX
简要概述原理：
每个文件都由各种不同代码组成，比如 01 代码。这类文件只有数字 0 与 1 组合。
压缩原理就是——通过寻找其中的规律，简化数字的排列。
可以简化成
5 个 0,2 个 1,3 个 0,10 个 1 的排列
可以简化成数学的
至于@yskin 说 没见过 2G 压缩到十几兆的。
实际上在极限压缩方式下其实 28.1G 压到 25.8M 都可以。
打开看后基本都能理解这个压缩的大概原理了。
下面是几种常见文件压缩算法原理介绍：
字典算法是最为简单的压缩算法之一。它是把文本中出现频率比较多的单词或词汇组合做成一个对应的字典列表，并用特殊代码来表示这个单词或词汇。例如：
有字典列表：
00=Chinese
源文本：I am a Chinese people,I am from China 压缩后的编码为：I am a 00 01,I am from 02。压缩编码后的长度显著缩小，这样的编码在 SLG 游戏等专有名词比较多的游戏中比较容易出现，比如《SD 高达》。
固定位长算法（Fixed Bit Length Packing）
这种算法是把文本用需要的最少的位来进行压缩编码。
比 如八个十六进制数：1，2，3，4，5，6，7，8。转换为二进制为：000100， 001000。每个数只用到了低 4 位，而高 4 位没有用到（全为 0），因此对低 4 位进行压缩编 码后得到：，，，。然后补充为字节得到：， 111000。所以原来的八个十六进制数缩短了一半，得到 4 个十六进制数：12，34，56，78。
这也是比较常见的压缩算法之一。
RLE（Run Length Encoding）
是一个针对无损压缩的非常简单的算法。它用重复字节和重复的次数来简单描述来代替重复的字节。尽管简单并且对于通常的压缩非常低效，但它有的时候却非常有用（例如，JPEG 就使用它）。
原理图 2.1 显示了一个如何使用 RLE 算法来对一个数据流编码的例子，其中出现六次的符号‘93’已经用 3 个字节来代替：一个标记字节（‘0’在本例中）重复的次数（‘6’）和符号本身（‘93’）。RLE 解码器遇到符号‘0’的时候，它表明后面的两个字节决定了需要输出哪个符号以及输出多少次。
这种压缩编码是一种变长的编码，RLE 根据文本不同的具体情况会有不同的压缩编码变体与之相适应，以产生更大的压缩比率。
　　变体 1：重复次数 + 字符
文本字符串：A A A B B B C C C C D D D D，编码后得到：3 A 3 B 4 C 4 D。
　　变体 2：特殊字符 + 重复次数 + 字符
文本字符串：A A A A A B C C C C B C C C，编码后得到：B B 5 A B B 4 C B B 3 C。编码串的最开始说明特殊字符 B，以后 B 后面跟着的数字就表示出重复的次数。
　　变体 3：把文本每个字节分组成块，每个字符最多重复 127 次。每个块以一个特殊字节开头。那个特殊字节的第 7 位如果被置位，那么剩下的 7 位数值就是后面的字符的重复次数。如果第 7 位没有被置位，那么剩下 7 位就是后面没有被压缩的字符的数量。例如：文本字符串：A A A A A B C D E F F F。编码后得到：85 A 4 B C D E 83 F（85H= B、4H= B、83H= B）
实现 RLE 可以使用很多不同的方法。基本压缩库中详细实现的方式是非常有效的一个。一个特殊的标记字节用来指示重复节的开始，而不是对于重复非重复节都 coding run。
因此非重复节可以有任意长度而不被控制字节打断，除非指定的标记字节出现在非重复节（顶多以两个字节来编码）的稀有情况下。为了最优化效率，标记字节应该是输入流中最少出现的符号（或许就不存在）。
重复 runs 能够在 32768 字节的时候运转。少于 129 字节的要求 3 个字节编码（标记 + 次数 + 符号），而大雨 128 字节要求四个字节（标记 + 次数的高 4 位|0x80+ 次数的低 4 位）。这是通常所有采用的压缩的做法，并且也是相比较三个字节固定编码（允许使用 3 个字节来编码 256 个字节）而言非常少见的有损压缩率的方法。
在这种模式下，最坏的压缩结果是：
输出大小=257/256* 输入大小 +1
其他还有很多很多变体算法，这些算法在 Winzip Winrar 这些软件中也是经常用到的。
霍夫曼编码（Huffman Encoding）
哈夫曼编码是无损压缩当中最好的方法。它使用预先二进制描述来替换每个符号，长度由特殊符号出现的频率决定。常见的符号需要很少的位来表示，而不常见的符号需要很多为来表示。
哈夫曼算法在改变任何符号二进制编码引起少量密集表现方面是最佳的。然而，它并不处理符号的顺序和重复或序号的序列。
原理我不打算探究哈夫曼编码的所有实际的细节，但基本的原理是为每个符号找到新的二进制表示，从而通常符号使用很少的位，不常见的符号使用较多的位。
简短的说，这个问题的解决方案是为了查找每个符号的通用程度，我们建立一个未压缩数据的柱状图；通过递归拆分这个柱状图为两部分来创建一个二叉树，每个递归的一半应该和另一半具有同样的权（权是∑NK =1 符号数 k, N 是分之中符号的数量，符号数 k 是符号 k 出现的次数）
这棵树有两个目的：
1． 编码器使用这棵树来找到每个符号最优的表示方法
2． 解码器使用这棵树唯一的标识在压缩流中每个编码的开始和结束，其通过在读压缩数据位的时候自顶向底的遍历树，选择基于数据流中的每个独立位的分支，一旦一个到达叶子节点，解码器知道一个完整的编码已经读出来了。
我们来看一个例子会让我们更清楚。图 2.2 显示了一个 10 个字节的未压缩的数据。
根据符号频率，哈夫曼编码器生成哈夫曼树（图 2.4）和相应的编码表示（图 2.3）。
你可以看到，常见的符号接近根，因此只要少数位来表示。于是最终的压缩数据流如图 2.5 所示。
压缩后的数据流是 24 位（三个字节），原来是 80 位（10 个字节）。当然，我应该存储哈夫曼树，这样解码器就能够解码出对应的压缩流了，这就使得该例子中的真正数据流比输入的流数据量大。这是相对较短的数据上的副作用。对于大数据量来说，上面的哈夫曼树就不占太多比例了。解码的时候，从上到下遍历树，为压缩的流选择从左 / 右分支，每次碰到一个叶子节点的时候，就可以将对应的字节写到解压输出流中，然后再从根开始遍历。 实现哈夫曼编码器可以在基本压缩库中找到，其是非常直接的实现。
这个实现的基本缺陷是：
1． 慢位流实现
2． 相当慢的解码（比编码慢）
3． 最大的树深度是 32（编码器在任何超过 32 位大小的时候退出）。如果我不是搞错的话，这是不可能的，除非输出的数据大于 232 字节。
另一方面，这个实现有几个优点：
1． 哈夫曼树以一个紧密的形式每个符号要求 12 位（对于 8 位的符号）的方式存储，这意味着最大的头为 384。
2． 编码相当容易理解
哈夫曼编码在数据有噪音的情况（不是有规律的，例如 RLE）下非常好，这中情况下大多数基于字典方式的编码器都有问题。
3. Rice 对于由大 word（例如：16 或 32 位）组成的数据和教低的数据值，Rice 编码能够获得较好的压缩比。音频和高动态变化的图像都是这种类型的数据，它们被某种预言预处理过（例如 delta 相邻的采样）。
尽管哈夫曼编码处理这种数据是最优的，却由于几个原因而不适合处理这种数据（例如：32 位大小要求 16GB 的柱状图缓冲区来进行哈夫曼树编码）。因此一个比较动态的方式更适合由大 word 组成的数据。
原理 Rice 编码背后的基本思想是尽可能的用较少的位来存储多个字（正像使用哈夫曼编码一样）。实际上，有人可能想到 Rice 是静态的哈夫曼编码（例如，编码不是由实际数据内容的统计信息决定，而是由小的值比高的值常见的假定决定）。
编码非常简单：将值 X 用 X 个‘1’位之后跟一个 0 位来表示。
实现在基本压缩库针对 Rice 做了许多优化：
1． 每个字最没有意义的位被存储为 k 和最有意义的 N-k 位用 Rice 编码。K 作为先前流中少许采样的位平均数。这是通常最好使用 Rice 编码的方法，隐藏噪音且对于动态变化的范围并不导致非常长的 Rice 编码。
2． 如果 rice 编码比固定的开端长，T，一个可选的编码：输出 T 个‘1’位，紧跟（log2(X-T)）个‘1’和一个‘0’位，接着是 X-T（最没有意义的(log2(X-T))-1 位）。这对于大值来说都是比较高效的代码并且阻止可笑的长 Rice 编码（最坏的情况，对于一个 32 位 word 单个 Rice 编码可能变成 232 位或 512MB）。
如果开端是 4，下面是结果编码表：
Thresholded
就像你看到的一样，在这个实现中使用 threshold 方法仅仅两个编码导致一个最坏的情况；剩下的编码产生比标准 Rice 编码还要短的编码。
最坏的情况，输出。
Lempel-Ziv (LZ77)
Lempel-Ziv 压缩模式有许多不同的变量。基本压缩库有清晰的 LZ77 算法的实现（Lempel-Ziv，1977），执行的很好，源代码也非常容易理解。
LZ 编码器能用来通用目标的压缩，特别对于文本执行的很好。
它也在 RLE 和哈夫曼编码器（RLE，LZ，哈夫曼）中使用来大多数情况下获得更多的压缩。这个压缩算法是有版权的。
原理在 LZ 压缩算法的背后是使用 RLE 算法用先前出现的相同字节序列的引用来替代。
简单的讲，LZ 算法被认为是字符串匹配的算法。例如：在一段文本中某字符串经常出现，并且可以通过前面文本中出现的字符串指针来表示。当然这个想法的前提是指针应该比字符串本身要短。
例如，在上一段短语“字符串”经常出现，可以将除第一个字符串之外的所有用第一个字符串引用来表示从而节省一些空间。
一个字符串引用通过下面的方式来表示：
1． 唯一的标记
2． 偏移数量
3. 字符串长度
由编码的模式决定引用是一个固定的或变动的长度。后面的情况经常是首选，因为它允许编码器用引用的大小来交换字符串的大小（例如，如果字符串相当长，增加引用的长度可能是值得的）。
实现使用 LZ77 的一个问题是由于算法需要字符串匹配，对于每个输入流的单个字节，每个流中此字节前面的哪个字节都必须被作为字符串的开始从而尽可能的进行字符串匹配，这意味着算法非常慢。
另一个问题是为了最优化压缩而调整字符串引用的表示形式并不容易。例如，必须决定是否所有的引用和非压缩字节应该在压缩流中的字节边界发生。
基本压缩库使用一个清晰的实现来保证所有的符号和引用是字节对齐的，因此牺牲了压缩比率，并且字符串匹配程序并不是最优化的（没有缓存、历史缓冲区或提高速度的小技巧），这意味着程序非常慢。
另一方面，解压缩程序非常简单。
一个提高 LZ77 速度的试验已经进行了，这个试验中使用数组索引来加速字符串匹配的过程。然而，它还是比通常的压缩程序慢。
当然静态数据和动态数据的压缩策略是完全不同的。
一个压缩文件是不是还可以用其他算法再继续压缩？
可以，但没要。压缩文件有极限值存在。高压一遍已经很接近这个值了，再压缩的话基本也就只有一丁点压缩率提升，甚至会增加体积。
随便做的渣绘图。不要在意细节→ →
下面是题外话。
那么一般要如何简单实现高压缩？
系统文件诸如 GAL 游戏跟一些纯代码的文档基本能直接用 7Z 进行无损压缩就可以了。当然，高压缩率也意味着更费时间的压缩跟解压。压缩率小的没必要用 7z，直接打包反而更适合。
影音图像文件多数压缩率只能通过再编码有损压缩。比如 BMP 图像转 jpg 吧图片的一些一般人用不到的杂信息去除，APE 转 MP3 之类。基本除了音源文件外其他要对比不太明显。(照片 BMP 通过 7Z 压缩后解压其实是有点变化的，这个不细说，一说就没完没了了。)
至于有的人说我上面附带的极限压缩例子太坑爹，于是再附带一个我做的动画压制 1080p BDMV 通过 10bit x264 再编码压缩成每话 90M 大小视频。源 BDBOX 总大小 119.16GB。
画面的话我【个人主观看法】觉得在电脑观看跟源盘没什么区别。（PS3 跟一些高端硬件芯片的解码器播放那是另一回事了）
画面控追求的 BDMV 无损画质也是相对无损。真正意义上的无损画质输出的影片，渲染体积 1 分钟视频就超过 10G。我个人渲过最大的是 18 秒 44.5G 8k 视频。
馆藏&396002
TA的推荐TA的最新馆藏
喜欢该文的人也喜欢我用的是WINRAR解压工具，近来才发现，用其解压后的文件并不比原来未解压之前的压缩文件大。　　比如我从清泉那里下载的《开天辟地4》中的一个压缩文件是614 MB　　我用WINRAR解压后却是613MB，这和没有解压有何区别？会不会是因为我的WINRAR没有注册。
楼主发言：1次 发图：0张 | 更多
　　能解开就好了。本来嘛，一些已经压缩过的视频压缩率就已经极低了，再加上Winrar的压缩信息，当然比原来会大一点
　　既然是这样的话那还有什么再压缩的必要嘛
　　确是有的是这样，　　因为不能或压缩不动。　　压缩时加载一信信息。　　
　　压缩方便下载
　　楼上的说的对，有些软件比如说游戏有成千上百个文件，如果要传到网络上得传成千上百次，累都累死了。压一下就成一个了，多方便，而且压缩的大小，跟你压的文件也有关系，你压文本文件看看。压缩率很打的呢
　　晕　　现在的压缩就是一口袋
　　一样大还压个P
　　软件公司怕盗版，或者显示他们的水平
请遵守言论规则，不得违反国家法律法规回复(Ctrl+Enter)压缩软件哪个好？
压缩软件哪个好？360压缩与winrar等4款压缩软件对比
　　不少网友在日常的工作中，常常需要使用到压缩软件，那么，压缩软件哪个好？今天，小编就给大家整理了4款常用的压缩软件：360压缩、winrar、2345好压以及快压的压缩性能的对比，从压缩各种文件的速度以及格式的多样性等方面进行对比，让大家可以轻松的了解这4款软件。
压缩软件下载地址
　　360压缩、、、快压等4款压缩软件的性能对比：
　　1.压缩映像文件速度的对比（原文件829MB）
　　WinRAR：rar 15分22秒 824M
　　WinRAR：ZIP 1分7秒 825M
　　快压：kz 12分52秒 829M
　　2345好压：ZIP 1分20秒 825M
　　360压缩：ZIP 1分55秒 826M
　　在压缩本身就是压缩文件的映像文件时，压缩成zip格式最为合适，压缩的时间最短且压缩率也很高，而其中WinRAR软件表现最好。
　　2.压缩视频文件速度的对比（原文件175MB）
　　WinRAR：rar 3分10秒 173M
　　WinRAR：ZIP 15秒 173M
　　快压：kz 21秒 173M
　　快压;ZIP 3分57秒 173M
　　2345好压：7z 20秒 173M
　　2345好压：ZIP 22秒 173M
　　360压缩：7z 3分23秒 173M
　　360压缩：ZIP 30秒 175M
　　在压缩本身就是压缩文件的视频文件时，还是使用ZIP格式压缩的效果最好，大家的压缩大小都差不多，但是从压缩时间上来看，使用WinRAR压缩软件需要的压缩时间最短，又是WinRAR软件省出。
　　3.压缩图片格式文件速度的对比（原文件32.2M）
　　WinRAR：rar 13秒 27M
　　WinRAR：ZIP 3秒 29.5M
　　快压：kz 51秒 23.5M
　　快压：ZIP 43秒 29.4M
　　2345好压：7z 24秒 28.6M
　　2345好压：ZIP 3秒 29.5M
　　360压缩：7z 22秒 28.6M
　　360压缩：ZIP 4秒 29.6M
　　在压缩本身就是压缩文件的图片格式文件时，WinRAR的rar格式的压缩比为83.9%，kz格式的压缩比更高，但是kz格式压缩时间很长，最求压缩率的网友可以选择使用快压来压缩图片，而喜欢压缩率和时间同样重要的网友则还是需要选择WinRAR。
　　4.从压缩和解压文件格式的多样性来看：
　　WinRAR：压缩：rar、zip等2种格式;解压：rar、zip、7z、iso、cab等14种格式 可制作exe
　　快压：压缩：kz、7z、zip、rar等4种格式;解压： 7z、rar、zip、iso、wim、cab等18种格式 可制作exe
　　好压：压缩：7z、zip、tar等3种格式;解压：7z、rar、zip、iso、wim、、img、cab等38种格式 exe功能仅限7z格式
　　360压缩：压缩：7z、zip、rar等2种格式;解压：7z、rar、zip、iso、wim、img、cab等39种格式 exe不能带路径
　　上面的结果可以看出由于kz格式的文件大家并不常用，只有在追求对图片压缩率比较高的网友才需要，所以这一轮比较可以得出360压缩较好。
　　总结：
　　以上就是全部的&360压缩和winrar\2345好压\快压哪个比较好？4款压缩软件的对比&内容。在众多压缩软件中，360压缩和WinRAR软件是最好的，快压其次，好压最后。
大家都在下
还没关注下载之家微信 的亲们赶紧扫一扫左侧的二维码吧！或搜账号:
还没关注下载之家微信 的亲们赶紧扫一扫左侧的二维码吧！或搜账号:
微信公众号
Copyright &
下载之家(www.xiazaizhijia.com).All Rights Reserved
备案号：闽ICP备号-1 闽公网安备 72号