MKVToolNix v24.0.0 released

[asarian]

If I were to split a movie in, say, 5 minutes chunks, and then were to have mkvmerge splice them all back together again, would I get a properly timed, seamless movie again? As in exactly timed correctly. Or would there be small time gaps from breaking up at time boundaries?

I'm a bit unclear as to where precisely the cut-off points are; at the end of a GOP? Or just at the exact time-index (which would likely break parts off somewhere in limbo). I'm in need of a precision splitting/splicing tool; hence my question. Thanks.

[LeMoi]

For the first question, i would say. You won't see gaps or anything else, playback will be fluid.
For the second question, i'll send you to the documentation files in mkvtoolnix folder ;)

[sneaker_ger]

It will only cut off full GOPs. The timings can get changed - though I'm not sure if this is intended. Maybe Mosu can elaborate on this?

[asarian]

For the first question, i would say. You won't see gaps or anything else, playback will be fluid.
For the second question, i'll send you to the documentation files in mkvtoolnix folder ;)

I read the documentation, of course. Yet I saw/see nothing in there pertaining to my question. The closest is a line that says:

"For the time: The format is either HH:MM:SS.nnn with up to nine digits for up to nanosecond precision or a number followed by the letter 's' indicating a number of seconds."

It still doesn't mention cut-off points (or GOPs, for that matter). Though I probably wouldn't miss 20 miliseconds or so in terms of audio-sync (when using a 2 hour movie split over 5 minute segments), still, I'd like to be sure.

[sneaker_ger]

I read the documentation, of course. Yet I saw/see nothing in there pertaining to my question. The closest is a line that says:

"For the time: The format is either HH:MM:SS.nnn with up to nine digits for up to nanosecond precision or a number followed by the letter 's' indicating a number of seconds."

It still doesn't mention cut-off points (or GOPs, for that matter).Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Due to buffering mkvmerge(1) will split right before the next key frame after the split point has been reached. Therefore the split point may be a bit off from what the user has specified.


---

Though I probably wouldn't miss 20 miliseconds or so in terms of audio-sync (when using a 2 hour movie split over 5 minute segments), still, I'd like to be sure.

If you don't notice any desync in the last segment you won't notice any desync in the spliced file. But the timings will not be exactly the same as in original file. Better to avoid this altogether. You may be able to reduce the timing differences to a minimum by using the "track" appending mode. (see doc)

[asarian]

---

Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Due to buffering mkvmerge(1) will split right before the next key frame after the split point has been reached. Therefore the split point may be a bit off from what the user has specified.


This is actually a good thing, in my case. I want to be able to rejoin parts later; and I don't care whether they're exactly X minutes: I just want the individual parts not to lose information.

So, from what you're telling me, seems a rejoin should be pretty lossless, at least; and timeable to at least 1 ms.

Thanks.

[sneaker_ger]

Mkvmerge won't throw any frames away, if you mean that. The spliced file will have just as many frames as the original file. The timing differences can be bigger than 1 ms depending on the file and the appending mode. But you will probably not note any difference.

[Chumbo]

@Mosu,
Has anything been done about this issue from the old thread? It's still an issue. By the way, MKVs created by MakeMKV don't have this issue. Thanks.

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

I've forwarded the problem to the person who contributed the new MPEG timecode calculation method. I hope he can shed some light on this problem.

[Mosu]

Not that I know of, sorry.

[Chumbo]

Not that I know of, sorry.
Any chance you can touch base with that person again to see if they have the time to fix it please? Thank you.

[Lincoln Burrows]

There seems to be an issue some people have with MKV files not playing in a stand alone Blu-Ray player.

I was having this issue myself, some files would play some would not. It turns out that the problem I was having was with the MKV's header. It seems that the newest version of MKVToolnix compressed the headers for all the streams (video,audio etc.) by default and some players can not read these. Previous versions of MKVToolnix did not do this. I searched for several days before I found the solution but when you add your files click the video stream, then click the "Extra Options" tab and where is says "Compression:" choose none.

I do this for the video, audio and subtitle streams just to make sure they will play in my player and I have not had it fail yet.

