Geep

The HUD and subtitle guis could be made aware of each others' layout via existing and new CVars. So if you wanted to, say, have subtitle field widths shrink as inventory icon size enlarges, you could. Not saying that's a good idea, just that it's possible.

The Wench voice is the first one I've tackled that actually needs some audio clips to be done with srt. For that, I've downloaded and installed "Cadet", free captioning software produced by public TV station WGBH in Boston. Working with one clip, I was able to produce a srt file. Painful process, though. I clearly need to look at more Cadet tutorials....

You'd certainly want that override to happen. I don't know if it does. You could try a test by providing an override .ogg & subtitle. Specifically, as an override target, in 2.11, Dragofer provided a dozen subtitles for The Cynic voice as part of the core; see tdm_sound_vocals_decls01.pk4\subtitles\tdm_ai_cynic.subs. If you want to make a version of my testSubtitles... FM specifically for these dozen, here is content for an appropriate fm_test_subtitles_shaders.sndshd: BTW, this voice is used by two AI characters: tdm_ai_guard_citywatch (defined in tdm_ai_humanoid_guards01\def\tdm_ai_guard_citywatch.def) tdm_ai_thief (in tdm_ai_humanoid_guards01\def\tdm_ai_thief.def)

I'll be doing The Wench next. If anyone has a particular voice they want me to do sooner rather than later, let me know.

FYI, as this project goes forward, I plan to work first on barks for which a text vocal script is available. Complete bark text are available - via the wiki's "Voices" - for these: The Thug [done] The Grumbler [done] The Pro [done] The Mature Builder (Builder3) [done] The Young Builder (Builder4) [done] The Lord [done] Simpleton [done] Average Jack [done] The Lady [done] The Wench [done, final revision] The Commander [done] The Moor [done] The Maiden [done] These vocal sets are also referenced under "Voices", but the bark text is missing: Builder 1 & 2* [done] The Drunk [done] The Cynic [done] The Lady02 [done] The Critic [done] (* Builder 1 just uses Builder 2 vocal assets. Also, beyond the scope here: there are a few "conversation" clips used in the Saint Lucia FM, not intended for general use, even though they are distributed with the core. These differ between Builder 1 and 2, and are "verbosity story". Their subtitles are distributed in the core as file tdm_sound_vocals_decls01.pk4\tdm_stlucia.subs ) If you have bark text for any of the missing vocal sets, please get me a copy. Thanks. There are additional vocal sets not referenced under "Voices". These are low priority for me. Probably all except the newer manbeast (which is the only one that has a substantial amount of English) will be put off beyond 2.12 release. They are: manbeast [done] player [mainly various grunts] raven horse generic elemental spider revenant zombie werebeast Further out still, there are numerous non-AI sound clips for which "effects" subtitles might be provided. Many of these are found in tdm_sound_sfx01.pk4 and tdm_sound_sfx02.pk4

Can only speculate. The HUD features were in TDM a long time (so mature) before they became resizable. Subtitles are still kind of a work in progress. Also, subtitles are optional, whereas the other HUD features are (with an exception or two) not. And maybe tdm_hud.gui is already complicated enough.

I think we still differ on what that implementation should be. Sorry, I'm going to be a pain in the butt. Not really true; currently, the last phrase of an SRT is still bound by the original clip duration. So, SRT would also need the ability to be extended. And the SRT author have the ability to make use of that extension when specify the last-phrase end time. That said, I'm mainly interested in inline at this time, so, in the interest of getting that done, willing to postpone consideration of SRT extensions (say until 2.13). On the third hand, SRT will probably be used a lot more with "story" phrases, including those appearing in Conversations. So maybe it can't be postponed. For conversations (including those that are inline), I think the default extension should be 0, not 0.2 seconds. Because it's not desirable to extend unless you really have to, as I argued earlier. No. What I want is duration extensions that can be individualized and applied on a per-sound-clip basis. I would much prefer just specifying another individual (but optional) parameter, even if that requires more cut/paste. If instead it's necessary to reorder and group sound clips to apply extensions, this will make management of my testing list considerably more difficult. ALTERNATIVE: I could imagine, instead of specifying an optional extension parameter, it could be calculated on-the-fly. The algorithm would count the number of characters and the approximate number of words, apply them against global max CPS and WPM settings, and generate extensions, bounded by 0.0 and 0.5 seconds by default. If you're interested in this alternative, we could pursue it further. (The CPS/WPM could be one or two user-adjustable CVars.)

