Subtitle Edit

[cubicibo]

SRT sucks, stop using it and move to better formats like ASS.

[guest]

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

OK, so how do I deal with that ??

I don't have any other issues that are worth complaining about, but the music symbol is a problem, and has been for me, for years.

I "rip" the subs using gMKVExtractGUI.v2.6.4, and then run it thru SE, and some of the characters that it replaces the music symbol with, are very random & varied.

I will capture the symbol every so often, tho.

Any suggestions ??

[guest]

SRT sucks, stop using it and move to better formats like ASS.

Maybe so, but what if your TV doesn't recognise ASS ???

[cubicibo]

Maybe so, but what if your TV doesn't recognise ASS ???

Complain to the TV manufacturer, or use other formats. People got LG to add support for new formats by complaining continuously.

[markfilipak]

... Any suggestions ??

Yes. Use SE to rip the subs.

[Emulgator]

I think I get it now.
I was inputting 1st line by hand, pressing ENTER, inputting 2nd line and fine, got my hard line break;
and you were handing over a 2-liner .ass file which got then rendered as 1-liner ?

[markfilipak]

I think I get it now. ... and you were handing over a 2-liner .ass file which got then rendered as 1-liner ?

Not quite, my friend. I'm working on an SRT. This fragment:
545
00:36:42,450 --> 00:36:44,740
- PICARD: Situations like these are
- What?
is the SRT source. And because "are" is not followed by a punctuation character, it's rendered as this:

- PICARD: Situations like these are- What?
This:

- PICARD: Situations like these are<br />- What?
is the list version of the same fragment. Is that clear, now?

What I propose is that a hard line break be added to SE so that the lines are displayed as this:
- PICARD: Situations like these are
- What?
I also propose that the hard line break be list-displayed as <<br />>.

PS: It occurs to me now that perhaps the "are<br />" -- no punctuation following "are" -- exposes a bug, eh?

[Emulgator]

Copied your first code block 545... into Editor, renamed Picard.srt, opened onto any odd video in SE4.0.8:
Rendered here as a 2-liner from the start.
A program settings thing maybe, otherwise the world of SE users would have complained ?

[markfilipak]

... A program settings thing maybe, otherwise the world of SE users would have complained ?
Oh, dear... I have:
'Settings'>'Continuation style'>'None' <<-- this is my setting
'None, dots for pauses (trailing only)'
'None, dots for pauses'
'None, ellipsis for pauses (trailing only)'
'None, ellipsis for pauses'
'Dots (trailing only)'
'Dots'
'Ellipis (trailing only)'
'Ellipis'
'Dash'
'Dash, but dots for pauses'
'Custom'
Perhaps your setting is something other than 'None', eh?
I don't think I've changed any settings other than 'Appearence'.

[Emulgator]

"None" here as well, never touched it. Hm.

[Emulgator]

A writeup of SE's proxy file depencies/conventions, maybe helpful for any manual pruning:
https://forum.doom9.org/showthread.php?p=2010776

[markfilipak]

"None" here as well, never touched it. Hm.
It's a mystery... Thanks for trying. ...Umm, look at your SRT in list mode and make sure that "are" is followed by "<br />" with nothing in between?

PS: I now think this bug has nothing to do with punctuation (see https://forum.doom9.org/showthread.php?p=2010877#post2010877).

[Emulgator]

(Retyped from list window)
- PICARD: Situations like these are<br />-What?
renders correctly as 2 lines in Edit window.
Without video, without audio, naked SE 4.0.8 standalone, unpacked from .zip, no common paths.
Conflicting/shared Settings.xml ?

[markfilipak]

A writeup of SE proxy...
I believe you are misusing the word "proxy". I think you mean "specification".

[markfilipak]

(Retyped from list window)
- PICARD: Situations like these are<br />-What?
renders correctly as 2 lines in Edit window.
Without video, without audio, naked SE 4.0.8 standalone, unpacked from .zip, no common paths.
Conflicting/shared Settings.xml ?

Yours:- PICARD: Situations like these are<br />-What?
Mine:- PICARD: Situations like these are<br />- What?

PS: I've noticed that SE has a lot of off-by-one bugs. This may be one of them.

PPS: The dialog is from "Star Trek: The Next Generation", season 5, episode 123, "The Next Phase". I just reloaded it and ran a test. I could not replicate the problem. That's disturbing. It means the problem has something to do with timecodes and/or shotchanges, which were not reloaded even though they still exist. I continue fixing ST:TNG subtitles and will keep my eyes open to this problem and see if I can replicate it in the future.

[guest]

Yes. Use SE to rip the subs.

OK, thanks, I will it a shot :)

