MKVToolNix v24.0.0 released

[hello_hello]

I won't add yet another option for tweaking yet another minute detail in its behavior. Each and every option increases the number of things a user has to wade through and it increases the amount of code that I have to test and maintain. Sorry.

That's okay. I'd not realised manually changing the output file name disables the automatic file name fiddling until now, so if I want MKVToolnix to stop fiddling, at least I know it can be done that way.

A different question... is there a reason why chapters aren't described very informatively in the streams list? For instance at the moment I'm looking at an MKV where the chapters are listed as "10 entries". Okay, that's enough entries for me to fairly safely guess it refers to chapters, but why isn't it labelled as such?

Also... minor GUI thing....
When you open an MKV containing chapters similar to the one I just described, you can re-order streams... except for the chapters "stream". They're an unmovable object. If there's an audio stream below the chapters in the streams list the audio stream can be moved up, but the chapters can't be moved down.

The location of the chapters in the streams list probably makes no difference to how the file is muxed (does it?) but is the lack of chapter re-ordering intentional?

Thanks.

[hello_hello]

One more question....
MKVToolNix has an option "drop last entry from imported Bluray playlists if it's near the end".

If it doesn't already (I'll confess I've not checked recently), could that option be extended to include any chapters with an entry right at the end?
I generally extract chapters from DVDs with MeGUI's chapter extractor (as a text file) and a fair proportion of them have that infuriating chapter right at the end. I'm almost in the habit of remembering to check and manually delete it before muxing if necessary, but it'd be great if MKVToolnix could do it automatically.

Thanks again.

[Mosu]

A different question... is there a reason why chapters aren't described very informatively in the streams list? For instance at the moment I'm looking at an MKV where the chapters are listed as "10 entries". Okay, that's enough entries for me to fairly safely guess it refers to chapters, but why isn't it labelled as such?

Huh? The "type" column clearly states that the entry is "chapters".

The location of the chapters in the streams list probably makes no difference to how the file is muxed (does it?) but is the lack of chapter re-ordering intentional?

It is intentional as the underlying mkvmerge does't support re-ordering of chapters. They're always processed in the order they're read from source files. Allowing the user to drag & drop such entries would most likley be confusing as it suggests a functionality that simply isn't there.

MKVToolNix has an option "drop last entry from imported Bluray playlists if it's near the end".

mkvmerge only drops the last entry from chapters read from MPLS files. Chapters read from other sources (chapter files, MP4 files, Matroska files…) aren't modified that way. Therefore the corresponding option only applies to Blu-rays, and there's no need for a change.

[hubblec4]

Hi Mosu

How close to the end must be a chapter to drop it?

@hello_hello
You could try my chapterEditor instead of MeGUI. There are few settings to ignore the last chapter.

[Mosu]

How close to the end must be a chapter to drop it?

mkvmerge will drop the last entry if it is within five seconds of the end of the duration indicated by the MPLS file the chapter is read from.

[hubblec4]

Maybe 5 seconds are too long. I had a Bluray with a "real" chapter 2,2 seconds before movie end.

The "Last chapter bug" came with DVD. I dont know exactly why there is a chapter so near the end, but in Matroska(and other containers) it is problematic to play it in MPC-HC(or other players). The player hangs or crashes. why?

[Mosu]

Because there are bugs in players. What else is new?

[hello_hello]

Huh? The "type" column clearly states that the entry is "chapters".

Ah..... that'd be the Type column I disabled almost immediately after I began using the new GUI because at the time it seemed redundant, and I even suspected it might have been mocking me a little, by taking up space and not displaying anything I couldn't learn by checking the codec column.
Except.... I now realise.... in the case of chapters. I probably should enable the Type column again. Maybe I can move it far enough over to the right to only see it when I scroll.....

Ah.... I forgot..... the columns automatically resize for each new Merge job, enabling the Type column to leap back into view. Taunted and mocked at the same time.... :)

It is intentional as the underlying mkvmerge does't support re-ordering of chapters. They're always processed in the order they're read from source files. Allowing the user to drag & drop such entries would most likley be confusing as it suggests a functionality that simply isn't there.

Fair enough if they don't need re-ordering, but my only confusion resulted from being able to move a stream above the chapters entry by dragging it up, while not being able to do the same thing by dragging the chapters entry down instead. Which I still attempt to do, maybe 50% of the time. They're just another entry in the streams list, and there's no warning sign...

