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.
macos-latest now runs on Apple Silicon, which fails one test
and probably still needs extra work for the packaging to work.
Until that's figured out, run on macos-13.
Equivalent functionality (allowing dependencies to be meson subprojects
and fixing the zlib HAVE_UNISTD_H issue) was merged upstream now
(thanks kasper), so this is no longer necessary. dav1d is now
enabled using -Dffmpeg:libdav1d=enabled.
Update API usage, incorporate new features, and refactor a bit:
- Use new progress callback to show progress bar
- Use new frame info functions to get timecodes/keyframes instead of
manually decoding
- Use new tracklist API to show track selection dialogs
- Expose option of whether to apply RFF
- Show a warning when bestsource had to revert to linear decoding
- Reuse the swscale context across frames and ensure the format
stays constant
- Add xxhash wrap
- No longer mark the bestsource video provider as slow
[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
odrling