[leoenc]

Is there a way to set more parameters for VobSub export via the command line? (E.g. font family, size, simple rendering...)
Perhaps there's a way to use a template file with all of the settings that are available in the GUI VobSub export window?

[markfilipak]

Is there a way to set more parameters for VobSub export via the command line? (E.g. font family, size, simple rendering...) ...

Subtitles on DVDs and Blu-rays are pictures of text. You can use FFmpeg to split out the pictures and save them as graphics. That's what SE does. To get letters with fonts and sizes you need to optically convert the pictures to strings of textual characters. That's what optical character recognition (OCR) does.

[leoenc]

@markfilipak, maybe I wasn't clear. I'm converting SRT to VobSub, not the other way around.
Here is my current CLI:
SubtitleEdit.exe /convert subtitle.srt VobSub /fps:25 /resolution:3840x2160 /targetfps:25

[markfilipak]

@leoenc, if you are making an MP4, I've not seen any computer-based player that will not render an embedded (muxed-in) SRT stream. So, I assume you're making a DVD and need vobsubs. I don't do that. I can't help. Sorry. I suggest you try FFmpeg.

[leoenc]

Actually I need to create MPEG-TS with DVB subtitles in ffmpeg, which requires bitmap based subtitles as input.

[markfilipak]

Actually I need to create MPEG-TS with DVB subtitles in ffmpeg, which requires bitmap based subtitles as input.

I've not done that, but I know that others have. FFmpeg has the text renders, with font control, and the codecs to get what you want. If you figure out the FFmpeg commands that do it, you may be able to use the very same commands in SE since SE uses FFmpeg... or you can just do it in FFmpeg and skip SE entirely.

[leoenc]

I haven't been able to convert textual subtitles to bitmap based subtitles with ffmpeg. It is limited to text->text or bitmap->bitmap workflows.

BUT, I managed to get much better results with SubtitleEdit /Convert when using ASS instead of SRT as I can edit the font/size etc. in the ASS file itself before conversion.

[Emulgator]

A resolution 3840x2160 is is out of vobsub specs anyway.
In .ts 1920x1080 SUP would work.
Then your workflow would be <your file> SE -> .srt -> tsMuxeR -> .ts or .m2ts
In tsMuxeRGUI you can specify font, color and alignment for the first SUP stream.
If you need more SUP streams then you would handedit the other streams into the tsMuxeR .meta file from first attempt, then run the tsMuxeR CLI from a batch file pointing to that .meta file.

[markfilipak]

I haven't been able to convert textual subtitles to bitmap based subtitles with ffmpeg. It is limited to text->text or bitmap->bitmap workflows.

You are presuming. It is not true. I know people have made bitmaps from text using FFmpeg and then made subtitles from the bitmaps. I've not needed to do that myself.

[leoenc]

A resolution 3840x2160 is is out of vobsub specs anyway.
In .ts 1920x1080 SUP would work.
Then your workflow would be <your file> SE -> .srt -> tsMuxeR -> .ts or .m2ts
In tsMuxeRGUI you can specify font, color and alignment for the first SUP stream.
If you need more SUP streams then you would handedit the other streams into the tsMuxeR .meta file from first attempt, then run the tsMuxeR CLI from a batch file pointing to that .meta file.

I deliberately use double the resolution of full HD, as then the subtitles render with antialiasing when scaled down.
When using SUP as source, the subtitles render incorrectly by ffmpeg (half of the subtitles is cut off).
I cannot use GUI tools, I'm building an automated workflow.

[leoenc]

You are presuming. It is not true. I know people have made bitmaps from text using FFmpeg and then made subtitles from the bitmaps. I've not needed to do that myself.

