Log in

View Full Version : MKVToolNix v24.0.0 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 [55] 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

Nico8583
22nd May 2014, 12:29
Hi,
I have a little question : I'm using MKVMerge 6.8.0 to merge MKV files with video h264, audio DTS or AC3 and subtitle sup files. Then I want to try to extract tracks from MKV to separated files so I use MKVExtract.
I have made a MD5 hash from source files (before mux) and extracted files (after demux) and there are differents (except for DTS track, MD5 are identical). Is it possible to extract tracks and obtain the same MD5 hash ?
Thanks !

sneaker_ger
22nd May 2014, 12:55
For H.264 this happens because mkvmerge does not remove the headers. When mkvextract extracts the stream it writes the header from the private field back into the bitstream without checking whether it already exists there. So with each H.264 ES -> mkvmerge -> mkvextract -> H.264 ES generation you will have the headers an additional time i.e. the checksums won't match. (Don't know about AC3 and sup.)

Nico8583
22nd May 2014, 13:31
Thanks for your explanation :)

Mosu
22nd May 2014, 14:00
That's not the only thing changed with h.264 bitstreams. Filler NALUs are removed as well.

For MP3 files ID3 tags are removed during muxing (both v1 and v2, both at the beginning and the end of the file). Same applies to AC3, AAC, TrueHD, TTA files. Generally all data that cannot be identified as a valid MP3 packet is dropped as well (similar for AC3; this applies mostly to audio read from AVI files where garbage is used for syncing audio tracks to the video track).

Nico8583
22nd May 2014, 14:14
Thanks for this complement :)
So if I want to extract all tracks and remux a new MKV, is there a difference between original remuxed mkv and new remuxed mkv ?
Or if I want to add a new track on existing MKV, is it better to use mmg.exe and nothing will be lost (tracks, attachments, covers, mkv properties, chapters...) ?

sneaker_ger
22nd May 2014, 14:34
Thanks for this complement :)
So if I want to extract all tracks and remux a new MKV, is there a difference between original remuxed mkv and new remuxed mkv ?
Or if I want to add a new track on existing MKV, is it better to use mmg.exe and nothing will be lost (tracks, attachments, covers, mkv properties, chapters...) ?

On extract some information can be lost (e.g. timecodes) so usually you just load the original mkv directly into mmg if you want to add a track. It's also easier and requires less time and space. You do not get 100% the same mkv if you mux the raw streams again because some info in mkv must be randomized i.e. it will differ even if the raw source streams were identical.

Mah
5th June 2014, 21:36
Is it possible to change the position of subtitles in mkvmerge, so that I can move subtitles little higher, bottom of screen and than mux it with mkvmerge into mkv file?

Thanks for help.

Simon88
5th June 2014, 23:31
Is it possible to change the position of subtitles in mkvmerge, so that I can move subtitles little higher, bottom of screen and than mux it with mkvmerge into mkv file?

Thanks for help.

mkv files are simply a container, it is the job of the media player which controls how subs are positioned or displayed. Some subtitle formats such as SRT relies entirely on the player while ASS files has MUCH more advanced control of how subs are interpreted/displayed that is built into the format itself, although some players allows for the overriding of how subs are displayed, eg vobsubs... the mkv cropping option may offer some limited control though...

Mah
6th June 2014, 06:05
Thanks for the answer... I edited SSA subtitles to my taste, but still on blu-ray player via USB it didn't help, because when merged via mkvmerge it didn't play SSA subtitles, but it played SSA subititles externally, but the position was the same as before (on the bottom), it didn't work... although on computer (on any software player), it worked.

Simon88
6th June 2014, 15:58
Thanks for the answer... I edited SSA subtitles to my taste, but still on blu-ray player via USB it didn't help, because when merged via mkvmerge it didn't play SSA subtitles, but it played SSA subititles externally, but the position was the same as before (on the bottom), it didn't work... although on computer (on any software player), it worked.

Many hardware players have limited cpu & ram and strips most advanced subtitle features. An MKV is treated like any other container, only 1st video & 1st audio track is read. I believe many only interpret the timing & text of subs only. An external SRT or ASS/SSA are treated the same.

Your ONLY consistently reliable option is to hard code the subs onto the video stream.:(

Mosu
9th June 2014, 18:26
Hey,

I've released mkvtoolnix v7.0.0. It's a release that includes a couple of minor enhancements to mmg and mkvmerge and the usual bug fixes (nothing major – though some more cases of overly long file detection times have been fixed).

The most prominent change is that mkvmkerge will now write certain track-specific statistics (such as bit rate) as tags. See the ChangeLog for more details. Accompanying this change is that mkvmerge's verbose identification mode will now include the track's tags as well in order to make retrieving that information easier for other programs.

For packagers: this build requires Boost's Date/Time library.

Here are the usual links:

…to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/source.html

…to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.9.1:

2014-06-09 Moritz Bunkus <moritz@bunkus.org>
* Released v7.0.0.

2014-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: In addition to the track statistics tags»BPS«, »DURATION«, »NUMBER_OF_BYTES« and »NUMBER_OF_FRAMES«mkvmerge will write two more tags identifying which application wrote the statistics (»_STATISTICS_WRITING_APP«) and when the file in question was written: »_STATISTICS_WRITING_DATE_UTC«.»_STATISTICS_WRITING_APP« will always contain the same string contained in the segment info header element »WritingApp«.»_STATISTICS_WRITING_DATE_UTC« will contain the same timestamp as in the segment info header element »Date«, though»_STATISTICS_WRITING_DATE_UTC« is actually a string representation instead of an integer value. Additionally a tag named »_STATISTICS_TAGS« is written containing the names of the tags that mkvmerge has set automatically. It equals the following currently: »BPS DURATION NUMBER_OF_BYTES NUMBER_OF_FRAMES«.
* build system: Boost's "date/time" library is now required.

2014-05-25 John Peebles <johnpeeb@gmail.com>
* mkvmerge: bug fix: If a single subtitle track contains two or more entries at the same timecode then the cue duration and cue relative position elements written were wrong.

2014-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: fixed wrong progress percentage shown during saving the information to text files. Fixes #1016 (https://www.bunkus.org/trac/ticket/1016).
* mkvmerge: new feature: Added a global option for disabling writing the tags with statistics for each track: --disable-track-specific-tags.

2014-05-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: When identifying a Matroska file in verbose identification mode track-specific tags will be output as well. The format is »tag_<tag name in lower case>:<tag value>», e.g. for a tag named »BPS« with the value »224000« the output would be »tag_bps:224000«. Enhancement for #1021 (https://www.bunkus.org/trac/ticket/1021).
* mkvmerge: new feature: mkvmerge will write track-specific tags with statistics (»BPS« for the average number of bits per second,»DURATION« for the duration, »NUMBER_OF_BYTES« and»NUMBER_OF_FRAMES« for the track's size in bytes and its number of frames/packets). Implements #1021 (https://www.bunkus.org/trac/ticket/1021).

2014-05-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Changed the file type detection order again. The text subtitle formats are now probed after those binary formats that can be detected quickly and unambiguously. This avoids some mis-detection if e.g. Matroska files as ASS text subtitles if they do contain such a track.
* mmg: enhancement: The chapter editor will only use fast-mode parsing when loading chapters from Matroska files.

2014-05-14 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: fixed invalid memory access in the cleanup procedures which only occurred if the output was redirected with the »--redirect-output« command line parameter.

2014-05-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The last chapter entry read from MPLS files is removed if it is at most five seconds long. Patch by Andrew Dvorak (see AUTHORS).
* mkvmerge: enhancement: added the attachment UID to the verbose identification output of Matroska files.

2014-04-21 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Selecting a subtitle track correctly sets the»character set« drop-down box if no character set was set for this track. Fixes #1008 (https://www.bunkus.org/trac/ticket/1008).
* mmg: enhancement: the subtitle character set cannot be set anymore for subtitle tracks read from Matroska files as mkvmerge ignores that setting for said container anyway (text subs are always encoded in UTF-8 in Matroska).

2014-04-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: mmg will look for the »mkvmerge« executable in the same directory as the »mmg« executable is located it if the location hasn't been set by the user on all operating systems (before: only on Windows). Improves detection if »mkvmerge« is not in the $PATH.

Have fun.

SeeMoreDigital
9th June 2014, 20:21
Nice one. Thanks Mosu :)

microchip8
9th June 2014, 21:30
Works fine on openSUSE 13.1. Thanks ;)

AYColumbia
10th June 2014, 03:06
Congrats on another major version and thank you. :)

mariner
15th June 2014, 18:06
Greetings.

Is there a way to combine splitting and appending (on multiple files) into one single operation?

Many thanks and best regards.

Simon88
16th June 2014, 00:45
Greetings.

