MKVToolNix v24.0.0 released

[sneaker_ger]

I don't have XP to test it but wasn't XP compatibility restored in version 8.0.0?

[Groucho2004]

Since I am stuck with version 0.7.80 (I'm still using XP), would you consider publishing your tool?

So far I have been using a software called MKV Chapterizer for this task, but it is not always reliable.

Cheers
manolito
mkvmerge v9 works fine on XP32SP3.

[Groucho2004]

The issue with the chapter generation should be fixed in pre-builds 01163 and higher (https://mkvtoolnix.download/windows/pre/).
Confirmed. Thanks for the fix.

[manolito]

mkvmerge v9 works fine on XP32SP3.

Oops, after these posts
http://forum.doom9.org/showthread.php?p=1721140#post1721140
http://forum.doom9.org/showthread.php?p=1721161#post1721161
http://forum.doom9.org/showthread.php?p=1721792#post1721792

where Mosu confirmed that v 7.80 would be the last version to work under XP I did not follow this thread any longer. Also because v 7.80 does everything I need, and I also got used to the old GUI over time.

Just checked v.9, and it really does work under XP, even with my non-SSE2 CPU. Great, thanks a lot Mosu...

Now I just have to get used to the new GUI, lots of new things to discover.
Quick question: Still no message or chime after a merging job has finished? At least I could not find it after a few minutes.


Cheers
manolito

[sneaker_ger]

There is no feature specifically for playing sounds but you can achieve it via the "executing programs" feature. (at the very bottom of the settings list)
https://github.com/mbunkus/mkvtoolnix/issues/1570#issuecomment-170256692

[manolito]

Thanks...

[Mosu]

Hey,

Due to two nasty bugs in v9.0.0 I've decided to release a hotfix with v9.0.1 today. The first bug is a regression from v8.9.0 in the code handling character sets for text subtitle files. The other bug is in the new code for generating chapters automatically.

As the prior release v9.0.0 is only two days old I'm including v9.0.0's full release announcement here:

Here's another release of MKVToolNix. There were tons of bug fixes all over the place. The most important one is probably in the HEVC handler which won't drop certain SEI NALUs anymore. This was a regression introduced in v8.7.0.

A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed.

One of the new features is mkvmerge's capability to generate chapters automatically whenever a new file is appended. Additionally it can also generate chapters in fixed intervals. This can be turned on in the GUI, of course.

There's one change for package maintainers: a Korean translation of the programs and the man pages has been added.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer and portable version (http://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 v8.9.0:

2016-03-28 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.1 "Obstacles".
* mkvmerge: bug fix: regression in v9.0.0: the text subtitle packetizer was wrongfully assuming an encoding of UTF-8 if none was given instead of assuming the system's encoding. Fixes #1639 (https://github.com/mbunkus/mkvtoolnix/issues/1639).

2016-03-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: if too many chapters had been generated with --generate-chapters then mkvmerge created a bogus entry in the meta seek element and did not actually write the chapters to the file.
* mkvmerge: bug fix: the DTS packetizer was setting the number of channels wrong sometimes when reducing to the DTS core. It was using the number of channels including the extensions instead of the channels of the core only.

2016-03-26 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.0 "Power to progress".

2016-03-25 Mike <kona8lend@gmail.com>
* build system: implemented support for explicit pre-compiled headers for Linux and Mac OS.

2016-03-25 Moritz Bunkus <moritz@bunkus.org>
* Installer: fixed support for silent installation and uninstallation.

2016-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two more issues in the conversion of teletext subtitles to SRT subtitles: 1. Packets belonging to pages that don't contain subtitles were used as valid end points for subtitles causing entries to become very short (e.g. 40ms). 2. Sometimes the timestamps of wrong packets were used as entry's start and end points causing start timestamps and durations that were slightly off. Second part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4/QuickTime reader: audio tracks with the FourCC 'lpcm' are muxed as A_PCM/INT/LIT instead of A_QUICKTIME.
* mkvmerge: bug fix: MP4/QuickTime reader: audio tracks can contain two instances of certain header fields (channel count, bits/sample & channel, sample rate) in the STSD atom: one instance in the version 0 header and one in the version 2 header parts. So far mkvmerge has used those from the version 0 header only and ignored the ones from the version 2 header. This has been changed to match the behavior of other players and MP4 readers like ffmpeg. If the STSD atom contains a version 2 structure then the fields from it will be used. Otherwise the fields from the version 0 part will be used. Fixes #1633 (https://github.com/mbunkus/mkvtoolnix/issues/1633).

2016-03-21 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation of both the programs and the man pages to Korean by Potato (see AUTHORS).
* MKVToolNix GUI: chapter editor enhancement: added a button next to the 'segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the input field.

2016-03-20 Moritz Bunkus <moritz@bunkus.org>
* build system: added an option to configure »--without-qt-pkg-config«. Normally configure uses pkg-config for detecting Qt and setting QT_CFLAGS and QT_LIBS. With this option configure won't use pkg-config and rely on the user having set both variables before running configure. This enables using Qt on systems where no pkg-config files are generated (e.g. Qt 5.6.0 on MacOS with frameworks enabled).

2016-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: change: on Windows and Mac OS mkvinfo will now launch the GUI by default unless the option »--no-gui« (or »-G«) has been given. This is due to the fact that on both OS users often use portable versions respectively disk images and launch the executable directly and not via start menu entries. In those situations adding command line options for launching the GUI is unnecessarily difficult.

2016-03-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues in the conversion of teletext subtitles to SRT subtitles: 1. Consecutive teletext packets with the same content are now merged into a single entry instead of resulting in multiple entries. 2. The calculation of a packet's duration was wrong in certain situations. Part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: the playlist items are sorted by their position within the playlist by default.
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: double-clicking on a playlist will select and add that playlist.

2016-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the number of bits per sample to the verbose/JSON identification output for FLAC files.

2016-03-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: fixed the duplication of VPS, SPS, PPS and SEI NALUs when extracting h.265/HEVC tracks. See #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) and #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).
* mkvmerge: bug fix: reverted the patch by Vladimír Pilný that made the h.265/HEVC not store SEI NALUs with the frames during muxing. It was supposed to prevent having the SEI NALUs present twice when extracting HEVC due to some SEI information also being stored in the codec private data, but it dropped a lot of other SEI NALUs irrevocably. Fixes #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).

2016-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the --sub-charset option is now ignored for text subtitle files that start with a byte-order mark (BOM) bringing the behavior in line with the documentation. Fixes #1620 (https://github.com/mbunkus/mkvtoolnix/issues/1620).

2016-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: implemented the extraction of Big Endian PCM (codec ID A_PCM/INT/BIG) to WAV files. The content will be byte-swapped into Little Endian PCM in the process.
* mkvmerge: enhancement: Big Endian PCM tracks will now be byte-swapped into Little Endian PCM, and the codec ID A_PCM/INT/LIT will be used. This was done due to a lot of players not supporting Big Endian PCM inside Matroska.

2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586 (https://github.com/mbunkus/mkvtoolnix/issues/1586).

2016-02-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue enhancement: completed jobs will now be removed from the queue automatically on exit if the job has been added more than 14 days ago in order not to let the queue grow arbitrarily large. This feature can be turned off and the number of days can be adjusted in the preferences.

2016-02-27 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: bug fix: fixed the handling of files where the last level 1 element has an unknown size. The programs will now either fix this element to have a known size or abort the process with an appropriate error message but without modifying the file. Fixes #1601 (https://github.com/mbunkus/mkvtoolnix/issues/1601).

2016-02-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: when extracting chapters in the simple format the user can use the new option »--simple-language …« for selecting the chapter names that are output. Normally the first chapter name found in each atom is used. With this option mkvextract looks for a chapter name whose language matches the specified one. Implements the feature enhancement part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).
* mkvextract: several issues regarding the extraction of chapters in the simple format have been fixed: if multiple names with different languages were present then an entry had been written for each name; the total number of entries written was wrong; the wrong entries were written. The new code only writes the first name found from the top-most chapter atoms of all editions. Chapters flagged as hidden or as not enabled are not extracted at all. Fixes the bug part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).

2016-02-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: added an option to multiply all chapter timecodes by a factor to the "additional modifications" dialog. Implements #1609 (https://github.com/mbunkus/mkvtoolnix/issues/1609).

Have fun :)

