mkvtoolnix 4.1.1 released

[honai]

It's VC-1 not h.264 but thanks for the clarification. The resulting file plays just fine.

While I'm at it: I've demuxed the EAC3 tracks from the Serenity EVOs with EVODemux. How do I mux that into MKV? mkvmerge complains that the audio tracks were AVC ES streams, which is definitely wrong.

[madshi]

It's VC-1 not h.264 but thanks for the clarification. The resulting file plays just fine.

While I'm at it: I've demuxed the EAC3 tracks from the Serenity EVOs with EVODemux. How do I mux that into MKV? mkvmerge complains that the audio tracks were AVC PS streams, which is definitely wrong.
You need to download a newer version of mkvtoolnix.

[honai]

Using the latest version from Mosu's signature, 2.0.2-1. Get message that the file type were AVC ES.

[Mosu]

EAC3 is only implemented in builds after 2.0.2-1 available for testing from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[delacroixp]

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576
Very neat...

:thanks:


:) :D :eek:
Pascal

[issa]

When I try to convert a AVI file contain XviD/DivX with AC3/MP3 into MKV with "--engage native_mpeg4" option. The final MKV file will out of sync. If I conevrt a AVI file contain H.264/AVC with AC3/MP3 using the same option flag. The result file is fine.
I would like to ask if the un-sync problem on XviD/DivX with AC3/MP3 with "--engage native_mpeg4" is an expected behavior.

[Mosu]

Of course not :) Async audio/video from in-sync files is always a bug.

[woah!]

hi Mosu

this is probably a silly question but how do i set the frame rate to 23.976 when muxing out an EVO file to mkv ?

i use graphedit and plug in the splitter/muxer ok and it gives me a perfect result. but then when i add it to mkvmerge i get again a perfect mux with the ac3 audio but the video is set to 25frames when i check :( the option in mkvmerge to set the fps is greyed out so i cant set it there.

[ACrowley]

hi Mosu

this is probably a silly question but how do i set the frame rate to 23.976 when muxing out an EVO file to mkv ?

i use graphedit and plug in the splitter/muxer ok and it gives me a perfect result. but then when i add it to mkvmerge i get again a perfect mux with the ac3 audio but the video is set to 25frames when i check :( the option in mkvmerge to set the fps is greyed out so i cant set it there.´

create a simple .txt File :

# timecode format v1
assume 23.976

load it in mkvmerge as timecode

[LeMoi]

When i append AAC tracks, aac-is-sbr is for first track in the GUI (and so it is for every appended track), and yet mmg keeps saying :
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.

[woah!]

´

create a simple .txt File :

# timecode format v1
assume 23.976

load it in mkvmerge as timecode

when i do that the video seems to be running very fast compared to the audio. heres a screenie of what haali shows :

http://img339.imageshack.us/img339/3973/haali1vk7.jpg

looks like its running at 29.97 to me..



update: ok using this timecode gives me a perfect sync result:

# timecode format v1
assume 29.97
0,126292,23.976

just have to change the amount of frames to match the calc frames given from EVOdemux

# timecode format v1
assume 29.97
0,[FRAME AMOUNT],23.976

[NuPogodi]

It's probably the right place to ask... Long time ago i compress some video with first vfw-version of h264 (i guess, still compiled by syskin) and mux them into mkv (mkvmerge, versions <1.5.X). Now i need to remux them again, namely, to add new subtitle streams. When i've tried to do it, the current version (2.0) gives me the error -1073741819. I guess it means "no longer support for vfw h264-videostreams", doesnt it? Well, the question is
1. can somebody provide a link for old mkvmerge versions?
2. is there any other way to add subtitles to this video or make it compliant to new mkvmerge versions?
Thanks.

[Mosu]

Such error numbers are usually crashes in mkvmerge which should normally not happen. Care to upload the file? :)

All older versions of mkvtoolnix are still available at http://www.bunkus.org/videotools/mkvtoolnix/win32/old/

[NuPogodi]

Such error numbers are usually crashes in mkvmerge which should normally not happen. Care to upload the file? :)
Thanks for a link... you are absolutely right, the older version (1.5) crashes with the same error. Upload? I'm sorry, the whole file was too large (~800MB). So i've splitted the first 1.3MB in TotalCommander (the crash still remains for this file, 20sec) and sent it by e-mail (our server doesnt allow ftp connection) to moritz at bunkus dot org.