I'm not presuming. Here is the output straight from ffmpeg:
[sost#0:2/dvbsub @ 0000024b03ac9cc0] Subtitle encoding currently only possible from text to text or bitmap to bitmap

Trust me, I've posted this after days of researching this online. I couldn't find anyone that made this work otherwise.

[Emulgator]

3840x2160 is is out of SUP specs as well, this plane is limited to 1920x1080.
No GUI ? see tsMuxeR CLI.

[markfilipak]

Trust me, I've posted this after days of researching this online. I couldn't find anyone that made this work otherwise.

FFmpeg can make static pictures out of any text. Once they are pictures, the pictures can be converted to various graphical subtitle formats. I've not done that sort of thing, but others have. If the graphical subtitles get cut off, then the pictures need to be dimensioned to oppose the cut off. Again, I've not done that, but others have.

There is an FFmpeg user's mailing list by which you can ask questions.

PS: When you render the text as pictures, you don't have to save them as files with serialized names. The pictures can be streamed into the coder that makes the subtitle stream, then the streams can be muxed -- all in one process, one command line.

PPS: You see, FFmpeg is not meant to be evoked by end-users. It's meant as a go-between between a script or GUI and the coders. That's why so many FFmpeg error messages say "Fix your code". That's why the FFmpeg documentation is unsuited to novices.

[markfilipak]

I've noticed that this: "- This is one speaker<br />- This is another speaker" splits to make this:
This is one speaker
This is another speaker
But this: "- This is one speaker--<br />- This is another speaker" splits to make this:
- This is one speaker--
- This is another speaker
The "^- " (regexp) substrings are not being removed. It is a hard fault. It has nothing to do with punctuation.

Again, I suspect an off-by-one bug.

[Nikse555]

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.

...

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.

Martijn (as the nice guy he is) has integrated his "SubTimingsBeautifier" into SE.
Read more here: https://github.com/SubtitleEdit/subtitleedit/pull/7105

----

Also, sorry for not being more active here.

@markfilipak: You reported a crash a while back... I cannot re-create the crash, can you still?

[markfilipak]

... Also, sorry for not being more active here.
It's nice to 'see' you here. I do hope all is well.

@markfilipak: You reported a crash a while back... I cannot re-create the crash, can you still?
I will try, sir. Let me explain...
I now use SE as expected: Layout 1, beautified, audio loaded. I used to use Layout 12 with MPV running separately and while switching between source view and list view. Unfortunately, I don't recall whether the crash occurred in Layout 1 or Layout 12.

There appear to be two major problems: 1, regexp, and 2, focus. I will cover them separately.

1, regexp.
The crash occurred during a regexp 'Find' but you already know that. I've found that sometimes regexp is sticky: a case sensitive 'Find' following a regexp 'Find' does not do a case sensitive search for the new string, but instead repeats the regexp search for the previous regexp. That 'stickiness' happens regardless of what the 'Find' dialog shows is selected. When it happens, if I close the 'Find' dialog and reopen it, the search history dropdown doesn't show the new string at all -- as if the case sensitive search didn't occur. Regexp seems to behave better now that I'm using Layout 1. I will be more diligent now that I know you actually read what I write.

2, focus.
Lack of focus and bogus focus is driving be a bit goofy and I sometimes lose whole subtitles. In Layout 12, there is no focus when SE is launched. As a result _all_ searches fail. I have to F2 from list view to source view, click on something (anything) in source view and then F2 back to list view. Once again, Layout 1, seems to not have this problem.

Edit add:
If I click the controls of the audio streamer: 'Play current' 'Next' 'Pause' or the play-pause button below the audio waveform, I may not notice that the 'Text' box has the current subtitle selected. If I use 'space' to stop the play, the current subtitle is replaced by that space character. I am not selecting the text. SE seems to do that on its own.

If the preferred usage is to open the SRT, then open the MP4, then apply timecode and shotchange beautification, then capture audio, I'd prefer SE to open a dialog for the SRT and MP4 and then do everything in one go so that I can do other things on my computer while the timecodes, shotchanges, and audio are loading.

Also, if I close SE and reopen, the timecodes, shotchanges, and audio are not reloaded. I have to go through the sequence all over again. I've tried importing timecodes and shotchanges from the previous session but that doesn't work.

I will do whatever you ask in order to help you.

Oh, yes, one more thing: I've noted cursor positioning and regexp errors that are best described as off-by-one faults.

--Mark.

Update: I just reloaded a prior job and timecodes, shotchanges, and audio waves _were_ reloaded, so whether or not reloads work is variable and not predicable. I will try to pin the problem down but I can't dismiss the feeling that it's related to focus flakiness. Initialization seems flaky.

[markfilipak]

I've realized why timestamps and shotchanges and wavs are sometimes not reloaded. When I make video.mp4 that has new subtitles, SE thinks it's a new job and doesn't reload the timestamps and shotchanges and wavs. It thinks it's a new job because the hash of video.mp4 has changed.

Hey! The video and audio streams have not changed! They have been remuxed with the new subtitles, that's all. The old timestamps and shotchanges and wavs are still valid.

This is also probably why I could not import the old timestamps and shotchanges and wavs.

Suggestion: Get rid of the hashes and use _names_. That would eliminate the problem. I can manipulate names. I can't fix-up hashes.

[Emulgator]

You can.
Let SE generate just one cheap kind of proxy file from the new video.mp4, the .wavs are enough.
You only need their hashed name. Copy the new name.
Paste the name to your trusted old proxy files, be it .shotchanges, reload.
BTW, I don't like hashes either, I am a handedit guy too.
But they make sense, because a reencode/remux under the same name might have different properties and following assumptions may fail silently.

[markfilipak]

...But they make sense, because a reencode/remux...
There is no reencode. The timestamps and shotchanges and wavs do not change. You know that. You wrote "reencode" while you were on autopilot. :-)

[Emulgator]

A .mp4 which "has new subtitles"... muxed in ? The hash algo would see a non-identical stream.
Is that a reencode or not ? For the hash algo: yes, for someone who concentrates on the video stream only: maybe not.
As I sequentially added 3 streams audio muxed into my .mp4 intermediates, that hash also changed.
So I had to adjust to that, renamed and could reuse what I prepared before.

I would expect no change in ,mp4 stream hash and no change in sideloading of proxies indeed, if you just generated .srt or .ass sidecar files.
Is it the latter ?

[markfilipak]

A .mp4 which "has new subtitles"... muxed in ?
Yes.
The hash algo would see a non-identical stream.
Is that a reencode or not ?
No. If I belabor the issue, people will not like it. Let me just say that textual subtitles are encapsulated and stored as plain text. They're not encoded. Nothing is reencoded or transcoded; just remuxed.
For the hash algo: yes, for someone who concentrates on the video stream only: maybe not.
By my reasoning, the idea of hashes should be abandoned.
As I sequentially added 3 streams audio muxed into my .mp4 intermediates, that hash also changed.
So I had to adjust to that, renamed and could reuse what I prepared before.
Of course.
I would expect no change in ,mp4 stream hash and no change in sideloading of proxies indeed, if you just generated .srt or .ass sidecar files.
Is it the latter ?
No. I remux -- with the new subtitles -- and then discover I'd missed something. So, I launch SE and fix it and remux a second time. I have built a factory to do it. During the intermediate fix, I usually don't need to consult the timestamps, shotchanges, or wavs, but sometimes I do.

I understand why Nik uses hashes. But if I choose to import the old timestamps, shotchanges, and wav, should SE silently refuse? ...I'll leave that statement as my final thought. Your idea to run new wavs and then rename the others is a good one. I'll use it. Thanks!

[markfilipak]

Using SE is the preferred manner... A regexp 'Find' for ^- (in order to find subtitles that contain splits) works only in the 'forward' [F3] direction. In the 'reverse' [Shift]+[F3] direction, any previous - is found regardless of whether it's at the beginning of the subtitle. To me, this again indicates an off-by-one flaw.

[markfilipak]

I would really like it if, when the mouse is over the waveshapes, the focus in _on_ the waveshapes instead of on the 'Text' box. That way, mouse scrolling would work and the space bar would control play-pause (instead of overwriting the subtitle text). By the way, I did not _put_ the focus on the 'Text' box -- it just happens (and is really irritating).

[Nikse555]

You can use Options - Settings - Waveform - set focus on mouse enter.

Would it help, if you could select from shot changes from the cache (from old video files), in the menu Video - Import shot changes?

Hopefully 4.0.9 will be out soonish.

[markfilipak]

You can use Options - Settings - Waveform - set focus on mouse enter.
Thank you! That's wonderful. I set both:
[x] Set focus on mouse enter
[x] Also set list view focus on mouse enter in list view
You might consider making those default.
To be honest, Settings scares me. I once clicked "Restore default settings" thinking it applied to only the settings that were shown but SE restored _all_ default settings, including 'Multiple replace'. I lost a lot of work.

Would it help, if you could select from shot changes from the cache (from old video files), in the menu Video - Import shot changes?
Yes indeed! But only if it was possible to determine the name of the video. Instead of hashes, consider this: VideoName.shotchanges, VideoName (1).shotchanges, VideoName (2).shotchanges, ...

May I send you a private message?

[Nikse555]

OK, beta updated. SE can now import shot changes "From existing cache..." - and the video file name of now a part of the shot changes file name.
https://github.com/SubtitleEdit/subtitleedit/releases/download/4.0.8/SubtitleEditBeta.zip

Sure, I do read private messages.

[markfilipak]

