Los porcentajes de error generalmente se expresan como probabilidades independientes, lo que significa que si existen, por ejemplo. cuatro bits que tienen una tasa de error de 1/3, habría una probabilidad de 16/81 de no errores, una probabilidad de 32/81 de exactamente uno, una probabilidad de 24/81 de exactamente dos, una probabilidad de 8/81 de exactamente tres, y una probabilidad de 1/81 de que los cuatro bits estén equivocados. Si la tasa de error de bit independiente no es cero, no hay forma de garantizar que no se entregarán datos incorrectos. Lo mejor que puede hacer es lograr una cierta probabilidad de entrega correcta, y dado un índice de error aleatorio del 25% en una carga útil de tamaño significativo, uno tendría que tener una gran cantidad de gastos generales para lograr incluso una probabilidad de entrega exitosa del 90%.
Sin embargo, en muchas situaciones del mundo real, los errores estarán fuertemente correlacionados. Por ejemplo, la probabilidad de que un grupo de 64 bits consecutivos en un paquete pueda ser reemplazado por datos aleatorios podría ser mucho mayor que la probabilidad de tener incluso cuatro bits erróneos repartidos por todo el paquete. Puede ser posible tratar de manera mucho más efectiva los errores fuertemente correlacionados que los errores no correlacionados. Por ejemplo, si uno quiere entregar 8192 bytes, podría dividirlos en grupos de 16 bytes, cada uno con un CRC de 16 bits. Los grupos se enviarían en pares, uno de los cuales se llamaría "par" y el otro sería "impar". Adjunto a cada meta-grupo de 16 pares de grupos, habrá un par extra de grupos, que representó el XOR de los datos en los primeros 16 pares (almacenando por separado un 'grupo de XOR de grupo par' y un 'grupo de pares' -XOR-group '), y un CRC de 32 bits. Se adjuntaría a la carga útil un 'meta-grupo' adicional, cuyos datos fueron el XOR de los 16 meta-grupos anteriores, más un valor de verificación de validación más grande (por ejemplo, un hash MD5)
Si se produce un solo error de ráfaga que tiene menos de 16 bytes de longitud, a lo sumo salpicará a lo sumo un grupo par y un grupo impar dentro de un meta-grupo. Dicha corrupción probablemente se detectaría y podría corregirse tomando el xor de los grupos no corruptos y el grupo group-xor apropiado. Habría una pequeña probabilidad de que la corrupción no se detecte a ese nivel, pero el CRC32 del meta grupo fallaría. En ese escenario, el receptor podría verificar si rechazar cada grupo en secuencia (reconstruir sus datos usando el grupo xor) generaría un meta-grupo válido. Si no, o si se corrompe más de un grupo par o más de un grupo impar dentro de un meta-grupo, el código podría descartar el meta-grupo y reconstruirlo usando los datos de xor-of-metagroups. La corrección de la reconstrucción se podría garantizar mediante la verificación de la validez de los datos generales.
Tenga en cuenta que este enfoque puede funcionar muy bien en la protección contra errores de ráfaga aislados, y uno puede ajustar fácilmente el número de niveles de jerarquía o el tamaño de los diversos grupos anidados según sea necesario para la aplicación. El enfoque no es óptimo para tratar con errores aleatorios aislados, pero como se señaló, en cualquier caso será muy difícil lidiar con la tasa de error aleatorio del 25%.