[echo]

Hi Mosu! I've found myself a bug! When the path contains greek letters and you drag'n'drop a file in mmg I get a "file identification failed" error (Return code: 2) and the path is shown as garbage. If I use the Add button everything works fine...

Oh, it's version 2.0.2 in linux if it matters...

[jwa999]

Loosing frames when splitting and linking.

When studing the mkv format i found this nice feature: linking split files. So I planned to use it to burn files that are too big. Split them up into ca 1 gig pieces and then archive. But when I split a 11 gig file into 11 pieces and then let the haali splitter glue them all back together, i noticed the result was 10 frames shorter than the original.

I use avisynth/directshowsource to virtualdub to analize the files.

Used mkvmerge 2.0.2 with mmg.exe to split the files
and Haali splitter 1.7.121.0 to view them.

The content of the file is h264 video, ac3 audio and S_TEXT/UTF8 subs.
The original h264 and ac3 audio came from a ts file that was converted to an mkv using haali splitter and muxer in graphedit. I always check that the converted file plays back properly and is in sync.

If i try to glue the split files back together, i'm getting the following error:

Warning: 'E:\!burn\1\e\H264.1080.50i.AC3.5.1-001.mkv' track 2: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 224ms in order not to lose any data. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>.

for each of the 11 files.

I'm getting that error as well on other files that i've remuxed with subtitles and then try to mux again. I sometimes add a delay to the audio track to correct sync, I wonder if that has something to do with it.

After the files are appended back together into one file, the 10 frames are still missing.....

On an other sample where it didn't give errors when muxing the video back, the audio gradually goes out of sync.

On a third sample, the linked files play back properly and in sync, but muxing them back together into 1 file gives the same audio errors again and the audio goes terrably out of sync: 192 ms per glued file...

UPDATE: looks like the ac3 track in the original mkv file was not upto spec. after remuxing, extracting and then muxing again, it finally was happy about the ac3 track and no longer gave timecode errors.
Now, after splitting and letting the haali splitter link all the files, it's still missing 10 frames. But when I append all the files back, I get the original number of frames back, except it's one frame shorter than the mkv file that I started out with.
So it looks like the haali splitter is skipping one frame for each mkv file it loads.

UPDATE2: After splitting and then glueing, an analizis of the timecodes reveales that there is a difference: In the original file, the timestamps go up smoothly by every 40ms for video and 32ms for audio. This is also true for the split files. They contain the original timestamps. However, in the glued file, there is now a duplicate timestamp for the video after each glued file, so that every file now starts 40ms earlier and earlier. The audio timestamps "jump" after the second glue point and again after glue points after that to keep up with the video.

CONCLUSION: It looks like the splitting process works ok, but the glue does not maintain the original timestamps and in the process starts making rounding errors.
The Haali splitter must suffer from a similar rounding error and removes a frame around the split point for each file.

jwa.

[zeropc]

is there any news if or even when v2.0.2 comes out for osx?

[philipshu]

i tried to use mkvmerge to split a D9 mkv file into two D5s
it says 'die' called: mm_text_io_c::read_next_char(): Invalid UTF-8 char. First byte: 0xfe

i am using 2.0.2 unicode windows version
is there any way to resolve this issue?
thanks

sorry apparently mkvmerge is having some conflict with another program
after shutting down that program the problem is fixed

[delacroixp]

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576
Firstly, thanks again to J_Darnley... the new muxing 'Format specific options' in MkvMerge work like a treat.

