mkvtoolnix 4.1.1 released - Page 50

rack04 · 26th May 2009, 22:04

Does mkvtoolnix accept Sony wave64 audio streams?

Mosu · 26th May 2009, 22:26

No, it doesn't.

frank · 28th May 2009, 10:36

I use MKVextractGUI 1.6.4.1 to extract and save the chapterfile (OGM).

But the last working version for MKVextractGUI is MKVtoolnix v2.6.0

Something was changed with the mkv parameters.
Any solution?

System: Win XP SP3

Mosu · 28th May 2009, 10:45

mkvextractGUI is not one of my programs and I don't support it. Maybe someone else knows a solution. I will also not change mkvextract to work around problems in the GUI.

clavelm · 28th May 2009, 15:33

Quote:

Originally Posted by Mosu

* mkvmerge: new feature: Added support for reading chapters from MP4 files. Fix for bug 385.

Lot's of

for that feature, I'm remuxing all mp4 to mkv, and for mp4 with chapters, I had to demux it to ogm chapter with yamb, then add it to the mux.
It's going to be so much faster !!

mark0077 · 28th May 2009, 21:14

Hi all,

I have recently started using makemkv to convert all of my TV Show's (originally dvd's) to mkv files. I notice when playing these mkv files that the aspect ratio is wrong on very many of these files. I have two questions for you mkv experts.

1) Is makemkv known for this behaviour
2) When I remux using mkvtoolnix, the output file also plays at the incorrect aspect ratio (16:9 playing with black bars top and bottom but original disks don't show this).

Thanks guys, bit confused and annoyed now because many of my old star trek tng disks got damaged overtime and my hdd copies are now deleted since I converted to mkv. I hope theres a way to get them all back to the right aspect ratio. I am using mpc-hc and media player to playback files with haalis matroska splitter.

rack04 · 28th May 2009, 21:28

Quote:

Originally Posted by mark0077

Hi all,

I have recently started using makemkv to convert all of my TV Show's (originally dvd's) to mkv files. I notice when playing these mkv files that the aspect ratio is wrong on very many of these files. I have two questions for you mkv experts.