I don't want you to have a huge MKV and waste a BDR disc because your player cant play the file now.Is this really happening? I looked at the "extra options" for each stream and nothing is selected by default:

http://img217.imageshack.us/img217/6048/imagemnxu.png

There are two options if you click on that box: none and zlib.

Should we always make sure "none" is selected? If that's the case why did you changed it?

Note: I used TsMuxer to demux the contents of m2ts files (video/audio/subtitle streams) and later MkvMerge to join all those streams into a MKV.

The author of this program replied:

Hardware players are notoriously behind in supporting official features. mkvmerge uses certain features like header removal compression by default because they've been part of the specs of over half a decade now. If your player does not support header removal compression then you have to turn it off manually, yes.

[LeMoi]

Yes, if it's not specified, it means it's enabled

[nurbs]

There is no real drawback if you disable it either. The size saved by the compression is basically zero. We're talking about a couple of hundred kilobytes per video.

[Sharc]

I have to disable the 'compression' for my new WDTV as well.
It took me a while to find out why the player refused to playback the files.....

[LeMoi]

Yes, this feature is completely useless for audio tracks and just adds compatibility issues with almost every hardware player and some software players, but Mosu refuses to disable it by default or let us the choice to disable it by default...

[GodofaGap]

Well the code for the GUI is available so if you want to make an alternate GUI that has compression 'none' as default you could do that with probably only adjusting a few lines of code.

Since there are so many complaints I'm surprised no one has done this and uploaded it somewhere yet anyway.

[LeMoi]

I don't know why, maybe because it concerns common users (like me) who don't know how to modify and compile a program like this

[robpdotcom]

I just use an older version (4.1.0 I think) from before the compression feature was added. Otherwise, I kept forgetting to disable compression, and ended up making incompatible mkv's.

[Lincoln Burrows]

Is there a way to reverse this if you already generated a MKV file with this issue?

All steps: TsMuxer (to demux the original BD files/m2ts) > Mkvmerge ----> MKV (with this problem) > What's next?

If I didn't selected "None" for all streams should I start all over again (from the beginning, see above) or simply open MKvmerge and select this option for all streams and create another MKV?

[robpdotcom]

simply open MKvmerge and select this option for all streams and create another MKV?

It's been a while, but I'm pretty sure that works.

[professor_desty_nova]

Is there a way to reverse this if you already generated a MKV file with this issue?

All steps: TsMuxer (to demux the original BD files/m2ts) > Mkvmerge ----> MKV (with this problem) > What's next?

If I didn't selected "None" for all streams should I start all over again (from the beginning, see above) or simply open MKvmerge and select this option for all streams and create another MKV?