The Windows console/C++ program to populate the first 2 columns of the foregoing spreadsheet, with the sound files and their durations, is now available, as executable or as source code: soundDurationsCSV.exe soundDurationsCSV.cpp To run this successfully, you must have ffprobe/ffmpeg installed on your machine, to fetch the durations. The comments of the cpp file has a link to info about how to do that. For command-line parameters, do: soundDurationsCSV -h If you want to compile this yourself, it requires C++ 17 (or later).

I have concerns here, but let me get back to you after the weekend, when things are calmer IRL and I can address this thoughtfully.

Above 3 items are released now, on the "Barks" thread: https://forums.thedarkmod.com/index.php?/topic/21740-english-subtitles-for-ai-barks/&do=findComment&comment=483331

Now available for QA & incorporation into TDM 2.12 - subtitles for The Lord Testing FM (now with instructions also in Objectives, as requested by @datiswous). Assumes TDM 2.11 testSubtitlesLord.pk4 Description of workflow, including use of Excel spreadsheet: SubtitlingWorkflow with Excel (for Lord, March, 2023).docx Excel spreadsheet used to develop subscripts. Calculates various metrics: TheLordSubtitles(v10, March 3).xlsx

No later than Tuesday, I'll be releasing the following - - A spreadsheet with all The Lord subtitles. The spreadsheet calculates metrics, that help decide which subtitles benefit from extension and what those extensions individually should be. Plenty of examples there. - A companion Word doc explaining the spreadsheet and the workflow generally. The spreadsheet is relatively complicated and so benefits from a column-by-column explanation. - The testSubtitlesLord FM with the resulting polished subtitles embedded in it. This FM is slightly different than its Thug predecessor; the Word doc has the differences. To come in March/April - - My personal Style Guide for these barks - A cleaned-up C++ program to gather sound clip durations to import into the spreadsheet. (Current version works but is a bit too smelly to release.) - Possibly the spreadsheet in template form - And another AI character's utterances.

For The Lord's barks, out of 391 sound clips, 44 would need a time extension (so 11.3%), in order to still allow a verbatim (i.e., unshortened) subtitle with a quite-fast reading rate of 20 CPS or 240 WPM. The maximum time extension I am doing is 1/2 second beyond the end of the clip. That is twice as long as considered best practice, but permits all of those to be rendered verbatim. Except for one, that even with a 1/2 second extension had to be shortened. I mark this with the comment "// Shortened" in the .subs file.

Considering only barks, not conversations... For most barks where the audio is more than 1 second, subtitle display extension is neither needed nor desirable. When it's reasonable to limit the subtitle duration to just the audio duration, that's what the captioning community seems to recommend. However, if a comparison of clip length to reading time (estimated by character and/or word count) shows that there's not enough time to read the caption (given a maximum reading rate chosen as policy), then the solutions are - shorten the subtitles (i.e., make it non-verbatim) slightly extend the subtitle display time So, in order to minimize the need for (1), the ability to do (2) is desirable. The amount of extension should be done on a per-subtitle basis, not by a global parameter. Hence the optional parameter.

Also, please keep on your radar changing the parsing for the "inline" command, so that it can take an additional optional parameter, I'm informally calling "extends to". This is the time in fractional seconds to show the subtitle. (This is one way to define the parameter; another would be as the ADDITIONAL time, beyond the clip duration.) For The Lord subtitles (currently about to start my final QA pass), I've already generated Extends To values, but marked them as "// TO DO: " comments so as not to break current parsing. Probably you'll see those subtitles next week - since IRL the kitchen is being boxed up in preparation for remodeling.

Ah, OK. That changes things, probably removes the case for changing the conversation's "wait until finished" behavior. Interesting that the player/narrator sound emitter doesn't seem to have the restriction that "one actor... cannot say two sounds at once". Yes, .srt should handle 2 lines (but I haven't done anything with .srt myself yet. Barks aren't generally long enough for that. For inline, you just embed a "\n" to get 2 lines.)