1) Is makemkv known for this behaviour
2) When I remux using mkvtoolnix, the output file also plays at the incorrect aspect ratio (16:9 playing with black bars top and bottom but original disks don't show this).

Thanks guys, bit confused and annoyed now because many of my old star trek tng disks got damaged overtime and my hdd copies are now deleted since I converted to mkv. I hope theres a way to get them all back to the right aspect ratio. I am using mpc-hc and media player to playback files with haalis matroska splitter.

I wonder if the header editor will allow you to change the aspect ratio. That would be the first place I would look.

mark0077 · 28th May 2009, 21:33

Quote:

Originally Posted by rack04

I wonder if the header editor will allow you to change the aspect ratio. That would be the first place I would look.

See I remuxed with aspect ratio 16:9 (it was set to "Resolution" 1024 x 576) but this didn't seem to have any effect. The new file played at the same incorrect AR. Any help would be great. I have a massive list of episodes that play all squashed... Damn you makemkv lol

rack04 · 28th May 2009, 21:40

Quote:

Originally Posted by mark0077

See I remuxed with aspect ratio 16:9 (it was set to "Resolution" 1024 x 576) but this didn't seem to have any effect. The new file played at the same incorrect AR. Any help would be great. I have a massive list of episodes that play all squashed... Damn you makemkv lol

What is the correct resolution?

mark0077 · 28th May 2009, 21:52

Well I tried setting it to 720 * 576 because ffdshow osd output shows the original disk as

Original DVD Reports
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

Converted to mkv with makemkv Reports
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 256/135, DAR: 64/27

mkvtoolnix Reports
Resolution: 1024 X 768

so to get 1024 x 576 makemkv must have multiplied the SAR by the resolution. I assume this is correct but... maybe not for DVDs. I know lots of (if not most) DVD's have both some sort of badly written aspect ratio flags and interlaced flags.

Maybe makemkv doesn't correct this as I know most video renderers do this correction automatically on DVD's without us noticing so maybe in my situation the renderer isn't recognizing a DVD and hence not doing the correction for me.

Note: I am not using ffdshow for any AR changes, resizing etc, just passing through to see OSD.

rack04 · 28th May 2009, 21:55

Quote:

Originally Posted by mark0077

Well I tried setting it to 720 * 576 because ffdshow osd output shows the original disk as

Resolution: 720 x 576, SAR: 64/45, DAR 16/9

so to get 1024 x 576 makemkv must have multiplied the SAR by the resolution. I assume this is correct but... maybe not for DVDs. I know lots of (if not most) DVD's have both some sort of badly written aspect ratio flags and interlaced flags.

Maybe makemkv doesn't correct this as I know most video renderers do this correction automatically on DVD's without us noticing so maybe in my situation the renderer isn't recognizing a DVD and hence not doing the correction for me.

Is the video format AVC? If so does the stream contain VUI parameters? Can you post a sample?

Inspector.Gadget · 28th May 2009, 21:57

1024x576 is the correct frame size for 16:9 PAL discs. They are stored on DVD as 720x576 and stretched on playback to display as 1024x576. Since this information is generally coded into the video stream itself, a remuxing app like MakeMKV shouldn't screw up the display size. When importing MPEG-2 video or a MakeMKV-created MKV containing it into mkvmerge, don't set any display size flags. If the display isn't correct in the resulting MKV, demux the video stream with MKVExtract and verify that there isn't some problem particular to it rather than the container.

Mosu · 28th May 2009, 22:00

Just a short note from myself. First, this is not a "makemkv" support thread. Please keep it on topic (the mkvtoolnix package consisting of mmg, mkvmerge, mkvinfo and mkvextract). Thanks.

Second, mkvmerge only (!) extracts the aspect ratio if the source file is not a Matroska file that already has display width/height set (e.g. if you mux from AVI or MP4 files or if you mux from a Matroska file that does NOT contain display width/height fields). This is intentional; the idea is to respect the user's wishes. If the source contains display width/height then the user wanted them set and mkvmerge should not change this automatically unless stated otherwise.

Third, yes, you can use the header editor to change/add the values for display width/height without having to remux.

mark0077 · 28th May 2009, 22:03

Quote:

Originally Posted by rack04

Is the video format AVC? If so does the stream contain VUI parameters? Can you post a sample?

Its just mpeg2 and some stereo audio. Its my first time attempting to convert some of my content to mkv (mostly to have tv show episodes appear correctly in xbmc) but I would have thought the conversion processes wouldn't do this.

Any suggestions would be fantastic. I agree, makemkv shouldn't have and probably didn't touch the original mpeg2, as converting entire DVD's took a very short amount of time.. I just wonder "who's" fault was it to have all of these episodes now playing at the incorrect AR. Ill try to see what the values of the flags are in the mpeg2 stream... if thats not too difficult :P

mkvinfo says
Pixel width: 720
Pixel height: 576
Display height: 576
Display width: 1024

which looks right. Ill try the header editor to see what changes "fix" the problem.

EDIT: Looks like a bug in ffdshow, using its internal decoders the problem happens, using mpc-hc decoder it doesn't. Thanks all, some excellent tools you have here.

Snowknight26 · 29th May 2009, 06:36

I recently remuxed an MP4 file to MKV but I noticed that whenever I played it, switching audio tracks would cause the video to stutter. As I was cutting a sample of that newly created MKV file, I noticed that mkvmerge gave me hundreds of these warnings:

Quote:

Warning: 'G:\source.mkv' track 3: 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 256ms in order not to lose any data. This may throw audio/video synchronization 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>.

The ms seemed to vary between 224ms and 256ms. I'm thinking its a bug considering what the message says, but I don't know what I files (cut if anything) I should be uploading for analysis. MP4 source? MKV remux? split MKV sample?

Mosu · 29th May 2009, 07:43

The MP4 file, but don't expect a quick fix, please.

TheFluff · 29th May 2009, 20:16

Here's a really bizarre bug (not sure if it's in mkvmerge or in something else) that I've been seeing for some time.

If you mux an ASS or SSA subtitles file to MKV with the subtitle lines not ordered by start time, and use VSFilter to render it when playing the MKV file, you get at least two bizarre effects.
1) Overlapping lines that not in start time order in the input file get a lot brighter and the alpha masking seems to break in one way or another.
2) If you use animated effects, lines that are not ordered by start time in the input file get rendered several orders of magnitude slower than they otherwise do.

These problems appear regardless of what splitter you use; I tried both Haali's splitter (latest version) and MPC-HC builtin one (Gabest's?). They only appear when the subtitle file is muxed into an MKV; they do not appear when you use the file in any other way (such as hardsubbing it on the video using VSFilter in Avisynth, or letting it autoload an external subtitles file).

