MKVToolNix v99.0 released

[Liisachan]

1) GUI: Even if "Use legacy MIME types for font attachment" is checked, .ttc is treated as "font/collection" in v59 (not in v58).

2) Valid language variant tags may be refused, when its prefix is not "simple" as in:
de-CH-1996
en-GB-scotland
zh-Latn-CN-pinyin
ja-Latn-hepburn-heploc

Example:mkvmerge -o out.mka --language 0:sl-rozaj-biske resian.m4a
Error: [...] The variant 'biske' must only be used with one of the following prefixes: sl-rozaj. Notice mkvmerge is complaining that biske must be used with the prefix sl-rozaj, but that is exactly what the user is doing here.

[alex.brown111@hotmail.com]

Hi,

I have a smooth problem with some MKV created by ffmpeg but only if read with my blu ray panasonic, no issue with PC via VLC:

If I run a command like this:

ffmpeg.exe -vsync 1 -i "G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t05_ori.mkv" -y -c:v libsvt_hevc -preset 5 -qp 21 -pix_fmt yuv420p10le -profile:v 2 -map 0:0 -map 0:s -map 0:6 -disposition:a:0 +default+forced -map 0:1 -disposition:a:1 -default-forced -map 0:2 -disposition:a:2 -default-forced -c:a copy -c:s copy -metadata:s:v:0 Language="rom" -t 60 "Star Trek Season 2- Disc 1_t05_ori.mkv_60_sec_vsync.mkv"

I get this result:

General
Unique ID : 155001068370375428158814323990732767024 (0x749C1EB1AD94DEA9BF0DBD1D91EC7F30)
Complete name : G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t01.mkv
Format : Matroska
Format version : Version 4
File size : 2.03 GiB
Duration : 50 min 31 s
Overall bit rate mode : Variable
Overall bit rate : 5 749 kb/s
Movie name : Star Trek Season 2: Disc 1
Writing application : Lavf59.3.101
Writing library : Lavf59.3.101
ErrorDetectionType : Per level 1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 50 min 31 s
Bit rate : 14.4 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.290
Stream size : 5.09 GiB
Writing library : Lavc59.1.102 libsvt_hevc
Language : rom
Default : Yes
Forced : No
Color range : Limited

Audio #1
ID : 5
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 50 min 31 s
Bit rate mode : Variable
Bit rate : 2 622 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 10.417 FPS (4608 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : -42 ms
Stream size : 947 MiB (46%)
Title : flac Surround 5.1
Writing library : Lavf59.3.101
Language : Italian
Default : Yes
Forced : Yes

Audio #2
ID : 6
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : rom
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 7
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : English
Service kind : Complete Main
Default : No
Forced : No



there is remarkable stuttering when I choose the flac track.

But if I run this line:

mkvmerge -o "Star Trek Season 2- Disc 1_t05_ok.mkv" "Star Trek Season 2- Disc 1_t05.mkv"

The stuttering is reduced to 90% on flac track and I get this result:

General
Unique ID : 218662047772936570314451312862733510369 (0xA480C74F192512B8CDAEEF935AB3A6E1)
Complete name : G:\Film da ottimizzare per blu ray\Deep Space 9 (ffmpeg ori)\Disk3\Star Trek Season 2- Disc 1_t01_ok.mkv
Format : Matroska
Format version : Version 4
File size : 2.01 GiB
Duration : 50 min 31 s
Overall bit rate mode : Variable
Overall bit rate : 5 686 kb/s
Movie name : Star Trek Season 2: Disc 1
Encoded date : UTC 2021-07-10 06:48:51
Writing application : mkvmerge v58.0.0 ('Supper's Ready') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4 / Lavf59.3.101

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 50 min 31 s
Bit rate : 2 629 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.053
Stream size : 950 MiB (46%)
Writing library : Lavc59.1.102 libsvt_hevc
Language : rom
Default : Yes
Forced : No
Color range : Limited

Audio #1
ID : 5
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 50 min 31 s
Bit rate mode : Variable
Bit rate : 2 622 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 10.417 FPS (4608 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : -42 ms
Stream size : 947 MiB (46%)
Title : flac Surround 5.1
Writing library : Lavf59.3.101
Language : Italian
Default : Yes
Forced : Yes

Audio #2
ID : 6
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : rom
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 7
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 50 min 31 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : -42 ms
Stream size : 69.4 MiB (3%)
Title : Stereo
Language : English
Service kind : Complete Main
Default : No
Forced : No





If I play any mkv file with my PC using VLC all files work perfectly without stuttering, but if I play a MKV file with my panasonic Blu ray player the video is not perfectly smooth like PC.

I have tested it using USB 3.0 port with SSD Samsung, but the result is the some with any other disk (apart the optical disk where the result is perfect)

I ask if there is workaround with mkvmerge to solve this problem. thank you !

[Mosu]

@Liisachan Thanks, I'll fix both.

[SeeMoreDigital]

Hi Mosu,

I've just finished uploading four (short duration) 2-layer Dolby Vision .m2ts contained sample files to your server...

EDIT: And the information I posted back in Jan 2020 (https://forum.doom9.org/showthread.php?p=1895241) is still relevant in your newer releases ;)

[Mosu]

1) GUI: Even if "Use legacy MIME types for font attachment" is checked, .ttc is treated as "font/collection" in v59 (not in v58).

2) Valid language variant tags may be refused, when its prefix is not "simple" as in:

Fixes for both have just been pushed.

[Liisachan]

@Mosu
Thanks, 1) 2) both fixed! But I found different minor issues.

3) Just because LANG has valid extensions/variants A & B, doesn't mean LANG-A-B is valid.
Ex1. "de-1901-1996" obviously doesn't make sense.
Ex2. "zh-cmn-yue" should be invalid, as "zh-cmn" (Mandarin) can't be further extended as Cantonese (yue).
Ex3. Common sense dictates that "hy-arevela-arevmda" doesn't make sense either, as Eastern Armenian & Western Armenian are mutually exclusive concepts ("sl-rozaj-biske" has a different structure, where "biske" is explicitly allowed as a sub-variant of "sl-rozaj").

