MKVcleaver : GUI for mkvextract with batch support v 0.7.0.2

[sheck]

Hmmm. Let me do some testing.

Looks like this only affects x64 version. Use x86 version for now.

[gendalv]

6.0.6 x64 crashes on launch - previous x64 versions aren't, 6.0.6 x86 isn't.
mkvtoolnix 5.8.0 win8.1x64
this

BEX64
MKVcleaver_x64_v0606.exe
0.6.0.6
54c92879
StackHash_3b37
0.0.0.0
00000000
PCH_30_FROM_ntdll+0x00000000000911FA
c0000005
0000000000000008

[hello_hello]

When using the custom file name option, if you include options such as language or delay that don't apply to every track, the tracks to which they don't apply are extracted with spaces in the file name. It's no big deal, but I just thought I'd mention it as maybe the file naming could be improved a little.

For example when language and delay are included in the custom file name, a chapter file is extracted like this (there's two spaces but I think the forum software is removing one):

video .txt

Cheers.

[sheck]

When using the custom file name option, if you include options such as language or delay that don't apply to every track, the tracks to which they don't apply are extracted with spaces in the file name. It's no big deal, but I just thought I'd mention it as maybe the file naming could be improved a little.

For example when language and delay are included in the custom file name, a chapter file is extracted like this (there's two spaces but I think the forum software is removing one):

video .txt

Cheers.

This is by design. I don't know how you're going to construct the file name so there is no way for me to know what to remove.

For example if your custom file name is [filename]_[lng]-[delay] then the output for subtitles will be somefile_-.srt

Simply remove spaces from the custom file name.

Edit:

I may add logic to remove some common characters like space, dash, # and underscore. Depending on how much work is involved.

[sheck]

6.0.6 x64 crashes on launch - previous x64 versions aren't, 6.0.6 x86 isn't.
mkvtoolnix 5.8.0 win8.1x64
this

BEX64
MKVcleaver_x64_v0606.exe
0.6.0.6
54c92879
StackHash_3b37
0.0.0.0
00000000
PCH_30_FROM_ntdll+0x00000000000911FA
c0000005
0000000000000008


This was already reported and confirmed. I'm working on a fix. Use x86 version for now.

[hello_hello]

For MKVCleaver 0.6.0.6 (and 0.6.0.3, although probably also the versions in between) selecting "Settings/TimesCodes/Timecodes Only" from the top menu stops the "Convert h264 tracks to AVI files" function from working. Is that expected behaviour?
I'm not actually checking "timecodes" for extraction. Just the video track. It extracts but the process stops there without converting to AVI. Changing the menu option to "Settings/TimesCodes/Timecodes With Tracks" gets it working.

Thanks.

[gendalv]

suggestion: add a filename option that would have <file name>.track# or just <file name> , it's useful for external subtitles and audio-tracks, without the need to rename them after extraction, since players can see tracks with the same name before a dot in the end.


16 similar files (3 audio tracks, 2 sub tracks total) extracting simultaneously:
for some reason when I selected first sub track manually in each file - it extracted the second subtitle track from each file instead.

[sheck]

suggestion: add a filename option that would have <file name>.track# or just <file name> , it's useful for external subtitles and audio-tracks, without the need to rename them after extraction, since players can see tracks with the same name before a dot in the end.


16 similar files (3 audio tracks, 2 sub tracks total) extracting simultaneously:
for some reason when I selected first sub track manually in each file - it extracted the second subtitle track from each file instead.

Custom Filenames should do what you want.

I will look into the extraction issue.

[hello_hello]

For MKVCleaver 0.6.0.6 (and 0.6.0.3, although probably also the versions in between) selecting "Settings/TimesCodes/Timecodes Only" from the top menu stops the "Convert h264 tracks to AVI files" function from working. Is that expected behaviour?
I'm not actually checking "timecodes" for extraction. Just the video track. It extracts but the process stops there without converting to AVI. Changing the menu option to "Settings/TimesCodes/Timecodes With Tracks" gets it working.

Any news as to whether the above is a bug or a feature? :)

Also, I can't get batch extraction of chapters to work with version 0.6.0.7. When i try to batch extract chapters, only the chapters from the last loaded file in the left pane are extracted.

Thanks.

[sheck]

Any news as to whether the above is a bug or a feature? :)

