MKVToolNix v83.0 released - Page 59

Mosu · 14th July 2021, 21:03

I've reconsidered and "improved" (= 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.

Quote:

Originally Posted by 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:

Code:

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.

Quote:

Originally Posted by Liisachan

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 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) and parsing those.

Thanks for all the testing & the feedback!

Liisachan · 15th July 2021, 02:55

Quote:

Originally Posted by Mosu

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 ]

Code:

<!DOCTYPE html><html lang="sl-rozaj-biske">
<head><title>test</title></head></html>

validates, while

Code:

<!DOCTYPE html><html lang="sl-biske-rozaj">
<head><title>test</title></head></html>

gets an error.

Quote:

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.

Quote:

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 · 15th July 2021, 08:27

Quote:

Originally Posted by Liisachan

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".

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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:

Quote:

Originally Posted by Liisachan

Really confusing...

!!! 😁

Liisachan · 15th July 2021, 16:59

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/lan...ubtag-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...).

Quote:

Originally Posted by Mosu

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:

Code:

Type: extlang
Subtag: min
Prefix: ms

But zh-min is grandfathered (i.e. an exception of the langtag rules):

Code:

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:

Code:

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 · 15th July 2021, 17:39

Quote:

Originally Posted by 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...).

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…

Quote:

Originally Posted by Liisachan

I suggest you use https://www.iana.org/assignments/lan...ubtag-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.

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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 · 15th July 2021, 21:04

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)

Code:

mkvmerge -o out.mka --language 0:ge in.ogg
mkvinfo out.mka
...
|  + Language: und
|  + Language (IETF BCP 47): hmj

Quote:

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

Ah, that's right!

Quote:

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

Quote:

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 · 15th July 2021, 21:58

Quote:

Originally Posted by 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')

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.

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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.

Quote:

Originally Posted by Liisachan

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 · 19th July 2021, 05:55

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 · 19th July 2021, 09:55

@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 · 19th July 2021, 14:04

Quote:

Originally Posted by 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.

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 · 21st July 2021, 05:08

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/".

Quote:

Originally Posted by Mosu

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 · 21st July 2021, 08:49

Quote:

Originally Posted by 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/".

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 · 24th July 2021, 11:23

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'

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 · 24th July 2021, 13:10

Quote:

Originally Posted by LeMoi

- 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:

Quote:

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 and here.

Quote:

Originally Posted by LeMoi

- 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, 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 · 24th July 2021, 16:09

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

Quote:

Originally Posted by Mosu

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 · 24th July 2021, 16:38

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 · 24th July 2021, 17:16

Quote:

Originally Posted by varekai

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.

Quote:

Originally Posted by varekai

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 · 24th July 2021, 17:23

Quote:

Originally Posted by LeMoi

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 · 24th July 2021, 19:24

The latest continuous builds have the sorting issue… sorted 😊

Perenista · 25th July 2021, 04:54

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?

19th July 2021, 05:55	#1168 \| Link
ctl-tx Registered User Join Date: Sep 2005 Posts: 22	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. Last edited by ctl-tx; 19th July 2021 at 06:00.

19th July 2021, 09:55	#1169 \| Link
varekai Registered User Join Date: Jul 2006 Posts: 530	@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 Last edited by varekai; 19th July 2021 at 10:04. Reason: .

24th July 2021, 11:23	#1173 \| Link
LeMoi Registered User Join Date: Sep 2004 Location: France Posts: 367	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' 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) Last edited by LeMoi; 24th July 2021 at 11:26.

24th July 2021, 16:38	#1176 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	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. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

24th July 2021, 19:24	#1179 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	The latest continuous builds have the sorting issue… sorted 😊 __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

25th July 2021, 04:54	#1180 \| Link
Perenista Registered User Join Date: Oct 2013 Posts: 207	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?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode