This commit fixes the broken ISO labels when using characters outside of the character set supported by ISO-8859-1. Every dstring written to the UDF headers is now inspected whether it can use the limited encoding or if it's necessary to encode it as 16-bit. This has the advantage of leaving all the dstrings which don't need 16-bit encoding, like folder and file names, without any modification in the file structure.
It turns out that playing sound files available as application resources is as simple as using QSoundEffect with a qrc URL. This saves us from all the shenanigans previously done in order to save the resource to a file just to be able to pass it to a QSound object.
The contents of the UI tab were saved as inline HTML in the UI file for TsMuxerWindow. Making them translatable would've exported the content to .ts files, which means that translators would have to put up with not only HTML, but HTML with XML escaping applied into it.
Moving the content to an external file seems like a best approach in this case. The content of the file is loaded in the appropriate language when switching languages. The HTML files themselves are included as resources at build time.
This commit erases all usages of std::wstring from the face of the project and reduces wchar_t usages to the necessary minimum, mostly for interoperability with WinAPI functions. UTF-8 encoded std::strings are used in place of std::wstring objects, and code which must operate on actual characters instead of the bytes which might represent a character has been modified in order to work properly - mostly the subtitle renderer and reader classes.
This change brings translation support to the tsMuxeR GUI. We have a Russian translation available so far, thanks to @abakum. The last selected translation is saved in the settings file and restored at the application's next startup. The currently used language is selectable by a combo box in the lower left corner of the window.
When joining several m2ts together (either in a mpls or manually), tsMuxer takes into consideration the start-time of the first file only.
This results in an incorrect subtitle start time when the m2ts don't all have the same start-time.
This simple fix solves this bug.
After #205, tsMuxer is reading over the end of the mp4 file, which results in erratic behavior -Visual Studio build works correctly, but cmake build does not.
This fix allows to stop the reading of the mp4 file at the last atom, before end of file.
The POSIX compatibility layer provided by the Microsoft C Runtime Library
treats its string arguments as if they were passed to the A-family of WinAPI
functions, which means that they undergo conversion to the ACP before being
passed to the actual WinAPI call. Passing UTF-8 encoded strings could have
never really worked.
Also, remove unused code in utf8Converter.cpp and remove the "sfDefault" from
the SourceFormat enum, whose meaning was platform-dependent anyway and did not
make sense anymore, as we now default to UTF-8 on non-Windows platforms anyway.
Processing falls back to the ACP on Windows to keep backwards compatibility.