In the official Matroska page (http://www.matroska.org/) go to the download section and see MKClean. This should come with a program to make files compatible with broken players.

[Superb]

I just use an older version (4.1.0 I think) from before the compression feature was added. Otherwise, I kept forgetting to disable compression, and ended up making incompatible mkv's.But then you're missing some very important bug fixes.

Example:
2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.

[nurbs]

There is no reason to create a raw AVC track with x264 if your target is MKV. Raw output is only necessary for Blu Ray (and possibly AVCHD). If you let x264 output MKV or MP4 to begin with that bug doesn't affect you.

Personally I stopped using the GUI and use the CLI now. That way I'm less likely to forget turning compression off. Setting things up is also faster that way if I do TV series. From what I read when other programs use mkvmerge they usually also disable the compression for audio and video tracks by default so I guess many people won't notice that it was added.

[asarian]

Yes, this feature is completely useless for audio tracks and just adds compatibility issues with almost every hardware player and some software players, but Mosu refuses to disable it by default or let us the choice to disable it by default...

Basically what it boils down to, is that I have to rewrite every mkv generated by mkvtoolnix with eac3to, as tools like tsMuxeR trip over the header compression as well.

[b66pak]

@Mosu feature request:

split .mkvs in equal size when provide ONLY the max number of splits...
_

[Mosu]

Won't happen, sorry. The reason is simple: mkvmerge does not know how big the file will become. It cannot know the size of all tracks before it starts muxing, therefore it's not possible to implement something like you've requested.

[Underground78]

Hello,

Is there an easy way to cut a sample from an mkv file (by cutting only the first X MB or seconds for example) ? If the splitting mode is used, more files than needed will be created. It is probably quite easy to do so but I have found the solution yet ...

[pelle412]

Is there a thread for future feature requests? I'd like to see automatic chapter joining when two MKV files are appended and each contains their own chapters. In the current version, only the chapters in the first MKV file is kept and the chapters in the second MKV file is lost.

[Mosu]

There's no extra thread, but what you've described should already be implemented. The next release has been built already, and I just have to find the time to write all of those release messages...

See also http://forum.doom9.org/showthread.php?p=1444584#post1444584 and the preceding posts for a related discussion.

[SamuriHL]

Sweet! That'll be a nice feature to have!

[Mosu]

Hey,

I've released mkvtoolnix v4.4.0. It contains the usual mix of bug fixes and a few enhancements but no major new features.

Nothing has changed for people building from source in general and package maintainers in particular.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.4.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.4.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.4.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.3.0:

------------------------------------------------------------
2010-10-31 Moritz Bunkus <moritz@bunkus.org>
* Released v4.4.0.
* build system: bug fix: Installation no longer fails if xsltproc is available but the DocBook stylesheets aren't. Fix for bug 575.
* mkvmerge: new feature: If the name of an input file starts with '=' then mkvmerge will not try to open other files with the same name (e.g. 'VTS_01_1.VOB', 'VTS_01_2.VOB', 'VTS_01_3.VOB') from the same directory. A single '=' as an argument disables this as well for the next input file. Implements bug 570.
* mmg: new feature: Added an option to disable extra compression when adding tracks by default.
* mkvmerge: bug fix: Made file type detection stricter for MP3, AC3 and AAC files. This prevents mis-detection of other file types as one of these for certain files. Fix for bug 574.

2010-10-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the usage of iterators with the STL "deque" template class. This caused mkvmerge to abort on systems which did not use the GNU implementation of the standard template library, e.g. OpenSolaris with the SunStudio compiler. Fix for bug 567.

2010-09-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The warning about subtitle entries that are skipped because their start time is greater than their end time now includes the subtitle number.

2010-09-23 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: 'drake install' did not work if the login shell was not POSIX compatible (e.g. fish). Fix for bug 559.

2010-09-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: When appending two Matroska files which both contain chapters the chapter entries of all editions will be merged even if the edition's UIDs were different to begin with. This is done based on the order of the edition. If both files contain three editions each then the chapters from the first edition in the second file will be put into the first edition from the first file; the chapters from the second edition into the second edition and so on.
* all: Added a translation of the programs into French by Trinine (see AUTHORS).
* mkvmerge: bug fix: The MPEG ES reader was accessing uninitialized data. This could lead to crashes or source files not being read correctly.
* mkvmerge: bug fix: Using "--no-video" on AVI files caused the video track to be mistaken for an audio track and included anyway. Fix for bug 558.
------------------------------------------------------------

Have fun.

[nurbs]

Thank you for your hard work.

[jasonwc]

* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

Thanks, this feature is greatly appreciated.

[hubblec4]

* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

Thanks, this feature is greatly appreciated.

yeah thats great.

[pelle412]

Great! Thanks for all the hard work :-)

[LeMoi]

yeah thats great.

+1, thanks for the effort!

[MrVideo]

Basically what it boils down to, is that I have to rewrite every mkv generated by mkvtoolnix with eac3to, as tools like tsMuxeR trip over the header compression as well.

I think you are just one of many that have been caught with their pants down over Mosu's interpretation of the specification. While he is correct that the video header compression is an option in the specification, it is just that, an option. To me, he has taken it upon himself to force everyone to support said option, even after all this time. As a result, you and many others, including player manufacturers and software programmers are being forced to deal with, what should be a non issue.

I wonder how many player manufacturers have gotten phone calls about their player no longer playing some MKV files and their not knowing why. Even if the player manufacturer does figure it and does upgrade their firmware, how many customers are going to know that they have to upgrade the firmware in their player. A lot of users have no clue about how this stuff works.

