Subtitle Edit

[Nikse555]

Originally Posted by markfilipak

I stumbled across this:
https://github.com/Flitskikker/SubTi...ngs-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]

Originally Posted by Nikse555

... 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]

Originally Posted by Emulgator

...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]

Originally Posted by Emulgator

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]

Originally Posted by Nikse555

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/subt...leEditBeta.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]

Originally Posted by Nikse555

... the video file name of now a part of the shot changes file name.
https://github.com/SubtitleEdit/subt...leEditBeta.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.


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).

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]

Originally Posted by Emulgator

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).