MKVcleaver : GUI for mkvextract with batch support v 0.7.0.2

[sheck]

Originally Posted by hello_hello

[full disclosure] I'm running MKVcleaver on XP [/full disclosure]

sheck,
I played around a bit more with AVI muxing.....

I tested MKVCleaver 0.6.0.6 and 0.6.0.5 and the results weren't any different to the current version, but when I stopped testing VFR MKVs I discovered muxing h264 streams as AVI works fine for any version of MKVcleaver as long as it decides they're constant frame rate. It's the streams being reported as VFR in the log file that fail to mux. Go figure... after an hour of testing VFR MKVs earlier.

avctoavi.exe doesn't seem to have a problem with any of the streams though. I can successfully use it to mux VFR h264 streams as AVI after MKVcleaver has extracted them. I tried the avctoavi that comes with MKVcleaver as well as a slightly old version that comes with avc2avi_gui. Both worked.

One thing I noticed if it means anything to you. When I switched to the older avc2avi the success rate for muxing VFR streams as AVI increased somewhat. Of the nine files I tested earlier only three failed to mux and for those a 232 byte AVI was created. I realise that's useless but it's an improvement on no file being created by the avc2avi MKVcleaver uses.

MKVcleaver 0.6.0.7 appears to have a 100% success rate when it comes to determining whether an MKV is variable frame rate (according to it's log). It also seems to have a 100% success rate when it comes to automatically extracting the timecodes along with a variable frame rate video stream. The muxing of VFR streams as AVI is mostly unsuccessful though.

MKVcleaver 0.6.0.5, 0.6.0.6 and 0.6.0.8 are fairly good at detecting VFR streams but not 100% accurate. I've got at least one VFR MKV they all see as CFR but version 0.6.0.7 gets it right. None of those versions are very likely to automatically extract timecodes even when they do detect a VFR stream. I think they might manage to do so very occasionally although through the last half hour of extracting streams they've had a combined success rate of 0%. The muxing of VFR streams as AVI is mostly unsuccessful with MKVcleaver's version of avc2avi.

I have no problems extracting. It's just the VFR detection and AVI muxing.
I really hope this isn't an XP thing..... although avc2avi is probably older than XP.

Thanks.

AVI files do not support vfr tracks so it will always fail to convert.
You must convert them to cfr manually first.

I will probably code MKVCleaver to log an error in these cases if I cannot find an automatic way to convert a vfr file to cfr.

[hello_hello]

Originally Posted by sheck

So you want time codes only option under each track ? Otherwise it would be the same as how it works now. Or do you want timecodes only option moved to the right pane and apply to all tracks ?

Yeah, I think my idea at the time was to have a "timecodes only" and a "timecodes with tracks" option in the right pane. That wouldn't alter the functionality would it, just make it obvious which mode MKVCleaver is in.

Or it mightn't necessarily need to be in the top right pane. The menu item could be moved to the Video Options section in the lower right pane with a checkbox to switch between timecodes and timecodes with tracks. Just so you can see what state it's in rather than it being hidden under a menu.

[hello_hello]

Originally Posted by sheck

If the video delay is 100ms and audio delay is 200ms then the video delay is useless (or if not then I would need to know cases why it would not be) so it is not written and the audio delay is calculated as audio delay(200ms) - video delay (100ms) = audio delay 100ms.

To be honest it was so long ago I'm struggling to remember what the issue was, although I don't think the correct delay was always being written.

The main problem is traditionally it's always been assumed the video delay is zero and the audio delay is adjusted accordingly, as mostly the video is re-encoded and any video delay is lost, but when it comes to the second rule it's being done differently.

If the audio delay becomes negative then both audio and video delay will be output as they are present in the input file.

To keep it consistent with the first rule, the extracted files should look like this, assuming the video delay is 200ms and the audio delay is 100ms.

Episode one 01 EN DELAY 0ms.h264
Episode one 02 EN DELAY -100ms.ac3

Using the current method if the video delay is 200ms and the audio delay is 100ms, after re-encoding the video, a muxer would normally need to apply a -100ms delay to the audio, but MKVCleaver writes 100ms and the audio sync would be out by 200ms.

I think currently the delay written to the audio stream can be different according to whether the video delay is also requested or not. To be honest, I'm not sure that's a good idea.

The above keeps the traditional "no video delay" assumption intact, but unfortunately it doesn't always work when extracting and remuxing. I don't there's an automatic solution to fit every circumstance, but maybe one idea might be to write the video delay to both streams, "if" the video delay isn't zero, as a guide for manual adjustment. ie

Original video delay 200ms, audio 100ms, extracted files:
Episode one <V200ms> 01 EN DELAY 0ms.h264
Episode one <V200ms> 02 EN DELAY -100ms.ac3

Original video delay 50ms, audio 200ms, extracted files:
Episode one <V50ms> 01 EN DELAY 0ms.h264
Episode one <V50ms> 02 EN DELAY 150ms.ac3

That gives you the required information to extract a stream, re-encode it, then mux it back into the original MKV, so to speak.
In the second example you'd extract the audio stream, add it back to the existing MKV, the muxer would automatically apply a 150ms delay, and you'd know to adjust it by +50ms to stay in sync.
In my case I'd generally do the opposite and adjust both streams by -50ms, but either way you need to know the original video delay to do it.

Just some thoughts.... but I think the audio delay should always be calculated the same way. Changing that according to whether it'd be positive or negative doesn't seem like a good idea to me, as I'm easily confused.

[hello_hello]

Originally Posted by sheck

I will need more info about this one. MKVCleaver can be made to write the delay the same exact way as gMKVExtractGUI.

I wasn't referring to how it's written, but the way it's displayed when opening an MKV.

It comes down to the problem discussed in my previous post. When an audio stream is extracted the original video delay is assumed to be zero, but if you want to extract it and remux it back into the original MKV, there's no way to know if the delay needs to be re-adjusted or even if there was a video delay in the original MKV without manually checking.



Even checking with MediaInfo doesn't tell you much. It adjusts the audio delay it displays automatically too, so if it shows a -100ms audio delay there's no way to know if the audio delay is 0ms and the video delay 100ms, or if the audio delay is 50ms and the video delay is 150ms etc. It never displays a video delay.

[sheck]

Originally Posted by hello_hello

Yeah, I think my idea at the time was to have a "timecodes only" and a "timecodes with tracks" option in the right pane. That wouldn't alter the functionality would it, just make it obvious which mode MKVCleaver is in.

Or it mightn't necessarily need to be in the top right pane. The menu item could be moved to the Video Options section in the lower right pane with a checkbox to switch between timecodes and timecodes with tracks. Just so you can see what state it's in rather than it being hidden under a menu.

I will color coordinate Timecodes on the right side. Red if timecodes only is set and regular color if it's not set

[sheck]

As for the delays, they are not purely for informational purposes. When muxing mkv files mkvmerge will read the delays from the audio files and set it automatically. It won't do the same for video files. So having an audio delay is more important. So if we can subtract audio delay from video delay and get a positive number, the video delay is removed completely from the file name, because it is no longer needed. Now, if we get a negative audio delay after the subtraction, there are multiple ways to go:

1) Write a negative delay to the audio file and forget about the video delay.
2) Write both the video and the audio delays to their respective files as they were in the source.