Both issues magically go away if you use a subtitle editor to order lines by start time before muxing. Which is absolutely bizarre, because I know mkvmerge does the EXACT SAME THING when you mux; I even used a hex editor to confirm this (the lines ARE ordered by start time in the MKV file; of course with a marker that notes the line's original position in the input file).

I made a small example demonstrating bizarre effect #1 mentioned above, in case you need it. Can be found at http://www.mod16.org/testfiles/subtitlebork/

The question is, is this a bug in VSFilter? If so, why does it happen? It should get the lines in the correct order regardless of whether the input is sorted or not, and it doesn't happen when using an external file. Does the splitter hand it the lines differently? If so, why does it break with two different splitters? Or is it a bug in the way the subtitles are muxed to mkv?

Mosu · 29th May 2009, 20:50

Quote:

Originally Posted by TheFluff

Both issues magically go away if you use a subtitle editor to order lines by start time before muxing. Which is absolutely bizarre, because I know mkvmerge does the EXACT SAME THING when you mux; I even used a hex editor to confirm this (the lines ARE ordered by start time in the MKV file; of course with a marker that notes the line's original position in the input file).

The difference is that those markers are used by the splitters to reconstruct the original order of the entries. This may pose a problem for the splitters of filters, I don't know.

Quote:

Or is it a bug in the way the subtitles are muxed to mkv?

No. Muxing has always worked this way since subtitle support was introduced back in... Oh I don't know... 2004 or so.

Quote:

I made a small example demonstrating bizarre effect #1 mentioned above, in case you need it.

Thanks, but no thanks. I have no interest in debugging such problems in programs I have no control over.

TheFluff · 29th May 2009, 21:33

Quote:

Originally Posted by Mosu

No. Muxing has always worked this way since subtitle support was introduced back in... Oh I don't know... 2004 or so.

This bug has existed for as long as I can remember; the first time I actually remember observing it was in 2007 but it has probably been around for even longer than that. Just sayin'.

Mosu · 29th May 2009, 21:48

Well, then it's obviously the demuxer's or filter's fault. Back when we implemented subtitle support we specified the way subtitles are stored ("we" as in "the Matroska team"). mkvmerge and other muxers that handle subtitles (e.g. AVI Mux GUI) work according to specs. If the playback applications cannot handle this flawlessly then in all honesty this is not our ( = the muxer application's) fault.

Demuxers and filters are not bug-free. Just sayin'.

26th May 2009, 22:04	#981 \| Link
rack04 Registered User Join Date: Mar 2006 Posts: 1,538	Does mkvtoolnix accept Sony wave64 audio streams? Last edited by rack04; 26th May 2009 at 22:07.

26th May 2009, 22:26	#982 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	No, it doesn't. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

28th May 2009, 10:36	#983 \| Link
frank Banned Join Date: Oct 2001 Location: https://t.me/pump_upp Posts: 811	No chapters with mkvextractGUI since MKVtoolnix v2.7.0 I use MKVextractGUI 1.6.4.1 to extract and save the chapterfile (OGM). But the last working version for MKVextractGUI is MKVtoolnix v2.6.0 Something was changed with the mkv parameters. Any solution? System: Win XP SP3

28th May 2009, 10:45	#984 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	mkvextractGUI is not one of my programs and I don't support it. Maybe someone else knows a solution. I will also not change mkvextract to work around problems in the GUI. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

28th May 2009, 21:52	#990 \| Link
mark0077 Registered User Join Date: Apr 2008 Posts: 1,106	Well I tried setting it to 720 * 576 because ffdshow osd output shows the original disk as Original DVD Reports Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9 Output: SAR: 64/45, DAR: 16/9 Converted to mkv with makemkv Reports Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9 Output: SAR: 256/135, DAR: 64/27 mkvtoolnix Reports Resolution: 1024 X 768 so to get 1024 x 576 makemkv must have multiplied the SAR by the resolution. I assume this is correct but... maybe not for DVDs. I know lots of (if not most) DVD's have both some sort of badly written aspect ratio flags and interlaced flags. Maybe makemkv doesn't correct this as I know most video renderers do this correction automatically on DVD's without us noticing so maybe in my situation the renderer isn't recognizing a DVD and hence not doing the correction for me. Note: I am not using ffdshow for any AR changes, resizing etc, just passing through to see OSD. Last edited by mark0077; 28th May 2009 at 21:57.

28th May 2009, 21:14	#986 \| Link
mark0077 Registered User Join Date: Apr 2008 Posts: 1,106	Hi all, I have recently started using makemkv to convert all of my TV Show's (originally dvd's) to mkv files. I notice when playing these mkv files that the aspect ratio is wrong on very many of these files. I have two questions for you mkv experts. 1) Is makemkv known for this behaviour 2) When I remux using mkvtoolnix, the output file also plays at the incorrect aspect ratio (16:9 playing with black bars top and bottom but original disks don't show this). Thanks guys, bit confused and annoyed now because many of my old star trek tng disks got damaged overtime and my hdd copies are now deleted since I converted to mkv. I hope theres a way to get them all back to the right aspect ratio. I am using mpc-hc and media player to playback files with haalis matroska splitter.

28th May 2009, 21:57	#992 \| Link
Inspector.Gadget Registered User Join Date: May 2008 Posts: 1,618	1024x576 is the correct frame size for 16:9 PAL discs. They are stored on DVD as 720x576 and stretched on playback to display as 1024x576. Since this information is generally coded into the video stream itself, a remuxing app like MakeMKV shouldn't screw up the display size. When importing MPEG-2 video or a MakeMKV-created MKV containing it into mkvmerge, don't set any display size flags. If the display isn't correct in the resulting MKV, demux the video stream with MKVExtract and verify that there isn't some problem particular to it rather than the container.

28th May 2009, 22:00	#993 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	Just a short note from myself. First, this is not a "makemkv" support thread. Please keep it on topic (the mkvtoolnix package consisting of mmg, mkvmerge, mkvinfo and mkvextract). Thanks. Second, mkvmerge only (!) extracts the aspect ratio if the source file is not a Matroska file that already has display width/height set (e.g. if you mux from AVI or MP4 files or if you mux from a Matroska file that does NOT contain display width/height fields). This is intentional; the idea is to respect the user's wishes. If the source contains display width/height then the user wanted them set and mkvmerge should not change this automatically unless stated otherwise. Third, yes, you can use the header editor to change/add the values for display width/height without having to remux. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

29th May 2009, 07:43	#996 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	The MP4 file, but don't expect a quick fix, please. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

29th May 2009, 20:16	#997 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	Here's a really bizarre bug (not sure if it's in mkvmerge or in something else) that I've been seeing for some time. If you mux an ASS or SSA subtitles file to MKV with the subtitle lines not ordered by start time, and use VSFilter to render it when playing the MKV file, you get at least two bizarre effects. 1) Overlapping lines that not in start time order in the input file get a lot brighter and the alpha masking seems to break in one way or another. 2) If you use animated effects, lines that are not ordered by start time in the input file get rendered several orders of magnitude slower than they otherwise do. These problems appear regardless of what splitter you use; I tried both Haali's splitter (latest version) and MPC-HC builtin one (Gabest's?). They only appear when the subtitle file is muxed into an MKV; they do not appear when you use the file in any other way (such as hardsubbing it on the video using VSFilter in Avisynth, or letting it autoload an external subtitles file). Both issues magically go away if you use a subtitle editor to order lines by start time before muxing. Which is absolutely bizarre, because I know mkvmerge does the EXACT SAME THING when you mux; I even used a hex editor to confirm this (the lines ARE ordered by start time in the MKV file; of course with a marker that notes the line's original position in the input file). I made a small example demonstrating bizarre effect #1 mentioned above, in case you need it. Can be found at http://www.mod16.org/testfiles/subtitlebork/ The question is, is this a bug in VSFilter? If so, why does it happen? It should get the lines in the correct order regardless of whether the input is sorted or not, and it doesn't happen when using an external file. Does the splitter hand it the lines differently? If so, why does it break with two different splitters? Or is it a bug in the way the subtitles are muxed to mkv? Last edited by TheFluff; 29th May 2009 at 20:18.

29th May 2009, 21:48	#1000 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	Well, then it's obviously the demuxer's or filter's fault. Back when we implemented subtitle support we specified the way subtitles are stored ("we" as in "the Matroska team"). mkvmerge and other muxers that handle subtitles (e.g. AVI Mux GUI) work according to specs. If the playback applications cannot handle this flawlessly then in all honesty this is not our ( = the muxer application's) fault. Demuxers and filters are not bug-free. Just sayin'. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.