Subtitle Edit

[Yosho]

New bug happening after AI updates.
AI transcriptions are now causing all lines to be transcribed and not only the line highlighted.
When transcription is done, it resets back to the first line in the subtitle.

[markfilipak]

This is going to be a long report. It includes many 'creature comfort' requests to make SE easier & quicker to use, and it includes what I think are a few bugs. I hope it pleases.

First, Thank you for sharing SE. It's perhaps the most complex, most difficult-to-write application I've ever seen. I consider its creation to be courageous indeed. I commend all the writers. They care, and it shows. I appreciate that there are actual buttons that push in. That makes it easy to see I've actually done something.

Overall: There is source view and list view. I suggest they be unified to make a single view having subtitle items on single lines, like list view now has. I suggest that the lower edit boxes be removed and that editing be enabled on the single lines that are above the current edit boxes. If the subtitle text is wider than the SE window, then wrap it within the subtitle text column; otherwise, don't.

Desired -- asterisks denote what would be the biggest time savers:
- Could there be an overtype mode? The [Insert] key would be used to toggle between insert and overtype.
- If there is highlighted text when [F3] is pressed, could 'Find' be directly executed on that highlighted text without having to open a 'Find' dialog.
* Could the text scroll up and down so that the current subtitle is always vertically centered?
* When editing times, I have to slow way down -- position mouse, click, long hold, swipe, click-release, type replacement time. That long hold must be there to prevent selecting HH:MM:SS:mmm as a whole; it breaks my rhythm. Perhaps double-click could select HH or MM or SS or mmm while [Shift]double-click would select HH:MM:SS:mmm as a whole. That would be very nice and would just about double my edit speed.
* Could [down-arrow] always position the cursor at the beginning of the next line?
* Could [up-arrow] always position the cursor at the beginning of the previous line?
* Could punctation be treated as white space when selecting entire words? In that regard, I've often dreamed of the following selection functionality: double-click selects entire word (but not any trailing punctuation). Click inside the existing selected string extends the selection to the end of the next word. Click inside the the existing selection extends it to the end of the next word. Et cetera. I've never seen an editor that would do that. It would be heavenly.
- Lacking vertical centering, could the cursor line be hightlighted so that it's easy to find. A pale background color is preferred. Highlighting across the entire width of the pane would be fine and might be simpler.
- When switching back and forth between list & source views, could they 'inherit' index numbers and cursor positions, one from the other. [note1]
- Could SE show that a video file has already been loaded, and show its name.
- Could SE tag particular entries for future reference, so that users can 'jump' from tag to tag like 'jumpping' forward and backward between 'finds'.
[note 1] Switching back and forth is required because list & source views have differing capabilities. I find list view of little use except as a means to add/delete/split/merge entries and to select all entries in order to [Auto br] all entries at once.

Undo: [Ctrl][Z] has major cursor positioning problems. After [Ctrl][Z], the cursor is in the wrong place. It does not jump to the undo point, so I can't tell what's been undone. Could you arrange it so that [Ctrl][Z] does not cause the current line to jump to the bottom of the source window? Could a single [Ctrl][Z] undo all the piecewise changes that have been made to the current entry and then stop? Currently, I can't track what's been undone and I get lost. When I do multiple [Ctrl][Z]s, I can't tell what's been undone. Likewise, when I do multiple [Ctrl][Y]s, I can't tell what's been redone. I think the easiest way to handle cursor position is to move the cursor (and vertical center) to the cursor position it had _before_ the undone text was first inserted, and to move the cursor (and vertical center) to the cursor position it had _after_ the redone text is re-inserted. That will probably require recoding cursor position with each keystroke in anticipation of possible undos.

Notifications: Notifications that cite line numbers are useless. The subtitle instances are numbered by instance, not by line. Any particular line number can't be found.

Initialization: If I forget to toggle source-/list-view a few times before doing my first 'Find', 'Find' doesn't work and shows 'not found' in every search.

'Multiple replace...': If subtitle text is highlighted, 'Multiple replace...' doesn't 'see' the highlighted text. For example, see
'SE Multiple replace... while text is selected bug.png'.
In that example, quitting 'Multiple replace...', unhighlighting the word "confine", and repeating 'Multiple replace...' works as expected. I have repeated the test with other words.

[Change all]: [Change all] currently doesn't change all. For example, a character's name, "Troi", appears as "Trol" over and over in the same session despite [Change all] correction. That experience is repeated in every session. [Change all] seems to always work on words that are not "Trol". I don't know what it is about the word "Troi" that is causing this malfunction.

Cursor position: For selected text -- selected via 'Find' for example -- have [<] put the cursor before the selection's beginning character and [>] put the cursor after its ending character. Currently, if "3456" is selected within "12345678", [<] puts the cursor here:
12345|678, and [>] puts the cursor here:
1234567|8.
To be consistent with standard text editors, [<] should put the cursor here:
12|345678, and [>] should put the cursor here:
123456|78.

[Replace all]: [Replace all] replaces only from the current subtitle to the end. It does not replace all.

Exception:
'Windows Forms Thread Exception.png'
show an exception during an attempted regexp Find. The exception is thrown every time I attempt a regexp Find.

Lack of focus: Switching from source view to list view, no list view element has focus, so [up-arrow]/[down-arrow] doesn't function and [Ctrl][A] selects nothing.

[markfilipak]

I see there are 'shot changes'.
I see this control: 'Tools'>'Adjust durations...' : '[X] Don't extend past shot changes'
I see this storage: c:\Users\Administrator\AppData\Roaming\Subtitle Edit\ShotChanges\

How do I make a ShotChanges table for use by 'Adjust durations...'? I have not found such a tool.

Thanks--Mark.

[Emulgator]

You may just have SE generate one and handedit afterwards. It is seconds.milliseconds format, ANSI coding.
ssss.ccc
The filename seems to be generated unique and random from 16 hex digits,
so I do not know how to push that into a project, I just let SE generate one, see above.
Invoking a rescan seems not implemented ATM, but I guess if you just rename the one belonging to the project (compare by modification date) a rescan should become available again.
BTW I decided to choose 0.2 as sensitivity, larger or default and some more shotchanges are missed.

[markfilipak]

You may just have SE generate one ...

How do I get SE to generate one? There doesn't seem to be a menu function to do that.

[markfilipak]

Let me explain.

In the last week I've modified the subtitles of 140 episodes of STAR TREK, THE NEXT GENERATION. It was tedious but went smoothly. The subtitles for the first 5 seasons were quite sloppy; they always began at the right times but often slopped over into the next scene by as much as 10 seconds. I had to manually edit the ending sexagesimal times.

Season 6 is different. The subtitle times span the vocalizations and that is too short. I want them to start at the given times but with 125% durations. Further, I want them clipped to prevent slopping into the next shot. To that end, I've loaded the MP4. However, I can't find a way to scan the MP4 to make a shot change table.

Also, I've not found 'Help' that still exists.

[Emulgator]

Just press the button "Beautify time codes" (red/green waveform)
(If this button is not visible in Toolbar: Settings -> Toolbar -> toggle "Beautify time codes" visible)
A window pops up. Tick Use FFprobe... then "Extract time codes".
(You got to download FFprobe the first time, IIRC SE does it for you.)
(This button can be activated only the first time, is then greyed out as long as the .timecodes file is present I guess)
Parsing might take considerable time (15..25min), depending on duration, codec and disk speed.
After successful parsing you will be presented with the message "128568 time codes loaded"
Then "Generate shotchanges". I suggest to lower sensitivity to 0.2 to catch them all.
(This button can be activated only the first time, is then greyed out as long as the .shotchanges file is present I guess)
Again Parsing might take considerable time (15..25min), depending on duration, codec and disk speed.
After successfull parsing you will be presented with the message "398 shot changes loaded".

If you prefer to have all audio languages muxed in to cater for any timing of any language (as I do):
It does matter from which container you decide to work from when attempting to switch audio streams and still be able to see waveforms.
I prepare a SE Mux just for that occasion.
.mkv seems to work well, .mp4 seems to work well.
.m2ts may have the BD-typical muxing delay which will shift any timestamps and hinder work.

P.S. Just checked it, I had renamed my last project's shotchange file again and again,
had SE parse again and again until I was happy with the result.
Fired up WinMerge to see the 3 versions side-by-side and yes, they filled up gradually.
Ah, and the .timecodes file in \TimeCodes folder has the same unique and random filename as the accompanying .shotchanges file.

So: Happy editing.

[markfilipak]

Just press the button "Beautify time codes" (red/green waveform)
(If this button is not visible in Toolbar: Settings -> Toolbar -> toggle "Beautify time codes" visible)
A window pops up. Tick Use FFprobe... then "Extract time codes".

Ah! "Beautify time codes"! That's where it's buried. Thank you. ...odd place to put such a vital function, eh?

