MKVToolNix v83.0 released

[SEALBoy]

Originally Posted by Mosu

It does have to do it this way, yes, as all frames of all tracks are interleaved by their timestamps. This means that all frames of video, audio & subtitle tracks that should be played at timestamp X are located closely together in the file. Conversely this means that the frames of a single track (no matter its type) are distributed all over the file. Taking out those frames isn't possible, and putting others into their place (or rather: where they should be located according to their timestamps) doesn't work either.

[GAP]

1. Are there any differences between the 32 bit and 64 bit versions that I should know about?
2. How do you append files with re encoding?

[von Suppé]

2. AFAIK MKVToolNix doesn't re-encode. You can append files in the input window by rightclick on your sourcefile --> Append files

[Liisachan]

1. Function-wise, probably no. A file written by a 32-bit version will play fine on a 64-bit OS and vice versa. Generally speaking, though, a 64-bit version should be slightly more efficient when muxing.

Incidentally, which version you used to create your MKV will be recorded in that MKV itself, and publicly visible if you share your file. In case you want to author it anonymously, a 64-bit version (much commoner) may be better for anti-fingerprinting.

You could also spoof MuxingApp / WritingApp strings too, hiding not only the "bit-ness" (32 or 64) but the Mkvmerge version, though perhaps doing something like this is stupid & pointless; e.g.

@REM Lying about WritingApp, setting a random string
mkvpropedit.exe muxed.mkv --edit info --set "writing-application=Lavf65.43.210"

Edit
PS: If you really want to change the writing-application string, you should also add --disable-track-statistics-tags option when muxing; otherwise, _STATISTICS_WRITING_APP will reveal the original writing app.

[Mosu]

Originally Posted by Liisachan

You could also spoof MuxingApp / WritingApp strings too, hiding not only the "bit-ness" (32 or 64) but the Mkvmerge version, though perhaps doing something like this is stupid & pointless; e.g.

In rare cases this might actually lead to problems. When reading Matroska files mkvmerge uses the writing app/muxing app strings to enable workarounds for certain bugs in certain versions of software. Luckily this hasn't been needed for quite a while now, so the chances are next to none of this being triggered accidentally. I just wanted to mention it for completeness' sake.

[tormento]

I have a variable framerate mkv file. As AVS doesn't support vfr, my idea was to export timestamp from matroska, encode the video assuming a fixed fps and then reapply the timestamp code.

Is there a way to export timestamp from the original mkv and apply to the final one?

[filler56789]

Originally Posted by tormento

Is there a way to export timestamp from the original mkv and apply to the final one?

With mkvextract:

Timestamp extraction:
The sixth mode finds the timestamps of all blocks for a track and outputs a timestamp v2 file with these timestamps.

Example:

mkvextract "a movie.mkv" timestamps_v2 1:timestamps_track1.txt

[tormento]

Originally Posted by filler56789

With mkvextract

And that would give me the capability to "transform" a constant framerate encoded (as I can't see alternatives) in a variable one?

[filler56789]

Originally Posted by tormento

And that would give me the capability to "transform" a constant framerate encoded (as I can't see alternatives) in a variable one?

Yes. mkvmerge can use a timestamp file for converting CFR to VFR.

[vrpatilisl]

hello, everybody, new update is very good. i have sony alfa 6300 camera also have shot some home videos with that.I want to append video files and creat one longer video file but don't want to lose any quality. i attach both filesmedia info txt here can anybody expert please go through it and let me know what i am losing if any?
thanks

please find TXT files in attachment.

[Mosu]

Hey everyone.

Hope y'all are having a couple of stress-free days behind & ahead of you, whatever you might or might not celebrate. I still haven't had much energy to invest into coding, to be honest, but decided to do one last release in 2021 anyway, mostly fixing a couple of smaller issues — especially the wrong-sized icons on high DPI displays, which I've gotten so many bug reports about 😁

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

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 since the previous release:

Version 64.0.0 "Willows" 2021-12-27
New features and enhancements

• MKVToolNix GUI: language dialog: when the user switches between the two edit modes, the mode's corresponding first control is automatically focussed.

Bug fixes

• all: language lists: the entries for "Ancient Greek (to 1453)" and "Modern Greek (1453-)" have been renamed to "Greek (ancient, -1453)" and "Greek (modern, 1453-)" respectively in order to be easier to find.
• mkvmerge: VobSub reader: files containing "id: --" lines to indicate that the track language isn't known were rejected by "mkvmerge". Now they're accepted, and "und" (undetermined) is used as the language. Fixes #3246.
• MKVToolNix GUI: chapter editor: the "Save to Matroska or WebM file" function was using the wrong standard file dialog (the "open file" one instead of "save"), leading to confusing button names. Fixes #3242.
• MKVToolNix GUI: high DPI scaling: fixed the icons in the tool selector having the wrong size for scaling factors other than 100% or 200%. Fixes #3229.

Build system changes

• The bundled "fmt" library was updated to v8.0.1.
• The bundled "nlohmann-json" library was updated to v3.9.1.
• The bundled "pugixml" library was updated to v1.11 revision 6a76cac.
• The bundled "utf8-cpp" library was updated to v3.2 revision b85efd6.

Have fun 😁

[filler56789]

Thanks for the endless updates

[videoh]

Thank you for high DPI support!

[SeeMoreDigital]

Wonderful job

[VBB]

Thank you Moritz, and a happy 2022!

[tormento]

Originally Posted by filler56789

Yes. mkvmerge can use a timestamp file for converting CFR to VFR.

Thanks!

And how can I convert an existing vfr MP4 into a MKV?

[filler56789]

Originally Posted by tormento

And how can I convert an existing vfr MP4 into a MKV?

mp4fpsmod?

mp4fpsmod 0.26
(libmp4v2 trunk-r507)
usage: mp4fpsmod [options] FILE
  -o <file>             Specify MP4 output filename.
  -i, --inplace         Edit in-place instead of creating a new file.
  -p, --print <file>    Output current timecodes into timecode-v2 format.
  -t, --tcfile <file>   Edit timecodes with timecode-v2 file.
  -x, --optimize        Optimize timecode
  -r, --fps <nframes:fps>
                        Edit timecodes with the spec.
                        You can specify -r more than two times, to produce
                        VFR movie.
                        "nframes" is number of frames, which "fps" is
                        aplied to.
                        0 as nframes means "rest of the movie"
                        "fps" is a rational or integer.
                        For example, 25 or 30000/1001.
  -c, --compress-dts    Enable DTS compression.
  -d, --delay <n>       Delay audio by n millisecond.
  -T, --timescale <keep|n>
                        keep: Keep original timescale.
                        n: Set timescale of videotrack to n.

[tormento]

Originally Posted by filler56789

mp4fpsmod

Wow, thanks.

[Mosu]

Originally Posted by tormento

And how can I convert an existing vfr MP4 into a MKV?

Simply remuxing it with MKVToolNix should suffice.

[SeeMoreDigital]

Indeed...