Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
20th June 2021, 23:51 | #1121 | Link |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
Attachment mime types: non-font-related side effects of the library change
As for font mime types, the new beta (58.0.0.30 tested) is clearly more reasonable. There are other (non-font-related) subtle differences, of which none seems really important so far, though some kind of issues might occur in rare situations because there are so many changes.
[58.0.0] -> [58.0.0.30] * = winner who guessed the registered type correctly (libmagic rules) vorbis.ogg = [audio/ogg]* -> [audio/x-vorbis+ogg] theora.ogg = [video/ogg]* -> [video/x-theora+ogg] .mp2 = [audio/mpeg]* -> [audio/mp2] (libmagic sucks) .m4a = [audio/x-m4a] -> [audio/mp4]* .ac3 = [application/octet-stream] -> [audio/ac3]* .rar = [application/x-rar] -> [application/vnd.rar]* (the new library seems cleverer in some cases) .mka = [video/x-matroska] -> [audio/x-matroska] .ass = [text/plain] -> [text/x-ssa] .wv = [application/octet-stream] -> [audio/x-wavpack] (some of other differences) .xml = [text/xml] -> [application/xml] .log = [text/plain] -> [text/x-log] .mtxcfg = [application/json] -> [text/plain] .ffindex = [application/zlib] -> [application/octet-stream] |
21st June 2021, 08:57 | #1123 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Thanks for the overview, Liisachan. I hadn't looked into it in detail as much.
Yeah, Qt can take both the content & the file name (= the extension) into account and will use the extension for resolving ambiguities. A lot of the differences you've noticed are down to using the extension, especially .mka = audio/… Even though some of those changes are debatable, I actually agree with these, for example: There is a clear difference between a file's encoding and its semantics. What I mean by that is: just because a file has been compressed with the z compression library doesn't mean that any other application than ffmpeg can make use of the uncompressed contents. Same with .mtxcfg files; just because it's JSON doesn't mean any other application storing their settings in JSON can make sense of my GUI's settings. That's why such files need their own MIME type, and if there isn't a specialized one, a more generic MIME type makes more sense.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
21st June 2021, 16:12 | #1125 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Yes, it does.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
21st June 2021, 18:11 | #1126 | Link | |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
Quote:
Code:
ren *.ac3 *.pt.ac3 ren *.srt *.pt.srt |
|
21st June 2021, 20:42 | #1127 | Link |
Registered User
Join Date: Jun 2013
Posts: 6
|
Has something changed between 53 and 57-58 with regards to appending, specifically --append-mode file and track? I've been using your program to split and append matroska files and have had no problems except when the files had subtitles which I fixed by adding the option --append-mode track. If I left it at default, the file would freeze video for 1-2 seconds (audio would still play) at the point where the 2 files were joined and then start playing normally. The append-mode track option would resolve this problem until I installed 57. I tried 58 as well, but have eventually gone back to using 53.
|
21st June 2021, 20:53 | #1128 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
No, the code dealing with appending tracks & files hasn't changed in a long time.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
22nd June 2021, 07:37 | #1129 | Link | |
Registered User
Join Date: May 2017
Posts: 18
|
Quote:
This will be a palliative measure that will help to get around this problem for now. I'm even preparing a new video on my channel on this subject of the "LanguageIETF" element, in it I'll give people some tips, trying to alleviate this situation. Your tip will be in the video for sure. Greetings from Brazil. |
|
22nd June 2021, 12:12 | #1130 | Link | |
Registered User
Join Date: Dec 2013
Posts: 13
|
Quote:
Windows 64bit and v58.0.0 |
|
22nd June 2021, 15:15 | #1131 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Can you post the pictures somewhere else, please? It can take quite a bit for attachments to be approved here from time to time. You can easily upload them to my file server. Thanks.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
24th June 2021, 12:46 | #1132 | Link | |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
Quote:
Code:
[settings] updates\checkForUpdates=false |
|
24th June 2021, 14:08 | #1133 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Just a small clarification: MKVToolNix only checks whether or not there's an update available. It does NOT contain code to update itself.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
24th June 2021, 16:00 | #1134 | Link | ||
Registered User
Join Date: May 2017
Posts: 18
|
Yes, palliative, because any other language that is also inside the folder will be renamed.
At the moment, I've opted for this alternative below, but it suffers from the same problem as the *.cmd script hint. Quote:
Quote:
For batch blending of series I will leave a video of my own, where I show how to do this without the need for commands. Downloadable software is in the video description. How to Merge Audio+Subtitles from Batch Series https://youtu.be/XR5Ez9eSRQM Last edited by Vicio; 24th June 2021 at 16:44. |
||
24th June 2021, 22:52 | #1135 | Link | |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
Quote:
ren *1.ac3 *1.pt.ac3 ren *2.ac3 *2.en.ac3 Your pattern might be more complicated; you might have to use something like Perl that generates your command line, or you might have to use ugly FOR in your batch file itself. Think this as a great opportunity to try new things. Leaning script-fu will save your time greatly in the long run — a blessing in disguise. Another simple option. Though it depends, using a text editor and directly editing the command-line is often faster once you understand how it works, than manually clicking here and there. This might be a generation gap, though. We didn't have any GUI for Matroska until MMG came out. We started by typing "regsvr32 kaxdemux.dll" to just play a MKV file ^^; PS (2021-06-25): @Vicio I mean, even if you can save 4 clicks or 40 clicks per track, muxing say 13 similar files (1-season episodes of the same series) using GUI is painfully tedious. Instead, you can prepare the command line for Episode 1 (here you can use GUI and copy-paste the command line), and then copy-edit it a little to make a 13-line batch file, "mux13eps.bat". While this batch file editing is usually easy enough (surely easier than doing the equivalent thing one by one on GUI), you could even automate that if you want to (for example, if there are 10 seasons x 13 files to mux, you may want to create a "meta-script" first which generates a big batch file automatically). @Mosu Thanks for clarification about updating check, and for fixing the year 2038 problem! Last edited by Liisachan; 25th June 2021 at 23:43. |
|
27th June 2021, 09:59 | #1136 | Link |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
leap sec quagmire
@Mosu
Though this is something technical and practically not yet important, robUx4 is thinking that, becuse say 2021-01-01T00:00:00Z is not exactly 20 years (counted in SI seconds) after 2001-01-01T00:00:00Z, the Date value for it should not be D = 86400*10^9*365.25*20 = 631152000000000000 = 0x08C2 4D66 6747 0000, but 5 leap seconds should be counted: D + 5*10^9 = 631152005000000000 = 0x08C2 4D67 914C F200. https://github.com/ietf-wg-cellar/eb...ion/issues/411 Though this is ideal, it’s non-trivial to be leap-second-aware; the meaning of the Date value will become ambiguous (is the writer/parser leap-sec aware or not?). What do you think? Would you implement this in MkvToolNix? If the standard becomes rigorous like that, 0x08C2 4D66 6747 0000 is no more 2021-01-01T00:00:00Z but 2020-12-31T23:59:55Z, the conversion between the value and a human-readable string being difficult or even impossible for the future value where we don't yet know how many more leap secs there will be. |
27th June 2021, 10:38 | #1137 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
I seen but not read the discussion around leap seconds. For me it's really easy: we're storing the number of nanoseconds elapsed since 2001-01-01 00:00:00 UTC. This is basically the same as what in computer terms is called the "Epoch" or the "Unix Epoch", just in nanoseconds instead of seconds & a slightly different reference date. It is a very, very common way to store dates & timestamps.
This representation doesn't concern itself with leap seconds at all, nor does it concern itself with time zones. Both only come into play when converting between that number of nanoseconds and a different representation/system, e.g. year-month-day hour:minute:second. That conversion is definitely varying over time, sure, especially when you create a file with a date that is, at the point in time when you create the file, in the future. But that's simply how it is. Other ways of expressing & storing date information has other problems, and most are very quirky edge cases. For example, if you decide to store a date as, let's say, six integers representing year, month, day, hours, minutes and seconds. You might think that his is fine. However, as soon as you introduce a leap second somewhere, how do you store it? You could store the value 60 for a second. Most software out there, however, will break somehow if you use 60 as a number of seconds (in the form of 2345-06-07 08:09:60). And if you want to do any sort of calculation with that type of storage (e.g. calculating the difference between two timestamps stored in this six-integers-format) you cannot simply convert those six integers to a number of seconds by multiplying & adding them all up, because for certain ranges there were 61 seconds in a minute and not just 60. Aaaaand then there are things such as countries changing time zones. And some countries simply skipping over whole sections of their calendar. If you want to go down this rabbit hole some more, see Tom Scott's excellent & entertaining video on the topic. Or to put it differently: what we think of as a "year" is actually a timeframe with of varying length. Both leap seconds & leap years make sure of that. Your calculation "86400*10^9*365.25*20" is therefore fundamentally wrong as it assumes that all years are equally long. Which they aren't. Storing the "Unix Epoch" value (or an equivalent) is an incredibly sane way to represent timestamps. You always have to take leap seconds, time zones into account anyway. So that's what MKVToolNix does (via Qt or other libraries): it converts between that epoch & a components-based representation based on all conversion rules available at the time of the conversion (when the user uses the program). In that way it seems Steve & I are in agreement.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. Last edited by Mosu; 27th June 2021 at 10:43. |
27th June 2021, 12:28 | #1138 | Link |
李姗倩 Lǐ Shān Qiàn
Join Date: Nov 2002
Posts: 1,340
|
I agree with you that counting leap seconds would be ideal, but this is not yet a solved problem in real life. On the contrary, not counting leap seconds is still quite common, while only a few "good" systems are leap second-aware.
A Unix timestamp, for example, is usually the number of seconds that have elapsed since January 1, 1970, 00:00 UTC, not counting leap seconds. That's why one says 2^31−1 <=> 2038-01-19T03:14:07Z. Counting leap seconds, this conversation wouldn't be deterministic, and the Y2038 problem would occur about 30 seconds before 03:14:07. The current version of MKVToolNix, too, converts e.g. 2038-01-19T03:14:07Z <=> 0x1039BFC8B3303600, not counting leap seconds (use Header Editor to set that Date, then open it with Info Tool, see the hex dump). While counting leap seconds is definitely ideal, the real-life implementations are generally not so ideal yet. To avoid potential confusion, there could be a LeapSecondAware flag for Date; or a legacy Date & an optional LeapSecondAwareDate elements. New LeapSecondAwareDate could be even better if it were 16 bytes, instead of 8 bytes, to avoid the Y2293 problem of EBML, in case Matroska will be still popular in the 23rd century |
29th June 2021, 11:30 | #1139 | Link | |
Registered User
Join Date: Dec 2013
Posts: 13
|
Quote:
https://ibb.co/vvPfJM9 https://ibb.co/rvhy4Hv I have noticed this ONLY happens when the destination file name is x:\ and not if the destination filename has additional subfolders, e.g. x:\mkvstuff\ will not change to \\ when pressing CTRL+T Steps for Windows on v58.0.0 64bit: 1. Add a random video file into the multiplexer 2. Set destination folder to c:\filename.mkv 3. Add a file title 4. press CTRL+T or use the menu shortcut 5. the destination folder will change to c:\\filename.mkv Not a big deal, just odd behavior. This didn't happen a few versions ago because I would have noticed. |
|
29th June 2021, 12:05 | #1140 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Thanks, but I cannot reproduce it following your steps; for me the result after 4. is e.g. "C:\test title.mkv". Might be dependent on certain settings in the preferences.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
Tags |
matroska |
Thread Tools | Search this Thread |
Display Modes | |
|
|