Is there a way to combine splitting and appending (on multiple files) into one single operation?

Many thanks and best regards.

A batch loop using the FOR, IN, DO commands can do it easily, assuming using Windows...

Chetwood
16th June 2014, 15:38
Anyone else muxed 1 srt file with 7.0 but got 2 instead?

hubblec4
16th June 2014, 16:13
hi mosu

I'm not sure if this is the right topic.

I have made some tests with my chapterEditor and i found a small "issue" after muxing the parts of a movie with mmg.

I have used the splitting option with timecodes. first cut is 00:00:05.000, second cut 00:00:21.000, third cut 00:00:41.000. (you get 4 parts)
there is a forced subtitle track inside and one subtitle is shown from 00:00:20.000 to 00:00:23.000. after the cutting and muxing (appending) part 2 and part 4

the subtitle is shown after the 00:00:20.000 timecode but it is still shown till the end of the movie. when i jump to the "new" timecode 00:00:24.000 the subtitle is not shown anymore.

i guess the subtitle starttime 00:00:20.000 starts the subtitle correctly but there is no end-time for the sub after remuxing.

sneaker_ger
16th June 2014, 16:58
Anyone else muxed 1 srt file with 7.0 but got 2 instead?

No. Sample?
(Note that 7.0.0 writes tags with statistics as default. Maybe your application shows them as tracks?)

Mosu
16th June 2014, 18:40
I have made some tests with my chapterEditor and i found a small "issue" after muxing the parts of a movie with mmg.

I haven't noticed anything like that before. Can you please upload some sample files (preferably the one before splitting) to my FTP server so that I can take a look?

mariner
17th June 2014, 07:22
A batch loop using the FOR, IN, DO commands can do it easily, assuming using Windows...

No GUI?

Mosu
17th June 2014, 07:42
If you want to split first and append some of those files created by splitting afterwards then I strongly recommend the »split by parts« mode which can replace those two steps with a single one. See the documentation (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).

If you want to append first and split afterwards then those two things can be done in a single operation, too, of course. Just »add« your first file, »append« your second and following files, and activate splitting.

All of that can be done with mmg.

mariner
17th June 2014, 15:05
If you want to split first and append some of those files created by splitting afterwards then I strongly recommend the »split by parts« mode which can replace those two steps with a single one. See the documentation (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).

If you want to append first and split afterwards then those two things can be done in a single operation, too, of course. Just »add« your first file, »append« your second and following files, and activate splitting.

All of that can be done with mmg.

Thanks for the kind reply, Mosu.

I can't figure out how to apply the split timecode range to each individual file to be appended. For example, I'd like to append segment A from file 1 to segment B from file 2. How does one indicate which timecode range applies to which file?

Many thanks and best regards.

Mosu
17th June 2014, 15:19
Ah, now I understand what you want to do. That's not possible in a single step.

Mosu
17th June 2014, 15:24
Well, it is possible, but in a roundabout way. Add and append all files. Then use --split parts:, like I've said above. The tricky part is calculating the timecodes. For example, let's assume you have two files. The first one is 2 minutes long, the second one is 3 minutes long. You want 0:30 – 1:30 from the first file and 1:15–2:15 from the second file.

If you don't use splitting then the resulting file will be 5 minutes long. Now we can calculate which timestamps in the full output file correspond to the desired ranged in the source files.

Range 1: source file 1 0:30 – 1:30 is the same in the output file, of course.
Range 2: source file 2's own 0:00 corresponds to the duration of source file 1's last timecode, 2:00. So range 2 = 1:15 – 2:15 corresponds to the range 2:00 + 1:15–2:15 in the output file.

The resulting argument for --split parts: should be something like 00:30–01:30,03:15–04:15.

Simon88
17th June 2014, 16:31
No GUI?

One of the BEST feature of MKVToolNix is the show the command line... If I need to do something to a large group of files, whether using to MKVToolNix or any other tool, once you "see" the command line, it can be slightly modified w/ variables and it'll do it automatically in MULTIPLE steps, if needed. Most GUI's are just front ends to the command line, not very useful when complex tasks are needed.

Simon88
20th June 2014, 23:47
Hi Mosu,

