I noticed a bug in the RemoveAtoms function that I didn't catch when I was porting it from the original Sidx function. Since we're removing multiple atoms, removing an atom at a lower offset could shift the offset of the later atoms, resulting in data corruption in the fragment unless taken into account. We can fix this by sorting the atoms by their offset in descending order before removing them, this ensures no offsets can be shifted since we're removing from back to front.
Note that I don't think this bug actually could have resulted in any corruption in the current implementation since the ordering of the removed atoms was always "sidx" then "ftyp", which are already guaranteed to have descending offsets, but if other atoms were added in the future it would likely result in data corruption.
I noticed a bug in the RemoveAtoms function that I didn't catch when I was porting it from the original Sidx function. Since we're removing multiple atoms, removing an atom at a lower offset could shift the offset of the later atoms, resulting in data corruption in the fragment unless taken into account. We can fix this by sorting the atoms by their offset in descending order before removing them, this ensures no offsets can be shifted since we're removing from back to front.
Note that I don't think this bug actually could have resulted in any corruption in the current implementation since the ordering of the removed atoms was always "sidx" then "ftyp", which are already guaranteed to have descending offsets, but if other atoms were added in the future it would likely result in data corruption.