Sloot数字编码系统

Question

在上世纪90年代末，一位名叫Romke Jan Berhnard Sloot的荷兰电子技术员宣布开发了Sloot数字编码系统，这是数据传输方面的一项革命性进步。他声称，可以将一部长片电影压缩到仅有8KB的文件大小。解码算法为370MB，据说Sloot向飞利浦高管展示了这一技术，并通过从一个64KB芯片中同时播放16部电影来使他们惊叹不已。在获得了一大批投资者之后，他于1999年9月11日神秘死亡。

这是否可能或只是一个故事？

- Vikas Yadav

Answer 1

关于Sloot数字编码系统的故事存在两种观点，它们是不兼容的：一种观点认为这是不可能的，而另一种观点则认为是可能的。

什么是不可能的？

将每个可能的电影存储到只有8KB的文件大小中。这归结于鸽巢原理。

一个长度有限的密钥（无论是千字节还是万亿字节）只能存储有限数量的代码，因此只能区分有限数量的电影。然而，可能的电影实际上是无限的。因为，假设它是有限的；在这种情况下，将会有一部最长的电影。通过仅向电影添加一个额外的图像，我就可以创建一个更长的电影，而我以前没有。因此，可能的电影数量是无限的。因此，任何长度有限的密钥都无法区分每个可能的电影。

只有允许密钥变得无限大，或者允许数据存储变得无限大（如果数据存储器已经包含了所有制作的电影，则可以使用由数字组成的密钥选择要观看的电影-但是，在这种情况下，无法为尚未制作的电影创建密钥），SDCS才有可能。当然，这使得这个想法变得无用。

“Pieter Spronck”链接：Pieter Spronck “什么是可能的？”

在设备上存储或加载有限数量的 feature-length 电影，并能够使用 8KB 密钥解锁它们。

那么这并不是关于压缩，而是编码/数据库/数据传输。这是分配模型的变化：为什么要在以后通过电话或 DVD 发送软件/数据，当你可以在制造时预存储它，或者定期一次性传输所有数据。这个模型非常接近于手机带有预装应用程序的方式，或者一些游戏允许您通过输入密钥来解锁新的游戏元素的方式。

Sloot专利并没有声称将 feature-length 电影压缩到 8KB 数据。他们声称具有8倍的压缩比率。

这不是关于压缩的问题。每个人都对此误解。这个原则可以与一个概念进行比较，即 Adobe-Postscript，发件人和收件人知道可以传输哪种类型的数据配方，而不实际发送数据本身。 - Roel Pieper

从这个角度来看，SDCS是数字版权管理的原始形式，可以将获取特定预存储数据的带宽减少到一个8KB的密钥。

想象一下，通过携带设备到当地视频店存储当月的热门电影。然后，当您想观看可用电影时，只需呼叫您的密钥或在加油站购买芯片卡。现在我们有足够的带宽来流媒体Netflix，但在90年代末期，我们还在使用拨号上网，并存在着价值数十亿美元的数据传输行业（DVD、CD、录像带、软盘、硬盘）。

是否可以同时播放16部电影尚未经过验证。虽然许多投资者声称已经看到了演示，但这些人都是来自像飞利浦、甲骨文、恩德莫尔和凯纳、柯菲尔德等受人尊敬的公司。我认为这不是不可能的，但需要更多证实。

- SDCSI

Answer 2

一个非常有趣的概念。从概念上讲，Sloot编码似乎是基于"接收器"拥有重型数据丰富(类似DRM)的程序的前提，能够预先加载大量预编程功能，并且能够执行复杂的编程任务，只需要最少量的数据指令。

我不是一名程序员，但目前存在当前数据传输挑战，其中更多关注点在于数据(密集和大量)的"传输"，而不是接收程序/硬件本身的能力。然而，Sloot强调的是使用具备更高性能的硬件/软件来预加载此类数据。希望我没有说得太明显了。

例如，以声音文件为例，不是发送包含Vivaldi - The Four Seasons Mp3的复杂声音文件，而是只需编写代码指示接收者乐曲的"音符"，因为该系统已经预先编程并能播放这些音符。当然，还有更多东西，但这个概念完全合理。换句话说，与其传输"Vivaldi"数据丰富的信号，不如将简单的指令发送给一个经过"Vivaldi"培训的接收器。不要发送作曲家，而是发送指令到已经存在的作曲家那里。

是的，电影在当前系统（以及1999年的系统）下可以包含数十亿条指令数据，但是，通过增强接收器的能力和预编程功能，能否实现Sloot所想出的东西呢？

目前，数据流似乎承载了负荷，而应该像Sloot建议的那样由接收器来承载。那么，将音乐作曲家乘火车送到全国各地的音乐厅，还是将音乐乐谱发送给已经在那里的另一位作曲家更有意义呢？这与预加载电影被“解锁”不同，而是电影播放器具有无限的能力，简单的编码可以指示其具有数量级更大的能力。

这只是一个门外汉的一些随机想法。

- Barry Ho