A preliminary estimate is that about 10% of The Lord subtitles would benefit from a small time extension. Edit: Not counting those that benefit from the 1-second minimum rule.

Related to this, sometime this week I'm going to - - change my Excel worksheet (currently with the ongoing The Lord work) to incorporate the 1-second rule and also calculate the minimum time extension that should be requested (assuming that feature becomes available at some point). - setup a separate local subtree for 2.12 dev builds. (This will be to receive dev TDM-installer releases. Not going the route of SVN pulls/builds). Then can do testing.

I wonder if it would be possible to alter the Conversation process, to make it more friendly to subtitlers and conversation authors? So currently (and abstractly): "wait until finished" is clipDuration + betweenClipSpace, where betweenClipSpace is hardcoded to 0.2 seconds and based on reasonable audio flow in a real-life conversation. Suppose this was changed to: "wait until finished" is MAX(clipDuration + betweenClipSpace, subtitleDuration + betweenSubtitleSpace) where subtitleDuration is the clipDuration including any extension (due to 1-sec rule or specific extension ask) betweenSubtitleSpace is a temporal visual gap between subtitles appearing in the same slot. Candidate values might be 0, 0.05, 0.1, 0.15. This could be ultimately hardcoded and apply to all FMs, but maybe should be a CVAR for initial evaluation. I think this would be closer to what @datiswous had in miind.

I believe "layers" is a DR-only thing. TDM doesn't know about them at all. In TDM console, you can use "teleport" to get to a named entity. I found it useful to have certain things (like teleport targets or rugs) with very simple, memorable names to teleport to. RE automation tool - which I have little knowledge of because my rig is too underpowered to run active DR and TDM at the same time - I can imagine there could be a way in the future for DR Layers to also send vast numbers of hide/unhide commands to individual ingame entities corresponding to layers. That approach probably would be slow, though.

@stgatilov, sounds so promising! I see, in the bugtracker, you've added cvars: You also said the conversation sounds go into s SND_CHANNEL_VOICE channel. So all parties to a conversation share the same channel, and thus what should be expected is that a single subtitle slot will show all parties, alternating. (This may or may not be better than having a separate slot for each party, but I understand that this is how it is.) I guess from what we're saying here, the conversation system doesn't support duets. It would be interesting to see if having a brief disappearance of the subtitle field between speakers would aid comprehension. This could be tested with, say, tdm_subtitles_inlineDurationExtension = 0.1 @datiswous, you're opinion? For conversations with a voice clip that needed a longer subtitle extensions than 0.2 (or triggers the 1 second duration minimum), "wait until finished" by itself would still (and correctly) cause the next subtitle to truncate the current one. It would have to be "wait until finished" followed by an additional conversation "wait" of fixed duration. BTW, for my testSubtitles program, I used the narrator voice (or maybe the player, I forget which), and, in spite of being from a common source, these sound clips can overlap/superimpose without a problem, presumably in different sound channels. And the subtitles appear in different slots. So the concept of a "sound emitter" is a subtle one.

Makes sense. You'd just have to give each instance of the silent ogg its own name, possibly the same name that you'd later replace with the real clip.

If the prototyping looks promising, then I can add a bugtracker request to cover the new .subs syntax.

For inline, if there is the additional parameter, that specified duration (whether longer or shorter than 1 second) over-rides the 1-second rule. (Thus, if for a future "effect" sound of footstep, you wanted to provide a "(clop)" subtitle every 1/4 second, say, you still could; you'd just have to be explicit.) @stgatilov, @nbohr1more, @Dragofer: The potential to get the foregoing capability - or not - will affect how I strike a balance between authoring verbatim and shortened subtitles. So, I need to get feedback ASAP as to whether or not this is reasonably possible for TDM 2.12. If so, I'll add it to the bugtracker as a New Feature request, and leave more subtitles as verbatim. If not, I'll continue shortening affected subtitles.

The i18n info on the wiki is mum on the subject, so I think there's no real support. However, speculatively, you could enter Latin-1 (i.e., ISO 8859-1) characters directly into your .xd file. This would probably work OK for players with English and some Western-European language locales. Others would presumably see mistranslated characters in those character locations. No hope for Asian or emojis with current system.