mkvmerge only drops the last entry from chapters read from MPLS files. Chapters read from other sources (chapter files, MP4 files, Matroska files…) aren't modified that way. Therefore the corresponding option only applies to Blu-rays, and there's no need for a change.

Sorry but I don't follow the logic....
MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed.....

@hello_hello
You could try my chapterEditor instead of MeGUI. There are few settings to ignore the last chapter.

Cheers. I'll give it a spin.
I encoded an old TV series a few weeks back.... a DVD boxset..... and every single episode had a chapter right at the end. It would have been nice if I didn't have to manually open about 200 text files to remove the last entry from each. After about thirty I seriously considered not muxing the chapters at all this time, given there was generally only five or six per episode anyway, not including the pointless/aggravating one at the end.

The "Last chapter bug" came with DVD. I dont know exactly why there is a chapter so near the end, but in Matroska(and other containers) it is problematic to play it in MPC-HC(or other players). The player hangs or crashes. why?

I've not understood why it's there either. Maybe if I ever played an actual DVD I'd work it out.
I can't say I've had problems with the last chapter causing hangs or crashes, but I have MPC-HC configured to skip to the next file in the folder after it runs out of chapters to skip to (if I click the skip button), but when there's a chapter right at the end it stops playing instead. I've got MPC-HC configured to come out of full-screen mode when it stops.... so instead of skipping when I click "skip", that last chapter effectively results in "exit fullscreen" which just to taunt me a little more, is naturally accompanied by a distinct lack of skipping....

[hubblec4]

Sorry but I don't follow the logic....
MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed.....

Thats very simple to explain.
MTX-GUI is able to open mpls files which contain all infos about chapters, therefore is it easy to check the last chapter entry.
For all other formats the MTX-GUI have to check the chaptertimes(if chapters are present).
Unfortunately is the IFO file not supported.

@Mosu
Feature request: could you add this support for IFO files?
I'm sure you say no, but maybe in future.
DVD is a format what will slowly die out(my opinion) but there are some stuff on DVD only.
It will be great to handle vob-files like m2ts files controlled by the IFO/(mpls).
DVD-sup files are not supported? Could you add this format too?

[Mosu]

Ah.... I forgot..... the columns automatically resize for each new Merge job, enabling the Type column to leap back into view. Taunted and mocked at the same time.... :)

You can re-order the columns via drag & drop (safe for the first column which cannot be moved).

MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed....

When reading chapters from an MPLS file mkvmerge knows that those chpaters come from a Blu-ray disc and that Blu-rays often contain a single chapter entry near the end. Additionally the MPLS file contains the Blu-ray's duration (well, that title's duration). That combination forms a well-defined scenario for which dropping the last entry makes sense.

In all the other cases such information is simply not known. The chpaters in an XML file might come from a Blu-ray, from a DVD, but they might also have been created manually. Even if they come from a Blu-ray they may have been fixed manually already. Additionally there's no information about the concrete length of a title; hence there's nothing to compare the last entry's start time with.

[Mosu]

Feature request: could you add this support for IFO files?
…
DVD-sup files are not supported? Could you add this format too?

I have no intentions on adding any more features regarding DVDs. Sorry.

[hello_hello]

@Mosu
Feature request: could you add this support for IFO files?
I'm sure you say no, but maybe in future.
DVD is a format what will slowly die out(my opinion) but there are some stuff on DVD only.
It will be great to handle vob-files like m2ts files controlled by the IFO/(mpls).
DVD-sup files are not supported? Could you add this format too?

MakeMKV does all that doesn't it?

In all the other cases such information is simply not known. The chpaters in an XML file might come from a Blu-ray, from a DVD, but they might also have been created manually. Even if they come from a Blu-ray they may have been fixed manually already. Additionally there's no information about the concrete length of a title; hence there's nothing to compare the last entry's start time with.

I hadn't thought of that. Now it makes sense.

[hubblec4]

MakeMKV does all that doesn't it?

Yes it does.
But I don't like makemkv's way. All Matroska stuff should be free, and in future you must pay for makemkv.
If Mosu and other people from the Matroska team were not, there would be no Matroska.

[hello_hello]

I don't like the time limited beta idea (if it still works that way). I don't use MakeMKV often, so I install it, use it, then invariably have to do it all again for the next disc, so I'll confess I tend to exhaust all other avenues first.

[Chetwood]

All Matroska stuff should be free
Really? What about decryption?

[hubblec4]

Really? What about decryption?
Yes really, or could you imagine Mosu want money from now on.

What you mean with "about decryption"?

