Geep

The update to subtitles for The Thug vocal set ("Thug2") is now available: testSubtitlesThug2.pk4 Corresponding Excel file - Thug2Subtitles.xlsx The testing FM is used to distribute this update. (See the preceding description of "Lord2" for recent testingSubtitles... improvements.) Out of 392 subtitles, the changes are as follows. Durations, Phrases, Linebreaks 5 formerly-inline subtitles are now each 2 srt phrases. Of the 5, 4 are muttering or snoring; 1 has a yawn between 2 sentences. For inline, 14 -dx extensions are added to pad duration between 0.25-0.50 4 previously-shortened inline captions are now restored to verbatim, due to extension (-dx or auto 0.20 seconds) 10 enforcements of 42-char/line policy are done by adding linebreaks Style Changes 15 Square brackets are replaced by parentheses 3 Sentences starting with 'evening are changed to Evening Transcription More Like Vocalization 1 "is" replaced by 's 1 "?" replaced by "."

The update to subtitles for The Lord vocal set ("Lord2") is now available, that makes use of the new -dx (durationExtend) feature of 2.12dev: testSubtitlesLord2.pk4 Corresponding Excel file - TheLord2Subtitles.xlsx As usual, the testing FM is used as the vehicle to distribute this update. Out of 390 subtitles (all of which are inline, no srt needed), the changes are as follows. Durations Extended 67 times, -dx was used to pad duration between 0.25 and 0.50 second (instead of default 0.20), calculated based on a presentation rate of 17 cps. The value of 0.50 was set as a cap by policy. When reached, it leads to a presentation rate higher than 17 cps. The cap is ignored if the presentation rate reaches the quite fast 20 cps. For Lord2, this occurred once (-dx 0.61, a value calculated for 20 cps presentation rate). This particular subtitle now is verbatim, unlike the original Lord subtitle release, where the text was shortened. Also for presentation rate reasons, leading optional "(...)" descriptors were dropped or shortened (1 case of each). In the spreadsheet, additional columns were added to help in the foregoing calculations. This will be documented when The Wench is released. Style Issues Capitalize leading 'Tis or 'Twas 14 times. Replace [...] with (...) for descriptors. Improvements for testSubtitles... FMs This applies to Lord2, forthcoming Thug2 and Wench releases, and later. In-game, the "Prev", "Again", and "Next" buttons are now twinned with a group of 3 more buttons labeled "Same but Quiet". As requested by @datiswous, these affect the cursub numeric counter without either playing an audio sound or showing its subtitle. The cursub counter (as an HUD overlay) shows itself more consistently, thanks to an implementation hack. Each subtitle appears in a field that is now Geep-standardized to a half-screen wide, compatible with a 42-char/line limit. This is done with an override of tdm_subtitles_common.gui, based upon a customization of TDM 2.11 code. (So it does not include visual indicators of AI location or speech volume found in recent 2.12dev's tdm_subtitles_common.gui).

Probably not enough to go on, for anyone to say. But it's great that you quickly found a way forward.

In the kdenlive subtitle editor, use the "End" counter to adjust the subtitle phrase end point. Then export to an .srt file, and look within that file. Does the phrase have the same specified endtime, or has it been changed? The latest Cadet release version, 2.0.044 of April 14, incorporates the beta. The main feature added was that, if you go into Tool/Preferences, there's a new line "Show cc reading rate with alarm threshold of [...] in units of [CPS or WPM]". There's also a bit more flexibility in how to advance from one phrase to the next. BTW, I found the Cadet project feature adds no value. I just (re)use an anonymous project, and export the .srt. If later I need to adjust something, I can use "Import" of the .srt to do so. If I strongly needed a tool that had speech-to-text capabilities, I would not use Cadet. Since I've got preexisting text for the vocal sets I'm currently processing, I'm not needing speech-to-text right now.

checkDurationsinSRT is now available: checkDurationsInSRT.exe checkDurationsInSRT.cpp This Win/console program scans a directory for .srt files, reporting on each in turn. It warns about those subtitle phrases(aka messages) that are potentially too short or too long in time, or that seem to require too high a reading rate, expressed in characters per second (cps). It also looks for within-file subtitle messages that overlap in time. Invocation: checkDurationsInSRT -l lowerBound [default is 1.0 sec] -u upperBound [default is 6.0 sec] -c maxCPS [default is 17] -d dirWithSrtFiles [default is current dir] -o output file [default is stdout] For more, run with -h or ? options, or see comments in the C++ source code file. EDIT: The above links now access a May 6, 2023 update, that corrects a significant error in character counting for the cps calculation. In addition, if a given subtitle's cps is too high, the warning now includes a suggestion: "try x.xxx seconds". That says what longer duration would be needed to achieve the target cps. How or whether than longer duration could be achieved is left up to you.

Yeah, it's pretty simple. I'm using a beta build, that adds an automatic cps calculate & display, and better supports my workflow... don't know the beta has seen public release yet. I found I could live with Cadet's quirks better than those of kdenlive. Chief among the latter: because kdenlive is based on video, it insists on changing exported srt times, presumably to conform to the frame timestamps (of a non-existent video). This bothered me too much, maybe more than it should. I don't specifically, though I do use utility programs and Excel to help calculate constraints and make decisions about - inserting line breaks when to use the new inline durationExtend option, and what value to give it SRT instead of inline Non-verbatim instead of verbatim transcription For a given vocal set, it appears just a small number of bark clips need the SRT treatment (and so Cadet) instead of inline. Another satisfied customer of buildSubtitleShaders. I've got another console utility about ready to release, for group checking SRTs. Soon. For me, this is an example of where it CAN fit in an inline, but should be placed in an SRT instead. I would definitely put the final phrase into a subtitle message, and at least consider breaking into 3 or 4 messages. For The Wench, there were some clips (of 7 - 30 seconds) where she's idly humming. Rather than a single inline, e.g., "(humming long tune, hoarsely)" that stayed up the whole time, I went with srt, showed that message briefly, and then towards clip end showed "(humming ends)".

I was just trying to distinguish between individual message (aka phrase) appearance time on-screen, and overall srt timeline maximum. You're thinking "duration" should to refer to only the latter, but I was momentarily using it to refer to the former. Probably it would be better with srt not to refer to "Duration" by itself, but instead: SoundDuration MessageDuration MaxMessageEndtime "Duration" by itself is misleading, because it seems to imply something about how long messages appear on screen; that's not the case because the first-starting temporal message in an srt doesn't have to start at time zero. (And the summation of individual MessageDurations is even less informative, since there can be time gaps between messages.) That's one way of reporting what for TDM is an srt error. OK, I understand what the expected code behavior is now. Thanks.

Now that I think about it, "duration" needs to be expressed in terms of each srt phrase. So the equation you gave is good for a single-phrase srt that starts at time 0. More generally: start = phrase start time (within clip) stop = phrase stop time diff = stop - start In most cases: d = diff For the final phrase, there is this constraint: stop = min(LastMessageEndTime, SoundDuration + tdm_subtitles_durationExtensionLimit) But are these globals also applicable to SRT? the 1.0 second lower bound (I was calling L) the 0.2 extension (I was calling X) BTW, how are overlapping time ranges within an SRT handled?

Good to know! Since SRT now has it's own way of extending (using end time of last phrase), there is probably not a need for -dx with srt. Hmm, I wonder what the calculation of d is for SRT. Probably could use this variable: e = end time of last phrase within srt Then maybe redefine variable x as: x = e - c In this case, x could be negative or positive. Then tie it in to the 3 internal globals. Maybe differs from inline.

OK, I would express this as: d = min(max(c + X, L), c + U) if x not defined d = min(max(c + x, L), c + U) if x defined (where x > 0) In this formulation, if the user chooses to set the maximum extension U to zero, then the values of x, X (default 0.2), and L (default 1.0) have no effect. Soon I hope. I can't finalize any more vocal sets barks until then. I'm not clear how parsing is dependent on line breaks here. I mean, this would be OK: inline "say1.ogg" "Hello, world" -x 0.3 inline "say2.ogg" "Goodbye" That said, I'm not wedded to "-x", but I would very much like to have the extension value either part or adjacent to the inline statement it modifies. Ideas: inline "say1.ogg" "Hello, world" "" // last parameter is no longer optional, but if "", then treated as if not given or inline "say1.ogg" "Hello, world" inline-extend 0.3 // or maybe inline-extend "say1.ogg" 0.3

Actually, there are additional possibilities where X and x are not additive, but alternatives: a.4) d = max(c,L) + min(X,x,U) a.5) d = max(c,L) + min(max(X,x),U) a.6) d = max(c,L) + min(x,U) // iff x > 0. In that case, x overrides X b.4) d = max(c + min(X,x,U), L) b.5) d = max(c + min(max(X,x),U), L) b.6) d = max(c + min(x,U), L) // iff x > 0. In that case, x overrides X