... After successful parsing you will be presented with the message "128568 time codes loaded"
Then "Generate shotchanges". I suggest to lower sensitivity to 0.2 to catch them all.

Well, If I was writing the code to detect shot changes, I'd pick frames having few frame-to-frame pixel correlations plus no/few motion vectors, but I imagine simply few pixel correlations is what is done. I also reckon that 0.2 is actually higher sensitivity -- a seemingly inverse metric that's inverse because it's based on percentage of correlation. I reckon running shotchanges takes so long because FFmpeg is decoding. Just looking at motion vectors would not require decoding and would be faster; maybe significantly faster. But of course lack of motion vectors is also characteristic of still images, so both MVs and pixel correlations would be needed to accurately assay shot changes.

So: Happy editing.

You're extraordinarily helpful and complete. I hope you live as long as you want, in perfect health, and blissfully happy.

--Mark.

[Emulgator]

Many thanks, Sir, for your kind words, and may I return the favor.

[markfilipak]

I recently discovered that 'Edit image db' > 'Add better match', is a very effective way to accelerate/improve training. Unfortunately, I haven't found a way to get a subtitle line that has a bogus '2'-to-'?', for example, into 'Edit image db' because 'Edit image db' is not available as a general tool.

nikse, I apologize if this is not the right place to make this request. ...I'm so impressed with SE!

--Mark.

PS: nikse, I want to make a large donation, however, I will not use PayPal. There is a better way. Kindly contact me privately. --M.

[markfilipak]

Comments, please...

I've learned to adjust timing solely via 'Synchonization'>'Adjust all times'>'(o) Selected and subsequent lines'. I tried to do 'Point sync' of a region but it didn't work out.

The region was 13:50.413..22:31.267. I specified ends that have zero deltas, but between them the times delta by nearly a second, some leading, some lagging.

Since the ends had zero deltas, I assumed the deltas I specified would affect only the times between those ends. I was disappointed to discover that _all_ the subtitle times were changed. Specifically, the initial subtitle was moved backwards by about 13 seconds and now appeared less than a second into the movie.

Perhaps there's a way to limit 'Point sync' to a certain set of subtitles, but I didn't see any way to do that.

[markfilipak]

In list mode, it would be more efficient -- less mouse -- to use the [up-arrow]/[down-arrow] keys instead of '< Prev'/'Next >' to go to the previous/next subtitle. Currently, the [up-arrow]/[down-arrow] keys have no function. '< Prev'/'Next >' could be completely removed.

[markfilipak]

May I request that a 'hard-break', <<br />>, be created. It would affect the [ Auto br ] function, and would fix a number of difficulties.

Thanks!

Added later: Are user interface suggestions not welcome here? --M.

[Yosho]

New bug happening in subtitle edit's faster whisper large-v3 showing "Subtitles by the Amara.org community." after transcription is complete on spoken line.

[Emulgator]

This is due to hallucination of the algo/model setting, can be mended by going into settings.
If any inference algo shall guess hard on noise it finds such things in the models and if seemingly fit, appends/inserts them.
Happens here too, appending credit/exit lines from all over the world's subbing/dubbing facilities.
Not necessarily a SubtitleEdit fault.

[markfilipak]

Version: 4.0.8
Find what: \n-([A-Za-z0-9])
Replace with: \n- $1

Original:
11
00:12:29,115 --> 00:12:30,913
-Morning.
-Good morning, Mrs. MacNeil.

Expected:
11
00:12:29,115 --> 00:12:30,913
- Morning.
- Good morning, Mrs. MacNeil.

Actual result:
11
00:12:29,115 --> 00:12:30,913
- $1orning.
- $1ood morning, Mrs. MacNeil.

More strangeness:
'Find what' has automatically become
Find what: \n-(G)

[markfilipak]

Does anyone have any ideas how I can get SE to fill in the times?
https://forum.doom9.org/attachment.php?attachmentid=18768&stc=1&d=1731682824
I've done hundreds of runs with SE but I've not seen this before.

FFmpeg says subtitles are
Stream #0:5[0x1200]: Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)

Thanks -- Mark.

PS (day later): Well, I tried all kinds of tricks. No cigar. But I did finally get the times into SE. What I did was run 'UNFORGIVEN [1992].m2ts' through MKVToolNix and save one audio stream plus the PGS subtitles as 'UNFORGIVEN [1992].mks'. SE was able to get the subtitles, with times, from that.

[markfilipak]

How can I rerun shot changes? Sensitivity 0.20 was not sensitive enough.