4) The "Edit Language" dialog should open by Alt (or something) + L. Some users, complaining about the increased number of clicks, might be happy this way too (with Alt+T and arrow keys, 0-click editing would be possible). If this isn't easy, maybe change the label "&Language" to "Langauge" to reduce UI confusion. Imho having two different UIs with the identical functions (clickable text and the pen button) is already slightly confusing.

[Mosu]

3. That's entirely correct, but nothing I'm going to fix, I've decided. I don't aim to create a 100% correct implementation. For example, at the moment I don't support grandfathered entries. Nor do I support entries with outdated codes (e.g. several examples in RFC 5646 use the country code "CS" which stood for the European country of "Serbia & Montenegro" — a country that doesn't exist anymore as they split into "Serbia" (RS) and "Montenegro" (ME); now "CS" isn't part of ISO 3166 anymore, and MKVToolNix rejects tags using it as invalid). And my code doesn't enforce the preferred order within extended language & variant sub-tags. Etc.

I consider it good enough. It should definitely not reject valid tags (apart from the grandfathered entries mentioned above), but I don't care that much for the other part (rejecting all invalid ones), to be honest.

4. Hmmmmmmmmm well. That won't make anyone not complain, I'm afraid. If they don't like the extra dialog, they don't like it. At the moment you can use the sequence "Alt+K Tab Space" for opening the dialog already. That's pretty quick to hit; shortening it to just Alt+L would not save that much time.

I'll think about it.

Edit: fixed key binding for "track name"; it's Alt+K, not Alt+T

[Mosu]

4) The "Edit Language" dialog should open by Alt (or something) + L

GUI: mux: open language dialog when pressing track language label's shortcut (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/3a9358ec09601adca371768c71d557495d8dc70d)

[Liisachan]

3) is okay for now, not really a practical problem. I was just wondering if you really assume "zh-mnp-nan" is valid here:
EXPECT_TRUE(mtx::bcp47::language_c::parse("zh-mnp-nan-Hant-CN").is_valid());

There are many 639-3 tags that can't be supported as legacy (639-2 based) Language values in Matroska, and not yet supported as LanguageIETF either. However, perhaps "cnr" should be supported since it's in ISO 639-2.

4) was something more basic. If UI says "Cop&y, Trac&k, &Language", users think Alt+Y, Alt+K, Alt+L should work; Alt+L did work in the past, so thanks for making it work again. (I too doubt this will make Vicio any happier, though.)

[Mosu]

4) was something more basic. If UI says "Cop&y, Trac&k, &Language", users think Alt+Y, Alt+K, Alt+L should work

Yeah I totally agree. I didn't remember that "Language" already has a keyboard shortcut — and it being present but not working is really not what I want.

I've just added similar shortcuts to almost all other places where language display widgets are used.

[Mosu]

I've reconsidered and "improved" (https://gitlab.com/mbunkus/mkvtoolnix/-/commit/a351d7629f86e61311261524395a31d783df8bef) (= fixed) the parser's validation of prefixes. Pretty much all examples you listed now test correctly, as do a lot of their variants for which I added a lot more test cases (e.g. "de-1901" and "de-1996" being valid, "de-1901-1996"). A side effect is that the order matters now, meaning "sl-rozaj-biske" is considered valid whereas "sl-biske-rozaj" isn't.

One thing I haven't changed (and don't think I ever will) is supporting legacy codes.

3) is okay for now, not really a practical problem. I was just wondering if you really assume "zh-mnp-nan" is valid here:
EXPECT_TRUE(mtx::bcp47::language_c::parse("zh-mnp-nan-Hant-CN").is_valid());

That was actually an example in RFC 4646 Appendix B in the "valid" section — which was a bit confusing, especially given that both extended language subtags ("mnp" and "nan") are known & valid, but their combination isn't, at least according to the current IANA language registry. I've changed that test to require failed validation.

However, perhaps "cnr" should be supported since it's in ISO 639-2.

