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!