@kylix #6
@asger #8
@colin2023 #24
@MozzieW #27

确实，主要是文章里，77 张 png 图，异常的大，居然要 150 MB 。。

都不用上 webp / avif ，随便用 `oxipng -o max` 无损压缩一下 png ，就只剩 6.6 MB 了。。（节省 96% 流量）

不知文章图片，咋搞的体积这么大的。。

https://i.imgur.com/krir4IG.png https://i.imgur.com/krir4IG.png

能控制同样「直连」、「 H265 / AV1 视频格式」吗？

会不会是商业带宽优先级更高、稳定性更好、延迟更低呢。。

以及，显卡对 H265 硬编码支持更好，同样码率画质更高啥的。。

@opscoffeecn #1

2018 年就有 https://squoosh.app 了吧。。

https://i.imgur.com/qltOb6C.jpg

@hiko2chen #45

36 楼的 PDF ，可能重复图片只保存了一份，但你可能重复压缩并存储了，所以体积缩小不明显？

---

1. 我用 pdfimages 解包出原始图片，压缩前共 55.6 MB ，极致压缩后共 21.0 MB ，都是 6297 张。

2. 再用 rdfind 删除重复文件后，压缩前剩 3086 张 27.4 MB ，极致压缩后剩 3186 张 9.2 MB 。（难道同一张图片，多次压缩结果不同？）

3. 猜测：

3.1 原 PDF 只存储一份重复图片（因为 55.6 MB > 51 MB ，还有其他内容、字体等要存储）

3.2 极致压缩后，可能重复图片也原样存储了，因为 ( 51 MB - 42 MB = 9 MB 极致压缩后节省体积 ) = ( 27.4 MB - 21.0 MB + 其他被精简掉的 2.6 MB )，看起来对得上？

3.3 如果极致压缩后，也能去掉重复图片，最终文件应该能小至 30 MB ？


---


感觉除非大幅牺牲画质，jpg / png 已经很难再减少体积了。。

要是 PDF 支持 avif 、heic 、jpeg-xl 等先进格式图片，就好了。。

4K 阿凡达图，4.23 MB jpg ，压成 0.15 MB avif ，减少 97% 体积，细节纹路噪点都还保留的可以。。

实测 avif-enc 压一遍那 3086 张原图，原始分辨率，画质基本不变时，可减少 72% 体积，只剩 7.8 MB 。。

https://i.imgur.com/qltOb6C.jpg

@kamikaze472 #8 现在浏览器 AI 功能，做到啥程度了？

能让它「 AI ，帮我保存这页推文里，所有图片视频，要最高质量」、「下载这个度百文库文档为 PDF 。自己搞定防下载机制」、「下载这个站小说，自己搞定防盗版机制」之类的任务了吗？

@festoney8 #84 DG 应该自己实现了一套 NTFS 读写算法的。。

上次我在微 PE 里，用可能有点老的 DG ，调整 Win11 分区大小。（那个 PE 里系统自带的分区调整用不了，说无服务还是啥）

结果重启后 Win11 进不去了。再次进入 PE ，文件管理器也不识别那个分区了，但 DG 还是能读出来里面的文件，我也靠这货备份数据，最后重装了。。

怀疑 Win11 的 NTFS 版本有新特性，老 DG 不认识，调整分区大小时破坏了。。https://i.imgur.com/krir4IG.png

@CristianoRonaldo #75 是如下图那样，克隆分区——按文件复制（可消除碎片）吗？

这速度可以啊，感觉应该就是巨量小文件的标准迁移方法了！学到了！

---

@festoney8 #78 诶，你说 DG 这办法，是不是类似上面说的，一边扫描原分区，一边分析所属文件，一边用自己的算法，批量积攒一堆小文件后，直接修改目标盘 NTFS 。。

毕竟速度这么快，肯定是顺序读写。又能消除文件碎片，肯定不是按原样拷贝 4K 块 / 扇区。

目标盘巨量小文件也能写这么快，肯定不是一会儿跑去写 $MFT ，一会儿写几 KB 文件内容。

---

@laminux29 #58 我知道机械硬盘 4K 随机读写差，巨量小文件又很吃这个，换固态肯定有飞一般的提升。