Also, I can't get batch extraction of chapters to work with version 0.6.0.7. When i try to batch extract chapters, only the chapters from the last loaded file in the left pane are extracted.

Thanks.

It was a bug. Works for me in 0.6.0.7.

I will look into the chapter extraction issue.

[hello_hello]

It was a bug. Works for me in 0.6.0.7.

I will look into the chapter extraction issue.

It's still not working correctly for me (version 0.6.0.7). I'm running XP if it makes a difference. When "timecodes only" is selected and the "convert to AVI" function is checked, MKVcleaver extracts the video but still fails to convert to AVI.

Thanks.

[sheck]

It's still not working correctly for me (version 0.6.0.7). I'm running XP if it makes a difference. When "timecodes only" is selected and the "convert to AVI" function is checked, MKVcleaver extracts the video but still fails to convert to AVI.

Thanks.

What's the codec for the video file ? Is it h.264 ? It will only convert h.264 to AVI.

[hello_hello]

What's the codec for the video file ? Is it h.264 ? It will only convert h.264 to AVI.

Yes, it's definitely h264 and it's definitely related to the timecodes option. Converting to AVI works as expected when "timecodes with tracks" is selected. When it's "timecodes only" the video is extracted normally but the process stops there.

[gendalv]

Please add [Title] and/or [Language] tags into the custom filename form. These are quite obvious tags to add imo :/

also would be nice to have some sort of indication of time remaining until completion or % done.

[sarofski]

"Track Language Code" no longer exists in the settings, could you add it again.
Meanwhile I'm trying to make a custom filename which includes language code. I have tried these lines:

<filename>_Track#_LNG
<filename>_Track#_[LNG]

But when I want to verify them I get a warning: Current filename configuration does not have a unique variable, Output files of the same types maybe overwritten.

And if I ignore it and save my custom file name, when I want to extract a track I get this error:
"Error: Failed to create the file 'D:\<filename>_Track#_LNG.aac': 0 (open file error)
Extraction failed"

What could be the problem?
Thanks

[sheck]

Please add [Title] and/or [Language] tags into the custom filename form. These are quite obvious tags to add imo :/

also would be nice to have some sort of indication of time remaining until completion or % done.

There is [LNG] tag. Does that not work ?
The title of what ? Track title ?

[sheck]

"Track Language Code" no longer exists in the settings, could you add it again.
Meanwhile I'm trying to make a custom filename which includes language code. I have tried these lines:

<filename>_Track#_LNG
<filename>_Track#_[LNG]

But when I want to verify them I get a warning: Current filename configuration does not have a unique variable, Output files of the same types maybe overwritten.

And if I ignore it and save my custom file name, when I want to extract a track I get this error:
"Error: Failed to create the file 'D:\<filename>_Track#_LNG.aac': 0 (open file error)
Extraction failed"

What could be the problem?
Thanks

Unique variable is one that changes from file to file, like file name. Otherwise all files will have the same output name and will be overwritten with the next one.

The way you had it should've worked, I think. :D. I will look into it. You have to follow the syntax though.

[mbcd]

Thanks a lot for this useful program.

One bug I found since a long time ago:

Extracting of chapters does not work. If I demux more than one file, I get finaly only ONE chapterfile which contains the chapters of the last demuxt file.

Something went wrong with chapter-extraction.

[frankp]

I'm using MKVcleaver in Windows 10 (64bit), but i can't seem to get it to work.
Files are loading, program is reporting it's extracting the subtitles, but no subtitles are placed in de destination folder.

[sheck]

I'm using MKVcleaver in Windows 10 (64bit), but i can't seem to get it to work.
Files are loading, program is reporting it's extracting the subtitles, but no subtitles are placed in de destination folder.