I personally do not like negative delays since some muxers will just drop the negative frames possibly making the audio cut out. I also don't know how every video player handles negative delays. So I chose not to deal with negative delays.

I think I will keep MKVCleaver the way it is in regards to writing negative delays to audio files, unless you can point me in a direction of some discussion where I can find more information about why I should not do it.

[sheck]

Originally Posted by hello_hello

I wasn't referring to how it's written, but the way it's displayed when opening an MKV.

It comes down to the problem discussed in my previous post. When an audio stream is extracted the original video delay is assumed to be zero, but if you want to extract it and remux it back into the original MKV, there's no way to know if the delay needs to be re-adjusted or even if there was a video delay in the original MKV without manually checking.



Even checking with MediaInfo doesn't tell you much. It adjusts the audio delay it displays automatically too, so if it shows a -100ms audio delay there's no way to know if the audio delay is 0ms and the video delay 100ms, or if the audio delay is 50ms and the video delay is 150ms etc. It never displays a video delay.

I think the answer here is the same as my previous post. I don't see a reason to display delays at all in the GUI as they are written to the file name.

I will test it to make sure the delays are calculated and written correctly, however, I don't see a reason to add that information to the GUI.

Again, if you can make a case as to how this saves time vs having the delay in the filename, I will reconsider.

[sheck]