[Emulgator]

Delete (or better rename) the appropriate .shotchanges file.

[markfilipak]

Delete (or better rename) the appropriate .shotchanges file.

Found them: c:\Users\Administrator\AppData\Roaming\Subtitle Edit\ShotChanges\*.shotchanges

Thank you, my friend. Wonderful!

I added links to both shotchanges and timecodes to the Windows menu so I can make copies when I'm done with a movie... if I remember. :-)

PS: You know, timecodes and shotchanges could be done at the same time, eh? ...I wonder what FFmpeg functions SE is using to detect shotchanges. UNFORGIVEN is awfully dark in many scenes. I'll look for a shotchange function that takes frame-to-frame contrast into account in order to make sensitivity an automatic variable. If I find such an FFmpeg function, I'll suggest it to Nikse.

[markfilipak]

I've done some experiments designed to find the best shotchange sensitivity. As you see below, 0.07 sensitivity produced the best results for the UNFORGIVEN Blu-ray.


sensitivity
/ number of shotchanges detected
/ / comment
/ / /
0.20 : 919 : missed too many shotchanges
0.15 : 1002 : missed too many shotchanges
0.10 : 1177 : missed too many shotchanges
0.05 : 1877 : too many false shotchanges
0.07 : 1485 : too many false shotchanges
0.08 : 1336 : missed too many shotchanges
0.07 : 1485 : the best I can do

What I found is that sensitivity of 0.07 still misses a few shotchanges in dark scenes, and it produces some double hits in a few bright scenes, but 0.07 seems to work a lot better than 0.20.

PS: The FFmpeg filter is called "scdet". Everything seems to use it except for the "tonemap_opencl" filter, which seems to use a more sophisticated setting system.

[Emulgator]

Yes, in the dark it becomes hairy for any algorithm.
I use to watch the video waveform and the tiny jump in black levels will tell exactly which frame the new strip was glued on.
You can still handedit the .shotchanges file, it is just seconds.milliseconds

[VoodooFX]

What those "shotchanges" provide in the subtitling context?

[Emulgator]

Just an orientation line to sync to.
Or maybe better said: To avoid overlapping subs across edit boundaries.
You can edit some rules, like a courtyard of 3 frames before and 2 frames after a cut.
SE will then automatically adhere to these rules and keep such courtyard clean.

[VoodooFX]

Is there some tutorial about this, there is some "Add shot change" at the waveform but no idea what it does it just adds a white line and that's it.

Anyway, wouldn't it be better to "adhere" to the actual speech boundaries?

[markfilipak]

Is there some tutorial about this...

It comes with experience.

I have subtitled hundreds of movies at this point. I've found that when a subtitle is not aligned with a shot change, when a subtitle change occurs just after a shot change, even by only a single frame, the result is distracting to the point of hampering timely reading of the subtitle. It creates a sorta strobe effect. I run a subtitle right up to the shot change, but not beyond unless it is well beyond (like, half a second or more).

I've been surprised that making a subtitle's duration shorter often enhances reading. What really hurts is when the words in the subtitle and the spoken words don't match, when subtitlers shorten or rephrase because they think it makes it easier to read. It doesn't.

[markfilipak]

What I'd really like to see is a tutorial of 'Beautify time codes'>'Edit profile'. What is a 'cue'? What do red zones signify? What do green zones signify?

When the going gets tough, I always fall back to editing start and stop times manually in the source list (as though SE was simply a UTF-8 text editor) while watching the video via MPV in a separate window -- I single step to find the exact shot change time. If I knew all about 'Edit profile' and cues and zones, that pain might be avoided, but I don't know what "cue" means and what red and green zones are and how to intelligently use them.

[markfilipak]

Well, I have some information.

Moving either end of a subtitle in the audio waveform window seems to have 7 millisecond resolution. Thus, subtitle boundaries ("cues"?) that have been snapped to frames are no longer snapped to frames. That is unfortunate. SE needs to work from frame numbers, N=0.., and automatically snap endpoint movements to those frames, N/FPS seconds. What SE currently does makes no sense to me.

PS: For 24/1.001 FPS, the endpoint movements should be in +/- 1.001/24 second intervals (i.e., about 42 milliseconds).

[Emulgator]

Which in the end would ask for an internal granularity that satisfies
the internal numerical representation of applicable formats/containers at all usual framerates.
Most historical subtitle formats would only allow to convey centiseconds in the end,
still an internal precision that matches all these requirements would be nice...
...since with number of iterations (120.000 frames anyone ? 180.000 ?) faults might add up easily, see my PCB Design example at the bottom.