[AYColumbia]

Thank you Mosu for the continued updates. Not crazy about the change below though as it'll require changing all my batch files, but thanks for providing the no GUI option.
... A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed. ...
I just did a test run with --no-gui and works great. Thanks again.

[Mosu]

AYColumbia: what exactly are you using mkvinfo in batch files for? mkvinfo's output is NOT designed to be parsed; e.g. attachments located at the back are not listed by default. Instead mkvmerge's identification output (e.g. "mkvmerge --identification-format json --identify yourfile.mkv") is and is the preferred way. It's also the only supported way to get the track IDs for mkvmerge and mkvextract.

[AYColumbia]

AYColumbia: what exactly are you using mkvinfo in batch files for? mkvinfo's output is NOT designed to be parsed; e.g. attachments located at the back are not listed by default. Instead mkvmerge's identification output (e.g. "mkvmerge --identification-format json --identify yourfile.mkv") is and is the preferred way. It's also the only supported way to get the track IDs for mkvmerge and mkvextract.
Oh wow. I didn't even know that mkvmerge had that option. Very useful and it's essentially why I'm using mkvinfo, i.e., I dump output to a file, parse though it to find number tracks, which are video, audio, subtitles, chapters, etc.

Thank you for the info on the JSON info which I will be looking into to see about updating my processes to use this instead.

