Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    1073
  • Joined

  • Last visited

  • Days Won

    58

Everything posted by Geep

  1. 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.
  2. 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.)
  3. 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).
  4. 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.
  5. 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
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.)
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. @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.
  17. 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.
  18. If the prototyping looks promising, then I can add a bugtracker request to cover the new .subs syntax.
  19. 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.
  20. 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.
  21. @datiswous and others, you can get my Windows console program buildSubtitleShaders.exe now at: https://drive.google.com/file/d/19Pf513nv5gwOzZ5tyWHJN7Ka-D9UxBET/view?usp=sharing Do "buildSubtitleShaders -h" to get help on parameters. The output should be compatible with an instance you clone (and rename) from the testSubtitlesThug FM, provided you go into the FM's .script file and change #define SHADER_PREFIX "fm_ai_thug_shader" to #define SHADER_PREFIX "fm_test_subtitles_shader" This will be the fixed sound shader prefix I use for all the AI vocal sets subtitles I will make available (embedded in various testSubtitles...) to QA in the future. I'm not releasing the full VS project for this program right now, but you can make your own console project and build it yourself with the only file needed, buildSubtitleShaders.cpp: https://drive.google.com/file/d/16Epx2V2iGa2b91Mnt0cbzGSb3IQBJpk7/view?usp=sharing Needs C++ v17 to compile. Rest are VS2022 defaults. For more on purpose and deployment, see comments in start of buildSubtitlesShaders.cpp generated output file
  22. This ties into another thing I would very much like, namely, the ability to extend the duration of a subtitle beyond the end of the clip. This is not possible now, so would require some build-out of threading capabilities for subtitles. There are a lot of barks that are too short, below the minimum recommended 1 second for a subtitle. In theory, one could add dead-air to the .ogg files, but really, way too much tedious work. Assume that the underlying tech issues to allow duration extension could be addressed. Then extension could be deployed through 2 complementary features - - Have the subtitle system automatically enforce the 1 second requirement for inline only. - Have the "inline" and "srt" commands take an optional additional parameter, for overall duration (i.e., greater than the clip duration). This would allow the subtitler to ask for a small time extension to accommodate CPS/WPM concerns. When specifying the final "srt" phrase, it could use that extended timeline. Typically, for longer clips, a small extension like 1/4 second more would suffice. A long extension is undesirable for voice-subtitle sync reasons. Finally, going back to the previous post, if the subtitles were threaded and more independent of the sound playing, then another capability would be, if a high-priority clip wants to play but there are no subtitle slots, see if any of the lower-priority clips will conclude shortly (ideally, within 1/4 second), and queue the subtitle to appear then (importantly, without shortening). Instead of immediately bumping the lower-priority clip.
  23. So, just thinking about priority further, we have the 3 obvious levels: 1) story 2) speech 3) effect Suppose, if all 3 slots are filled, a higher-priority subtitle could "bump" (take over the slot) of a lower-priority one. I'm thinking this would not be too difficult technically. From a reader's viewpoint, the main difficulty is that the bumped subtitle would appear on-screen for a shortened amount of time. How do you minimize the grief? You have to choose which subtitle to bump. If they're different priorities (1 is speech, 1 is effect), this is easy. Otherwise, you might choose the subtitle of the sound clip that is closest to completion anyway. This implies knowing the total duration and the starttime of playing clips. Maybe you need to put in a 1/10 second no-subtitle moment when the bump occurs, a visual cue.
  24. Copied from the AI Barks thread. In response to datiswous, I said:
  25. Here's my understanding. There are 3 stacked non-overlapping "slots" for a subtitle field to appear in. You can see this in the testSubtitles FM if you hit any of the buttons fast enough. (Granted, this is all in the same voice, not different voices.) When a sound is about to play, the sound system looks for the lowest unused slot to put its field in. And it keeps that field until the sound clip ends (e.g., across multiple srt phrases). If a sound starts playing and there's no slot free, then no subtitle appears for it. Because the sound system currently doesn't know who/what emits a sound, it can't "reserve" a slot for a particular AI or other entity across separate .ogg files. Even without knowing the emitting entity, what the subtitle system could do now (but doesn't currently) is look at the standardized pathname of the sound file, and determine what vocal set it comes from. It could then "reserve" a slot for a while for future utterances from the same voice. Is that a good idea? Unclear to me. (There's a broader issue here about giving priority to "story" phrases over "speech" phrases. I'll move this to the Future thread.) Later in the year, when more bark subtitles for different voices are in 2.12dev, it should be possible to just drop your player into a room of miscellaneous AI and fill up those 3 slots big time.
×
×
  • Create New...