Please file a bug here (http://blogs.sapib.ca/apps/bugs-requests/)

[sheck]

Changes:

* Added video delay placeholder to custom file names
* Audio delay is calculated against video delay when audio delay is not negative
* Added separator and placeholder cleanup when using custom file names
* Removed avdump. VFR check is now done with MediaInfo.dll
* Updated MediaInfo.dll
* MediaInfo full media information is now in a separate window
* Update URL is now set in a DNS record
* Tested with latest MkvToolNix


Fixes:

* Custom file name chapter and cuesheets extraction errors
* Update check would not turn off
* Status bar progress should now work on Windows 10
* Extract button behavior correction when removing tracks in the left pane
* Inconsistent logging when extraction errors occured
* Other minor bug fixes

[73ChargerFan]

Thanks for the update!

[Simon88]

Windows 10 appears to flag MKVcleaver v0.6.0.8 Portable as a Trojan. I can neither extract it or access it as Windows 10 quarantines it.

[hello_hello]

Thanks for the new version!

I've deleted a fair bit of this post now as after some trial and error I think I got a clearer picture of the problem. Not what's causing it, but at least when it happens. The explanation continues in post #427.

The problem:
For quite a while I've found MKVcleaver to be fairly hit and miss when it comes to converting h264 streams to AVI.
The MKV in the log below is one I encoded using the latest x264 and muxed with the latest MKVToolNix. It's variable frame rate. This is what the log file says after extracting with MKVckeaver 0.6.0.8

Extraction started on 08/09/2016 at 11:23:04
test.mkv :
Extracting Items - video(vfr) (ok);
Converting h264 track to AVI (ok);
Done
Extraction finished on 08/09/2016 at 11:23:12

It failed to mux the h264 stream as an AVI though.

With VFR detection enabled, MKVcleavcer 0.6.0.7 automatically extracts the timecodes along with the video stream for the above file, but 0.6.0.8 does not. Neither version muxes the extracted video as an AVI. They appear to be trying though, as a "remuxing as AVI" message appears in the status bar very briefly, but nothing else happens. I assume the utility MKVcleaver uses for muxing must be silently failing.

Cheers. :)

[hello_hello]

Feature request:

Would it be possible to add a "timecodes only" option to the right pane for batch extracting?
99.9% of the time I use the right pane even when I'm only extracting streams from a single MKV, and it'd be handy if it took precedence over the timecodes option under settings. That way you could (for example) select "video" and "timecodes" in the right pane to extract both, or "video" and "timecodes only" to extract just the video timecodes etc. At the moment selecting timecodes in the right pane often requires checking the timecodes option under the Settings menu to make sure it's set correctly, which is not a major inconvenience, but not having to check would be even better.

Thanks.

[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 (http://www.videohelp.com/software/avc2avi). 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.

[filler56789]

...............

I really hope this isn't an XP thing..... although avc2avi is probably older than XP.

ONLY if you mean XP w/ Service Pack 3. XP was released in 2001 :)

[hello_hello]

Feature request(s):

Would it be possible for a future MKVcleaver to write three letter language codes to the extracted streams rather than two letter codes? I don't know about other encoder GUI's (do any muxers use two letter language codes?) but MeGUI would automatically set French as the language for this stream:
test_track2_fre_DELAY 0ms.ac3
And for this one:
test_track2_french_DELAY 0ms.ac3
For this too:
test [2] French Delay 23ms.ac3
But unfortunately not so much for this one:
test 02 FR DELAY 23ms.ac3

And while I hesitate to mention the opposition.... although MKVcleaver's batch demuxing has no peer.... I'll confess the way gMKVExtractGUI displays the delay for each MKV stream is kind of nice... and handy sometimes. ;)

[hello_hello]

ONLY if you mean XP w/ Service Pack 3. XP was released in 2001 :)

Yes I was referring to the third instalment in the XP trilogy.

