<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>For the record, file written with libmatroska are guaranteed to have sorted Cues thanks to this line: https://github.com/Matroska-Org/libmatroska/blob/master/matroska/KaxCues.h#L67</p>
</blockquote>
<p>That is very good to know, but given the “trust nothing” mentality I kinda vote for doing another pass on the data just to make sure that it is actually sorted.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Since we’re using libmatroska for reading, rather than recreating a sort, you might use the same Sort() call before actually using the data in the KaxCues that you just read.</p>
</blockquote>
<p>The reason an “additional” sort was introduced is because I couldn’t find anything that would allow you to really sort a bunch of <code>KaxCluster</code>s. The default implementation of the virtual <code>EbmlElement::IsSmallerThan</code> (which is inherited down, together with <code>EbmlMaster::Sort</code>) simply compares the equality of the <code>EbmlIds</code>.</p>
<p>Disregarding the fact that equality is used instead of proper less-than, given the fact that there is not a way to properly sort KaxClusters we still need to have our own sorting method somewhere (if we care about files where these do not appear in order), and as such I added the code in question.</p>
<p>Using a container where sorting happens implicitly (such as a map) would of course allow us to remove the code in question if we use the (integer) time as key.</p>