My scripts generating the various lists only downloads certain data from the internet; other data is taken from Arch Linux's copy of ISO codes (which originates in Debian's work to turn those list into easily parseable JSON files). That copy doesn't include "cnr" yet; that's why it's missing from MKVToolNix. There's an open issue (https://salsa.debian.org/iso-codes-team/iso-codes/-/issues/29) for including "cnr" already, but judging from the open issues & merge requests the project looks not to be too active, unfortunately.

I'll look into downloading the lists directly from ISO's website directly (e.g. ISO 639-3 is available here (https://iso639-3.sil.org/code_tables/download_tables)) and parsing those.

Thanks for all the testing & the feedback!

[Liisachan]

A side effect is that the order matters now, meaning "sl-rozaj-biske" is considered valid whereas "sl-biske-rozaj" isn't.

That should be a correct behavior: biske is a member of sl-rozaj, but rozaj is not a member of "sl-biske" (which is invalid). Get a second opinion from [ https://validator.w3.org/#validate-by-input ]
<!DOCTYPE html><html lang="sl-rozaj-biske">
<head><title>test</title></head></html> validates, while <!DOCTYPE html><html lang="sl-biske-rozaj">
<head><title>test</title></head></html> gets an error.

One thing I haven't changed (and don't think I ever will) is supporting legacy codes. So that old Matroska files will always play fine, both by old and new players, even if future players may be reading LanguageIETF by default? I think that's a very good thing, and I hope the same thing will be true about the legacy font mime types too.

Let's say the audio track is Cantonese. Language=yue is impossible in the current Matroska specs, so we have Language=chi. The question is, can we have LanguageIETF=yue at the same time? Or should it be LanguageIETF=zh-yue even though being redundant and not the best practice? This may become an issue when players actually start reading LanguageIETF. Perhaps we're going to have to ask player-side devs to support both yue and zh-yue equally, just like standard and legacy font mime types.

That was actually an example in RFC 4646 Appendix B in the "valid" section — which was a bit confusing, especially given that both extended language subtags ("mnp" and "nan") are known & valid, but their combination isn't, at least according to the current IANA language registry.

It's your accidental typo :) RFC 4646 Appendix B says zh-min-nan (grandfathered but valid), not zh-mnp-nan (and neither zh-mnp nor zh-nan is valid). As LanguageIETF in Matroska, if we use zh-yue instead of yue, then we'll have to use zh-min-nan instead of nan, for the same reason. This point itself may be debatable, though.

EDIT: The last paragraph is wrong. Both zh-mnp and zh-nan are valid, and also zh-min-nan is technically valid too: "nan" (preferred) = "zh-nan" (synonym) = "zh-min-nan" (grandfathered), while "ms-min" = "min" ≠ "zh-min". Really confusing...

[Mosu]

That should be a correct behavior: biske is a member of sl-rozaj, but rozaj is not a member of "sl-biske" (which is invalid).

Yes. What I said wasn't exactly what I meant to say, which was "order matters & MKVToolNix now gets it right".

Let's say the audio track is Cantonese. Language=yue is impossible in the current Matroska specs, so we have Language=chi. The question is, can we have LanguageIETF=yue at the same time?

Yes, though mkvmerge only helps you so much in this regard. If you use e.g. "--language 1:yue", it will set LanguageIETF=yue but (Legacy)Language=und as yue doesn't have an associated 639-2 code. At the moment you cannot specify both independently of each other, and I have no plans to implement that capability either (mostly because it would be a real nightmare to implement in the GUI that isn't a huge confusion pile of poo).

If you need to support legacy players in such situations, you can use mkvpropedit after multiplexing. It will treat the property "language" similarly to mkvmerge, namely setting both LanguageIETF and (Legacy)Language, but it also knows the "language-ietf" property which will only set LanguageIETF. So:

"mkvpropedit v.mkv --edit track:2 --set language=chi" will set LanguageIETF=zh, (Legacy)Language=chi
"mkvpropedit v.mkv --edit track:2 --set language=chi --set language-ietf=yue" will set LanguageIETF=yue, (Legacy)Language=chi (Attention: order matters here; using them the other way around, "language" after "language-ietf", would mean that the value from "language" overrides the one from "language-ietf" as "language" sets both)

Using "--language 1:zh-yue" works, too. In that case mkvmerge will set LanguageIETF=zh-yue and (Legacy)Language=chi as chi is the 639-2 code associated with the 639-3 code zh.

So as to the question what best to do in order to be properly compatible, let's just say… it's complicated. My take: decide on either of the following:

Multiplex with language "zh-yue" if compatibility with older players is important and you want the simplest workflow
Use mkvpropedit with "--set language=chi --set language-ietf=yue" after muxing if compatibility with older players is important and you're OK slightly complicating your workflow[1]
Multiplex with language "yue" if compatibility isn't that important

[1] This can even be automated. The GUI supports running arbitrary programs after multiplexing. One could write a script (in whatever language) that uses mkvmerge to query the current track languages. For all tracks with a language of "yue" it runs mkvpropedit on the file & uses the aforementioned "--set language=chi --set language-ietf=yue" for those tracks. Then configure the GUI to run that script after mutliplexing & use "yue" as the track language going forward.

also zh-min-nan is technically valid too:

I disagree; the IANA registry only lists "zh" as a valid prefix for both extended language subtags "min" & "nan".

One thing be both definitely agree on:

Really confusing...

!!! 😁

[Liisachan]

The recent updates are impressive, but there seem to be some accidental regressions. A few basic tags are now refused: Latin (la; lat), Sign Languages (sgn), Artificial languages (art). Also, some minority tags, previously recognized, are now refused (lsg, rsi...).

I suggest you use https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry which is solid and more up-to-date than SIL's tables — also including recently added 3-letter codes (bic, bij, blg...) & script codes (Ougr, Pcun...).

I disagree; the IANA registry only lists "zh" as a valid prefix for both extended language subtags "min" & "nan".

You’re right, zh-min-nan is not a valid langtag. However, according to RFC4646, §2.1, a language tag is valid, not only when it is a valid langtag, but also when it is grandfathered. Actually, contrary to what you said, zh is not even listed as a valid prefix for min:
Type: extlang
Subtag: min
Prefix: ms But zh-min is grandfathered (i.e. an exception of the langtag rules):
Type: grandfathered
Tag: zh-min Similarly, zh-min-nan is grandfathered.

The current test version of MKVToolnix tends to refuse deprecated tags. Totally refusing deprecated tags, though, one can't use zh-yue: Type: redundant
Tag: zh-yue
Description: Cantonese
Added: 1999-12-18
Deprecated: 2009-07-29
Preferred-Value: yue

Legacy tags like zh-*** might be necessary as you explained. On the other hand, it would be ideal to keep things simple, refusing redundant/deprecated tags. If I could arbitrarily update the Matroska specs, I’d simply allow ISO 639-3 as the value of Language, e.g. Language=yue, Name=Cantonese. If a player selects a track by simple string comparison, it doesn’t need to know what yue means. A Cantonese-speaker can just type "yue" in the "preferred audio language" editbox, and everything would work. The current version of MPC-HC and MPC-BE can already do this (tested after changing 'und' to 'yue' by a binary editor), even showing nicely "Cantonese [yue]" in the audio menu.

I kind of understand why zh-yue (Deprecated, Redundant) is recommended over yue (standardized in 2009) in Matroska. But then, because of similar, practical reasons, shouldn't application/x-truetype-font be recommended over font/ttf? What's the point in using font/ttf, when both old and new players understand the legacy mime but not all players don't recognize font/ttf (standardized in 2017) yet? If anything, I'd make the "Use standard mime types for font attachments" checkbox as opt-in for those who really want to use them: enabling it doesn't really improve anything, except maybe the file size will become smaller by a few bytes, while confusing or upsetting a few end users (like those who are still using the last official version of MPC-HC). Imho the mime-type transition was slightly premature, with few advantages; it could have waited for a little longer, until most MPC-HC users switch to clsid2 builds or -BE. SourceForge, once a great site, is making things difficult, still recommending old MPC-HC (which doesn’t recognize font/ttf), along with the latest stable version of MPC-BE.

[Mosu]

The recent updates are impressive, but there seem to be some accidental regressions. A few basic tags are now refused: Latin (la; lat), Sign Languages (sgn), Artificial languages (art). Also, some minority tags, previously recognized, are now refused (lsg, rsi...).

Yeah, I excluded languages of type A (ancient = extinct since ancient times) & E (extinct in recent times). Latin falls into type A.

Artificial got lost 'cause I only process 639-3 at the moment and "art" is only part of 639-2 but not of 639-3. In fact, 639-3 doesn't contain language collections while 639-2 do, and I totally forgot about that fact.

I'll re-add processing 639-2 lists & disable filtering by type. That'll add… another 1.000 entries or so…

I suggest you use https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry which is solid and more up-to-date than SIL's tables

The LSR (language subtag registry) doesn't provide all the information I need, unfortunately. For example, it doesn't contain 639-3 alpha 3 codes if there is a 639-3 alpha 2 code. Search for "lat" and you'll see what I mean. You can find the entry for "la", of course, but no mention of "lat". Same for bibliographic vs. terminologoy 639-2 codes; it doesn't include those at all (see entry for German for which "de", "ger" and "deu" must be recognized, "de" used in LanguageIETF and "ger" in (LegacyLanguage) — but the LSR only lists "de", obviously).

I am using the registry for extended language sub-tags & variants, though.

However, according to RFC4646, §2.1, a language tag is valid, not only when it is a valid langtag, but also when it is grandfathered.

Ah, that would explain why it's listed in the "valid" section of Appendix B. As I said, MKVToolNix doesn't support grandfathered entries at the moment & no plans to change that.

Actually, contrary to what you said, zh is not even listed as a valid prefix for min:

Oh, you're right. I must have accidentally looked in the next line in iana_language_subtag_registry_list.cpp, which is "mnp" and which is valid for "zh". My bad.

On the other hand, it would be ideal to keep things simple, refusing redundant/deprecated tags.

I disagree. Neither is invalid. If they're accepted now, there's no reason to change that.

What's the point in using font/ttf, when both old and new players understand the legacy mime but not all players don't recognize font/ttf (standardized in 2017) yet?

Correctness & using standards where possible. As there's no way to know when "most MPC-HC users have switched", there's no use in waiting. Any timeframe is arbitrary.

With your arguments you could even refuse to ever add any type of new element (such as LanguageIETF) to Matroska ever again as there are always players out there refusing to play files that contain elements they don't know about, and we don't know when users have switched over from those players. It's a losing game.

For those who have problems with the MIME types, several options exist. It's up to the user to decide how much legacy support they want to offer.

[Liisachan]

A weird behavior, perhaps introduced somewhere between v52 and v56. When the language name for a 3-letter code (e.g. 'hmj') is exactly 2-letter (e.g. 'Ge'), and this 2-letter name is not identical to any valid language tag, then the 2-letter string is accepted as if it were a valid language tag.

Exmaple (note "ge" is not a valid language tag)
mkvmerge -o out.mka --language 0:ge in.ogg
mkvinfo out.mka
...
| + Language: und
| + Language (IETF BCP 47): hmj

For example, it doesn't contain 639-3 alpha 3 codes if there is a 639-3 alpha 2 code. Ah, that's right!

I disagree. Neither is invalid. If they're accepted now, there's no reason to change that.
I have nothing against zh-yue, etc. As a general statement, though, it would be ideal if this part is as simple as possible, the same language not having many, confusing synonyms.

I have nothing against font/ itself either, but the switch was a bit abrupt. I thought you agreed that the mime type transition wouldn't be a surprise attack, and that there would be some kind of advance warning. If I had known there were going to be MIME type changes, I could have tested pre-release versions and chances are, the MIME-related bugs in v58/59 wouldn't have existed. But v58 had been already released, so it's pointless to say this. The problems were fixed rather quickly, for which I'm thankful :)

With your arguments you could even refuse to ever add any type of new element (such as LanguageIETF) to Matroska ever again as there are always players out there refusing to play files that contain elements they don't know about, and we don't know when users have switched over from those players. It's a losing game. Well, as you know very well, the nature of EBML is such that it's freely extensible on the assumption that a parser will ignore elements that don't know or don't want to support. The font mime problem is different, in that an old parser does know the element FileMimeType, and we're changing the semantics of the value of this existing element. There has been an agreement that one must use "application/x-truetype-font" for an embedded font for subs. Haali/Gabest said, "use this, or else the font is not used" and typesetters were like "Okay, we'll use it". Other players also accepted the same protocol, and everything has been working fine for 10+ years. Breaking this agreement is much trickier than adding a totally new element (which can be harmlessly ignored).

Anyway, it was unfortunate that there didn't exist registered mime types for font files... it's no one's fault.

Because of this experience, it seems natural to ask this pre-emptively: maybe should we use "yue" instead of "zh-yue" from the beginning, so that the value of languageIETF will remain stable? Just wondering, not insisting anything. Perhaps whichever is fine, because hopefully a good player in the future will support both.

[Mosu]

A weird behavior, perhaps introduced somewhere between v52 and v56. When the language name for a 3-letter code (e.g. 'hmj') is exactly 2-letter (e.g. 'Ge')

Interesting case. Turns out, "Ge" is a valid _name_ of a language. This will only work with language names that are three letters long or shorter; otherwise the regular expression used to match against a BCP 47 tag structure won't match.

You can also use the language called "Gen" as an example; it works, and its code "gej" is written to the Matroska file.

I'll definitely fix this, most likely by removing the comparison to the name field as I don't think I ever intended that to work.

I have nothing against font/ itself either, but the switch was a bit abrupt. I thought you agreed that the mime type transition wouldn't be a surprise attack, and that there would be some kind of advance warning. If I had known there were going to be MIME type changes, I could have tested pre-release versions and chances are, the MIME-related bugs in v58/59 wouldn't have existed.

The problem with that is that I would have to had prior knowledge about how that went down. The thing is, MIME type detection depended on the "magic" library. For quite a while the Linux builds of MKVToolNix were using newer versions of the library (the ones that come with the respective distribution) whereas the Windows variant of the same MKVToolNix release were built with a rather ancient version of the same library. This meant that the same MKVToolNix version detected font MIME types differently without me realising this at all.

What drove me to update magic for the Windows build wasn't to make behavior the same across OSses, either. Instead, I primarily wanted to update in order to remove a ton of potential security issues in said library. magic deals with untrusted material from untrusted sources. I have a moral responsibility to keep it as up to date as possible.

Now why did I wait so long to update? That wasn't intentional either. I'm using the "MXE" project for cross-compiling from Linux to Windows. MXE functions a bit like a Linux distribution, just for providing huge set of build recipes that can compile everything from the compiler & the libraries & the programs on Linux to be run on Windows so that you can build your own program on top of that infrastructure. I'm relying on the MXE project keeping their build recipes up to date. For magic, unfortunately, that build recipe was quite stale, it turned out.

After updating the library I realized that it featured a change to font MIME types. When I compared that to Linux I noticed that on Linux the new font types had already been in use for quite a bit. So that seemed to be as good a time as any to change over officially as part of my releases had done so for a while.

If I had planned it all in advance, this would likely have gone down differently. It was more of an accident, though, and things were already broken.

The font mime problem is different, in that an old parser does know the element FileMimeType, and we're changing the semantics of the value of this existing element.

I get that, believe me, and like I said above, if it had been a planned change and all that.

Because of this experience, it seems natural to ask this pre-emptively: maybe should we use "yue" instead of "zh-yue" from the beginning, so that the value of languageIETF will remain stable?

Unlike font MIME types, there are valid, specced options for Chinese in BCP 47 today. Some of them just might be removed one day. When (or even if) that will be, I don't think anyone really knows.

I wrote earlier about the three options I see for users. I will not and cannot make a recommendation. I know what I'd do for my personal files, were I to speak Chinese, which I'm not, but personal libraries are just one of the many use cases, a lot of them with widely different requirements. So… yeah. 🤷

With BCP 47 I think players will have to do a lot of leg work for "proper" support for them, whatever "proper" means, exactly. In MKVToolNix I only need to consider creating (= letting the user input them), validating (either from user input or from existing data) and partially with displaying them.

For players, the "displaying them" part becomes that much more important, and there are so many things to consider, given that tags can become so large, and replacing the subtags with their corresponding names might yield huge huge-readable strings. On top of that players have to implement matching: letting the user chose their preferences, then matching those preferences to existing tags and deciding which to auto-select. I don't envy them that work, and I fear most players won't put too much work into it (if any at all; sticking to (Legacy)Language is probably appealing to a lot of developers).

BCP 47 is bloody huge. But just like Unicode, this isn't actually a technical problem, it's a human problem, as we were the ones to create all those languages and scripts and symbols. Basically we all have ourselves to blame for all the work we now must do 😁

[ctl-tx]

I have a request. Is it possible to make the "use legacy MIME types for font attachments" Preference apply to fonts attached in the Header Editor as well? Right now, I would have to manually enter the legacy MIME type into the MIME type box. It's a pain if there's more than a handful of fonts being attached.

[varekai]

@Mosu
First, read and watched on TV news about the disastrous flooding in Western Europe and hope you are safe.

Second, thanks for this one-of-a-kind software, really apprecitate it!
Win 10 + MKVToolNix v59.0.0

I've read the MKVToolNix FAQ but am uncertain if my method is supported?
I have several media files with video and audio and srt subtitles.
I would like to remove some audio tracks and subtitles and then multiplex to separate files to another HDD.
Thinking this will speed up the multiplex?
What I can't get to work is that the video files should be kept as is one by one and not joined to one big file.
Racking my brains trying to figure out the settings for batch and output to another HDD directory folder.
Think I read in FAQ that batch is not possible?
But... some time ago I think I got it to work... but I can't repeat that...

Best regards
varekai

[Mosu]

I have a request. Is it possible to make the "use legacy MIME types for font attachments" Preference apply to fonts attached in the Header Editor as well? Right now, I would have to manually enter the legacy MIME type into the MIME type box. It's a pain if there's more than a handful of fonts being attached.

I thought I had done that, but you're right, it doesn't work as intended at the moment. I'll look into it.

[Liisachan]

If Header Editor can do that, maybe the attachment MIME types should be automatically updated while MKV-to-MKV transmuxing, when the user opts out from using "font/".

Unlike font MIME types, there are valid, specced options for Chinese in BCP 47 today.

The truth is opposite in a way. On the one hand, the specs say both (1) using an x- value without registration and (2) registering a (non x-) value with IANA, are acceptable mechanisms for defining a new media subtype. For example "video/x-matroska" is acceptable (valid), though it can't be registered as-is. Similarly, "application/x-truetype-font" is valid, except it can't be registered as-is.

On the other hand, "zh-yue" is registered and explicitly marked as "obsoleted" since more than 10 years ago, with "Preferred-Value: yue". Although zh-yue is still valid, it's no more preferred.

The real bad legacy, though, may be "application/vnd.ms-opentype" for OTF. This one is not an x- type, nor registered. So technically it's really invalid (or are there some kind of exceptions for "vnd." ?).

[Mosu]

If Header Editor can do that, maybe the attachment MIME types should be automatically updated while MKV-to-MKV transmuxing, when the user opts out from using "font/".

The option only affects the MIME type of newly added attachments, not of existing attachments. I'm not a fan of auto-updating existing MIME types either. In addition it would be quite some work for mkvmerge as it doesn't support modifying existing attachments at all at the moment. All of that requires more time than I'm willing to invest.

[LeMoi]

Hello and thanks for the latest update.

- I don't really understand the new 'Default' track system. Before this update, there were automatically only one (the first) track that was marked as default, one video, one audio and one subtitle track, now, every track is marked as Default, is this normal ? I manually unselect the other tracks to keep only one of each type as default, do I need to or can I keep them all as Default?
- Since the latest version, the files are not added in the correct order if there's numbers in the first chars, even if they are selected in the right order in the 'Add window'
https://nsa40.casimages.com/img/2021/07/24//210724123643701334.jpg
Before this update, the file "10_..." was added after the file "9_...", I don't really understand why this the "10_..." file is added after the "4_...'

PS : in this example, "0_..." is video, "1_..." to "4_..." are audio files, other files are subtitles (idx/sub and SRT)

[Mosu]

- I don't really understand the new 'Default' track system. Before this update, there were automatically only one (the first) track that was marked as default, one video, one audio and one subtitle track, now, every track is marked as Default, is this normal ? I manually unselect the other tracks to keep only one of each type as default, do I need to or can I keep them all as Default?

The meaning of the "default track" flag has changed in the Matroska specs recently. The original meaning was "this track should be played by default". It turned out that this wasn't what most players implemented, nor what was actually useful. Therefore we (= the Matroska specs team) decided to change it to mean "this track is eligible to be played by default" with the expectation that other factors such as a track's language factor into this decision as well.

Here's the current wording from the spec notes (https://www.matroska.org/technical/notes.html#default-flag):

The “default track” flag is a hint for a Matroska Player indicating that a given track SHOULD be eligible to be automatically selected as the default track for a given language. If no tracks in a given language have the default track flag set, then all tracks in that language are eligible for automatic selection. This can be used to indicate that a track provides “regular service” suitable for users with default settings, as opposed to specialized services, such as commentary, hearing-impaired captions, or descriptive audio.

The Matroska Player MAY override the “default track” flag for any reason, including user preferences to prefer tracks providing accessibility services.

For example, if you have four audio tracks, with the first one containing director's comments in English, the other track being regular soundtracks in e.g. French, English and Japanese, the first track should NOT have "default track" set, the other three SHOULD have it set. That signals to a player that it should select one of the tracks 2, 3 or 4 by default, taking the user's language preferences into account.

MKVToolNix was changed to match the current specs.

If you're interested in the details, they're discussed here (https://github.com/ietf-wg-cellar/matroska-specification/issues/374) and here (https://github.com/ietf-wg-cellar/matroska-specification/pull/447).

- Since the latest version, the files are not added in the correct order if there's numbers in the first chars, even if they are selected in the right order in the 'Add window'

Hmm yeah, I'm now forcefully sorting the list alphabetically, which was necessary in order to implement feature request 2866 (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2866), and from the pure string comparison point of view 10_… sorts lower than 2_… as the numeric value of the '0' character is lower than the numeric value of the '_' character. This is a common problem with sorting strings with numbers on a computer if the sorting algorithm isn't specifically aware of their mixed nature. One simple-ish workaround is to prefix numbers lower than 10 with a 0, making them 01_…, 02_…, 10_… etc., which works as the characters representing numbers always sort how a human would say "correctly" when comparing them amongst themselves.

That being said: I do have such a numbers-aware sorting algorithm in MKVToolNix already and use it in other appropriate places. I'll simply switch to that one which should both fix your issue & keep feature request 2866 working.

[LeMoi]

Thanks for your answer about the 'default' flag, I got it.

One simple-ish workaround is to prefix numbers lower than 10 with a 0, making them 01_…, 02_…, 10_… etc., which works as the characters representing numbers always sort how a human would say "correctly" when comparing them amongst themselves.

That being said: I do have such a numbers-aware sorting algorithm in MKVToolNix already and use it in other appropriate places. I'll simply switch to that one which should both fix your issue & keep feature request 2866 working.

About the sorting algorithm, I know older versions of Windows needed the numbers to have same-digit numbers to be sorted correctly, but Windows 7 fixed that and most programs now handle that correctly. MKVToolnix used to do so, so that's why I was surprised to see this regression -to me.
I'll use two-digits numbers if there are more than 9 tracks until maybe there'll be a fix

[Mosu]

Well, it's not an OS-level thing (Windows x vs Windows y vs Linux), but a per-application thing. You probably mean Windows Explorer in WinXP vs its variant in Win7.

The thing is, for detecting sequentially-numbered files (one of the prerequisites) I need to process them in numerical order so that the file numbered N comes directly before N+1. There really is no guarantee for me, the application, that the file names handed over either via the operating system (via drag & drop), from an application-specific "open file" dialog or from the command line (think of Windows' "send to" feature) are sorted. Therefore MKVToolNix must do so. Earlier versions didn't have the aforementioned feature, therefore they didn't care about the order.

But like I said, should be easy to fix.

[Mosu]

First, read and watched on TV news about the disastrous flooding in Western Europe and hope you are safe.

Meh, totally overlooked your post. Thanks for your concern! Luckily for me I live well away from the affected areas and am not involved directly. I do have friends in the region, though, and yes, they're all luckily still alive. Many of them have lost their houses, though, some partially (basement & first floor completely flooded and uninhabitable), some have lost everything. It is kind of apocalyptic there.

What I can't get to work is that the video files should be kept as is one by one and not joined to one big file.

Sounds like you're adding all the files to a single mutliplex job. That won't work. Each multiplex job always creates one Matroska file, no matter how many files you add to it. If you want to create multiple Matroska files (one for each source file) you'll have to create one multiplex setting for each source file, too.

There are several avenues for automating such processes, including implementing something around the command-line tool mkvmerge or using third-party applications.

[Mosu]

I'll use two-digits numbers if there are more than 9 tracks until maybe there'll be a fix

I just saw in the source code that sorting is only done if the "recognize file sequences" feature is turned on in the preferences: "Multiplexer" → "Detect file name sequences…" Turning it off should help you, too.

[Mosu]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/) have the sorting issue… sorted 😊

[Perenista]

Why is it that MediaINFO says my video has a name but MKVToolnix doesn't show that name nowhere inside the file? I mean the track itself has been "named" but I am not seeing anywhere where this information is stored, so I can remove or edit...

EDIT: located in the HEADER editor. Is there a problem if we remove this element?

[Mosu]

The movie/segment title is purely option. It can be removed safely.

In the multiplexer the movie/segment title can be found on the output tab.

[LeMoi]

I just saw in the source code that sorting is only done if the "recognize file sequences" feature is turned on in the preferences: "Multiplexer" → "Detect file name sequences…" Turning it off should help you, too.

Unfortunately I like the 'Recognize file sequences' feature, so I don't really want to turn it off!

I tried the latest build, the problem looks to be solved, thanks for your reactivity :)

[Mosu]

You're quite welcome. Thanks for the report.

[Liisachan]

The option only affects the MIME type of newly added attachments, not of existing attachments. True, disregard that comment of mine. Not only the implementation would be non-trivial for you, this would also mean, for consisntency, that the mime types of existing attachments should be auto-updated in the reverse way too when MKV is transmuxed, and most users probably don't expect/want that.

(Users of v58 may want to fix the broken mime types due to libmagic, but they can do so by re-muxing instead of transmuxing.)

[varekai]

@Mosu
Thanks for your kind reply, much appreciated.
Good to hear all is well with you.
I can feel your concern for your friends, it is troubled times now.

You presented some new ideas to me and I will do some trial&error.
I'm not very good at using command-line but I'll figure it out... :D

Best regards
varekai

[Mosu]

Heya everyone.

Here's a new release of MKVToolNix: v60. It includes a substantial amount of improvements for BCP 47/RFC 5646 language tags. It also fixes a nasty bug in the HEVC code that could lead to a loss of some frames when appending HEVC tracks under certain circumstances.

Nothing's changed for package maintainers this time around.

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

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 60.0.0 "Are We Copies?" 2021-07-31
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: added support for language families from ISO 639-5 that aren't part of 639-2.
all: IETF BCP 47/RFC 5646 language tags: implemented support for Alpha 2 country codes of the "user-defined" category: "AA", "QM"–"QZ", "XA"–"XZ" and "ZZ".
all: IETF BCP 47/RFC 5646 language tags: updated the various lists of valid subtags from the official specs.
MKVToolNix GUI: multiplexer: pressing the keyboard shortcut for the track's "Language" label (Alt+L for English) will now open the language dialog.
MKVToolNix GUI: multiplexer: added an option in the preferences for turning off the colored boxes indicating which file each track belongs to.

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: fixed validating extended language & variant subtags against their allowed prefixes (e.g. a valid tag with a country code as in "de-CH-1996" is recognized as valid while two generally known variants that aren't allowed together as in "de-1901-1996" is recognized as invalid).
all: IETF BCP 47/RFC 5646 language tags: when looking up a language for a two- or three-letter code, the programs will no longer compare that code with language names as that was unintended, ambiguous (e.g. the code "Ga" could be interpreted as the 639-2 alpha-2 code for "Irish" or as the name of the language called "Ga") and only worked with languages whose name was at most three letters long.
mkvmerge: HEVC/H.265: appending Matroska files with HEVC tracks might lead to the loss of the first couple of frames from each of the second and all following files. Fixes #3170 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3170).
mkvmerge, mkvextract: HEVC/H.265 parser: fixed the programs aborting when parsing VPS or SPS NALUs with invalid content due to unhandled exceptions. Fixes #3162 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3162).
MKVToolNix GUI: multiplexer: when the option "use legacy MIME types for font attachments" is enabled, the GUI will now use "application/x-truetype-font" for font collection files.
MKVToolNix GUI: multiplexer: fixed escaping the "mkvmerge" argument in the "Show command-line options" dialog for the "Windows (cmd.exe)" mode. Fixes #3164 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3164).
MKVToolNix GUI: multiplexer: when adding multiple files at once, the GUI will sort file names with numbers the way a human would expect it to. For example, "1.mp4", "9.aac", "10.srt", "11.srt" are now sorted exactly that order instead of "1.mp4", "10.srt", "11.srt", "9.aac".
MKVToolNix GUI: header editor: the header editor will now honor the "use legacy MIME types when adding font attachments" setting when adding new attachments.


Have fun 😎

[hubblec4]

Thanks a lot for all your work.

[VBB]

Thanks Mosu!

[Perenista]

I have a situation with the app...

- With a MKV open I am trying to add track #1 (MP3 audio) from an AVI. The AVI has 2 audio tracks.
- Then I have chosen all these options:

https://i.postimg.cc/Bnr3W5k2/X1.png

The problem is: MKVToolnix is saying "default: YES" for both audio tracks and telling me portuguese is their language.

I get it that MKVToolnix is saying PT for both. What shouldn't happen here is default: YES. It should be default: NO for the two.

This is after I edit the MKV before saving, so fixing the problem described:

https://i.postimg.cc/mrBdFtF0/XX2.png

Doing this to dozens of videos is going to be a waste of time....

If I am not mistaken what is missing here is a new option, which is only available for subtitles:

Disable "default track" flag for audio tracks

[Mosu]

You're not up to date what the "default track" flag means according to the current Matroska specification. That meaning has changed within the last year or so, and MKVToolNix was adjusted to match that new meaning. Please see this post (https://forum.doom9.org/showthread.php?p=1948368#post1948368) where I've written about it a few days ago. I also have a slightly more concise FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Default-and-forced-flags-and-default-yes-no-in-the-GUI#meaning-of-the-flags) on the topic.

[Mosu]

Anyone using MKVToolNix v60 should probably check the preferences → "Multiplexer" → "Process Priority"& set it to "lower" if it's on "lowest", v60's new default. Unfortunately "lowest" is substantially slower on Windows, even if nothing else is going on.

Unfortunately I forgot to mention that new default in the NEWS.md file for the v60 release. I've now changed the default to "lower" and included a note in NEWS.md.

This problem only affects users with a new installation/when no settings file exists.

[Liisachan]

Just curious: why not "Normal priority" by default? The OS, by default, automatically lowers the priority if the process is background anyway, plus today's CPUs are multicore and not so easily monopolized (muxing is not CPU-intensive).

Another thing that could have been in the news is: "MIME type handling for ttc fonts has been fixed".
Now one can create good MKVs again via GUI with font attachments (both compatible files and new-player-only files). Finally :)

@Perenista
In the new specs, things are more flexible and more than one audio (or subtitle) tracks can be Default=YES. Since it's flexible, we can manually set Default=YES/NO as we like, and (if desired) make it so that only one audio track and only one sub track have Default=YES - that's what I do anyway. For example, suppose you have two tracks with the identical subtitle text, one being more styled & CPU-intensive, the other being less so. You can mark whichever as Default=YES as you like, the other as Default=NO, assuming that the player will auto-select the Default=YES track when the file is played and the other track is manually selectable.

[Mosu]

Just curious: why not "Normal priority" by default? The OS, by default, automatically lowers the priority if the process is background anyway, plus today's CPUs are multicore and not so easily monopolized (muxing is not CPU-intensive).

It was on "normal" by default until v60. The thing here isn't CPU load, it's actually I/O load. The setting actually causes mkvmerge to lower both its CPU and its I/O priority.

The trigger was a report from a user complaining that mkvmerge using 350 MB/s of I/O bandwidth (fast SSDs, multiple mkvmerge processes running in parallel) was bringing their system to a standstill. A lower-than-normal I/O priority is totally appropriate here as it signals to the OS that what mkvmerge does isn't the most important thing (and it really isn't — interactive things such as web browsers, music/video players are always more important).

