假设我们有一大块来自数据传输介质的数据，具有以下属性：
这种情况下最好的错误检测和纠错算法是什么？当然，它始终是每个块的有用数据量和成功验证（纠正）概率之间的折衷。
这只是完整问题的部分答案，因为我不会回答如何确定起点。请参阅 mcdowella 的答案。我本打算将其作为评论，但它太长了。
对于连续传输的消息，实际上不再需要任何纠错。即使发生一个位翻转（或一堆），它也不太可能影响正在传输的同一位的每个实例 - 特别是如果它永远重复。所以从这个意义上说，你的冗余因子是 N，随着广播的进行，N 接近无穷大。
所以重建你的 64 位现在非常容易，因为你有很多样本要查看。假设接收器知道循环长度，您只需轮询流并计算 64 个位置中每个位置的每个位出现的次数。
所以说在 100 个完整的循环之后，你会得到：
Bit # 0s / 1s Interpret bit as
Bit 0: 100 / 0 0
Bit 1: 0 / 100 1
Bit 2: 99 / 1 0
Bit 3: 98 / 2 0
Bit 4: 1 / 99 1
...
Bit 63: 96 / 4 0
根据这些样本，您可以统计地找出正确的位值是多少。接收者继续接收周期的时间越长，你的界限就越强。因此，如果传输了足够多的周期，您可以容忍任意高的错误率。
当然，这适用于任何周期长度——不仅仅是 64 位。因此，将此方法与 mcdowella 的方法结合使用（由于索引足迹，数据大小可能会增加）。
如果接收方不知道循环周期，有两种方法可以计算出来：
猜测长度并运行轮询。继续对不同的长度执行此操作，直到获得具有非常高相关性的长度。（每个位的高置信度）
对接收到的数据执行傅里叶变换。假设数据不是太可笑的嘈杂，这将立即揭示该时期。
这是从http://en.wikipedia.org/wiki/Frame_Relay中提取的一些想法的尝试。
以 01110 的固定标头开始每个 64 位块。如果您有更多标头信息（例如序列号或交替位标志、校验和...），您可能可以安排位模式 01110 永远不会出现。对于任意数据，将任何出现的 0111 替换为 01111 - 这意味着有效数据速率现在取决于基础数据。让这一层的数据提供者确保数据几乎是随机的，例如通过应用http://en.wikipedia.org/wiki/Randomizer。我认为您在这里的总数据丢失约为 6 位，这符合描述 0..63 移位所需的 6 位。
在接收器中，寻找 01110 来标记块的真正开始。如果你没有看到一个这样的模式，你就知道这个块已经乱码了。我认为破坏现有的 01110 并产生假的至少需要两位错误。
导致块错位的乱码看起来不像典型的位乱码，因此 CRC 错误率计算不会开箱即用。我会在每个块中包含一个非 CRC 校验和——也许是一个计算 mod 31 或 mod 961 的校验，以避免被禁止的 5 位模式 01110，尽管取决于与之相邻的内容，您可能需要更加严格。与多项式 CRC 不同，未检测到错误的几率约为 31 分之 1 或 961 分之 1，对所有单个错误没有特别保证。
我认为您没有足够的空间来明智地进行每个块的纠错，但是您可以在每 M 个普通块之后包含 N 个纠错块，例如使用 SECDED 应用于列。例如，您可能有 57 个数据承载块，然后是 6 个纠错块，将每个有效负载位位置视为承载 57 个数据位，然后是 6 个校验和位。如果错误倾向于破坏单个块的全部或一个块，例如通过导致块重新对齐失败，这应该可以很好地工作。
评论后——
编辑
好的，通过一条连续传输的消息，您的带宽较少，但 cpu 相对较多。想到两件事：
1）给定任何类型的校验和或对消息的其他约束，您可以通过例如考虑所有单比特错误、翻转接收到的消息的位并查看校验和现在是否有效来实现一些有限的纠错。
2) 可以通过仅查看通过消息的 5 位窗口来检查消息是否符合上面建议的位填充方案。我认为即使您需要对其进行调整以使其在环绕时正常工作也是如此。这意味着可以通过可处理大小的 BDD 检查消息（Knuth 4A 第 7.1.4 节）。这意味着您可以统计符合比特填充方案的 64 位消息的数量，并在消息号和消息（同一部分）之间进行有效转换。因此，您可以使用此方案，而无需对要发送的数据进行潜在的随机化或最坏情况假设，只需将其视为 0..N 范围内的数字的编码（其中 N 将通过 BDD 计算）和64 位消息。事实上，不太优雅的是，我认为您可以使用具有 5 位状态的动态编程来代替 BDD。