http://souls-online.net/delacroixp/AutoMKV/MkvMergeMuxingDisplayThumb.jpg (http://souls-online.net/delacroixp/AutoMKV/MkvMergeMuxingDisplay.jpg)


It all started with 'Band of Brother (http://forum.doom9.org/showpost.php?p=977686&postcount=1684)'... an Q18 CQ-CRF encode that looked lacklustre and bleached compared to the original (see post)...
I have posted an enquiry on H264 Filters (http://forum.doom9.org/showthread.php?t=124430)... but that's a 'complete makeover'... perhaps a small (simple) solution would work best.

I was so impressed with MKV's ability to morph movies after encoding rather than before... that perhaps it's possible to boost colour saturation during the muxing process rather than during the entire encoding process itself.

Are there any colour muxing options available to MKV ?


:):D:eek:
Pascal

[zgx]

I have a large h264 video file that I got from from and Blu-ray "xport". The file is fine and I can play it back with CoreAVC for example

I want to put it in a MKV container but I am having some problems with it.

MKVmerge accepts the file and everything seams to be fine. But when I play back the resulting MKV file the video is totally distorted.

Anyone have any idea how to mux this file properly?

[DreckSoft]

Same prob here. Tried m2ts => mkv with GraphEdit, with GDSMux, m2ts => 264 (plays fine) => mkv with MKVToolnix, m2ts => 264 => MP4 (distorted video) => mkv (distorted video). so nothing seems to work :-((

[chros]

Just a theoretical question: how does the stretch function of an audio stream is working? (it's very useful)

eg: if the value is 1.5, it means that we have 1 and a half times longer duration than the video stream.
So what it does exactly? Does it duplicate frames ? Or miss out some audio samples?

Thanks

[Mosu]

Just a theoretical question: how does the stretch function of an audio stream is working? (it's very useful)

It only modifies the timecodes, not the samples.

[chros]

It only modifies the timecodes, not the samples.
Which what is it mean ? Duplicate or drop frames ?
(Sorry if I'm stupid ...)

[Mosu]

Which what is it mean ? Duplicate or drop frames ?
(Sorry if I'm stupid ...)

It does neither. It only multiplies the timecodes with the factor.

[bob0r]

@Mosu


I have found some problems with certain .ts H.264 MBAFF files.
Some seek and mux .... some dont seek and dont mux using Haali's gdsmux.exe (lenght is not calculated also)

Now Haali wants a sample file.

As i also had problems with Big H.264 MBAFF files with mkvtoolnix, muxing sometimes stalls at a certain point.

I have this: George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts 12.2GB Rarred (.001 = rar) on a server.

Now my question is:
Can i upload (FXP ftp to ftp) it to you?


Edit:
Indeed the demuxed video.h264, trying to mux into .mkv gives this again:


mkvmerge v2.0.2 ('You're My Flame') built on Mar 12 2007 16:12:08
'G:\cap\BBC-HD\video.h264': Using the AVC/h.264 ES demultiplexer.
Track 0 of 'G:\cap\BBC-HD\video.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080.
'G:\cap\BBC-HD\video.h264' track 0: Using the MPEG-4 part 10 ES video output module.
The file 'G:\cap\BBC-HD\video.mkv' has been opened for writing.
'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 198068 bytes.



So it is the perfect sample!


P.S.
can you explain: "set the display dimensions to 1964/1080." Where does the 1964/1080 come from?

[chros]

It does neither. It only multiplies the timecodes with the factor.
So is it means slowed down audio?

[Mosu]

@Mosu


I have found some problems with certain .ts H.264 MBAFF files.
Some seek and mux .... some dont seek and dont mux using Haali's gdsmux.exe (lenght is not calculated also)

Now Haali wants a sample file.

As i also had problems with Big H.264 MBAFF files with mkvtoolnix, muxing sometimes stalls at a certain point.

I have this: George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts 12.2GB Rarred (.001 = rar) on a server.

Now my question is:
Can i upload (FXP ftp to ftp) it to you?

I'm not sure if FXP works, but you can try. I'll set up an account for Haali so that he can get the file from my server when you're done.

[bob0r]

Haali already is downloading the file, i FXPed him the file.

FXP works............ now pray we get some speed :p

Edit:
[22:18:58] Transferred: george.gently.2007.bbc-hd.1080p.h.264.ac3.2.0.133 72,264,381 bytes in 6 minutes 45 seconds (173.9 KB/s)
ETA: ~ 20 hours.... hope you got 13GB(*2) free :o

[Mosu]

Damn, I should have read your message sooner. The reason why mkvmerge eats such huge amounts of memory is because it doesn't support MPEG transport streams. It mis-detects your file as a raw AVC elementary stream and tries to parse the file that way. I will add detection of transport streams to mkvmerge so that it'll abort with an appropriate error message and not display this behaviour.

[delacroixp]

Sometimes I incorrectly set the DAR resolution or aspect ratio and then re-calculate with SeeMoreDigital's Aspect Ratio Signalling (ARS) Calculation Tool (http://forum.doom9.org/showthread.php?t=107039).
Is it possible to reset the few signalling bytes rather than to remux the entire movie project ?

:thanks:


:):D:eek:
Pascal

[bob0r]

@Mosu:

If that was a message to me:
That error occurs with:
George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.h264
demuxed with elecard xmuxer pro.

(mplayer is crap when it comes to demuxing)

.h264 or .h264 and .ac3 together, both crash.

But yeah, direct .ts support would be great!

Edit for below:
@DreckSoft
Yup, it seems a pure size/memory issue, but it should be fixed soon now, as Mosu has a 12GB file :)

[DreckSoft]

Damn, I should have read your message sooner. The reason why mkvmerge eats such huge amounts of memory is because it doesn't support MPEG transport streams. It mis-detects your file as a raw AVC elementary stream and tries to parse the file that way. I will add detection of transport streams to mkvmerge so that it'll abort with an appropriate error message and not display this behaviour.

The problem also exists on raw 264 streams from HD-DVDs.

[bob0r]

@Mosu

Haali has managed to "work-around" on the broken H.264 MBAFF .ts file you got also.

So if you can/want to make .ts as import support, you can ask Haali what he did to make it working.

Haali splitter on broken H.264 MBAFF .ts file:
1: allows seeking using mpc
2: allows muxing with gdsmux.exe (so direct .ts to .mkv works now)

[Isochroma]

Some suggested improvements for mkvmerge GUI:

1. Attachments. When an MKV file is added, the tracks are shown and can be checked/unchecked. However, any attached files are not shown in the Attachments box under the Attachments tab.

This should be made to work just like the tracks in the Input tab. All attached files, from all MKV files dropped into the window would be listed in the Attachments box, with check boxes to their left, checked by default.

2. Timecodes. MKV files with timecodes attached to their track(s) don't show up as such, though remuxing the track(s) will preserve the timecodes.

Suggested fix: Timecodes line becomes a drop-down selector box, containing the timecodes (if already existing), and any selected by the Browse... button. Only one in the list can be selected, of course.

[Mosu]

Is it possible to reset the few signalling bytes rather than to remux the entire movie project ?

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.

[Mosu]

Some suggested improvements for mkvmerge GUI:

1. Attachments. When an MKV file is added, the tracks are shown and can be checked/unchecked. However, any attached files are not shown in the Attachments box under the Attachments tab.

This should be made to work just like the tracks in the Input tab. All attached files, from all MKV files dropped into the window would be listed in the Attachments box, with check boxes to their left, checked by default.

Yeah, I know... Won't happen due to lack of time.

2. Timecodes. MKV files with timecodes attached to their track(s) don't show up as such, though remuxing the track(s) will preserve the timecodes.

Suggested fix: Timecodes line becomes a drop-down selector box, containing the timecodes (if already existing), and any selected by the Browse... button. Only one in the list can be selected, of course.

You're assuming that the timecode files are somehow stored in a Matroska file, which they aren't. mkvmerge uses the information from a timecode file and calculates the actual timecodes from it. Therefore there's no way to tell from the final Matroska file that a timecode file was used in the first place, much less so what its contents were.

[delacroixp]

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.

:thanks: much

I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...


:):D:eek:
Pascal

.
..
... so maybe a 'property editor' would do the trick... 2 or 3 minutes of remuxing is no big deal but getting-it-right would be kewl...

[robU*4]

:thanks: much

I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...


:):D:eek:
Pascal

.
..
... so maybe a 'property editor' would do the trick... 2 or 3 minutes of remuxing is no big deal but getting-it-right would be kewl...

The Shell Extension would be the tool but it's not 100% compliant and safe. So I think the best way is to remux the file. Is it so much more work ?

Maybe when we have a tag-only app to tag matroska files it could also update safely that kind of information.

[delacroixp]

Sometimes I incorrectly set the DAR resolution or aspect ratio and then re-calculate with SeeMoreDigital's Aspect Ratio Signalling (ARS) Calculation Tool (http://forum.doom9.org/showthread.php?t=107039).
Is it possible to reset the few signalling bytes rather than to remux the entire movie project ?

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.
I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...


The Shell Extension would be the tool but it's not 100% compliant and safe. So I think the best way is to remux the file. Is it so much more work ?

Maybe when we have a tag-only app to tag matroska files it could also update safely that kind of information.

:thanks: much... I hope the Shell Extension works out... I guess more work is better than less.
The tag-only app seams the way to go...


:):D:eek:
Pascal

[Isochroma]

Today I decided to test remuxing a file without renaming it. The first message I get is:

"The output file 'filename.mkv' already exists. Do you want to overwrite it?"

However, when I click the Yes button, the next error reported is:

"filename.mkv' and of one of the input files is the same. This would cause mkvmerge to overwrite one of your input files. This is most likely not what you want."

It seems redundant that I get two messages, when I could get none at all, if the overwrite method were changed to the following:

1. check if outputfilename == inputfilename (including path) [add case check for case-sensitive filesystems here]

2. if yes, check if silent-overwrite is enabled (new item in preferences). if yes, go to 4, if no continue.

3. ask to overwrite outputfilename. if yes, go to 4

4. overwrite old file with new, by either:

a0.1 check that path+filename of 'filename-old.mkv' is no longer than filesystem maxlength
a0.2 if so, report error & abort, otherwise continue
a1 rename the old file 'filename-old.mkv'
a2 write the new file as 'filename.mkv'
a3 delete 'filename-old.mkv'

or

b0.1 check that path+filename of 'filename-new.mkv' is no longer than filesystem maxlength
b0.2 if so, report error & abort, otherwise continue
b1 write the new file as 'filename-new.mkv'
b2 delete the old file 'filename.mkv'
b3 rename the new file to 'filename.mkv'

It is also possible to modify the binary contents of a file, even changing its length, if the correct OS APIs are called. This would not entail the need for double the space, as the previous method would. However, the previous method is much simpler and should only take a few minutes to implement.

The reason I suggest this improvement, is because I overwrite many mkv files making minor modifications to track names, languages, etc. every day. When this needs to be done, I have to add an extra character to the output filename, mux, delete the original, then rename the new file back, all manually.

This need not be the case; just think how annoying it would be if you had to do this every time you saved a Word document, .txt file, etc.

[delacroixp]

Today I decided to test remuxing a file without renaming it. The first message I get is:

"The output file 'filename.mkv' already exists. Do you want to overwrite it?"


Solution:
1. check if outputfilename == inputfilename (including path) [add case check for case-sensitive filesystems here]

2. if yes, check if silent-overwrite is enabled (new item in preferences). if yes, go to 4, if no continue.

3. ask to overwrite outputfilename. if yes, go to 4

4. overwrite old file with new, by either:

a0.1 check that path+filename of 'filename-old.mkv' is no longer than filesystem maxlength
a0.2 if so, report error & abort, otherwise continue
a1 rename the old file 'filename-old.mkv'
a2 write the new file as 'filename.mkv'
a3 delete 'filename-old.mkv'

or

b0.1 check that path+filename of 'filename-new.mkv' is no longer than filesystem maxlength
b0.2 if so, report error & abort, otherwise continue
b1 write the new file as 'filename-new.mkv'
b2 delete the old file 'filename.mkv'
b3 rename the new file to 'filename.mkv'

Perhaps, a catch-all solution might be to rename the file 'filename.mux.mkv' right from the start... as implemented in the DivX Mux GUI (http://www.propr.de/divxmuxgui/), leaving the user to rename, relocate or whatever... and possibly renaming 'filename.remux.mkv' as a 2nd refinement in the case of a single file modification.

The idea of creating a temp muxing file and replacing the old one is pretty neat... though a further refinement might be to merely rename the old file 'filename.old.mkv'... leaving the user to delete or otherwise make use of...

Last thought... perhaps we could have an 'Output Folder' in Settings... which would forestall much of the aggravation from counter-intuitive, renaming, relocating and overly-complex interaction...


:):D:eek:
Pascal

[Mosu]

I can understand the need for such a behaviour, but I don't want to make this overly complicated. Here's what I propose to implement:

A new configuration option is added which controls mmg's output file overwriting. The possible values are "ask before overwriting", "overwrite without asking and resolve file name conflicts" and "rename old file before running mkvmerge".
"ask before overwriting" is the same behaviour as it has always been. It's also the default setting.
"overwrite without asking and resolve file name conflicts" will do the obvious: just overwrite the file if it exists already. If the same name is used for the output file and an input file then the new output file will automatically get a new name in the form "filename.1.mkv"; if that exists, then "filename.2.mkv" etc.
"rename before starting mkvmerge" will cause mmg to rename the existing file to "filename.backup-1.ext", if that one exists, then to "filename.backup-2.ext" etc

I can also add another option for setting a default output folder. At the moment mmg uses the path name of the first file that is added as the output folder.

What I don't like and what I will likely not implement is this:

"always rename the muxed file to something like 'filename.mux.mkv" -- This would probably introduce one unneccessary step for a lot of users: removing the ".mux" in the output file name. If the source files are already named correctly then the destination file should be as close to the same name as possible.

[LeMoi]

I can understand the need for such a behaviour, but I don't want to make this overly complicated. Here's what I propose to implement:

"rename before starting mkvmerge" will cause mmg to rename the existing file to "filename.backup-1.ext", if that one exists, then to "filename.backup-2.ext" etc
And input filename will be corrected in command line ?

[Mosu]

And input filename will be corrected in command line ?

No, I'm only talking about renaming output files or changing the name mkvmerge will output to. Input files will never, ever be touched.

[bob0r]

@Mosu

How is the file going?

[LeMoi]

""rename before starting mkvmerge" will cause mmg to rename the existing file"

[Mosu]

How is the file going?

I can mux it with mkvmerge using ~65 MB memory tops. I'll have to clean up the source a bit; expect a new build soon.

[Mosu]

""rename before starting mkvmerge" will cause mmg to rename the existing file"

...the existing output file.

Like I said, mmg will never rename an input file. Why? Because no user expects that a program would rename a file that the program is supposed to just open for reading. Would you like if MS Word would just rename your files whenever you chose "File -> Save"?

[Brother John]

I like the idea of those three options. :) Two thoughts about them:

How about a fourth one: "Use file/segment title as file name if present". That's how I name my files and I'd be really surprised if this wasn't a common way to name output files.

Concerning the "rename before" option. A common scenario: You have a video-only file called c:\movie.mkv (probably encoded by x264.exe or xvid_encraw). When you load this file into mmg to mux audio & Co the name for the muxed file is auto-set to c:\movie.mkv. That's a small flaw even in the current mmg version and it'd conflict directly with the "rename before" option: Existing file to be renamed is the input file, but input file renaming is not allowed.