When SE is run on a command line, and when it's ready to OCR, it opens a "Transport stream subtitle chooser" dialog. That dialog is not getting the focus and does not appear on the taskbar. The only way to see it is to minimize the other windows. However, windows that are running virtual machines will not minimize, so the dialog cannot be seen at all. That situation requires fixing. All that is needed is for SE to appear on the taskbar so that it can be clicked.

This applies to Windows.

[markfilipak]

... the video file name of now a part of the shot changes file name.
https://github.com/SubtitleEdit/subtitleedit/releases/download/4.0.8/SubtitleEditBeta.zip

I'm running the beta. The video file name is _not_ part of the shot changes file name.

[markfilipak]

When running SE on a command line:
"C:\Program Files\Subtitle Edit\SubtitleEdit" H:\BDMV\STREAM\source.m2ts
SE wants to save the SRT here:
H:\BDMV\STREAM\source.srt
However, drive H: is an optical disc drive, so saving source.srt there fails. I've tried all the usual command line switches listed by 'SubtitleEdit /help'. None works. How can I get SE to save the SRT somewhere else by default (i.e., without browsing in the save dialog)?

[markfilipak]

In September I created an SRT by my old method, which was to extract subs from the source M2TS, then use FFmpeg to make an MP4, then run the MP4 in MPV while manually editing the SRT in SE. I essentially used SE, source mode, as a UTF-8 text editor. Then I used FFmpeg to mux the SRT into the MP4. The whole process took forever but the subs were exact. Each sub started and ended exactly in sync with the vocalizations -- very, very tight. (Actually, too tight.)

Now I'm using SE on that SRT in the way Nikse intends: layout #1 with snaps to timecodes and shotchanges, and I find the subs are a little more than 700ms early -- that's 17 frames early, very noticeable.

In frustration, I threw out the SRT and extracted a new SRT _from_ the MP4. Right now I'm looking at the MP4 via MPV, frame-by-frame, while looking at the SRT. The subs in the _new_ SRT are 3 frames early. I am baffled.

https://forum.doom9.org/attachment.php?attachmentid=18781&stc=1&d=1734663213
The top waveform is from the stereo stream. The bottom waveform is the FC channel of the 7.1 stream. They are different and neither of them match the times of actual utterances as I have observed from lip movements in MPV. In MPV they are identical. In SE they are both wrong.

The top waveform is 1000ms early. The bottom waveform is 800ms early.

The only way I noticed these errors was because my original SRT was manually made, via my old method (i.e., Layout #12), with exact subtitle startings and endings that were exactly matched to lip movements.

Summary: The actual subs in the MP4 are exact. But the subs extracted from the MP4 are 3 frames early. The waveforms shown are 1000ms early for the stereo source or 800ms early for the front-center channel of the 7.1 source. So many moving parts makes this a confusing issue, eh? Are you confused? I hope not.

PS: To help clear this up, What is shown below is what SE displays (top) versus actual (bottom).
https://forum.doom9.org/attachment.php?attachmentid=18783&stc=1&d=1734727865
The subtitle start is actually slightly later than what SE displays, and the actual utterances quite a bit later than what SE displays.

Nikse, I've tried every way I know to get this sample to you. It's only 364MB. Neither github nor email will accept it. Sorry.

UPDATE.
I'm editing the next video and there's no problems. Something about the video above is throwing SE off, or throwing FFmpeg off, or both. I will retain the six minute sample for a few days...

UPDATE.
Unfortunately, the screen capture in "PS:" has been removed. Doom9 did that, not me.

[markfilipak]

Here's what I want:
All in- and out-cues aligned with frames. <<-- I have done this
I will manually put in-cues on shot-changes, or not.
If sub1's out-cue is less than 2 frames from sub2's in-cue, then move sub1's out-cue to sub2's in-cue minus 2 frames.

SE is moving in-cues. I don't want SE to move in-cues.

How do I set up Tools > Beautify time codes... > Edit profile to do what I want?

There's an alternative: If you know what red zones and green zones are about, would you please, please tell me?

[Emulgator]

Summary: The actual subs in the MP4 are exact. But the subs extracted from the MP4 are 3 frames early.
The waveforms shown are 1000ms early for the stereo source or 800ms early for the front-center channel of the 7.1 source.
If the source SE gets to see contained any muxing offsets ("audio delay", timestamp offsets and so on) it will be a can of worms.
The usual muxing offset TS of Blu-ray .m2ts alone generates such unexpected offset because on timestamp generation
ffmpeg reads the stream, finds first frame at muxing offset TS, reports that as "timecode" and SE can only interpret that as valid subtitle timecodes.
While it is not. An extra routine would have to parse such .m2ts extra and subtract that muxing offset value from the reported values, then generate the report. (Maybe a hint to Nikse to add that delay check before)
For now I would get rid of any wrong delay assumptions before manually.
I would not suggest to mux your generated .srt into .mp4 using ffmpeg, and then work from that remux again.
In fact do not use ffmpeg. cubicibo found out ffmpeg using wrong timestamp generations, especially with 23.976p
{45kHz/90kHz->180kHz for 23.976p ->[360kHz for 47.952p] problem:
It takes case-flipping of integers to get muxing right under given TS constraints, and this seems not implemented in ffmpeg yet}
If that applies here, don't know, but that finding is enough for me to avoid ffmpeg for anything muxing altogether.

I suggest to generate your work .mp4 mux containing video (plus all audio tracks and no subs) using any MP4Box GUI, I use MeGUI for that.
I keep all subs as sidecar files and work from the very same .mp4.
Only in the end I mux all subtitles into my desired final container.
Not using any ffmpeg, but MP4Box for .mp4
or tsMuxeR for .MTS, ts, .m2ts, Blu-ray volumes,
or mkvtoolnix for .mkv.
That was beautifully safe so far. Hope that helps.

[markfilipak]

If the source SE gets to see contained any muxing offsets ("audio delay", timestamp offsets and so on) it will be a can of worms.

Hello, my friend.

"Muxing offsets"? "Audio delay"? In an M2TS stream? I've never seen that. What packet analyzer are you using that shows you such a property? Now, I really think the difference in the timing of the two audio streams is in the display, within SE, but I'm always open to learning more of course. :-)

