Re: [Cellar] On the multiplicity of Info elements

[Moritz Bunkus <[e-mail]>]

Hey,

I only remember the discussion around Tracks being multiple, not
particularly for the other ones. Our intent way back when was to allow
muxers to write multiple instances of _the same information_ in
different places in order to make the file more resilient against
damage or incomplete downloads with protocols like BitTorrent.

The same reasoning could be applied to Info. Both elements are
absolutely crucial to playback; the other level 1 elements safe for the
clusters simply aren't.

> SeekHead, Info, Cluster, Tracks, and Tags are multiple.

SeekHead and Cluster must be multiple. SeekHead in order to allow moving
a SeekHead to the end of the file while still referencing it from the
start (so that normal players will still find it quickly). Cluster for
obvious reasons.

> And Cues, Attachments, and Chapters are non-multiple.

I have no idea why Tags is multiple and these three aren't.

To me the following would make sense:

- Info, Tracks – multiple but only if each instance contains the same
  information

- SeekHead, Cluster – multiple without restrictions

- Attachments, Chapters, Cues, Tags – single

Kind regards,
mosu