Sure, I simply could have told them to lower the priority themselves, but I'm a firm believer that in that while configurability is nice to have (and very important to a lot of people), having the default settings be appropriate for most users is even more important.

Another thing that could have been in the news is: "MIME type handling for ttc fonts has been fixed".

Not sure what you're missing. The following entry is present for v60:

* MKVToolNix GUI: multiplexer: when the option "use legacy MIME types for font attachments" is enabled, the GUI will now use `application/x-truetype-font` for font collection files.

[Liisachan]

It was on "normal" by default until v60. The thing here isn't CPU load, it's actually I/O load. The setting actually causes mkvmerge to lower both its CPU and its I/O priority. Ah, I see. That makes sense. And you're right, for some reason I didn't notice that ttc entry in the changelog (though I knew the issue itself had been fixed). Thanks again!

[quietvoid]

When adding multiple tracks with numbered naming like "XX 1", "XX 2", the tracks are automatically appended together with seemingly no way to separate them.
Is there an option to avoid this behaviour?

[Mosu]

Sure, in the preferences → "Multiplexer" → "Detect file name sequences"

[quietvoid]

Cool, thank you.

[markfilipak]

I've been searching for a solution for about 7 hours and have not found Joy.

How do I simply concat VOBs and remux them? The concat works like magic, but the subtitle streams are missing.