[hubblec4]

Hi Mosu

The entry "ChapterSegmentEditionUID" is this the same like "ChapterSegmentUID"?
Also when I use the CSE-UID instead of the CS-UID, play then a complete edition of the file as segment?

[Mosu]

The intention is to use both together. You use ChapterSegmentUID to tell the player which segment to play and you can refine that selection by telling it to only play a certain chapter edition with the ChapterSegmentEditionUID. Obviously the edition referred to with ChapterSegmentEditionUID must be part of the segment referred to with ChapterSegmentUID.

I don't understand your second question, though, it doesn't make much sense to me yet.

[hubblec4]

The intention is to use both together. You use ChapterSegmentUID to tell the player which segment to play and you can refine that selection by telling it to only play a certain chapter edition with the ChapterSegmentEditionUID. Obviously the edition referred to with ChapterSegmentEditionUID must be part of the segment referred to with ChapterSegmentUID.
Ok that's clear.

I don't understand your second question, though, it doesn't make much sense to me yet.

(I had even just think about it again.)

A Segment means another file, identified by the SegmentID.
Chapter-Segment-Linking works only with ordered chapters.

When I use chapter segment linking, then from a
another file a video part played. The duration of the video part is determined by the start and end times in the chapter.

So far so good.

An edition has multiple chapters, will all these played when I specify a ChapterSegementEditionUID?
What is with the timestamps in the chapter where the linking is set? Will these ignored?

[Mosu]

Note that I wasn't involved in speccing the ordered chapter stuff, that was all Steve Lhomme, and I haven't used ordered chapters myself. Therefore I cannot really answer this with authority. I would guess that if an edition is referenced via ChapterSegmentEditionUID that all chapters in said edition will be played in the order given by their start timestamps. I don't know how timestamps in the link sources will be handled though for the aforementioned reasons.

[hubblec4]

Note that I wasn't involved in speccing the ordered chapter stuff, that was all Steve Lhomme, ....
But you're the only one who is so easy to reach and always responds. Thanks a lot.

[Ex0rcist]

MKVExtractGUI doesn't work anymore with MKVToolNix since version 9. It must be something related to "mkvinfo.exe".

[Mosu]

See here (https://github.com/mbunkus/mkvtoolnix/issues/1636).

[hubblec4]

MKVExtractGUI doesn't work anymore with MKVToolNix since version 9. It must be something related to "mkvinfo.exe".

No, I'm sorry. As I've said before changing the existing format is a recipe for breaking other people's tools.

A bit confusing...
Ok, the format has not changed, but the result is the same.
Breaking other tools.

[Mosu]

True, of course. But in this case usability for a LOT of Windows and Mac users trumps keeping backwards compatibility. Changing the output format, on the other hand, only benefits a small number of users while potentially breaking a number of parsers. I haven't done this on a whim. Over time I've received quite a lot of mails by people using the portable version of the Mac OS DMG who were confused that they couldn't start mkvinfo's GUI.

[LeXXuz]

I've remuxed a couple of Matroska files with the latest version.
I noticed the usual "Encoder Settings" information of x264 encoded video tracks is gone.

At least MediaInfo does not show them any more. Have there been some changes to this lately?

[Mosu]

No changes come to mind.

[Mosu]

Additionally I cannot reproduce this:

[0 mosu@sweet-chili ~/prog/video/data] x264 --crf 24 -o before-remux.264 v.avi
…
encoded 1672 frames, 257.41 fps, 288.88 kb/s
[0 mosu@sweet-chili ~/prog/video/data] mediainfo before-remux.264
…
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v.mkv before-remux.264
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo v.mkv
…
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v2.mkv v.mkv
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo v2.mkv
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvextract tracks v2.mkv 0:after-remux-and-extraction.264
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo after-remux-and-extraction.264
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] x264 --version
x264 0.148.2643 5c65704
(libswscale 4.0.100)
(libavformat 57.25.100)
built on Feb 15 2016, gcc: 5.3.0
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: GPL version 3 or later
[0 mosu@sweet-chili ~/prog/video/data] mediainfo --version
MediaInfo Command line,
MediaInfoLib - v0.7.84
[255 mosu@sweet-chili ~/prog/video/data] mkvmerge --version
mkvmerge v9.0.1 ('Obstacles') 64bit

