There's no apparent reason that we need our packets to be "second-aligned".
Neither does the heuristic that picks the divisor looks sensible anyway.
25 should be a good divisor for all common sample rates, as the derived packet
size/length will be sensible and consistent (40ms). The packets will keep on
being "second-aligned", regardless of whether that is necessary.
Also making sure that m_min_packet_size is no less than 4ms for the 44.1KHz
family.
Determining the path to the current executable uses several functions
of boost::filesystem::path. Therefore their locale should be
initialized before they're used.
gettext 0.21 caches opened catalogs differently than prior versions
did, at least on mingw, where it handles directories as wide-char
strings instead of char-strings.
MKVToolNix always initializes the English locale first. The
command-line parsers are the ones that call `gettext()` before they
start parsing the command-line arguments. That happens right in the
common initialization/setup routine.
For `gettext()` initialization MKVToolNix must provide the path to the
catalogs. For Windows it concatenates the installation path (meaning
the directory the current executable is located in) with the
sub-directory `locales`.
During that very first initialization the path to the current
executable hasn't been determined yet, though, resulting in the
relative path `locales` to be passed to
`bindtextdomain()`. `gettext()` then locates the English catalog,
finds it, opens it & caches its location.
After parsing the command-line arguments MKVToolNix might need to
change the locale (e.g. due to the `--ui-language` argument or, in
case of the GUI, due to values stored in its configuration). At that
point the exe location has been determined. Therefore the next call to
`bindtextdomain()` will receive an absolute path, not a relative one.
For some reason I wasn't able to determine this leads to the lookup of
cached catalogs coming to the (wrong) conclusion that the catalog's
been opened already, even though the requested locale is
different (e.g. `de` vs. the initial `en`). No matter, the
already-opened catalog for English is used.
This patch changes determining the path to the exe to be the first
action to be taken in the common initialization/setup routine. That
way the first invocation of `bindtextdomain()` will also be done with
an absolute path; in fact, all calls to `bindtextdomain()` will now be
done with the same absolute path.
The result is that the cache lookup inside `gettext()` comes to the
right conclusion that the catalog for locales other than English has
in fact not been opened yet. It does another lookup, this time for the
new locale, and everything works as expected.
The directory initially selected in the dialog is now based on the
settings regarding how the destination file name should be constructed
automatically. For example, if that setting is set to "fixed
directory", the dialog's initial directory will be set to the that
fixed directory from the preferences.
Fixes#3021.