Thanks,
Mark.

FFPROBE h:\VIDEO_TS\VTS_04_1.VOB
Stream #0:0[0x1bf]: Data: dvd_nav_packet
Stream #0:1[0x1e0]: Video: mpeg2video (Main)...snip
Stream #0:2[0x20]: Subtitle: dvd_subtitle
Stream #0:3[0x21]: Subtitle: dvd_subtitle
Stream #0:4[0x22]: Subtitle: dvd_subtitle
Stream #0:5[0x23]: Subtitle: dvd_subtitle
Stream #0:6[0x24]: Subtitle: dvd_subtitle
Stream #0:7[0x25]: Subtitle: dvd_subtitle
Stream #0:8[0x26]: Subtitle: dvd_subtitle
Stream #0:9[0x27]: Subtitle: dvd_subtitle
Stream #0:10[0x28]: Subtitle: dvd_subtitle
Stream #0:11[0x29]: Subtitle: dvd_subtitle
Stream #0:12[0x2a]: Subtitle: dvd_subtitle
Stream #0:13[0x2b]: Subtitle: dvd_subtitle
Stream #0:14[0x2c]: Subtitle: dvd_subtitle
Stream #0:15[0x2d]: Subtitle: dvd_subtitle
Stream #0:16[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream #0:17[0x81]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:18[0x82]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:19[0x83]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:20[0x84]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s