@stgatilov, I started to apply the inline "-x" option for extra time to a vocal set, but then realized that I needed to know better how it worked, in order to choose appropriate values. So some questions: 1) Does the inline -x work... a) the same for "story" and "speech" verbosities b) differently If (b), the next questions will need to be answered twice. I'm going to state these in mathematical terms, summarizing the behavior of the algorithm and reflecting the order in which values are combined. All variables are in seconds. c = length of a given sound clip x = inline -x value for extra time. Should be positive. Zero if not given. d = calculated length of subtitle duration L = global giving a lower bound on subtitle duration. Default is 1.0 X = global giving an extension to subtitle duration. Default is 0.2 U = global giving an upper bound on X. Default is 5.0 2) When there is no value of x, which equation describes the algorithm's behavior? a) d = max(c,L) + min(X,U) b) d = max(c+min(X,U),L) 3) When there is a valid value of x, the equation becomes... a.1) d = max(c,L) + min(X,U) + x a.2) d = max(c+x,L) + min(X,U) a.3) d = max(c,L) + min(X+x,U) b.1) d = max(c+min(X,U),L) + x b.2) d = max(c+x+min(X,U),L) b.3) d = max(c+min(X+x,U),L) Thanks for help with this.

Books are out of scope for this thread, which is just concerned with subtitles. As an aside, because of the way book text is laid out (separate independent overlays for "title" and "body" text), changing the font from what the FM author provided would tend to make a mess.