[sneaker_ger]

I can't reproduce either.
Note: the x264 settings are stored at the beginning of the encode. If you split it into several parts only the very first part will have them. (if you use split parts to skip the beginning none will)

[sl1pkn07]

split mkv/mka (using mkvmerge) with concatenate timecodes gets intermediate files with 6 or more Kb of size (useless)


┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ mkvmerge -o split.avs.mka.split.mka --sync 0:0 audio_2.0.ac3 --split timecodes:00:00:05.005,00:00:05.005,00:11:11.838,00:11:11.838,00:12:25.612,00:12:25.612,00:23:47.059,00:23:47.059,00:34:34.039,00:34:34.039,00:45:16.914,00:45:16.914,00:58:34.544,00:58:34.544,01:09:44.147,01:09:44.147,01:20:38.667,01:20:38.667,01:31:42.864,01:31:42.864,01:41:48.402,01:41:48.402,01:56:42.162
mkvmerge v9.0.1 ('Obstacles') 64bit
'audio_2.0.ac3': Usando el desmultiplexador para el formato 'AC-3'.
'audio_2.0.ac3' pista 0: Usando el módulo de salida para el formato 'AC-3'.
El archivo split.avs.mka.split-001.mka ha sido abierto para su escritura.
Progreso: 0%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-002.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-003.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-004.mka ha sido abierto para su escritura.
Progreso: 9%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-005.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-006.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-007.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-008.mka ha sido abierto para su escritura.
Progreso: 20%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-009.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-010.mka ha sido abierto para su escritura.
Progreso: 29%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-011.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-012.mka ha sido abierto para su escritura.
Progreso: 38%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-013.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-014.mka ha sido abierto para su escritura.
Progreso: 49%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-015.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-016.mka ha sido abierto para su escritura.
Progreso: 59%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-017.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-018.mka ha sido abierto para su escritura.
Progreso: 68%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-019.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-020.mka ha sido abierto para su escritura.
Progreso: 77%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-021.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-022.mka ha sido abierto para su escritura.
Progreso: 86%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-023.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-024.mka ha sido abierto para su escritura.
Progreso: 100%
Los registros del cue (el índice) están siendo escritos...
El multiplexado tardó 7 segundos.
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ ls *mka -h
-rw-r--r-- 1 sl1pkn07 users 399K abr 4 20:57 split.avs.mka.split-001.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-002.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 20:57 split.avs.mka.split-003.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-004.mka
-rw-r--r-- 1 sl1pkn07 users 5,7M abr 4 20:57 split.avs.mka.split-005.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-006.mka
-rw-r--r-- 1 sl1pkn07 users 53M abr 4 20:57 split.avs.mka.split-007.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-008.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-009.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-010.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-011.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-012.mka
-rw-r--r-- 1 sl1pkn07 users 61M abr 4 20:57 split.avs.mka.split-013.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-014.mka
-rw-r--r-- 1 sl1pkn07 users 52M abr 4 20:57 split.avs.mka.split-015.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-016.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-017.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-018.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 20:57 split.avs.mka.split-019.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-020.mka
-rw-r--r-- 1 sl1pkn07 users 47M abr 4 20:57 split.avs.mka.split-021.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-022.mka
-rw-r--r-- 1 sl1pkn07 users 69M abr 4 20:57 split.avs.mka.split-023.mka
-rw-r--r-- 1 sl1pkn07 users 5,8M abr 4 20:57 split.avs.mka.split-024.mka

[Mosu]

