Re: [Cellar] On the multiplicity of Info elements

[Moritz Bunkus <[e-mail]>]

Hey,

> The Matroska files with CRC Elements store a checksum of what data is
> stored in the Master-element rather than what is interpreted (via
> defaults).

That's good as it is and it's the only possible way to handle it.

> I think switching the CRC to calculate interpreted data rather than
> stored data would present numerous challenges.

Worse, it'd be impossible. Each time the specs change wrt. to default
values (e.g. by adding a new element with a default value) the CRC would
implicitly be invalidated as the CRC was calculated over the old set of
elements with a default value.

The problem I'm mentioned on my issue on GitHub is solely in libEBML's
design. A library's design should not force the specs to follow it. The
proposed CRC specs are fine as they are. No need to change them. I'll
just have to fix/extend libEBML accordingly (not easy, but doable).

> > My usecase for checksums was indeed just error recovery.

Just to be clear. "Error recovery" usually means both "error detection"
and "error correction". CRCs are only meant and useful for the
recovery. On their own they don't do anything for correction.

Only when combined with redundancy e.g. in the form of having multiple
"tracks" element with the same segment can they be used for
correction.

Kind regards,
mosu