I'm currently using the latest Hauppauge WinTV 7 CDv3.5 app to capture some over-the-air TV and latest MKVToolNix v7.00... The transport stream container can & often do contains an extra junk stream or two that I can easily remove & re-mux back to a TS file. However, I really like the flexibility of the MKV container & your excellent tool, MKVToolNix, that goes with it. I found that it has trouble detecting the MPEG-2 video portion and only found the audio, but I found a workaround by re-muxing w/ ffmpeg first. I also wanted to preserve the TWO closed captioning EIA-608 and EIA-708 streams... VLC plays the captioning perfectly as a TS file... In the mean time, I had to extract captions and convert them to an SRT file before re-muxing them into MKVs. It wold be great if I can also store the unmodified binary captioning info together w/ the SRT file I had extracted, so I can simply delete the TS file... That way, in the future, if I ever need to re-constitute the TS file, I can simply re-mux it and have the captioning streams intact... because closed captioning encoding gear are VERY expensive....

I know you aren't interested in doing any more MPEG-2 work, but I'm wondering if you will offer a way of storing closed captioning? As I understand it, future H.264/265 video standards will still use the same closed captioning formats. I only know that North America uses EIA-608/708 & Europe uses Teletext...

If you need short samples, I'll be happy to provide them to you for examination/testing (just tell me how many minutes to capture, where to upload it, and file-name to use...)...

Here's a short MediaInfo of a two minute capture...
General
ID : 1 (0x1)
Complete name : C:\Conversion\10.1_20140620_1525.ts
Format : MPEG-TS
File size : 310 MiB
Duration : 2mn 50s
Overall bit rate mode : Variable
Overall bit rate : 15.2 Mbps
Law rating : TV-PG

Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : MPEG Video
Commercial name : HDV 720p
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=30
Codec ID : 2
Duration : 2mn 50s
Bit rate : 14.1 Mbps
Maximum bit rate : 15.6 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 59.940 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.255
Time code of first frame : 19:23:22:30
Time code source : Group of pictures header
Stream size : 287 MiB (93%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 257 (0x101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 2mn 50s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -247ms
Stream size : 7.82 MiB (3%)
Language : English

Text #1
ID : 256 (0x100)-CC1
Menu ID : 1 (0x1)
Format : EIA-608
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 2mn 50s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)

Text #2
ID : 256 (0x100)-1
Menu ID : 1 (0x1)
Format : EIA-708
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 2mn 50s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)

Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
Duration : 2mn 50s
List : 256 (0x100) (MPEG Video) / 257 (0x101) (AC-3, English)
Language : / English
Service name : Service01
Service provider : FFmpeg
Service type : digital television
Law rating : TV-PG

Mosu
21st June 2014, 12:01
It wold be great if I can also store the unmodified binary captioning info together w/ the SRT file I had extracted, so I can simply delete the TS file...

I'm willing to work on reading CCs from M2TS files and converting them to SRT on the fly. What I will not do, though, is simply to store the binary data alongside with it. If you need something like that then you'll have to extract the CC sub-streams and attach them to the Matroska file manually.

Having a sample file or two would be nice, especially of both the EIA formats. I'd like to take you up on your offer. See the information in my signature for where to upload. Please name the file(s) something like closed-captions-….ts. Thanks.

I know you aren't interested in doing any more MPEG-2 work

Well… more or less, yes. I will take a look at the file and why mkvmerge doesn't recognize the track (as it generally does support MPEG-2 video read from M2TS files), but if it turns out to be too much effort to fix then I may possibly not do it.

, but I'm wondering if you will offer a way of storing closed captioning? As I understand it, future H.264/265 video standards will still use the same closed captioning formats. only know that North America uses EIA-608/708 & Europe uses Teletext...

Having a sample with Teletext would be nice, too, though as you're in America I don't expect you to fly to Europe just to capture one ;)

Thanks.

Simon88
23rd June 2014, 01:03
Hello Mosu,

I couldn't just upload one or two file but decided to send you a more representative sample. I had some trouble using FireFTP and had to install FileZilla instead. They are just two minutes long each. Their resolutions, framerates, and several important aspects all varies a bit between stations, so I deleted some of the ones that had blank closed captions, and a few has a SAP track, to display a second audio track for DVS, descriptive video service (for visually-impaired people), and some sticks a Spanish "subtitles" track in the English Audio programming.

CCextractor can process the CCs without issue, but certain aspects of the raw closed captioning are lost after conversion to SRT. eg, musical notes & symbols, extended unicode characters, screen positioning, and Chinese/Japanese/Korean characters are lost. RAW CC data appears to use VERY little space after zlib compression. VLC plays the RAW CC data without issue or the need for conversion as does a few others. I used VLC to play & verify the presence of the CCs in the TS files. These files I uploaded are RAW files, captures straight from the air with latest WinTV app, unaltered or "ts-doctored" in any way whatsoever for you to examine.