@datiswous, I'll try to incorporate Skip Forward/Backward buttons (or whatever I end up calling them) into the upcoming testSubtitlesWench release. Likely sometime next week.

An update of command-line tool "buildSubtitleShaders" is now available: Win executable C++ source code file With this Feb. 10 version, if you ask for help (buildSubtitleShaders -h or ?), there's an additional option shown: -c counter start value (default: 1). Eases merging results from different sound file folders. As before, comments in the source code file provide full documentation.

Yeah, that is a pain in the butt. The main problem with multiple input folders is that you really want to be able to specify relative paths on the command line (i.e., not just absolute), but then reformulate the paths into the form that TDM wants in the sound shader. I tried to code that earlier, and ended up with a real mess. One of those situations where the more you try to fix, the worse it gets. So I abandoned that attempt. What I could do instead, fairly easily, is to provide another command line option that would let you specify a starting number greater than 1, so you wouldn't have to separately renumber. EDIT: See next item.

??? If you don't specify the output file, then it writes to stdout. The expected behavior would be you would see the output on the terminal screen, unless you did something like "> my_new_results.sndshd". Are you not seeing that with wine? No, you currently would have to run the program separately for each folder and cut/paste to merge the outputs by hand. Since that's kinda trivial, and programming for multiple input folders less so, probably won't be happening. I'm thinking here you're talking about a "testSubtitle..." FM. So in addition to jumping to a particular soundfile by changing the cursub value in the console, you'd maybe like 2 more in-game buttons, to skip forward and skip backwards?

You might want to manipulate inventory items & count, & available weapons, too. Some scripting support, but varies.

The Wench bark subtitles are essentially done, but there are some issues with a handful of .ogg files (see new bug tracker report #6284). So I'm holding up release pending resolution. I'm going to briefly revisit the subtitles for the first 2 AI characters, to make better use of SRT and of the new duration-extensions capabilities in 2.12dev.

I agree that listdefs as they are now are not useful to FM authors, because alteration of the C++ source code is needed. If there was some data array that was useful across FMs, then it might justify a collaboration to have C++ support it. For instance, I could imagine a generic fm_data_string_array, with read/write access, that you could associated with any FM-specific listdef. Don't have a clear idea here.

Also, I was interested in getting metadata about the TDM fonts. Some forum posts suggested you just rename a font's .dat file to .ttf, and then font tools (like those provided by FreeType) could read it. But all I'm seeing is an unrecognized file format when a read is attempted. ???

@stgatilov, this is precisely where our views diverge. We're both interested in a narrower, aspect-corrected font, but for different reasons: You're looking to increase the amount of text than can be held... I'm looking to make the backing fieldwidth less wide, and think there's already too much text per subtitle. A possible compromise would be to make the fieldwidth 2/3rds of the screen. This would maintain the current amount of text, given the current font but now aspect-corrected. Probably more text (ugh) with the Stone font, aspect-corrected.

I have argued that the 2.10/2.11 implementations have field widths that are way too wide, unpopular with most subtitling orgs, and conflicting with TDM's corner inventory and weapon icons. So breaking backward compatibility now would be a good thing, before it's too late and too many FMs are subtitled targeting wide fields. But I can only suggest, and continue to make my bark subtitles fit in a less-wide field, taking into account sentence and phrasing breaks. Future automated text conversion update tools could be helpful.

No consensus has been reached on changes. Certainly I have a subtitle style I prefer, and applying that style to briefings and other story subtitles would no doubt mean changes for some existing subtitles. This would not be much work for inline subtitles. Breaking up over-long srt phrases would take more work. You could pause or slow-walk subtitling if you think warranted.

True. Or shorten it to -x 0.123, where -x stands for Xtra time. I guess you mean that some scale factors cause poor font rasterization. Let's start there.