I use SE to extract PGS from the M2TS and convert to SRT via SE's optical character recognition (OCR). I've had no time stamp problems with that step. None at all, ever.

What I think is happening is that when I rerun SE, reopen the SRT, and beautify time stamps again (because SE does not reload the shot changes or wavs), SE is taking the time stamps in the SRT and changing them again -- which it shouldn't do because the time stamps haven't changed. Each time I rerun SE, the time stamps get further and further away from the original time stamps. The key is probably the red and green zones in 'Tools' > 'Beautify time codes...' > 'Edit profile'. But I don't know what the zones are or what red and green signify. It's not documented.

Aside: Only yesterday did I discover that I don't need to quit SE and rerun it -- that simply opening Beautify and clicking "OK" reruns the profile within the current SE session.

... I suggest to generate your work .mp4 mux containing video (plus all audio tracks and no subs) using any MP4Box GUI, I use MeGUI for that. I keep all subs as sidecar files and work from the very same .mp4. Only in the end I mux all subtitles into my desired final container. Not using any ffmpeg, but MP4Box for .mp4 or tsMuxeR for .MTS, ts, .m2ts, Blu-ray volumes, or mkvtoolnix for .mkv. That was beautifully safe so far. Hope that helps.
Yes, thank you. I'll look at those tools. FYI, I've never had a problem muxing via FFmpeg.

[markfilipak]

I think I've found a Beautify profile that works. It's listed below. Is there some way I can bind a single keyboard key -- any key -- to run it via the following:
Alt+T B B B Enter Tab Tab Tab Enter
or really, any method.

Of course, that would not be necessary if SE continuously snapped to frames and continuously ran the Beautify profile, but I understand that it does not.

Tools > Beautify time codes... > Edit profile

General > Gap: 2
In cues > Gap: 0
In cues > Zones: 0 0 0 0
Out cues > Gap: 0
Out cues > Zones: 0 0 0 0
Connected subtitles > In cue is closest > Gap: 2 0
Connected subtitles > In cue is closest > Zones: 2 0 0 0
Connected subtitles > Out cue is closest > Gap: 0 2
Connected subtitles > Out cue is closest > Zones: 0 0 0 2
Connected subtitles > Treat as connected if gap is smaller than: 100
Chaining > General > (•) Zones: 0 0
Chaining > General > If there is a shot change in between: Don't chain
Chaining > In cue on shot change > (•) Zones: 0 0
Chaining > In cue on shot change > [x] Still enforce General rules when unaffected
Chaining > Out cue on shot change > (•) Zones: 0 0
Chaining > Out cue on shot change > [x] Still enforce General rules when unaffected


UPDATE: The profile above works very well. And it's predictable. And it keeps cue points in their places once they have been placed and beautified -- they don't creep. I'm satisfied (though it still would be nice to know what the red and green zones are).