MKVToolNix v24.0.0 released

[Bigmango]

Originally Posted by Bigmango

Disabling antivirus didn't change anything.

I have sent you the file "1_2_audio.flac".

This file is the result of a DTS-HDMA conversion with eac3to. There were 2 DTS-HDMA tracks converted together. The first track (which I sent you) gives this JSON error on windows (but can be added fine with the linux version), and the second track (which I didn't send) can be added properly as it doesn't give this error.

This is very strange.

Furthermore, I also from time to time (not always) get this error when trying to open mkvs which I have created with this same windows version 9.7.1. (but on linux, same version 9.7.1, I can open these files without any problem).

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

Thanks.

[Mosu]

Originally Posted by Bigmango

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

I cannot reproduce your problems here on Windows — neither with 9.7.0, nor with 9.7.1 or the current development snapshot.

It's possible that, for some reason, the GUI's file identification cache contained broken data. Using a different version causes the cached data to be removed, hence why it's working with 9.7.0. It's quite possible that it may work now even if you switch back to 9.7.1.

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

[Mosu]

Originally Posted by nautilus7

Hi, does mkvmerge support DSD format (the audio format found in SACD)? I have some .dff files and can't mux them into .mka container. Any way to do it? Sample (money.dff) in your ftp.

No, mkvmerge doesn't, nor does Matroska in general.

[SeeMoreDigital]

Originally Posted by Mosu

No, mkvmerge doesn't, nor does Matroska in general.

That's a real shame.

That said, somebody would then need to create a parser/splitter to support playback of such contained streams

[Bigmango]

Originally Posted by Mosu

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

Removing this cache directory seems to have fixed the problem.

Thanks.

[Perenista]

I have a video recorded by FRAPS that is using these settings (in terms of Aspect Ratio):
http://i.imgur.com/fX3BhbN.png

If I wanted to use these settings:
http://i.imgur.com/FwJzKds.png

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.

[sneaker_ger]

Originally Posted by Perenista

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.

Why not? Do you want to force black bars on all 4 sides? I think that's indeed not possible. Otherwise just choose AR 1.339 (well, basically 4/3) when muxing using mkvmerge (or add/change the values in exisiting Matroska files using the Header Editor).

[hello_hello]

The MKVToolNix cache folder.....

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

I almost always add the initial file or stream to be muxed via the Explorer right click SendTo menu. ie Right Click/SendTo/mkvtoolnix-gui.exe. but as the number of files in the cache folder increases, so too does the amount of time it takes MKVMergeGUI to "get itself ready". If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

I haven't timed it exactly, but at the moment the cache folder contains 894 files totalling 3.9MB, which doesn't seem excessive (in respect to size), however the time between the GUI opening and the input fields becoming usable would now be close to ten seconds.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

I deleted the contents of the cache folder a short while ago, and so far that seems to have fixed the slow opening problem, but I've only used MKVToolNix a couple of times since then, so time will tell.

Thanks.

[Mosu]

Originally Posted by hello_hello

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

Obviously, that shouldn't happen.

If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

Interesting interaction. The GUI has a cleanup process for the cache directory. It is supposed to remove cache files that were created with an older version. It is run in a separate thread as it isn't supposed to affect normal operation of the GUI, and it's started right when the GUI starts.

The problem here is most likely that every access to the cache directory is guarded by a mutex so that only one thread can access it at any given moment. The cleanup process acquires a lock on this mutex when it starts and releases said lock once it finishes. At the same time the file identification tries to acquire a lock on the same mutex which has to wait until the cleanup process is finished.

A fix might be as trivial as to change the cleanup process to release and re-acquire the lock after each file it has processed. That way the file identifier's lock request can be processed, too.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

Yeah, that's likely due to OS-level caching.

Thanks for describing this so accurately. It's definitely a bug, and I'll definitely fix it.

[hello_hello]

I have another cache question......

In the past I've tended to load video files/streams into MKVMergeGUI for muxing before they're completed, so today I opened an MKV the x264 encoder was in the process of writing as it encoded and checked the cache file info. I closed MKVTookNixGUI and opened the MKV again. The cache file was overwritten but only the two "objectID" values had changed.

Are the "objectID" values important for correct muxing? I ask because there's a very good chance that after having opened the MKV a second time, I'd leave it loaded in MKVToolNixGUI until x264 has finished encoding, then I'd mux it.
If I remove it from the GUI first though, and open it again after the video encoding has finished, I assume the "objectID" values would change again. If I don't do that, they remain the same in the cache file. Does it matter?

Thanks.

[Mosu]

The GUI uses several pieces of inormation to determine whether the cache entry is still valid: the GUI's version, the file's name/size/last modification timestamp. As the latter two properties change with a file that's still written to, the GUI will invalidate the entry the next time the file must be identified.

I don't know which "objectID" values you mean.

[hubblec4]

The "objectID" is very impotant!
MTX-gui needs this for the correct order (display and muxing).
The "objectID" changes every time when you change the input.

[Mosu]

Ah _that_ objectID.

hubblec4 is not entirely correct. The important thing about the objectID is that it is consistent within the same file so that the track order works correctly. However (!), it is totally unimportant that it changes each time such a cache file is created, and even more important, the objectID does NOT depend on the identification output.

So yes, you can continue using the already-loaded file.

[Mosu]

Originally Posted by hello_hello

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

This has been fixed in the latest pre-builds (01414 and higher). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

[hello_hello]

Originally Posted by Mosu

This has been fixed in the latest pre-builds (01414 and higher). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

Thanks. I'll give it a spin and report back.

[v0lt]

I have a problem with converting some MPEG-2 files. After packing in MKV files are not played back smoothly in MPC-BE and MPC-HC.
The problem would be solved enabling the option "enable time correction". But it's not the best solution.

What is it? Incorrect operation of mkvtoolnix or the player?

Here are the first 10 timestamps that gives spitter.

Frame:   0, TimeCode:        138
Frame:   1, TimeCode:         58
Frame:   2, TimeCode:         98
Frame:   3, TimeCode:        258
Frame:   4, TimeCode:        178
Frame:   5, TimeCode:        218
Frame:   6, TimeCode:        378
Frame:   7, TimeCode:        298
Frame:   8, TimeCode:        338
Frame:   9, TimeCode:        498
Frame:  10, TimeCode:        418

And here is another file. It played good.

Frame:   0, TimeCode:        680
Frame:   1, TimeCode:        720
Frame:   2, TimeCode:        840
Frame:   3, TimeCode:        760
Frame:   4, TimeCode:        800
Frame:   5, TimeCode:        960
Frame:   6, TimeCode:        880
Frame:   7, TimeCode:        920
Frame:   8, TimeCode:       1080
Frame:   9, TimeCode:       1000
Frame:  10, TimeCode:       1040

[Aleksoid1978]

Player must playback such files normal - upload short sample.

[v0lt]

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

Added:
Maybe this problem comes from MPC-BE and LAV decoders. This problem occurs on all system renderer. That is not with Haali and madVR.
If I use Microsoft DTV-DVD Video Decoder, the problem goes away for all renderers except Haali (there is a black screen).

[Aleksoid1978]

Originally Posted by v0lt

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

"Bug" in video-decoders, in timestamp handle logic. Both files playback smooth with ffplay.exe and also in MPC-BE with MPEG-2 decoder(libmpeg2).

[SeeMoreDigital]

Hi v0lt,

Both files play okay on my Panasonic when cast via UPnP.

However, when I tried de-muxing and re-muxing the .mkv files they both appeared to be buggy