[qyot27]

Yes really, or could you imagine Mosu want money from now on.

What you mean with "about decryption"?
MakeMKV is a ripping program that just happens to use Matroska as the output format when doing title-based rips. Its sole purpose is disc decryption (of which only the Blu-ray ripping is time-limited, the DVD part has been stated repeatedly to remain free); it's not a Matroska muxer.

[hello_hello]

The DVD part has been stated repeatedly to remain free); it's not a Matroska muxer.


I'm sure a couple of times MakeMKV informed the time limit had expired and a new version was required, or was it the temporary license key has to be replaced? I have a memory of both.
I know it's always been said DVD ripping will remain free, but it's not mutually exclusive with time-limiting, as long as the replacement versions always include free DVD ripping capabilities.
Have I remembered it wrong, or has something changed?

[qyot27]

I'm sure a couple of times MakeMKV informed the time limit had expired and a new version was required, or was it the temporary license key has to be replaced? I have a memory of both.
I know it's always been said DVD ripping will remain free, but it's not mutually exclusive with time-limiting, as long as the replacement versions always include free DVD ripping capabilities.
Have I remembered it wrong, or has something changed?
I don't really know, I seem to remember still being able to use DVD functionality after a license expiration a while back, but that could have regressed in later versions.

Not that it really matters in the end: DVD ripping programs are a dime a dozen, including the FOSS ones.

[Mosu]

Somewhat unscheduled I'm releasing v9.4.1. It fixes several errors in mkvmerge, most of which are exploitable via specially crafted file. They were found by fuzzing done by Justin Smith.

Nothing's been changed regarding the packagin since v9.4.0.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.0:

2016-09-11 Moritz Bunkus <moritz@bunkus.org>
* Released v9.4.1 "Black Rain".

2016-09-07 Moritz Bunkus <moritz@bunkus.org>
* Note: most of the bugs fixed on 2016-09-06 and 2016-09-07 for issue #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780) are potentially exploitable. The scenario is arbitrary code execution with specially-crafted files. Updating is highly recommended.
* mkvmerge: bug fix: AVC & HEVC readers: the readers will now refuse to handle files where the detected pixel width or height is equal to or less than 0. Before this fix the muxing process aborted with an assertion inside libMatroska. Fixes the last test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of allocated space). Fixes two test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of a fixed-size array). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: an error message will be printed instead of an uncaught exception when an invalid atom chunk size is encountered during resync. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: AAC reader: fixed mkvmerge throwing an uncaught exception due to the sample rate being 0. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: fixed an invalid memory access (use after free) during global destruction phase. Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: using very large --sync values (several minutes) with certain container formats was causing mkvmerge to abort muxing. Fixes #1774 (https://github.com/mbunkus/mkvtoolnix/issues/1774).


Have fun :)

[Jamaika]

It's don't work. I can't import file HEVC.
for %%f in ("%~dp1*.h265") do mkvmerge %%f --disable-track-statistics-tags -o %%~nf.mkv
Error: The file 'x265_v2.0+24_crf08_aqmode0_threads1_hightier.h265' has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly.
mkvmerge --list-types
HEVC/h.265 elementary streams [265 hevc h265 x265]:(

[Mosu]

Please upload such a file to my FTP server.

[Jamaika]

https://www.sendspace.com/file/6bvdow

[Mosu]

Thanks. I'll take a look.

[Mosu]

I'm currently testing a fix. If that plays nicely with my test suite then I'll prepare release v9.4.2 afterwards.

[Mosu]

Unfortunately the just-released v9.4.2 contained a nasty regression in both the AVC and HEVC readers. I'm therefore releasing v9.4.2 mere hours after v9.4.1. The only difference is the fix to the aforementioned regression. I'm including the whole announcement for v9.4.1 below.

Somewhat unscheduled I'm releasing v9.4.1. It fixes several errors in mkvmerge, most of which are exploitable via specially crafted file. They were found by fuzzing done by Justin Smith.

Nothing's been changed regarding the packagin since v9.4.0.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.0:

2016-09-11 Moritz Bunkus <moritz@bunkus.org>
* Released v9.4.2 "So High".
* mkvmerge: bug fix: AVC & HEVC readers: release v9.4.1 contains a change to both readers so that they will refuse to handle files where the detected pixel width or height is equal to or less than 0. This check was wrong in certain cases causing mkvmerge to reject a file as an unsupported file type. This has been fixed while keeping the constraints on width & height having to be positive.
* Released v9.4.1 "Black Rain".

2016-09-07 Moritz Bunkus <moritz@bunkus.org>
* Note: most of the bugs fixed on 2016-09-06 and 2016-09-07 for issue #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780) are potentially exploitable. The scenario is arbitrary code execution with specially-crafted files. Updating is highly recommended.
* mkvmerge: bug fix: AVC & HEVC readers: the readers will now refuse to handle files where the detected pixel width or height is equal to or less than 0. Before this fix the muxing process aborted with an assertion inside libMatroska. Fixes the last test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of allocated space). Fixes two test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of a fixed-size array). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: an error message will be printed instead of an uncaught exception when an invalid atom chunk size is encountered during resync. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: AAC reader: fixed mkvmerge throwing an uncaught exception due to the sample rate being 0. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: fixed an invalid memory access (use after free) during global destruction phase. Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: using very large --sync values (several minutes) with certain container formats was causing mkvmerge to abort muxing. Fixes #1774 (https://github.com/mbunkus/mkvtoolnix/issues/1774).