[hello_hello]

I've been thinking a little about the different ways delays could be handled when extracting lately. I don't know if there's a perfect solution, but from the help file....

If Audio and Video delays are both requested and when the audio delay is positive relative to the video track then audio delay is calculated as (video delay - audio delay) and only the audio delay will be output; the video delay will be suppressed.

Should that read "calculated as (audio delay - video delay)"?
And could I ask.... what does "if audio and video delays are both requested" mean exactly? It seems obvious but....
I have a file with a 50ms video delay and a 100ms audio delay.
My custom file name setup:
[Filename]< [Track#]< [LNG]< [vDelay]< [Delay]

Extracting video on it's own - no delay written to the stream.
Audio on it's own - 50ms delay.
Together - no video delay written, 50ms audio delay.

Taking the video delay out of the file name setup:
[Filename]< [Track#]< [LNG]< [Delay]
The result is exactly the same. MKVcleaver won't write the real 100ms audio delay no matter what I do.

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

Traditionally a negative delay is written to the audio stream and it's truncated accordingly by the muxer.... under the assumption it's being muxed with a video stream that no longer has a delay (ie after re-encoding), but to my way of thinking the traditional "assume no video delay" assumption is being applied when the audio delay exceeds the video delay, but not when the video delay is greater, and it's making my head hurt..... :)

[hello_hello]

Some fresh woes when remuxing video as AVI.....

This is how MKVInfo describes the video:

| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 43 (h.264 profile: High @L4.1)
| + Default duration: 33.367ms (29.970 frames/fields per second for a video track)
| + Video track
| + Pixel width: 656
| + Pixel height: 480
| + Display width: 656
| + Display height: 480

It's constant frame rate, encoded by x264 within the last few days and muxed with MKVToolNix 9.4.2

MKVCleaver extracts the video fine and gives it a .h264 extension.
The entry from MKVCleaver's log file when using the "convert h264 track to AVI" option:

Extraction started on 09/23/2016 at 07:29:40
video.mkv :
Extracting Items - video (ok);
Codec is not V_MPEG4/ISO/AVC. Not converting to AVI
Done
Extraction finished on 09/23/2016 at 07:29:42

I tried remuxing with MKVMerge 7.8.0 to see if that'd make a difference. It did not. I tried telling MKVCleaver to use MKVToolNix 7.8.0 to see if that'd make a difference. It did not. I still don't know if this is an XP thing. I've been meaning to test using a newer version of Windows but I haven't installed one yet.

[Perenista]

This app isn't working with this MKV, too:
http://forum.doom9.org/showpost.php?p=1786481&postcount=258

It's only extracting the XML chapters. I tried selecting all audio tracks and subtitles.

P.S. It's confirmed: the reason it isn't extracting is due to the PCM 5.1 track. Read my post below:
http://forum.doom9.org/showpost.php?p=1786760&postcount=260

Why is this app also refusing to extract PCM 5.1 tracks? The rest of the tracks can be extracted fine.

[sheck]

Hmm... I see there are a lot of posts, however, I never received any notifications. I have to look into that.

[sheck]

Windows 10 appears to flag MKVcleaver v0.6.0.8 Portable as a Trojan. I can neither extract it or access it as Windows 10 quarantines it.

I can't do anything about it. Please, report it as a false positive.

But before that, make sure that the hash matches the one on my site.

[sheck]

Feature request:

Would it be possible to add a "timecodes only" option to the right pane for batch extracting?
99.9% of the time I use the right pane even when I'm only extracting streams from a single MKV, and it'd be handy if it took precedence over the timecodes option under settings. That way you could (for example) select "video" and "timecodes" in the right pane to extract both, or "video" and "timecodes only" to extract just the video timecodes etc. At the moment selecting timecodes in the right pane often requires checking the timecodes option under the Settings menu to make sure it's set correctly, which is not a major inconvenience, but not having to check would be even better.

Thanks.

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 ?

[sheck]

Feature request(s):

Would it be possible for a future MKVcleaver to write three letter language codes to the extracted streams rather than two letter codes? I don't know about other encoder GUI's (do any muxers use two letter language codes?) but MeGUI would automatically set French as the language for this stream:
test_track2_fre_DELAY 0ms.ac3
And for this one:
test_track2_french_DELAY 0ms.ac3
For this too:
test [2] French Delay 23ms.ac3
But unfortunately not so much for this one:
test 02 FR DELAY 23ms.ac3

And while I hesitate to mention the opposition.... although MKVcleaver's batch demuxing has no peer.... I'll confess the way gMKVExtractGUI displays the delay for each MKV stream is kind of nice... and handy sometimes. ;)

I will look into it. Shouldn't be a problem.

[sheck]

If Audio and Video delays are both requested and when the audio delay is positive relative to the video track then audio delay is calculated as (video delay - audio delay) and only the audio delay will be output; the video delay will be suppressed.

This means that if the user requests both delays to be written to the filename...

The way it's calculated is:

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.


Should that read "calculated as (audio delay - video delay)"?

Yes, that's correct. That's a typo on my end. It is coded correctly in the source though.


I have a file with a 50ms video delay and a 100ms audio delay.
My custom file name setup:
[Filename]< [Track#]< [LNG]< [vDelay]< [Delay]

Extracting video on it's own - no delay written to the stream.
Audio on it's own - 50ms delay.
Together - no video delay written, 50ms audio delay.
Taking the video delay out of the file name setup:
[Filename]< [Track#]< [LNG]< [Delay]
The result is exactly the same. MKVcleaver won't write the real 100ms audio delay no matter what I do.

I will look into this one. Probably an oversight on my part.

[sheck]

Some fresh woes when remuxing video as AVI.....

This is how MKVInfo describes the video:

| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 43 (h.264 profile: High @L4.1)
| + Default duration: 33.367ms (29.970 frames/fields per second for a video track)
| + Video track
| + Pixel width: 656
| + Pixel height: 480
| + Display width: 656
| + Display height: 480

It's constant frame rate, encoded by x264 within the last few days and muxed with MKVToolNix 9.4.2

MKVCleaver extracts the video fine and gives it a .h264 extension.
The entry from MKVCleaver's log file when using the "convert h264 track to AVI" option:

Extraction started on 09/23/2016 at 07:29:40
video.mkv :
Extracting Items - video (ok);
Codec is not V_MPEG4/ISO/AVC. Not converting to AVI
Done
Extraction finished on 09/23/2016 at 07:29:42

I tried remuxing with MKVMerge 7.8.0 to see if that'd make a difference. It did not. I tried telling MKVCleaver to use MKVToolNix 7.8.0 to see if that'd make a difference. It did not. I still don't know if this is an XP thing. I've been meaning to test using a newer version of Windows but I haven't installed one yet.
I will look into this one.

[sheck]

This app isn't working with this MKV, too:
http://forum.doom9.org/showpost.php?p=1786481&postcount=258

It's only extracting the XML chapters. I tried selecting all audio tracks and subtitles.

P.S. It's confirmed: the reason it isn't extracting is due to the PCM 5.1 track. Read my post below:
http://forum.doom9.org/showpost.php?p=1786760&postcount=260

Why is this app also refusing to extract PCM 5.1 tracks? The rest of the tracks can be extracted fine.

This is a question for Mosu. Looks like mkvextract.exe is not able to extract the track.

[sheck]

Feature request(s):

And while I hesitate to mention the opposition.... although MKVcleaver's batch demuxing has no peer.... I'll confess the way gMKVExtractGUI displays the delay for each MKV stream is kind of nice... and handy sometimes.


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

[sheck]

[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 (http://www.videohelp.com/software/avc2avi). 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]

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]

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]

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.

https://s23.postimg.org/c6x5o9l8r/gmkv.gif

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]

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]

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.

https://s23.postimg.org/c6x5o9l8r/gmkv.gif

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]

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]

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.

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.