Originally Posted by hello_hello

Original video delay 200ms, audio 100ms, extracted files:
Episode one <V200ms> 01 EN DELAY 0ms.h264
Episode one <V200ms> 02 EN DELAY -100ms.ac3

Original video delay 50ms, audio 200ms, extracted files:
Episode one <V50ms> 01 EN DELAY 0ms.h264
Episode one <V50ms> 02 EN DELAY 150ms.ac3

That gives you the required information to extract a stream, re-encode it, then mux it back into the original MKV, so to speak.
In the second example you'd extract the audio stream, add it back to the existing MKV, the muxer would automatically apply a 150ms delay, and you'd know to adjust it by +50ms to stay in sync.
In my case I'd generally do the opposite and adjust both streams by -50ms, but either way you need to know the original video delay to do it.

I don't follow this. Is it not the same to have video delay of 50ms and audio delay of 200ms as having video delay of 0ms and audio delay of 150ms ? Why would you need to adjust it when muxing ?

[sheck]

I was going through possible scenarios with the audio,video delay and, you're right hello_hello, there are too many possibilities. So I've decided to just write the original values from source to the file name.

[hello_hello]

Originally Posted by sheck

I was going through possible scenarios with the audio,video delay and, you're right hello_hello, there are too many possibilities. So I've decided to just write the original values from source to the file name.

Please don't.... but if you do, that would be one argument for displaying the delay values for each stream in the GUI.

I have a file with a 100ms video delay and a 150ms audio delay.
150ms is written to the audio stream when it's extracted. If the video is re-encoded the video delay will become zero and 150ms will be wrong. It should be 50ms. The only way to know what a 50ms or 150ms audio delay means (however you do it) is if you can check the video delay.

DGIndex has always written negative audio delays and it's never been an issue for me. I can't say I've even felt like important audio was removed when muxing because the delay was negative. Does the audio ever start before the first frame?
If you happen to have an issue with that, it's easy enough to manually over-ride when muxing.
"Episode one 02 EN DELAY -117ms.ac3"
The muxer will automatically apply a -117ms delay. Change it to zero manually, make the delay for the video stream 117ms and the beginning of the audio won't be cut, but most people would probably be used to the "video delay is zero" method, and I suspect prefer it, otherwise every muxer wouldn't do it.

Personally I think the precedent set by DGIndex should be adhered to, because that's what everyone expects. The delay written to the audio stream should assume the video delay is zero and adjusted accordingly, whether that makes it positive or negative.

I still think the best compromise is to stick to that system and also write the video delay to the audio stream, if it's not zero.
Something like:
"Episode one <V50ms> 02 EN DELAY 150ms.ac3"

You know if you're re-encoding the video a 150ms audio delay will be correct. You know if you extract the audio, re-encode it and remux it with the original file there's a 50ms video delay to account for, so the audio delay needs to be manually adjusted to 200ms.

Originally Posted by sheck

I don't follow this. Is it not the same to have video delay of 50ms and audio delay of 200ms as having video delay of 0ms and audio delay of 150ms ? Why would you need to adjust it when muxing ?

I guess you know what I was referring to now, but it's the difference between muxing the audio after having encoded the video (effectively making the video delay zero) and re-encoding the audio only and remuxing it with the original MKV, in which case the video delay mightn't be zero, so ideally you'd have a way to check it.

If anything I'd at least prefer to go with the "always assume the video delay is zero" method because generally it is. Video delays in MKVs aren't particularly common, but they do exist.

One final thought..... I've not used DGIndexNV or any of the newer flavours, which I assume can extract audio from MKVs, as most encoder GUI's do, as does MKVExtractGUI or gMKVExtractGUI etc..... but it'll be really nice if it didn't matter which program you used to extract the audio, it'd have the same delay written to the stream when it's extracted. Do you know if DGIndexNV can extract the audio and does it write negative delays?
As far as I know, all programs would write the same delay now as long as the video delay really is zero, but so far the only other program that takes any video delay into account is gMKVExtractGUI (aside from maybe DGIndexNV) and it works on the "video delay is zero" principle, but you can at least check the video delay with the GUI if need be.

Thanks.

[Danette]

When running a batch of MKV’s, MKVCleaver 0.6.0.8 (32-bit) hangs on my Win 7, at various points in a batch list, about half the time. This requires killing the process and, when restarted, picking up where it left off.

