Tap-to-time provides the user the ability to tap to the lyrics/syllables
of the song in order to time lines or karaoke. It consists of these
extra UI interactions:
- **Indicator**: tap marker: a designated marker that can be moved to
the current audio position; indicated in:
- the audio display by a green arrow underneath a marker
- the karaoke display by a green-colored syllable
- **Control**: tap marker: the tap marker can be changed by selecting
syllables on audio display in karaoke mode, or clicking the markers on
audio display in dialogue mode
- **Control**: ctrl-right-click audio display: starts playing the audio
from that exact position until the end of the file
- **Option**: Timing/Tap To Time: enables the tap marker indicator and
commands
- **Button**: time_opt_tap_to_time: toggles the Timing/Tap To Time option
- **Button**: time_tap_connect (hotkey I): a command that:
- moves the tap marker's position to the current playing audio
position
- sets the next marker to be the tap marker
- if the tap marker is already the last marker AND BOTH autocommit AND
next-line-on-commit is ON, will move onto the next line
- if moved on to the next line, also sets the start marker to the current
audio position, so the two lines are connected, and moves to the
next tap marker (essentially reinvoking time_tap_connect once)
- **Button**: time_tap_no_connect (hotkey O): similar to
time_tap_connect, except it will not set the next line's start
position even if moved to the next line
Expected workflow:
1) User loads song lyrics
2) User splits each line into syllables
3) User turns on tap-to-time, autocommit, and next-line-on-commit
4) User plays audio from beginning, tapping time_tap_connect to each
syllable, occasionally tapping time_tap_no_connect when a break between
lines is desired
5) If user messes up a line, they can set the tap marker to where they
want to restart from, and ctrl-right-click to start the audio a few
seconds before it
6) Syllables can be split/merged at will, and adjustments to timing can
be done using normal karaoke timing controls
Having the timing correction in MoveMarker is extremely surprising
behavior if any other part of the code uses MoveMarker expecting it to
work correctly as advertised
Some matroska files have audio start at timestamp 0 and video later.
In this case mkvtoolnix seems to use the first block of the first
cluster to the audio track (I would assume this is only an
implementation detail and not really from the matroska specs. And also
could happen in other cases without the video being delayed, but that's
not the point). Aegisub used to read this first block and use its
timestamp as the starting point of the video track.
With this commit, Aegisub tries to read all the blocks until it can read
the first timestamp of the video track and use it for the subtitles'
timestamps. Audio tracks don't seem to be impacted by these changes.
[src\meson.build] Add DirectWrite has dependency
[src\font_file_lister_gdi] Rework GDI FontCollector to use DirectWrite
This replaces all the logic of using the Windows registry to obtain the font path by using DirectWrite. The goal is simply to improve the quality of the code. This doesn't change any functionality
[src\meson.build] Remove Uniscribe has dependency
Uniscribe was only used for the FontCollector. Since we now use DirectWrite, we don't need it anymore.
[src\dialog_fonts_collector] Catch exceptions that FontCollector may raise
On Windows, the initialization of the FontCollector can raise an exception
[src\font_file_lister] Document the exception that GdiFontFileLister can throw
[src\font_file_lister_gdi] Correct possible memory leak when an error occur
Fix error caused by AddFontResource on Windows 10 or higher
[meson.build] Replace add_project_arguments with conf.set for HAVE_DWRITE_3
[src\dialog_fonts_collector] Update message error and optimisation
[src\font_file_lister_gdi] Correct documentation typo
[src\font_file_lister_gdi] Cosmetic nit - Initialize hfont in one line
[src\font_file_lister_gdi] Cosmetic nit - Remove if statements brace
[src\font_file_lister_gdi] Replace WCHAR param of normalizeFilePathCase to std::wstring
[src\font_file_lister_gdi] Replace WCHAR by std::wstring
[src\font_file_lister_gdi] Use IDWriteFontFace::GetSimulations to detect fake_italic/fake_bold
See this comment: https://github.com/arch1t3cht/Aegisub/pull/107#issuecomment-1975229652
[src\font_file_lister_gdi] If Win7/8 has Win 10 SDK on compile time, correctly verify if font has character(s)
With the Visual Studio 2019 toolchain on Windows 7, it installs the Windows 10 SDK by default. Because of this, ``HAVE_DWRITE_3`` is true, so the ``QueryInterface`` always fails. Now, if the ``QueryInterface`` fails, we try to verify if the font has characters with a Windows Vista SP2 compatible code.
[src\font_file_lister_gdi] Support facename that contains only whitespace AND truncated facename
Problem 1:
Previously, if a user wrote "\fn ", it would return the font Arial, which is not what we want. This is because when we request EnumFontFamiliesEx with whitespace or an empty lfFaceName, it will enumerate all the installed fonts.
Solution 1:
To resolve this issue, let's implement a solution similar to libass to determine if the selected facename exists: 649a7c2e1f/libass/ass_directwrite.c (L737-L747)
Problem 2:
GDI truncates font names to 31 characters. See: https://github.com/libass/libass/issues/459
However, since I changed the method to determine if a facename exists, I ensured that we still support this "feature".
To test this, I used the font in: https://github.com/libass/libass/issues/710
[src\font_file_lister_gdi] Add a FIXME comment regarding the utilization of std::wstring over WCHAR
[src\font_file_lister_gdi] Add FIXME comment about charset
This can be useful when scripts want to read the entire frame
and pass it on somewhere else (say, write it to a file or use some
library function on it).
This still breaks when the 0 digit is narrower than some other
digit, but that's unlikely and the current behavior now matches
the original behavior when all times are < 10h.
Fixesarch1t3cht/Aegisub#111 .
This is what users will want in the majority of cases, and switching
to this makes using this function much easier.
However, this does break backwards compatibility. Luckily to my
knowledge this function is not actually used in any existing published
script (all scripts using get_frame just use getPixelFormatted instead)
so the damage shouldn't be too large. But this is also why I'd rather
rip off the band-aid of breaking backwards compatibility now than later.
When destroying a frame handle, the previous logic would copy the
shared_ptr in the userdata and then free it twice (once explicitly
and once at the end of the function), which is actually UB, even
if if worked fine so far. This commit now ensures that it's the
actual userdata's shared_ptr that's freed in the gc function.
An unfortunate consequence of this is that the grid widths have to
be computed on every change to line timing, which will probably
have an impact on timing performance when autocommit is enabled.
It's probably not a huge impact but it's worth keeping an eye on.
All current renderers and muxers have no issues with longer timestamps.
However, classic VSFilter keeping track of time with a 32-bit int,
leads to a more meaningful limit at 596h, so enforce that instead.
Since the stringification code for SRT and ASS (but not SMPTE) relied on
hours being single digit, replace them with a simple format string.
GUI inputs are still limited to <10h, but at least
pre-existing timestamps no longer get mangled.
odrling