Have fun :)

[Jamaika]

:thanks:

[Mosu]

You're welcome, and thanks for the quick feedback & the sample file.

[Ripman]

Thanks for the new 9.4.0 release.

I'll check that DTS sampling issue within the next few days.

I checked a DTSHDMA audio track @ 192khz with mkvtoolnix 9.4.0.

The tests I conducted were clean; it works fine, as does the previous flac method I suggested. Here is the GitHub link: https://github.com/mbunkus/mkvtoolnix/issues/1762

Here are the logs from the successful mux with DTSHDMA@192khz.

https://www.dropbox.com/s/sz3nnak52yjkm3d/08.3_mmg_logs---DTSHD_sampling_results---OK%20%289.4.0%29.zip?dl=1

(I realize you did a .1 and .2 release.)

[Ripman]

2016-07-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the automatic adjustments to the output file name based on the track types selected for muxing and the mechanism for keeping output file names unique had been broken since release v9.3.0. Fixes #1743.


I still see "my version" of this (1761); I put a comment in there too. I originally reported this because it was different behavior than the old mmg. https://github.com/mbunkus/mkvtoolnix/issues/1761

pic from 9.4.0:
https://www.dropbox.com/s/uiiy9e1iv7kyh7l/10b_mmg_notes---no_vid_mkv%20%289.4.0%29.gif?dl=0

[Mosu]

That behavior is intentional. As soon as the user changes the output file name from the default suggestion the GUI will stop messing around with it. I have no intentions of changing this.

[Ripman]

That behavior is intentional. As soon as the user changes the output file name from the default suggestion the GUI will stop messing around with it. I have no intentions of changing this.

Thanks. I see how it works now - de-select the video, then change the file name. Very good.

Tbh - I thought the functionality in the old Mmg was to prevent users from generating an mkv file without a video track. The new MKVToolnix allows an mkv to be created without a video track and I think you are saying that is by design.

[Mosu]

I'm saying that I don't think that the program always knows better than the user. The program will do stuff automatically, but as soon as the user says "I know better than this bloody device!" (by manually changing the name) the GUI will take the hint and stop messing with it.

The intention has never been to prevent the user from doing something. It has always been to make the common cases easy and fast to achieve. Do the right thing by default, but don't impose your will on the user.

[Ripman]

Thanks for clarifying. I'm usually a command line user, but when you released the new MKVToolnix around 8/8.1 I figured I should help identify "things" in the new gui until everything was stabilized. The new gui is much easier on the eyes tbh.

I'll probably volunteer to do some documentation for you in later q4 -- wish I had more time to help with code/docs/etc.

[VincAlastor]

mkvtoolnix 9.4.x and opus audio frame size 60ms

Since mkvtoolnix version 9.4.x i can't merge mkv files with opus audio streams which have a larger frame size than standard 20ms. Well i normally use the full value of 60ms. I'm confused why mkvtoolnix have a problem with this opus encoder parameter?!?!

[Mosu]

I've just fixed that particular issue. New pre-builds for WIndows (https://mkvtoolnix.download/windows/pre/) that include the fix are available.

[manolito]

Currently I am converting my huge DVD collection to AVC / AAC in an MKV container using MakeMKV and StaxRip. In about every 1 in 50 source files I get a H264 video stream which MKVMerge refuses to recognize.

Here is such a H264 file:
https://we.tl/LrTHNPzcJs

I tried MKVToolNix versions 6.30, 7.80 and 9.42, and they all behave the same. I used X264 r2334 which comes with StaxRip 1.1.90.