Looking for hints in an old thread, I find that, once MKVCleaver hangs, mkvextract.exe does not appear in the task manager.

[Mosu]

Hey,

someone just reported to me that using MKVToolNix v10.0.0 breaks mkvcleaver. Note that I haven't verified this myself, but please look into it.

My guess is that it's one of two things:

1. v10.0.0 is the first version with more than one digit in a component which might cause a version check to fail.
2. Additionally sorting version numbers via simple string comparisons will sort 10.0.0 as being smaller than 9.9.0. Again this might make a version check fail.

[desperado836]

yeah, it pukes on me, only extracting the chapters file, had to roll back to MKVToolNix 9.9.0, works perfectly then

[davizator]

Originally Posted by desperado836

yeah, it pukes on me, only extracting the chapters file, had to roll back to MKVToolNix 9.9.0, works perfectly then

yes, same here...

[Mosu]

The author has written here that it was indeed a buggy version check, and that this check's been fixed for the upcoming release.

[mkdrive2]

I am unable to extract the audio from mkv files when I use MKVToolNix version 10.0.0 or 11.0.0. I get the following error message in the log file:

Extracting Items - audio (error);
Codec is not V_MPEG4/ISO/AVC. Not converting to AVI
Error: Nothing to do.
Extraction failed

I reinstalled version 9.9.0, and there are no problems again.

[hello_hello]

sheck,
Will the next MKVCleaver support older versions of MKVToolNix or will an MKVToolNix that goes "ding" be required (version 11+)?

It seems MKVToolNix can never work on XP again because apparently some people wanted a muxing program to play sounds, and that'll prevent it working on XP forever.

I'm just wondering if we'll still be able to use older XP machines for extraction with a version of MKVToolNix that runs on them because it doesn't go ding (version 10 or older).

Cheers.

[sneaker_ger]

AFAIK the sound playing is a feature of MkvToolNix GUI and shouldn't affect other tools using mkvextract or mkvmerge. Of course no one will guarantee you for how long. And usually old versions work for quite some time because the basic CLI usage rarely changes.

[sheck]

Changes:

* Implemented SQLIte database as the storage engine for internal arrays and the log
* Added utility to rotate logs
* Added log settings and log viewer
* Added more detailed logging
* Update check is now using JSON format
* Changed mkvmerge -i to mkvmerge -J. MKVCleaver is now using JSON format to query MKVtoolNix CLI tools
* Removed mkvextract version check
* Added minimum MKVToolNix version. Minimum version is 10
* Added [LNG3], [LNGf] and [Delay] placeholders
* Removed [vDelay] placeholder
* Changed how [aDelay] placeholder works
* Added Quick and Full VFR detection modes
* Added VFR to CFR conversion (experimental)
* Removed avdump2
* Added batch filters for extraction
* Moved About button under Help menu
* Added Segment UIDs extraction
* Added ability to add files to MKVCleaver by dragging and dropping a text file
* Added instance check. Max instances is now 1
* Removed Audio FLAC in OGG container option
* Major source changes to accommodate SQLite DB and Windows 10
* MKVCleaver minimum GUI size is now set for both x and y axis
* Minor changes to custom.ini file options
* Timecodes checkbox text will be red when Timecodes Only option is selected (visual aid)

Fixes:

* Fixed Drag & Drop on Windows 10
* Fixed state and text detection for files and tracks windows under Windows 10
* Fixed Go button state changes based on what is selected
* Fixed Audio track language was displayed as English when no language was set
* Fixed h.264 to avi conversion errors
* Optimized code to idle CPU when nothing is happening
* Changed acv2avi.exe to the version from VideoHelp

[sheck]

Originally Posted by hello_hello

sheck,
Will the next MKVCleaver support older versions of MKVToolNix or will an MKVToolNix that goes "ding" be required (version 11+)?

It seems MKVToolNix can never work on XP again because apparently some people wanted a muxing program to play sounds, and that'll prevent it working on XP forever.

I'm just wondering if we'll still be able to use older XP machines for extraction with a version of MKVToolNix that runs on them because it doesn't go ding (version 10 or older).

Cheers.

Older versions are no longer supported, Minimum MKVToolNix version supoorted is 10. This is due to MKVCleaver switching to JSON for querying mkvmerge and mkvextract.

It should still work on XP, however, I don't have XP any longer to test.