但在此之前，也需要从原机械盘读出来不是？

感觉楼主这个做法，应该是标准解了。。

---

https://i.imgur.com/PfPqD3y.png

@festoney8 #54 Windows 不至于每写一个文件，就强制落盘 $MFT 吧，应该能内存里缓存一段时间，积攒一堆新文件元数据，再一起写入，平摊随机读写成本，转换成大量顺序读写？

其实感觉楼主应该换新方法存储了，否则 NTFS 每次读写都得额外访问 $MFT 、校检权限、杀毒软件放行等，严重拖慢速度，特别是像现在的备份 / 迁移时。。

感觉巨量小文件存数据库里更优，元数据很轻量，且能和文件内容放在一起，减少几次随机 IO （视索引 B+ 树层级而定）。还不用 4K 簇对齐，更充分利用硬盘空间。备份 / 迁移时，还能大文件整体拷贝，吃满硬盘性能。

如果实在要以文件系统形式，对其他程序提供服务，可以用些 fuse 手段。或者参考 RamDisk 它们怎么实现文件读写接口的，它们随机读写文件速度极快，因此这个抽象层应该不会有太多性能损耗。。

现在 AI 这么发达，上述应该不难实现，论坛首页都一堆讨论 AI 的 v 友，请教下他们，或者出点小钱让其帮忙，应该就行了。。

@festoney8 对呀，就是一个个文件去读，但按照它们内容在硬盘上顺序，去决定文件列表，这样磁头就不需要频繁移动，减少寻道时间，尽量将随机读写，转化成顺序读写了吧？

实在不行，就手动分析物理硬盘上，每个 4K 块数据，属于哪个文件的呗。然后顺序读取分区，提取数据缓存在内存里，哪个文件缓存完了（可能有文件碎片成多个 4K 块），就写入到另一个硬盘里。

别说不可能，各种碎片整理软件，都能知道每个文件每一块碎片，在物理磁盘上的偏移范围。。

@laminux29 #36 数据库在随机读写里面的小文件时快不了多少，但作为一个大文件，整体去备份 / 迁移，应该能顺序读取，吃满硬盘性能吧。。

另外，你觉得 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理，是可行的吗？

@jiagm #33 fastcopy 有利用 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理吗？感觉是真的可行的。。

如果还没有这样的软件，感觉楼主 @CristianoRonaldo 可以找论坛里，那帮用 AI 很厉害的人，快速写个这样的小工具出来用？

@festoney8 诶，你们觉得，要是能顺序读取硬盘的同时，分析出是哪个文件的内容（应该能通过 MFT 主文件表，获取每个文件数据分布范围吧）。若该文件读完整了，就写入到另一个硬盘里，应该会快很多吧。。

或者，获得所有文件数据分布范围后，按在硬盘上的顺序，依次读取这些文件，磁头不用频繁移动，也能节省大量时间？（也算近乎顺序读取了？）

这种巨量小文件，存进数据库里（如 SQLite ），是不是会好很多？

NTFS 文件系统，每个文件元数据（文件名、长度、时间、权限等）起码占 1KB （ MFT 主文件表里），文件内容还要浪费 < 4KB 用于簇对齐。读写文件还得经过复杂的权限校检、杀毒软件放行等。（估计 WinPE 里会快些）

数据库就轻量很多。8 年前 SQLite [测试]( https://sqlite.org/fasterthanfs.html )，随机读写 10KB 小文件，比文件系统快 35%，节省 20% 空间。转移/备份时也是顺序读写，能全速吃满硬盘。。

@vopsoft x265 是软件，h265 才是一种编码格式。。

有啥地方有分享 TMPGEnc 压制的片子吗？看看画质如何。。

@1una @Tink 现在有啥压 av1 / vvc 的地方吗？我看有人几百 MB 压一部 1080p 《哪吒 2 》，画质就很不错了。。现在存储涨价挺猛的，要是能屯这种小体积高质量的片，还是很舒服的。。


@ntedshen 噢，说十年前是吧。。当时主流 CPU 是 i5-4590 之类的吗。。看了下 r23 跑分，多核是 7945HX 在 65W 功耗时 10%。。加上当年 x265 估计优化还不行，压 1080p 确实可能都还有点吃力吧。。