And to top it off, as mentioned many a time, not being able to set an option in the GUI to always have no compression as a default, is not being very friendly to the users. It results in many forgetting to set the option and having to either do it over, wasting time, or having to fix it via other means. Worse yet, sending off a DVD to a friend/relative and having the friend/relative complain that the DVD didn't work, then remembering that the option wasn't set.

So you aren't the only one scratching their head over this decision.

I do all of my work via scripts, so I'll be setting the option to not use compression, as will everyone else that uses the CLI.

IMHO, nothing is being accomplished with video header compression, other than lots of grief for lots of users, you being one of them.

[SamuriHL]

I think you are just one of many that have been caught with their pants down over Mosu's interpretation of the specification. While he is correct that the video header compression is an option in the specification, it is just that, an option. To me, he has taken it upon himself to force everyone to support said option, even after all this time. As a result, you and many others, including player manufacturers and software programmers are being forced to deal with, what should be a non issue.

I wonder how many player manufacturers have gotten phone calls about their player no longer playing some MKV files and their not knowing why. Even if the player manufacturer does figure it and does upgrade their firmware, how many customers are going to know that they have to upgrade the firmware in their player. A lot of users have no clue about how this stuff works.

And to top it off, as mentioned many a time, not being able to set an option in the GUI to always have no compression as a default, is not being very friendly to the users. It results in many forgetting to set the option and having to either do it over, wasting time, or having to fix it via other means. Worse yet, sending off a DVD to a friend/relative and having the friend/relative complain that the DVD didn't work, then remembering that the option wasn't set.

So you aren't the only one scratching their head over this decision.

I do all of my work via scripts, so I'll be setting the option to not use compression, as will everyone else that uses the CLI.

IMHO, nothing is being accomplished with video header compression, other than lots of grief for lots of users, you being one of them.

IMO, you should look before you leap.


* mmg: new feature: Added an option to disable extra compression when adding tracks by default.

[MrVideo]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

I just noticed that the FAQ has an error. To wit the header is:

Why does audio or video not play anymore since v4.1.0 (e.g. MP3, AC3, DTS audio tracks, h264 video tracks)?

But the body has the following:

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac and MPEG-4 part 2 (aka. XviD/DivX) video tracks. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

The header says h.264, yet the body says MPEG-4 part 2. Those are not equal. Does the header compression deal with ALL MPEG-4 video? If so, the FAQ needs to be fixed.

It would also be nice is the FAQ listed the CLI option to disable the video header compression.

[Lincoln Burrows]

Hey guys,
as explained here (please check this thread):
http://www.makemkv.com/forum2/viewtopic.php?f=1&t=2111

Do you think there's a chance that MKVToolnix can have a feature to make MKV slideshows work?

I have tested "The Adventures of Robin Hood (1938)" Blu-ray disc and attempted to convert the slideshows (pictures) into MKV, but failed. The resulted file only plays for 1 second. The m2ts file from the BDMV/STREAM also plays for 1 second. But using TMT player from Arcsoft, which reads the entire BD folder, it plays fine, showing all pics and with 2m40s lenght.

However, BDEdit was capable of playing the m2ts file with 2m40s when I pushed "play" on the MPLS file from the PLAYLIST folder that was reffering to this content. If BDEdit can send this instruction to the M2ts file and recognize this content as "slideshow", there must be a way to fix this.

[MrVideo]

IMO, you should look before you leap.


* mmg: new feature: Added an option to disable extra compression when adding tracks by default.


That is mmg, AFAIK, it has nothing to do with mkvmerge or the GUI.

By default, the compression is still on for all of the tools. mkvmerge has an option to disable the compression (if I can find it) and so does the GUI, but you have to set it every time.

The point is that you have to kill the compression. If you forget, it might not play everywhere.

[SamuriHL]

That is mmg, AFAIK, it has nothing to do with mkvmerge or the GUI.

By default, the compression is still on for all of the tools. mkvmerge has an option to disable the compression (if I can find it) and so does the GUI, but you have to set it every time.