MKVMERGE --output concat.mkv h:\VIDEO_TS\VTS_04_1.VOB

MKVINFO --summary concat.mkv
Track 1: video, codec ID: V_MPEG2, mkvmerge/mkvextract track ID: 0...snip
Track 2: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 1...snip
Track 3: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 2...snip
Track 4: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 3...snip
Track 5: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 4...snip
Track 6: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 5...snip

PS: 'FFMPEG -i "concat:h:\VIDEO_TS\VTS_04_1.VOB|..." -map 0 -codec copy -dn concat.mkv' takes forever or pukes on PTSs or both.

[Mosu]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

[markfilipak]

MKVToolNix doesn't support reading subtitles directly from DVDs. You'll have to extract them with other software such as Subrip or Subtitle Edit. Then feed those extracted files to MKVToolNix.

Ah! Thanks, I think what I'll try next is this:
MKVMERGE --output AVTEMP.mkv VTS_xx_x.VOB
FFMPEG -i AVTEMP.mkv -map 0 -i "concat:VTS_xx_1.VOB|VTS_xx_2.VOB.." -map 1:s -codec copy TARGET.mkv
Hopefully, because I'm asking it to only mux the subtitles, FFMPEG will be smart enough to entirely bypass PTS-rounding issues and the infamous "Timestamps are unset in a packet for stream.." warning. But I suspect that FFMPEG is not that smart and I'll be back at square one.

Is there a way to do the muxing entirely in MKVMERGE via '--subtitle-tracks n,m,...' without messing with 'n,m...' at all? In other words, is there a way to tell MKVMERGE to mux in all subtitle tracks without indexing those tracks? Oh, wait, I'll bet that's why you included a special '-1' stream number (i.e. all streams). I'll try to figure out how to use it with '--sync' but exclude the video stream.

What I'm doing (in my notation):
23.9fps[24pps] --> 24fps[24pps] (via forcing PTSs in FFMPEG [note 1]) --> 60fps[60pps] (via vapoursynth.InterFrame [note 2]).
[note 1] Forcing PTSs does 2 things: 1, it corrects the running time so that the result is identical to what's seen in theaters (i.e. 24fps), and 2, it creates absolutely correct CFR PTSs that are montonically increasing and are purely integer (thereby avoiding rounding errors).
[note 2] Motion vector interpolation to 60fps[60pps] eliminates telecine judder on 60Hz TVs. I've already done this and it looks incredible. I'm trying to automate the process.