Implementation of #3545 causing much confusion
This started as a possible issue with predictability of track ordering when supplying multiple source files to mkvmerge, including supplying the same source file multiple times with different "filters" (--no-audio, --no-subtitles, --no-video etc.).
However, this was complicated by the fact that mkvmerge v77 appears to, under certain conditions, create files where (as far as I can tell) mkvinfo lists the tracks in an order that does not match the "Track number" mkvinfo itself reports (presumably the "TrackNumber" element?), making it more difficult to determine what the track order actually is in the file, and thus making it rather very difficult to ascertain whether there is an actual issue with track ordering or not.
.
mkvmerge: tracks in the destination file will now be sorted by their type automatically unless the track order is specified with the
--track-order
option. The order is as follows: video tracks first followed by audio & subtitle tracks with other rarely used types of tracks last. Tracks of the same type will be sorted in the same order as their source files occur in the command-line arguments. Note that this doesn't affect file identification. Implements #3545 (closed).
.
Before the change, an easy way to re-order tracks by type with mkvmerge was to do something like:
mkvmerge -o dst.mkv -A -S -M --no-global-tags --no-chapters src.mkv -D -S -M --no-global-tags --no-chapters src.mkv -D -A -M --no-global-tags --no-chapters src.mkv -D -A -S src.mkv
Giving you video track(s) first, then audio track(s), subtitle track(s) and then the rest. The example above being very long to avoid duplicating attachments/chapters/etc.
To simplify the example, let's assume input with only video, audio and subtitle tracks:
mkvmerge -o dst.mkv -A -S src.mkv -D -S src.mkv -D -A src.mkv
…would give dst.mkv with video track(s) first, then audio track(s), then subtitles.
And this would work when using --track-order is not feasible, for example, when you do not know how the tracks are ordered in the input, or how many tracks are in the input (or simply when processing multiple files where the track count differs from file to file).
Now, the results seem somewhat incomprehensible altogether. I will split this across multiple posts in an attempt to try and keep things a bit organized.