The H264 file plays in all my player software, and MP4Box has no problems creating an MP4 file from it. So I believe that MKVMerge is to blame for this issue.

Any thoughts?


Cheers
manolito

[sneaker_ger]

Does this always happen with the same source files? My encodes with new and same x264 differ from yours in the first bytes. I encoded with the x264 included in StaxRip 1.9.0 (direct to raw ES, not mkv/mp4 and then demux). I don't want to keep Mosu from fixing this but maybe you have a hardware error on your hands that's corrupting your files. If you are not directly encoding to raw ES it would be interesting to see what muxer and demuxer steps you used.

[manolito]

Yes, it always happens with the same source files. So far I could not see any pattern to predict if a source file will have this issue.

I don't believe that it is a hardware glitch because it is reproduceable for the same file.

I use the X264 version which ships with StaxRip 1.1.9.0. My workflow is like this:

Convert the source DVD structure to MKV using the current version 1.10.2 of MakeMKV. I then feed this MKV to StaxRip specifying an MKV output file. StaxRip first demuxes the source MKV with MKVExtract, then transcodes audio, then converts the MPEG video to raw H264, and as the last step it muxes the converted streams using MKVMerge. My AviSynth source filter is DSS2Mod, but I tried ffms2 also and got the same result.

With a problematic source the converted raw H264 video cannot be opened by MKVMerge so I end up with a muxed MKV which only contains audio and chapters.

I can save the result using the elementary streams from the StaxRip temp folder. I fire up YAMB, import the video and audio streams and let it create an MP4 file. This MP4 is accepted by MKVMerge just fine, so I only need to import the chapter XML file and mux to MKV.


Cheers
manolito

[SeeMoreDigital]

I fire up YAMB, import the video and audio streams and let it create an MP4 file. This MP4 is accepted by MKVMerge just fine, so I only need to import the chapter XML file and mux to MKV. Just-so-you-know... TSmuxerGUI 2.6.12 also accepts your source ;)

[sneaker_ger]

That's very peculiar.

Anyways, I overlooked some headers and now I get the same bytes at the start and the same error. This also happens with recent x264. Interestingly it triggers only with at least 128 frames. I don't know if that is a coincidence or if it matters (with 128 being a power of 2). :confused:

https://www.sendspace.com/file/5cpeb5

[Mosu]

Hey,

Currently I am converting my huge DVD collection to AVC / AAC in an MKV container using MakeMKV and StaxRip. In about every 1 in 50 source files I get a H264 video stream which MKVMerge refuses to recognize.

and

Anyways, I overlooked some headers and now I get the same bytes at the start and the same error.

Thanks for the report & the sample files. mkvmerge was wrongfully detecting those files to be MPEG transport streams. I've made that detection code more strict, and now both of your sample files are recognized as h.264 elementary streams again.

New pre-builds with the fix included are available from the usual location (https://mkvtoolnix.download/windows/pre/).

[manolito]

:thanks:

[nautilus7]

Hi, what's the current support state of pcm audio muxing?

I am trying to mux a mpls blu-ray playlist directly to mkv. The playlist contains a pcm audio stream (24bit, 48KHz, mono channel). The resulting mkv file plays at half speed when the pcm audio is selected. The audio is correctly detected by lav splitter and sound is heard, but at half the speed (both audio and video at half speed). On the contrary, if I select the other audio stream (dts audio), the mkv file is played correctly at normal speed, despite the pcm being present inside the mkv container.

[Mosu]

It should work, but it obviously doesn't properly. Can you provide a sample file (the source .M2TS) for this, please? The first 200 MB or so should suffice. See my signature where to upload it. Thanks.

[nautilus7]

Currently uploading, but it would take about 1 hour, due to my slow adsl connection.

Unencrypted ftp didn't work, so I used the secured connection.

[Mosu]

Don't worry about it, I'm at work anyway and don't have time to look into it right now.

[nautilus7]

Done uploading.

File is in "upload" folder, name "sample_pcm_nautilus7.m2ts". Thanks!

[Mosu]

Thanks. I will probably not get around to looking into it until the weekend.

[Mosu]

File is in "upload" folder, name "sample_pcm_nautilus7.m2ts". Thanks!

I've fixed the problem which only affected PCM tracks with an odd number of channels (https://github.com/mbunkus/mkvtoolnix/commit/2cac968f958e5c1b3c6fe9a4e84ecc7ddc036d0b). New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.