The point is that you have to kill the compression. If you forget, it might not play everywhere.

UM, HUH???? MMG IS the GUI! Look in the options page!!

P.S. Mosu, thanks for adding that option, btw. I know it goes against what you want and I know a lot of people will SERIOUSLY appreciate it. Thank you.

[SamuriHL]

http://img97.imageshack.us/img97/6679/mmgoptions.png (http://img97.imageshack.us/i/mmgoptions.png/)

Uploaded with ImageShack.us (http://imageshack.us)

See there? It's a great addition.

[robpdotcom]

I have to say, after going back and re-reading through Mosu's reasons for not disabling compression, I think he was correct in his stance. I also think he is correct in giving us the option to disable it by default.

The more I thought about it, the more I began to see it this way:
The mkv's created my mmg (a free program, which was created by a programmer without compensation for his work) were fully within the Matroska specs. So, if someone sells a device claiming to be mkv compatible, then that device should be compatible with any mkv which complies to the Matroska specs. In other words, the person donating his time and skills had it right, while the manufacturers making money off their products had it wrong.

However, it also became clear that these manufacturers were not going to fix their broken players, so it was us who were paying the price.

So, I definitely appreciate Mosu's willingness to bend on this issue, but I also understand (and even admire) the stance he took in trying to force the manufacturers to fix their players.

:thanks:

[SamuriHL]

I have to say, after going back and re-reading through Mosu's reasons for not disabling compression, I think he was correct in his stance. I also think he is correct in giving us the option to disable it by default.

The more I thought about it, the more I began to see it this way:
The mkv's created my mmg (a free program, which was created by a programmer without compensation for his work) were fully within the Matroska specs. So, if someone sells a device claiming to be mkv compatible, then that device should be compatible with any mkv which complies to the Matroska specs. In other words, the person donating his time and skills had it right, while the manufacturers making money off their products had it wrong.

However, it also became clear that these manufacturers were not going to fix their broken players, so it was us who were paying the price.

So, I definitely appreciate Mosu's willingness to bend on this issue, but I also understand (and even admire) the stance he took in trying to force the manufacturers to fix their players.

:thanks:

100% correct. Mosu didn't have to bend to the will of users. However, as users of his product, since he did this for us, how about we take up his cause? If you have a device that doesn't work with compression on, pressure them to fix it! I think that's fair. :)

[MrVideo]

As an author of a frontend you can safely upgrade to > 4.0.0 if you're already using 4.0.0. Just add "--compression -1:none" to all non-subtitle files.

I'm a little confused. I think this is the option I want in order to turn off video/audio header compression, but when doing --help, it is listed under:

Options that only apply to VobSub subtitle tracks

Am I missing something here?

[SamuriHL]

I'm a little confused. I think this is the option I want in order to turn off video/audio header compression, but when doing --help, it is listed under:

Options that only apply to VobSub subtitle tracks

Am I missing something here?

I think the help description is wrong. It should apply to video/audio tracks.

[MrVideo]

UM, HUH???? MMG IS the GUI! Look in the options page!!

I don't use the GUI, have never used the GUI. Thought it was started with a different name.

As such, I stand corrected about GUI users having to always remember to set the option to disable header compression. For that I apologize.

Just what was accomplished by all of this? The mkvmerge program has an option to turn off compression and now Mosu has capitulated and added an option of turn off compression within the GUI.

Will programmers and player manufacturers update their software/firmware, now that the pressure is less? For sure word has gotten out about the header issue.

[robpdotcom]

However, as users of his product, since he did this for us, how about we take up his cause? If you have a device that doesn't work with compression on, pressure them to fix it! I think that's fair. :)

Starting daily emails to WD....... now.:p

[MrVideo]

Reading the mkvmerge.html has left me more confused than ever regarding how to disable video/audio header compression.

Here is what is in the document:
Options that only apply to video tracks:

--compression TID:method

Selects the compression method to be used for the VobSub track. Note that the player also has to support this method. Valid values are 'none', 'zlib', 'lzo'/'lxo1x', 'bz2'/'bzlib' and 'mpeg4_p2'/'mpeg4p2'. [...]

