MKVToolNix v24.0.0 released

[raymondjpg]

Thanks for your explanation. The mkvextract.exe warning message did indeed appear for both v9.8.0 and v9.7.1 when run with the "problem" file at the command prompt, but delivered output as required in both cases. So it looks as if the issue is with MeGUI tolerating the warning in v9.7.1, but not v9.8.0. I'll keep using v9.7.1 until MeGUI updates to tolerate v9.8.0, if indeed that happens in time.

[hubblec4]

Hi Mosu

Short question:
Are there deprecated language codes which you filter and transform, like country codes(gb,tp)?

[Mosu]

Yes, there are:

• scr → hvr
• scc → srp
• mol → rum

[arrgh]

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
 
<Tags>
 <Tag>
    <Simple>
      <Name>3d-plane</Name>
      <String>6</String>
    </Simple>
 </Tag>
</Tags>

http://www.bilder-upload.eu/show.php...1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

[raymondjpg]

Originally Posted by Mosu

The problem is really two things: your broken file and MeGUI's handling of such a situation (if my guess at what's happening is correct). The old behavior of mkvextract was just wrong; it was lying about how successful it was — it was still encountering the issue and trying to deal with it. It just wasn't signalling this to the calling process (meaning it would exit with exit code 0 even though there was a warning, which is simply wrong). The new behavior is the correct one as it gives the calling tool more information about what actually happened.

I have found that mkvextract.exe 9.8 causes MeGui to exit with an error when processing most of the mkv files in my archives. The behaviour is not just confined to the one file I posted details on, which you suggest is "broken".

As a result I have reverted to mkvextract.exe 9.7.1 which does not cause MeGui to exit with an error.

I'm sure that non-technical users would prefer a version of mkvextract.exe that works with MeGui than to know that the new behaviour of mkvextract.exe 9.8 is the correct one.

Ideally I'm sure that non-technical users would prefer to see mkvextract.exe 9.8 working well with all mkv files in MeGui.

[Mosu]

If the file structure is really broken, then exiting with a proper warning is the right course of action. It's really up to MeGUI to handle such cases by not aborting. Like I said, a warning isn't fatal, therefore MeGUI shouldn't treat it as such.

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.

[raymondjpg]

Originally Posted by Mosu

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.

Thank you!

I have uploaded the file I first had problems with, Bones S11E01.

[Mosu]

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.

[raymondjpg]

Originally Posted by Mosu

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.

Thank you for looking. I will pass the suggestion on in the MeGUI thread.

[hubblec4]

Originally Posted by Mosu

Yes, there are:

• scr → hvr
• scc → srp
• mol → rum

Many thanks for this info.

[raymondjpg]

Originally Posted by Mosu

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.

The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

Thanks again.

[arrgh]

Originally Posted by arrgh

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
 
<Tags>
 <Tag>
    <Simple>
      <Name>3d-plane</Name>
      <String>6</String>
    </Simple>
 </Tag>
</Tags>

http://www.bilder-upload.eu/show.php...1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

...takes so long to approve even a small txt...

obviously the value "6" is just an example and must be replaced by the correct individual subtitle value

[Mosu]

Originally Posted by raymondjpg

The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

That's good to hear!

[Mosu]

Originally Posted by arrgh

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

[arrgh]

Originally Posted by Mosu

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

I accept it, since I have a work-around and the other 95% do work super-good (don’t get me wrong, I’m happy!), but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

Best Regards
arrgh

[Mosu]

Originally Posted by arrgh

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

"Language", "default", "forced" all correspond to certain track header fields. "delay" and "stretch" affect the timestamp calculation. All of these things are officially supported elements of the Matroska specification.

Your "3d plane" tag is an unofficial tag that some players use to affect something. Big difference.

but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

What's lacking is manpower and people actually knowledgeable and passionate about these things. Regarding 3D video I'm neither. We (as in the Matroska team and the CELLAR working group) welcome anyone including you to join in the standardization effort that's currently underway. Work on 3D things would most likely be welcome by a lot of people, but it will only get done if people actually step up and do the work. That's how it works with Free/Libre and Open Source software.

[kuchikirukia]

Arrrrgh, it just happened again. Had a power outage and it started remuxing everything muxed since February 8th, and that was a HUUUUUGE list. Thankfully it only screwed one file and was a minor inconvenience for one other since I had to go and fix its UID.

Can we get a big "Abort Job Queue" button?

[sneaker_ger]

How does that happen? Mosu mentioned something about OS caching but February 8th ...

[kuchikirukia]

Originally Posted by sneaker_ger

How does that happen? Mosu mentioned something about OS caching but February 8th ...

Don't know. I don't even have write cache flushing disabled. I'm only using Windows 10's default write cache.

Wasn't just mkvtoolnix, either. I had another program revert a setting I had changed days earlier.
Windows 10 really needs a place to submit bug reports.

[ndjamena]

I just remuxed a recorded ts file, there's a section 50 minutes in where it looks like there were problems with the signal, the audio skips on playback and there's some minor pixelation. The ts plays back fine on MPC-HC but upon remuxing with MKVMerge the audio and video after that point in the resulting MKV goes about a second out of sync.

FFMPEG remuxes it fine and its MKV plays back without issue.

Is this expected behaviour for MKVMerge with this kind of material?