If you need longer samples, please let me know...:)

Nico8583
26th June 2014, 17:48
Hi,
I've made about 150 Blu ray with the same method but with 2 movies there is a problem.
I have encoded original H264 stream (from my original Blu ray) with DGMVCSource (for 3D version of Dragon Gate 3D) or DGIMDecode (for 2D version of Dragon Gate 3D) + AviSynth 2.5.8 + x264 and mux it with MKVToolnix 6.8.1 (but same issue with 7.0.0). For both movies, normal duration time is about 2 hours but when there are muxed in MKV, any player show a duration about 3 hours ! If I mux the same stream movie in M2TS with tsMuxer, duration is correct so I think there is a problem with MKVToolnix. Movies are "Dragon Gate 3D" and "Riddick" (French versions).
Could you help me ?
Thanks !

Mosu
27th June 2014, 09:35
I couldn't just upload one or two file but decided to send you a more representative sample.

Quite an impressive selection. Thank you very much!

Mosu
27th June 2014, 09:37
HFor both movies, normal duration time is about 2 hours but when there are muxed in MKV, any player show a duration about 3 hours !

I have no idea what the issue might be, especially if the very same method leads to correct results in so many more cases. Without access to the files in question (meaning the Blu-rays, unfortunately) I cannot really comment further on this.

Nico8583
27th June 2014, 12:37
I'll try to encode again but I think it will be the same issue :(

Frozen Fractals
4th July 2014, 02:48
Quick question. Why does 7.0.0 add extra tags (viewed using MediaInfo Lite) and how to get rid of them?

DURATION : 01:18:26.285000000
NUMBER_OF_FRAMES : 112836
NUMBER_OF_BYTES : 7824617775
_STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27
_STATISTICS_WRITING_DATE_UTC : 2014-07-04 04:35:51
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Before it was like this:

General
Unique ID : 232382587752882843431441932852508950773 (0xAED342288477565E80B727CC5C9B00F5)
Complete name : E:\Pirates of the Caribbean_ Dead Man's Chest (1080p HD) (1).mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 7.29 GiB
Duration : 1h 18mn
Overall bit rate : 13.3 Mbps
Encoded date : UTC 2014-07-04 04:35:51
Writing application : mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 9 2014 15:16:27
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 18mn
Bit rate : 12.9 Mbps
Width : 1 920 pixels
Height : 802 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.350
Stream size : 7.14 GiB (98%)
Writing library : x264 core 133 r2334 a3ac64b
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=12 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=90 / rc=2pass / mbtree=1 / bitrate=12918 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Thanks :)

Sparktank
4th July 2014, 03:17
Quick question. Why does 7.0.0 add extra tags (viewed using MediaInfo Lite) and how to get rid of them?

IIRC, those new tags are only added when invoked with "-v" (verbose) command.

Have you added "-v" to your command line (or batch scripts)?
Or to the mmg preferences?
"Add command line options"
-> "-v"
-> "Save as default for new jobs"

They don't take up much space and shouldn't affect playback on any software/hardware. Not that I've noticed.

If you read the changelog for v7.0.0, you'd find out more information on the new tags.

Chetwood
4th July 2014, 04:33
Why does 7.0.0 add extra tags ?

Why not read the changlog before updating?

I've released mkvtoolnix v7.0.0. It's a release that includes a couple of minor enhancements to mmg and mkvmerge and the usual bug fixes (nothing major – though some more cases of overly long file detection times have been fixed).

The most prominent change is that mkvmkerge will now write certain track-specific statistics (such as bit rate) as tags. See the ChangeLog for more details. Accompanying this change is that mkvmerge's verbose identification mode will now include the track's tags as well in order to make retrieving that information easier for other programs.

Frozen Fractals
4th July 2014, 05:59
IIRC, those new tags are only added when invoked with "-v" (verbose) command.

Have you added "-v" to your command line (or batch scripts)?
Or to the mmg preferences?
"Add command line options"
-> "-v"
-> "Save as default for new jobs"

They don't take up much space and shouldn't affect playback on any software/hardware. Not that I've noticed.