(http://dvd-manufactur.de/dvd-manufactur-de_14_tech-stuff_de-de.html
Ausgehend von 27 MHz erhalten wir dann durch 300:1 Frequenzteilung die playerinterne System Clock von 90 kHz.
Dies sind die "Ticks", nach denen sich jegliches DVD-Timing richtet.
Nun kommt der Trick, wie man doch noch zu der "krummen" NTSC-Framerate kommt:
Bei beiden Systemen führt ein Vorteiler :3 zu einer Zwischenfrequenz von 30 kHz.
Der NTSC Divider (Denominator) 1001 kann aus 2 Primzahlteilern implementiert werden :143 :7
Der PAL Divider (Denominator) 1200 kann aus 6 Primzahlteilern implementiert werden :5 :5 :4 :3 :2 :2
90000:3003 = 30000:1001 = 29,97002997002997...
90000:3600 = 30000:1200 = 25,00000000000000...
---
The 1001 divisor from NTSC had led to the DVD ticks of 1/90.000s,
which unfortunately needed a 33bit register to accommodate daylong durations, the later .m2ts ticks of 1/45.000s allowed to accomodate 1 day in a 32-bit register.)
SD Video: A 27MHz quartz delivers 2fs base clock.
Base clock divided by 300 gives 90kHz, these are the DVD ticks, divide these by 3 gives 30kHz intermediate clock.
Divided by 1200 (primes :5 :5 :4 :3 :2 :2) gives 25fps for PAL.
Divided by 1001 (primes :143 :7) gives 29.97fps for NTSC.

For the SD framerates we could get off with 1/30000s base ticks and dividers of 1001 (NTSC) and 1200 (PAL).
.m2ts (and in consequence BD subs) bring a granularity of 1/45000s.
Now the HD double framerates 59.94/50 would be asking for 1/60000s base ticks and dividers of 1001 (Double-NTSC) and 1200 (Double-PAL).
DVD .VOBs (and in consequence DVD subs) bring a granularity of 1/90000s.
So 1/180000s would accommodate them all, 5.555µs...
- Edit: 23.976p need 1/360000s, see cubicibo below.

Early versions of KiCAD (a PCB design suite) had an internal precision of 0.1mil.
Which sounded exhaustive, but choked on the 1/64" and even 1/32" grids of usual edge connectors.
On other occasions (pin headers) even the manufacturer (Molex) called one of their series "156",
but concluding 156 mils from that became a trap, at least for me.
"156" was informal only, historically and more correct it should have been 5/32".
As I tried to generate larger footprints from a starting pair of pads it became obvious
that my largest edge connector footprint (40-row) would end up 1mil (0,254mm) too short beause of that rounding error multiplied by 40.
In my search I remembered the sequence 15625 from TV line frequency, and there it was, the missing ...25 in positions -5 and -6, pointing to 1/64th.
In PCB design 1mil mismatch is a no-fit, tool collision and a full fail. Hand shifting every other pair of pads to the next 0.1mil helped, BUT:
One would need µmil to convey the granularity of imperial mechanical units into decimals, here 0.015625",
and indeed the later KiCAD versions had to acknowledge that and went to convey nm granularity.
And don't get me started about recent and historical drawings conveying such faults,
omitting the underying design rules and giving rounded or even misleading numbers...

[cubicibo]

For the SD framerates we could get off with 1/30000s base ticks and dividers of 1001 (NTSC) and 1200 (PAL).
Now the HD double framerates 59.94/50 would be asking for 1/60000s base ticks and dividers of 1001 (Double-NTSC) and 1200 (Double-PAL).

A common 90 kHz base clock with integer math is not sufficient. Ideally, all computation must use fractions to avoid rounding errors. This is required for 23.976 and 59.94, as they are equal to 3753.75 and 1501.5 ticks respectively. If you wish to process all common framerates as an integer count of ticks, you need to use a 360 kHz base clock.

Even FFmpeg gets 23.976 wrong in TS containers: all video PTS will be spaced by exactly 41.7 ms (3753 ticks), effectively producing a video running at 23.980815 fps rather than 23.976. 23.976 requires the PTS delta to be 3754 on every frame except when `frame_id & 0x3 == 1`, where it has to be 3753. This all comes down naturally if you use fractions, as the tick count is truncated to integer at the very end.