Track IDs

Some of the options for mkvmerge(1) need a track ID to specify which track they should be applied to. Those track IDs are printed by the readers when demuxing the current input file, or if mkvmerge(1) is called with the --identify option. An example for such output:
$ mkvmerge -i v.mkv
File 'v.mkv': container: Matroska™
Track ID 1: video (V_MS/VFW/FOURCC, DIV3)
Track ID 2: audio (A_MPEG/L3)

Track IDs are assigned like this:

AVI files: The video track has the ID 0. The audio tracks get IDs in ascending order starting at 1.

AAC, AC3, MP3, SRT and WAV files: The one 'track' in that file gets the ID 0.

Ogg/OGM files: The track IDs are assigned in order the tracks are found in the file starting at 0.

Matroska™ files: The track's ID is the track number as reported by mkvinfo(1). It is not the track UID.

The special track ID '-1' is a wild card and applies the given switch to all tracks that are read from an input file.

Where is my confusion?

1) Only applies to video tracks? It is supposed to apply to video and audio tracks.
2) Marked in red: VobSub?
3) Track IDs in general. Zero or one, which is it? The example shows that TID1 is the video track, yet if an AVI file is used as the source, the TID is zero? If the MKV file is to have video and audio, if a separate audio file is input (AC3 for example), the TID of the audio file can't be zero. What about when the video source is an MP4 file (output from x264)?

Doesn't mkvmerge just assign the TIDs based upon the order they appear on the command line, starting at one? So, if an AVI file has one video and two audio stream, TID1 is the video, TID2 is the first audio stream and TID3 is the second audio stream. If a separate audio file is also on the command line, it would get TID4.

I get the impression that the track assignments within source files are only useful if options like -a and -d are used. If the afore mentioned AVI file, having two audio streams, only has one of the audio streams desired, the -a option would be used, i.e., -a 1 in order to only import audio stream #1. The video stream is imported by default. Within the MKV file, the video stream is referenced as TID1 and the audio as TID2.

In my case, the mkvmerge command line look like:
mkvmerge --default-language eng -o "$WINDIRNAME\ \${NAME}.mkv" -A -S "$WINDIRNAME\\${NAME}.mp4" -a 0 -D -S "$WINDIRNAME\\${NAME}.ac3" --no-clusters-in-meta-seek

Ignore the funny looking file names, as this is a cygwin Z-shell script.

If I read the document file correctly, I should be able to use the following option: --compression -1:none and have it apply to both the video and audio files. Is that considered a global option and placed before the -o option?

As a side note, if I am reading the document right, I shouldn't need the -a, -A, -D or -S options, since the MP4 doesn't have any audio and AC3 doesn't have any video and neither have subtitles.

Should my command line look like:
mkvmerge --default-language eng --compression -1:none -o "$WINDIRNAME\ \${NAME}.mkv" "$WINDIRNAME\\${NAME}.mp4" "$WINDIRNAME\\${NAME}.ac3" --no-clusters-in-meta-seek

Sorry about the confusion, but the documentation needs to be fleshed out a little more as track IDs appear to take on different meanings and the placement of some options within the command line are unclear, i.e., is --compression a global option, or must it be placed before the file being imported, and why, since it contains a track ID that points to a video or audio stream?

UPDATE: The command line shown above needed the --no-clusters-in-meta-seek removed, as that option appears to no longer be valid.

More importantly, the --compression option kinda worked, and kinda didn't. I had to use MediaInfo 0.7.36 to find out how the header compression was being applied. It showed that compression was gone from the video, but not from the audio. I read the doc to mean that a TID of -1 would apply the "none" to all of the files imported into mkvmerge. Is there not a way to do that?

I ultimately had to use the following command line:
mkvmerge --default-language eng -o "$WINDIRNAME\ \${NAME}.mkv" --compression -1:none "$WINDIRNAME\\${NAME}.mp4" --compression -1:none "$WINDIRNAME\\${NAME}.ac3"

Now I'm really confused as to how TIDs are used. I'm guessing the video -1 could be changed to 1 and the audio -1 could be changed to 0.