If you read the changelog for v7.0.0, you'd find out more information on the new tags.
No, I don't think I have. It's a vanilla install of mkvtoolnix. I am using the GUI and currently using "--disable-track-statistics-tags" to get rid of them, but it seems to be a stopgap solution. Unfortunately, it also rids of the information about the writing library and encoder settings. I mean...I don't mind the extra tags being there, it's just my OCD is getting to me with it having all the uppercase letters and underscores. :scared:
Why not read the changlog before updating?
I did...that's why I am asking about how to get rid of them.

Sparktank
4th July 2014, 06:15
Just did a test remux without invoking "-v" anywhere in the GUI.
It does the tags, regardless.

it's just my OCD

:rolleyes:

Mosu
4th July 2014, 07:23
Those tags have nothing to do with any verbosity (-v) setting.

See this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AAutomaticTagGeneration).

Mosu
4th July 2014, 07:27
No, I don't think I have. It's a vanilla install of mkvtoolnix. I am using the GUI and currently using "--disable-track-statistics-tags" to get rid of them, but it seems to be a stopgap solution. Unfortunately, it also rids of the information about the writing library and encoder settings.

This is wrong. Either you're not looking in the right place or the application you're using has fucked up the »no statistics tags« case.

Regardless of any command line option used mkvmerge always writes the »writing app« and »muxing app« header elements (»header elements« being the important bit here).

Since 7.0.0 mkvmerge will also write those new tags, and one of those tags contains the information which application created those statistics tags (»_STATISTICS_WRITING_APP«). mkvmerge sets this to the same value that it writes into the header element »writing app«. But, again, even with »--disable-track-statistics-tags« the header elements will still be set to the usual values which you can verify easily with mkvinfo.

Sparktank
4th July 2014, 10:01
See this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AAutomaticTagGeneration).

Bookmarked. I don't read through that site as often as I should.

Mosu
4th July 2014, 10:05
To be fair that particular FAQ entry is only a couple of days old.

gendalv
4th July 2014, 16:30
i'm using mkvtoolnix 5.8.0 gui.
10 queued simple tasks (adding srt subtitles into mkv containers)

there isn't enough space on my disk to complete all of the tasks, but there is on another disk, so in File->settings I change it from saving to the same folder - to exact folder on another disk

but it still saves into the same folder, is there a way to change which folder previously queued tasks output files?

Mosu
4th July 2014, 20:45
The »default folder« setting is only relevant when you add the very first file to a new muxing job (to be more precise: the output file name will only be set automatically when you add a file if the output file name is empty in that moment). Therefore changing this setting doesn't affect existing jobs.

You can, though, simply edit the job files; they're only text files, after all. They're stored in C:\Users\YourUserName\AppData\Roaming\mkvtoolnix\jobs.

Frozen Fractals
5th July 2014, 00:29
This is wrong. Either you're not looking in the right place or the application you're using has fucked up the »no statistics tags« case.

Regardless of any command line option used mkvmerge always writes the »writing app« and »muxing app« header elements (»header elements« being the important bit here).

Since 7.0.0 mkvmerge will also write those new tags, and one of those tags contains the information which application created those statistics tags (»_STATISTICS_WRITING_APP«). mkvmerge sets this to the same value that it writes into the header element »writing app«. But, again, even with »--disable-track-statistics-tags« the header elements will still be set to the usual values which you can verify easily with mkvinfo.
Ah, yes..I meant to go back and edit my post. It DOES NOT rid of the encoder information like I stated above. Indeed it does keep it and I was lead to believe it was removed because the particular file I tested it on did not have the tags to begin with in the first place. "--disable-track-statistics-tags" in fact only rids of the new "tags" found in v7. Thanks for the info.

SeeMoreDigital
5th July 2014, 11:04
Could a 'check box' be added to more quickly enable/disable these new meta-data lines?

Mosu
5th July 2014, 12:07
I won't do that, sorry.

nautilus7
5th July 2014, 12:42
Hi, I have some satellite broadcasts (World Cup EBU feeds) that mkvmerge can't properly detect and remux the 3rd audio track. LAV filters can't decode that track properly so maybe there's something with the track. Here's a sample (https://www.sendspace.com/file/gulxjy) of such broadcast. Can you have a look, please?

SeeMoreDigital
5th July 2014, 13:02
According to MediaInfo, there are 5No audio streams in your sample ;)

filler56789
5th July 2014, 13:03
^ According to MediaInfo, that sample file contains a "Dolby E" audio stream. TSmuxer doesn't like it, and eac3to detects it as "RAW/PCM".