"00:00:05.005,00:00:05.005,00:11:11.838,00…" means:

Start the first file at 00:00:00.000
Start the second file at 00:00:05.005 or the first key frame afterwards
Start the third file at 00:00:05.005 or the first key frame afterwards, too

This doesn't make sense. You're probably looking for "splitting by parts".

[sl1pkn07]

is generated by split_aud perl script http://mod16.org/hurfdurf/?p=33

edit: the trim line:
Trim(0,149)++Trim(150,20134)++Trim(20135,22345)++Trim(22346,42768)++Trim(42769,62158)++Trim(62159,81425)++Trim(81426,105330)++Trim(105331,125398)++Trim(125399,145014)++Trim(145015,164920)++Trim(164921,183068)++Trim(183069,209854)

[Mosu]

Yeah, well, that's not really my problem. Sorry. You're feeding mkvmerge somewhat useless parameters. No wonder the results are what they are. If you're having trouble with that Perl script then please contact the script's author.

[sl1pkn07]

@TheFluff, i summon you!

[TheFluff]

I haven't maintained that garbage since like 2010, fix it yourself or take a look at vfr.py

e: but just by taking a cursory glance at your trim line I can already tell you that your problem is that your first trim statement is useless, try removing it and replacing 150 in the second statement with 0, split_aud.pl isn't smart enough to figure out that there's a continuity there

[sl1pkn07]

ok. thanks

[TheFluff]

see edit, some of your trim statements are redundant (i.e. trim(0,149)+trim(150,0) is a no-op) and split_aud.pl won't figure that out for you

[sl1pkn07]

The trim line is generated by avspmod, chapters file (from BD, edited for remove some unused ones) and "bookmarks from chapter.py/qpfile from bookmarks.py" avspmod plugins, not by hand.

and yea. only the first trim (0,149) is redundant, the others trims is because is a "big file" m2ts with all episodes concatenated one each other

[sl1pkn07]

if remove the first trim the output is different (less generated files). but have the same issue:


└───╼ perl split_aud.pl -v -i audio_2.0.ac3 trims.avs
Executing: mkvmerge -o trims.avs.mka.split.mka --sync 0:0 audio_2.0.ac3 --split timecodes:00:00:05.005,00:11:11.838,00:11:11.838,00:12:25.612,00:12:25.612,00:23:47.059,00:23:47.059,00:34:34.039,00:34:34.039,00:45:16.914,00:45:16.914,00:58:34.544,00:58:34.544,01:09:44.147,01:09:44.147,01:20:38.667,01:20:38.667,01:31:42.864,01:31:42.864,01:41:48.402,01:41:48.402,01:56:42.162

mkvmerge v9.0.1 ('Obstacles') 64bit
'audio_2.0.ac3': Usando el desmultiplexador para el formato 'AC-3'.
'audio_2.0.ac3' pista 0: Usando el módulo de salida para el formato 'AC-3'.
El archivo trims.avs.mka.split-001.mka ha sido abierto para su escritura.
Progreso: 0%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-002.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-003.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-004.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-005.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-006.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-007.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-008.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-009.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-010.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-011.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-012.mka ha sido abierto para su escritura.
Progreso: 40%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-013.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-014.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-015.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-016.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-017.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-018.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-019.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-020.mka ha sido abierto para su escritura.
Progreso: 81%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-021.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-022.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-023.mka ha sido abierto para su escritura.
Progreso: 100%
Los registros del cue (el índice) están siendo escritos...
El multiplexado tardó 1 segundo.
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ ls -h *mka
-rw-r--r-- 1 sl1pkn07 users 399K abr 4 22:15 trims.avs.mka.split-001.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 22:15 trims.avs.mka.split-002.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-003.mka
-rw-r--r-- 1 sl1pkn07 users 5,7M abr 4 22:15 trims.avs.mka.split-004.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-005.mka
-rw-r--r-- 1 sl1pkn07 users 53M abr 4 22:15 trims.avs.mka.split-006.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-007.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-008.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-009.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-010.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-011.mka
-rw-r--r-- 1 sl1pkn07 users 61M abr 4 22:15 trims.avs.mka.split-012.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-013.mka
-rw-r--r-- 1 sl1pkn07 users 52M abr 4 22:15 trims.avs.mka.split-014.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-015.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-016.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-017.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 22:15 trims.avs.mka.split-018.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-019.mka
-rw-r--r-- 1 sl1pkn07 users 47M abr 4 22:15 trims.avs.mka.split-020.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-021.mka
-rw-r--r-- 1 sl1pkn07 users 69M abr 4 22:15 trims.avs.mka.split-022.mka
-rw-r--r-- 1 sl1pkn07 users 5,8M abr 4 22:15 trims.avs.mka.split-023.mka