But in the digital realm, you may encounter any framerate and even some where frames last longer than on second. It is the responsibility of the software to convert a milliseconds timestamp to a frame count accurately without any rounding error.

[Emulgator]

Ah yes, true. The 23.976fps being a fraction of NTSC indeed calls for 1/360000s ticks to make integer math sufficient.
Good find about FFmpeg, this tells a story about odd reported framerates relying on that.
I remember a discussion in mpucoder's forum about handling such prime fractions within his DVD VOB muxer,
and how he got kudos for implementing that elegantly...

[cubicibo]

I would still advise to use (integer) milliseconds for a subtitle editing software. The key is to implement a solid TimestampTimecode class that can be manipulated on both frames and millisecond at any time.
- When loading a SRT file, the framerate would be 1000 and both MS and TC are processed the same. If the user then specify a framerate to author the subtitles, then internanally the processing would adapt if the user shift everything by a single frame.
- When loading a PGS or DVB file, framerate would be inferred from the stream metadata (and possibly PTS?)

Anyhow, this is easy to suggest, but not necessarily easy to implement in the codebase.

[markfilipak]

Which in the end would ask for an internal granularity...
Ummm, unless there's something I don't know about...
SE needs to work from frame numbers...
Frame numbers, not accumulations. ...Or-- Or just grab the previous/next frame's PTS and compute hh:mm:ss.ms from that. How hard could that be, for gosh-sakes.

[markfilipak]

...If you wish to process all common framerates as an integer count of ticks, you need to use a 360 kHz base clock...
Actually, 720KHz is more comprehensive. I've used that as TB in FFmpeg and it worked fine in most play-software, but some play-software refused to play the videos.

[cubicibo]

You are missing the point. Subtitles are adapted to a given video whose timebase shall not be modified. This is why subtitles frequently use their own timebase in milliseconds. If the user wants to round timestamps to the closest frames, up to them to instruct the subtitling software what is the FPS and rounding direction. Anything else is insanity; just look at the complexity of VS and AVS source filters and how often they fail to estimate the framerate.

This is exactly why I said the default time unit should be a millisecond, unless the subtitle format specify a framerate, like PGS.

[markfilipak]

