Subtitle Edit

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

Originally Posted by VoodooFX

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

Originally Posted by Emulgator

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]

Originally Posted by Emulgator

Which in the end would ask for an internal granularity...

Ummm, unless there's something I don't know about...

Originally Posted by markfilipak

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]

Originally Posted by cubicibo

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

Originally Posted by cubicibo

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/SubTi...ngs-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.


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.