They're deprecated in the Matroska specs.
Also mark them deprecated internally in the code so that neither
mkvpropedit nor the header editor will write them when updating other
track header elements.
When adding files the GUI has special handling for
chapter/tags/segment info files, whose paths must be specified in the
corresponding text inputs. Those files don't show up like other
regular source files do.
This type detection is done by comparing their content to certain
patters via regular expressions. This recognition could wrongfully be
triggered if any such file was embedded in another file verbatim,
e.g. with a chapter XML file attachment in a Matroska file. When
trying to add that Matroska file, the GUI would treat it as a chapter
file instead of a regular one.
Fixes#3487.
Back when the code base was switched from `std::filesytem::path` to
`boost::filesystem::path` several bugs in `libstdc++` were found that
required workarounds for detecting whether directories exist & for
creating missing directories, especially with the handling of UNC
paths.
Even after switching back to `boost::filesystem::path` these functions
were still used. Turns out though that they don't work correctly with
UNC paths. Therefore we now remove those workarounds again & go back
to using the corresponding functions from `boost::filesystem`, which
work just fine.
Fixes#3483.
This might happen when executing the GUI from a directory the user
doesn't have access to. The GUI will always look for an exe in the
current working directory first, and if that's inaccessible the
one-argument variants of the various `boost::filesystem::is_…`
functions throw.
Fixes#3481.
Internally MKVToolNix always stores UTF-8-encoded narrow
strings. However, on Windows boost::filesystem uses the OEM CP by
default for narrow strings.
Fixes#3473.
First of all, it wasn't stripping whitespaces from each line of the
entry, but only from the start of the first & the end of the last
line (in other words: from the start & end of the whole entry).
Second, modifying during extraction is the wrong thing to do
anyway. The only modification done is removing any existing line feed
characters in order to have consistent Unix-style line endings.
Part of the fix of #3470.
gcc's implementation of the C++17 file system library doesn't support
UNC paths of style `\\?\…` on Windows. There doesn't seem to be any
progress towards implementing support for it.
Fixes#3058. See also #2916.
Added file types (both via the "add" button and via drag & drop) can
be either regular source files (files that are listed on `mkvmerge`'s
command line without preceding options; e.g. Matroska, MP4, SRT…) &
non-source files (for which special options are needed, e.g. chapter
files with `--chapters /path/to/file.xml`).
Until this commit all non-source file types were handled first. They
were always set in the currently-selected tab. All source files were
handled later, including the handling of where to add them (current
tab, all to one new tab, one new tab per file…).
This commit reverses the order: source files are handled first,
non-source files afterwards. The result is more consistent if the
choice where to add them is "all in a single new tab". With the older
model all non-source files were always set in the tab that was open
before adding the files. With the commit all added files will end up
in the new tab, both source & non-source files.
Fixes#3469.
Can prevent mis-detection if the file name has the wrong
extension. For example, a WAV file with DTS inside but with an
extension of `.dts` might be detected as the wrong type of DTS.
Fixes#3462.