You are missing the point. Subtitles are adapted to a given video whose timebase shall not be modified.
Agreed.
This is why subtitles frequently use their own timebase in milliseconds.
Agreed.
If the user wants to round timestamps to the closest frames, up to them to instruct the subtitling software what is the FPS and rounding direction.
Subs and frames are unrelated... unless you want subs snapped to frames (which I do because I make tight subs and because I've found snapping to frames, especially to shot-change frames, to be necessary for flawless reading while listening.) I'd love to use all the sub-windowed features of SE all the time, but I've found SE unfortunately doesn't maintain frame snaps. So, I mainly use SE as a simple UTF-8 text editor.

Now, I'm fairly new to SE. There may be settings that do maintain frame snaps during editing but I just haven't found them. I would gain more confidence with SE if I knew what "cues" were and what the red and green zones signify.

[markfilipak]

Great news. I now see how SE is intended to be used. It took me 50 minutes to do what yesterday would have taken half a day. SE is terrific, but only if used as Nikse has planned.

But isn't that the way it always is? Isn't learning a tool mainly learning how the designer intended it to be used, and then sticking with it?

To paraphrase a well-known adage: "In the dark, every problem looks like a nail sticking up." Well, SE is there, but it's in the dark.

[markfilipak]

I stumbled across this:
https://github.com/Flitskikker/SubTimingsBeautifier/wiki/How-to-use-Sub-Timings-Beautifier
It appears that Nikse has integrated Flitskikker's work into SE, but with some changes.

There are 11 green Zones and 11 red Zones. What do the colors signify?

In cues
Zones (blank interval)
(green) <-- what does this control?
(red) <-- what does this control?
Zones (subtitled interval)
(green) <-- what does this control?
(red) <-- what does this control?
Out cues
Zones (subtitled interval)
(green) <-- what does this control?
(red) <-- what does this control?
Zones (blank interval)
(green) <-- what does this control?
(red) <-- what does this control?
Connected subtitles
In cue is closest
Zones (end of sub1)
(green) <-- what does this control?
(red) <-- what does this control?
Zones (start of sub2)
(green) <-- what does this control?
(red) <-- what does this control?
Out cue is closest
Zones (end of sub1)
(green) <-- what does this control?
(red) <-- what does this control?
Zones (start of sub2)
(green) <-- what does this control?
(red) <-- what does this control?
Chaining <-- what is the physical meaning of "Chaining"?
General
Zones
(green) <-- what does this control?
(red) <-- what does this control?
In cue on shot change
Zones
(green) <-- what does this control?
(red) <-- what does this control?
Out cue on shot change
Zones
(green) <-- what does this control?
(red) <-- what does this control?

Related Questions: What
- if a subtitle ends before a red Zone?
- if a subtitle ends in a red Zone but before a green Zone?
- if a subtitle ends in a green Zone?
- if the green Zone is larger than the red Zone?
- if the red Zone is larger than the green Zone?
- if the red Zone and the green Zone are the same size?
- if a subtitle begins after a red Zone?
- if a subtitle begins in a red Zone but after a green Zone?
- if a subtitle begins in a green Zone?
- if the green Zone is larger than the red Zone?
- if the red Zone is larger than the green Zone?
- if the red Zone and the green Zone are the same size?

PS: To clarify: Martijn van B. (aka Flitskikker) has written some nice documentation. But that documentation has not been included in SE, not even by reference, and, what green and red Zones signify is not documented.

[markfilipak]

Is there any way to force SE to put these:

'c:\Users\Administrator\AppData\Roaming\Subtitle Edit\TimeCodes\a4380571ab71e489.timecodes'
'c:\Users\Administrator\AppData\Roaming\Subtitle Edit\ShotChanges\a4380571ab71e489.shotchanges'
here:

'g:\[D]\Videos\_subtitles_chapters\STAR TREK, TNG [1987..1994]\5-113 Conundrum.timecodes'
'g:\[D]\Videos\_subtitles_chapters\STAR TREK, TNG [1987..1994]\5-113 Conundrum.shotchanges'
instead, so that they go right beside this:

'g:\[D]\Videos\_subtitles_chapters\STAR TREK, TNG [1987..1994]\5-113 Conundrum.srt'
Why? Well, when I launch SE on '5-113 Conundrum.srt', it is not finding the timecodes and shotchanges, so I have to run beautify again. Also, the numbers are making me crazy.

Edit: I tried to import 'C:\Users\Administrator\AppData\Roaming\Subtitle Edit\TimeCodes\a4380571ab71e489.timecodes', but that failed.
The image below is a composite of 2 screen shots.
https://forum.doom9.org/attachment.php?attachmentid=18777&stc=1&d=1732858550

Huh? "...include a copy of the subtitle." I don't know how to respond.

[Emulgator]

At the moment SE rolls the dice to make names, and paths are hardcoded.
Maybe you can ask Nikse to change that, I would welcome that too.

[markfilipak]

At the moment SE rolls the dice to make names, and paths are hardcoded.
Maybe you can ask Nikse to change that, I would welcome that too.

Thanks, I will. That purportedly is the way Flitskikker's beautifier worked. ... I would run Flitskikker's beautifier on its own and then import the timecodes and shotchanges but as you see from my previous post, importing timecodes doesn't seem to work either -- it seems to provoke some sort of generic unknown-subtitle-type response. I've tried opening to the SRT file, and opening to the video file, but whichever file is opened first, I get the same response upon import of the previous timecodes. Actually, SE _should_ bring in the existing timecodes that it generated in an earlier run, but that isn't happening either. Oh, dear. Do you have any insight into these problems? I'd prefer a workaround to having to spend the time and effort to compose and test and document a bug report.

[Emulgator]

Here I run 5 versions of SE side by side as noinstalls,unpacked straight from the .zip, so no hassle with hidden/shared paths.
C:\Users\Administrator\AppData\Roaming\Subtitle Edit\TimeCodes\: I would abhore that ;-)
For the cutting edge version
C:\_PROG\! Subtitle Tools\SubtitleEditBeta\SceneChanges
C:\_PROG\! Subtitle Tools\SubtitleEditBeta\ShotChanges
C:\_PROG\! Subtitle Tools\SubtitleEditBeta\TimeCodes
For the safe versions SE408
C:\_PROG\! Subtitle Tools\SE408\SceneChanges
C:\_PROG\! Subtitle Tools\SE408\ShotChanges
C:\_PROG\! Subtitle Tools\SE408\TimeCodes
and so on down to SE404.
Let SE generate the first set of timecodes/shotchanges.
Make a copy of each, rename the originals
6316127b6e514232.timecodes20241130a
change any threshold and let SE regenerate.
Same procedure. Rename to
6316127b6e514232.timecodes20241130b
.....
6316127b6e514232.timecodes20241130c
Now you may merge (WinMerge)/handedit on these.
Merge them as you prefer and rename the result back to
6316127b6e514232.timecodes
SE should read that file with the same name back into the linked project without knowing you were inbetween.
If I can force a timecode file with differing name into a project... let's see.
At the moment I can't find the way of SE linking the .waveform .gifs, and the timecodes, and the shotchanges with the assets.