with vfr.py script (wiiaboo git) generate a big file instead of multiple files

[Mosu]

You're still using the script wrong, I guess, as it still spits out the same split points multiple times: …00:11:11.838,00:11:11.838,00…

Now can we please stop this about that script? This is the MKVToolNix support thread. If you're having trouble with using those scripts then create a new thread for it or discuss it elsewhere. Thanks.

[sl1pkn07]

with accient version of mkvtoolnix (<8.4.x, not remember exactly) that script work without this "issue"

and yes, i now stop talk about this "regression(?)"

greetings

edit: works without problem with vfr.py. sorry for the noise

[Chetwood]

Mosu, I've muxed 3 BDs from HDD1 to HDD2 with MakeMKV, then remuxed them again from HDD2 to HDD1 with MKVToolnix to rearrange tracks. Despite MKVToolnix not having to extract the main movie from a complete BD, it took quite longer to simply remux the same files; something I've been noticing for a while. Any idea why this might be?

movie 1
06:55 <- MakeMKV
11:57 <- MKVToolnix

movie 2
05:54 <- MakeMKV
10:22 <- MKVToolnix

movie 3
09:54 <- MakeMKV
15:11 <- MKVToolnix

[Mosu]

mkvmerge's memory handling and format parsing is not the most efficient on the planet.

[73ChargerFan]

But the GUI starts so amazingly fast! :D

[Gravitator]

Хай!
It possible to add display the size of the audio and video tracks in the table? And when disconnecting audio or video tracks show the change of the final file size.

[Mosu]

No, it's not, as that information is simply not available for a lot of the supported input file types (e.g. MPEG-TS, MPEG-PS, Matroska if no track statistic tags are present, FLV, Ogg/OGM, AC3 if it contains TrueHD as well…).

[Ex0rcist]

Does anyone know if you extract streams from mkv container with MKVExtract for example, what happens to audio delay if there's any?

[sneaker_ger]

Mkvextract (unlike eac3to) does not add any silence to neutralize the delay so you have to write it down and account for it in the processing chain you are using.

[gpower2]

You can use gMKVExtractGUI, that finds the delay of the audio tracks and writes them to the extracted filename. ;)

[stax76]

Does anyone know if you extract streams from mkv container with MKVExtract for example, what happens to audio delay if there's any?

StaxRip has also a very rich demuxing GUI for mkvextract, mp4box and eac3to, it writes the delay to the audio file name and detects delays from file names. While demuxing is recommended StaxRip however does not require audio or subtitles to be demuxed.

[hubblec4]

Hi Mosu

Is that intention or mishap you broke loading of mtxcfg's which are created before Version 9.0.0?

http://forum.gleitz.info/attachment.php?attachmentid=99113&d=1460585832

[Mosu]

Of course I intentionally implement functionality that causes crashes ;) Just kidding, obviously. That's definitely a bug. I'm trying hard to preserve compatibility with older settings files in newer releases of the GUI.

As the attachment is still pending approval I cannot look into it yet. Can you please upload the file to my FTP server? Thanks.

[hubblec4]

The file is uploaded to your FTP.


Edit:

What is with the mtxcfg's are created with V9.0.0 and higer, these are backward compatible to older versions of the GUI?

[Mosu]

Thanks, I'll look into it. No, I don't make any guarantees that config files from newer versions can be read by older ones. The most recent change incompatible with older versions was the attachment handling.

Edit: The change I meant is this one (https://github.com/mbunkus/mkvtoolnix/commit/7a60d3d6d344b37825a00f0e17fc05ea0b3ca5a9?diff=unified).

[Mosu]

@hubblec4: The file cannot be loaded by release 9.0.1, that's true, but it can be loaded just fine by the current development version. I'm pretty confident that the commit that fixed this behavior is this one (https://github.com/mbunkus/mkvtoolnix/commit/42271f5c5737dc3f62e51689207855a9b98ecde8).

[hubblec4]

Yes the file has more then 650Kb and thats the issue. Crazy.
But nice to know, I thought I have to rewrite my mtxcfg-procedure....puh.