[markfilipak]

Here I run 5 versions of SE...
Emulgator, I'm going to assume you are responding to me. Kindly forgive me if I'm wrong.

Why are you running five differing versions of SE?

Are you suggesting that differing shotchanges, some with 'bright'-thresholds (~0.20) and some with 'dim'-thresholds (~0.07) be made, then edited, then merged with the bright segments taken from the 'bright'-shotchange file and the dim segments taken from the 'dim'-shotchange file? Yes, of course. But is that necessary?

I have set threshold to 0.07 and simply ignore any false shotchange-bars that result -- they really don't hurt anything. As an experiment I was thinking of setting threshold to 0.01 in hopes that every frame would be considered a shotchange frame so that when I move subtitle front-ends and/or back-ends with shotchange-snap "ON", they will always be frame-aligned. I don't have the time for the experiment now, but I may do it in the future.

Edit:
I tried to do the experiment but the shotchange threshold (aka "sensitivity") wouldn't go below 0.05, so I abandoned the attempt.

[guest]

I have a lot of trouble when the subtitles I run thru SE have a lot of these ♪...

It doesn't seem to make any difference if the Music Symbol option is checked or not.

[Emulgator]

Shotchanges can of course be handled within one version of SE, ffmpeg/ffprobe do not change in that regard.
And setting any threshold to very sensitive, then deleting the false positives is good too.

I only mentioned my 5-version approach to explain the possibility of choosing from a multitude of results without having to un/reinstall
AND no interference with my files while in common system paths.
If I want to introduce any file to the other SE version I copy over and I rename, not hoping for being picked up or not and fail.

As an example the various speech-to-text results of the various whisper installations that manifest with different SE versions across different languages make it worth for me.
In the end I shall keep 3.6.13 with the then whispers, and maybe some 2 or 3 earlier versions 4.0.x, like 4.0.2, 4.0.4..., and the last version.

[markfilipak]

I have a lot of trouble when the subtitles I run thru SE have a lot of these ♪...

Tip: Those are UTF-8 symbols. Do you have trouble with UTF-8? What sort of trouble?

[markfilipak]

Timecodes from the preceding session do not reload in a new session -- same MP4, same SRT. In an attempt to make the situation better, if I use 'File'>'Import'>'Time codes...' an open dialog appears; if I deselect 'Files of type: Subtitle files'and select 'Files of type: All files'then browse to 'c:\Users\Administrator\AppData\Roaming\Subtitle Edit\TimeCodes\eeab10db83639b26.timecodes' and open it, I get the timecode list, but with same "Unknown subtitle type" notice shown in my posting, here: https://forum.doom9.org/showthread.php?p=2010626#post2010626. If I nonetheless click [_Okay_], timecodes are still not loaded. I believe this is a bug. Does anyone wish to comment? Replication of this would be helpful. Thanks!

[markfilipak]

May I suggest again that there needs to be a hard <br />? Perhaps shown as <<br />>?

Without <<br />>, this:
- PICARD: Situations like these are<br />- What?
- PICARD: never easy, Number One.<br />- What wasn't easy?
is displayed as
- PICARD: Situations like these are- What?
- PICARD: never easy, Number One.
- What wasn't easy?
If I add any punctuation following the word "are", then the second line of the first subtitle is correctly displayed (along with the bogus punctuation of course). But if there is nothing following the word "are", then the second line is incorrectly concatenated as shown above.

[Emulgator]

No problems here. I just input text "- PICARD: Situations like these are" without tags, press ENTER, and there it is: A hard line break.

[markfilipak]

No problems here. I just input text "- PICARD: Situations like these are" without tags, press ENTER, and there it is: A hard line break.

The problem is with the 2nd line following the 1st line. There is no hard line break between them even though there's <br /> between them, so, the 1st & 2nd lines become one line. I have run into this error many times. This time, I can't find a trick to fix it -- that is, I can't put any punctuation at the end of line 1. Look at my post completely.

PS: I just reread your posting... I am _not_ putting the '<br />' tags in. SE is putting them in.

PPS: To be clear, the source is this:

545
00:36:42,450 --> 00:36:44,740
- PICARD: Situations like these are
- What?