Subtitle Edit

[von Suppé]

Improved the scaling when video player is active (will still use scaling of current video window)...
I had to struggle and figure out a bit to understand what you meant. I think I got it now.

I created a simple, two-lines test-SUP with an utter top-left and an utter bottom-right picture. For (current) "position change WYSIWYG" usage. Try if I could drag the window around so the two subtitles would show in the proper position.
This worked for the top-left corner. I've not been able to get the lower-right corner properly placed (as would be logic). The bottom SUP stays in the black bar under the (fullframe 1920x1080) video, however I drag.
The preview needs some work, indeed.

I can confirm the position-changes themselves are properly honoured in the output. This is great.
It would be a nice touch if the export colours of the new/edited texts could be set to "auto-match" the source colours? (lick lick :D)

Thanks for now, will go test further.

[ismail0100]

Hi @Nikse555

I translated the Turkish language file according to the last master language file (I updated it today.). I sent you an e-mail 1-2 months ago but you didn't say anything, so I write from here. Thank you very much for your works.

Language file: https://www.mediafire.com/file/iyp2ba95rqkfdd7/tr-TR(13.12.2020).xml/file

[Nikse555]

Hi @Nikse555

I translated the Turkish language file according to the last master language file (I updated it today.). I sent you an e-mail 1-2 months ago but you didn't say anything, so I write from here. Thank you very much for your works.

Language file: https://www.mediafire.com/file/iyp2ba95rqkfdd7/tr-TR(13.12.2020).xml/file

thx :)
Sorry, I forgot to write back (but I did add it).
Included in latest beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip


@von Suppé: OK, waiting for the images...

@Janusz: thx, I think the export resolution for ts is fixed now.
SE bdedit can also import bd subs from mks/ts now.

[Janusz]

@Nikse555
Yes, thank you. Good job. So far I checked this short ts and the export / import of the .sup file in beta 243 is already working as expected.
What do you think about combining into dialog lines (adding "-") lines that were separated during the export with the [Use Color] option using the start time of the string?

[ismail0100]

Thank you very much Nikse [emoji1]

[von Suppé]

@von Suppé: OK, waiting for the images...
Hey, this is strange. When I read my post while not logged in at Doom9, the images are directly shown in my post.
Being logged in, no pictures, the links are "awaiting approval".

Can somebody confirm this to be normal? Thanks.

[darksen]

@darksen
Disable the new [Use syntax coloring] option in Settings / Font / UI Font / Text box - that came out in beta.
By default, this option is enabled. When turned off, selecting works as before - no problems.
My version is 3.5.18 NEXT, beta 135.
If you don't want to disable this option, use SHIFT + left / right arrows for precise selection.

Thanks, I thought about that but I really liked the colors.
It is all working like before.

[Nikse555]

@Nikse555
What do you think about combining into dialog lines (adding "-") lines that were separated during the export with the [Use Color] option using the start time of the string?

Thx for testing :)
SE bd edit can now also open subtitles directly from ts files, so that should not be needed (even though not all images from ts files are bd sup).


@von Suppé: I don't see the images when not logged in...

[von Suppé]

@von Suppé: I don't see the images when not logged in...
My bad, sorry. It had to do with Firefox "remembering" these pictures. Cleaned cookies & cache, pictures don't show anymore when not logged in.
So, still awaiting clearance.

[Janusz]

Thx for testing :)
SE bd edit can now also open subtitles directly from ts files, so that should not be needed (even though not all images from ts files are bd sup).

Yes, in this case (such a ts file and the dvbsub strings it contains) everything works fine. I knew that turning on [Use color] would break lines,
but I didn't know that doing OCR and reusing - that is, turning off [Use color] - would reconnect previously separated lines while keeping the color information. :D
Are there more of these nowhere described program behaviors?
Is it possible in the program to export the original images of the subtitles in such a way that they can later be converted into text (OCR) exactly as in this particular case?

Here: https://gitter.im/SubtitleEdit/subtitleedit?at=5ebfc649f3ce603074c0d500 @borifax describes his problem,
which I also encounter - hence my question about adding the option to combine dialogs based on the start time of the subtitle.

[Nikse555]

@Janusz: Where did your last post go?

Anyway, new SE bdedit beta upped: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip
How are the image coordinates in ts files now?

[Janusz]

@Janusz: Where did your last post go?
I only did my tests on this short file, which is available above, and everything looked fine here.
For the same, but full file and other files with colored text, the comments and conclusions drawn were not confirmed, so I decided to delete this post.

Anyway, new SE bdedit beta upped: https://github.com/SubtitleEdit/subt...leEditBeta.zip
How are the image coordinates in ts files now?
The new beta for this short file correctly sets the text and color information. For a full video file, only positioning is correct.

With a full video file, OCR loses color information for some lines. In the fragment shown in the image, all lines should have their color attribute set.
Additionally, if I perform OCR several times in succession for this file with the [Use color] option selected, the lines without color will change.
On the e-mail I sent a link to download a bit longer ts file where you will be able to see how the color attributes change for some lines.

https://www.mediafire.com/convkey/9c8f/3ue7780gbbnbubd6g.jpg

Edit 15/12/2020
I did a few (5) OCR scans for the full video file. Download here. (https://www.mediafire.com/file/ksnrbloi6e85ied/full_ocr.zip/file)
By comparing srt files with each other, you can see exactly that the files are not identical.
There are no differences in the text itself, and this is the most important thing. :D
Interestingly, the differences end at line 89 and then up to 1108 it's clear.
The color attributes for some lines (those up to number 89) are not preserved - they change the shade and even the color, because no color is also a color (by default, e.g. white).
Subtitles changing color will look a bit strange for the actor speaking his text in a longer scene.

[von Suppé]

@ Nikse: Can you confirm that, once a video is opened, positioning and scaling of the previewed SUPs - within the video itself - still need work? I tried your latest Beta 254.

(@ mods: I don't know why my attached pics are still not approved. Please let me know if & why they'd be not proper?).

[Nikse555]

@Janusz: thx for the files - I'm not really sure... but is latest beta better?
https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

@von Suppé: The few files I've tested with here looks good after video is opened... what are the resolution for your sub and video?
(it probably does not take different res of sub/video into account)

[von Suppé]

files I've tested with here looks good after video is opened...

What videoplayer do you have set in Settings --> Video player tab?

...what are the resolution for your sub and video?
(it probably does not take different res of sub/video into account)

Both SUPs and (full-frame) video I test with are 1920x1080.

I'll do some more schreenshots for explanation and post them another way. Waiting-time for attachment approval is annoying in this case. Will be back.

[EDIT] BTW I noticed the Beta at VideoHelp has a higher version-number than your latest Beta here? Any particular one you'd advice to use/not use?

[Janusz]

@Janusz: thx for the files - I'm not really sure... but is latest beta better?
https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip
Unfortunately, there is still no improvement in the new Beta.

Coming back to the srt file comparison.
Since the differences were only up to line 89, I prepared 5 new srt files starting the OCR from line 90. It came out as before.
At the beginning there are differences - this time through 64 lines, then there are no differences to the end of the video file.
I don't know what to think about it.

[Nikse555]

@von Suppé: I use mpv as video player inside SE.
The beta version from Video Help and here is the same. The about box in SE says "3.5.18 Next, beta 256"... "3.5.18 Next" and "3.6.0" is the same.

@Janusz: The color issue should be fixed now (a multi threading issue): https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

[von Suppé]

I'll start my post from a few days ago over again.

I created a 2-line test SUP file with one subtitle positioned in the utter upper left corner and the other one in the utter bottom-right corner. They were authored for 1920x1080 video.
See the images.


The first two pictures show the 2 subtitles directly after opening the video and without having changed the size of the whole edit-window.
The two subs indeed appear in the utter corners, but outside the video. Note that the video you see is full-frame 1920x1080, so no black bars in the video itself.

https://www.mediafire.com/view/etviakbexxctnm3/1.png/file
https://www.mediafire.com/view/06a0leugf7q0url/2.png/file

The other two pictures show the subtitles after having - only - horizontally stretched the edit-windows such, that no black bars appear in the preview.
The upper-left seems ok. Only the position, that is. The bottom-right position is not okay: there's still space between the subtitle and the borders of the video. Note that both subtitles are horizontally stretched (compared to the "originals") by resizing the edit-window.

https://www.mediafire.com/view/dav445x62rstwr9/3.png/file
https://www.mediafire.com/view/jtceq1wa0h6tpsn/4.png/file

That's why I was asking earlier if the preview needs work still. The editing possibilities of this tool are already superb.
The output works like a charm. The WYSIWYG factor that depends on a perfect preview, needs some attention, IMHO.

Sorry, I didn't manage to get the pictures directly inside my post; I'm terrible with this.

[Janusz]

@Janusz: The color issue should be fixed now (a multi threading issue): https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zipThe comparative tests performed in the same way as before turned out well.
With five passes, I got exactly the same result each time - no differences for the text formatting and the text itself.
Great job, thanks.

Still open is OCR of the colored text from the sup file so that the color attributes are preserved in the srt file.
Do you foresee adding such a feature to the program in the future?

[Nikse555]

@von Suppé: OK, I see the issue now... don't know why yet.

@Janusz: cool - thx for reporting the issue and testing :)


Also new stuff in SE bdedit like adjust timings for selected lines + change color for selected lines:
https://www.nikse.dk/se-bdedit-context-menu.png
https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

[Janusz]

I don't know if it should be like that, but:

In your picture, the current line number and the total number of lines both show 54/428. Shouldn't it be 54/427?
At least for me, the total number of lines at this point is always 1 more than it really is.
The visible [Quick OCR texts ...] function disappears from the context menu after it is used and is never again available in a given session.
It also does not appear after loading a new sup file.

[Nikse555]

@von Suppé: The precision in the preview should be better now.

@Janusz: thx for the info - should be fixed now.

Beta link: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip
Also some settings now where it's possible to choose preview colors + margins for alignment.

[von Suppé]

Yes, preview is much better. Thanks for the fix, Nikse555

[VoodooFX]

Here is error when I press on "Image pre-processing..." (subs are imported images):

https://i.imgur.com/4PCs8oJ.png

Another thing, after I finished ocr with nOCR it somehow lost all info/characters I typed in and asks for every character again on same images.

[Nikse555]

@VoodooFX: Sorry, cannot re-produce any of that. Can you? If yes, please share info on how to re-produce :)

@von Suppé: thx for verifying :)

The new SE - import bdsup (from .sup/.mkv/transport-stream), is now close to final first version (save with position info to .sup or bdn xml):
https://www.nikse.dk/se-bdedit.png

[VoodooFX]

@VoodooFX: Sorry, cannot re-produce any of that. Can you? If yes, please share info on how to re-produce :)

Try this image:
https://i.imgur.com/pbjIvsp.jpg

As for trained data loss I can't reproduce it on few image subs.
I'm not sure when it did happen, at the end of whole nOCR job I noticed that one character is detected as italic, so corrected that and started OCR again from first line - SE asks for every character again.

[Melan]

File: .ts
Method: BIC
Everything is fine until checked: Use color. Then:
- The number of subtitle images is increasing,
- Some lines split.

https://i.imgur.com/57QKZzJ.png
https://i.imgur.com/fEx17Ij.png

Sup file as attachment.

[Janusz]

@Melan
If you turn off [Use color] the lines will reconnect and there will be 454 of them.
If you do not disable [Use color] and save the srt file after OCR using [OK], the result will be as many lines as you want (454).
If you do not disable [Use color] and save the srt file after OCR using the context menu, the result will be 463 lines.

[Melan]

To fully see what the error is, you need to work with the .ts file. The .sup file does not fully reflect the problem.
It looks like the text of some colored lines does not fit into the image.

https://i.imgur.com/at4Jl6K.png
https://i.imgur.com/W47Ztxp.png

[Janusz]

@Melan
When it comes to color inscriptions, I work only with ts files, because with sup it is impossible to recreate the color attributes.
The program error in your example is a bad division of the image into lines, and this was not visible in the previous images.

[Nikse555]

Try this image...

thx for the image :)
SE should no longer crash for this image: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

[VoodooFX]

SE should no longer crash for this image
Doesn't crash anymore, but only if "Auto Transparent Background" is selected, deselect it and it will crash. :)

Thanks for active development, I see future in this new nOCR method.
Btw, I think that "Max wrong pixels" at max 50 is not enough for 100x100 or 200x200 characters, or is it?

[Nikse555]

Doesn't crash anymore, but only if "Auto Transparent Background" is selected, deselect it and it will crash. :)

Thanks for active development, I see future in this new nOCR method.
Btw, I think that "Max wrong pixels" at max 50 is not enough for 100x100 or 200x200 characters, or is it?

Good find again :)
This crash should be fixed too: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

Also raised to "Max wrong pixels" to 100.

[hello_hello]

Hi.
For dialogues, is it possible to treat them the same way as single lines? The idea being for the Fix Common Errors function not to convert the word "here" to "Here" by treating lines 14, 15, 18 and 19 the same way as lines 10 and 11. Or is it just not something an automated process can be clever enough to do?

9
00:05:05,212 --> 00:05:07,212
This is a line of dialogue,

10
00:05:07,236 --> 00:05:09,236
here the line of dialogue continues...

11
00:05:09,260 --> 00:05:11,260
here the line of dialogue ends.

13
00:10:06,188 --> 00:10:09,188
- This is the first dialogue,
- This is the second dialogue,

14
00:10:09,212 --> 00:10:13,212
- here the first dialogue continues...
- here the second dialogue continues...

15
00:10:13,236 --> 00:10:17,236
- here the first dialogue ends.
- here the second dialogue ends.

17
00:10:20,260 --> 00:10:24,260
- This is the first dialogue,
- This is the second dialogue.

18
00:10:24,284 --> 00:10:28,284
- here the first dialogue continues...
- This is the second dialogue.

19
00:10:28,308 --> 00:10:33,408
- here the first dialogue ends.
- This is the second dialogue.

Also, some "fixes" seem oblivious to dialogues. For the line below, Subtitle Edit doesn't seem to know the second dialogue should begin with a capital.

4
00:04:22,474 --> 00:04:25,574
- This is line four,
- this is also line four.

The Fix Missing Quotes option seems oblivious to both line breaks and dialogues. It leaves the following unfixed.

1
00:03:21,452 --> 00:03:23,506
- "This is line one.
- "This is also line one.

2
00:03:23,530 --> 00:03:25,431
"This is line two.
"This is also line two.

And... Remove Unneeded Spaces seems to require a line to end in a period in order to work. It would leave these unfixed, but it would fix the missing space if the second dialogue, or both, end in a period (but not if the first line ends in a comma).

6
00:04:58,390 --> 00:05:01,116
-This is line six
-This is also line six

7
00:05:01,140 --> 00:05:03,164
-This is line seven,
-This is also line seven.

Thanks.

[nekrovski]

Few days ago I used batch convert and it worked fine. I try it now, it says failed but I cannot find a log or anything for clues.

Okay, I figured it out. It's because I was pointing to a non existent folder for the output files. I thought Subtitle Edit will create a folder on its own when you try to output to a non existent one.

[Nikse555]

Few days ago I used batch convert and it worked fine. I try it now, it says failed but I cannot find a log or anything for clues.

Okay, I figured it out. It's because I was pointing to a non existent folder for the output files. I thought Subtitle Edit will create a folder on its own when you try to output to a non existent one.

SE normally auto creates the output folder... what's the exact path you entered for output folder?

[Janusz]

@Nikse555
In the latest beta 415 - settings / shortcuts do not list the available keyboard shortcuts in the right-hand window.

[Nikse555]

@Nikse555
In the latest beta 415 - settings / shortcuts do not list the available keyboard shortcuts in the right-hand window.

Thx :)

Fixed in latest beta.

[DanDare1983]

Hi,

First of all I'd like to say thankyou for the hard work that has gone into this program. Its a very useful program that has helped me a numerous amount of times. I would currently like to remove a couple of lines from a .sup file and save as a sup file, I did this by opening the. Sup file and deleting the line I needed taken away. After I exported as blu-ray sup but realised when playing that the subs are alot narrower than the original subs. Would it be possible to keep the subs as original and remove the subs I don't need?

TIA

[Nikse555]

@DanDare1983: Sounds like resolution changed - did you use the new "File -> Import -> Blu-ray (.sup) subtitle file for edit..." ?
This feature is only in latest beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

[DanDare1983]

@DanDare1983: Sounds like resolution changed - did you use the new "File -> Import -> Blu-ray (.sup) subtitle file for edit..." ?
This feature is only in latest beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

Hi,

Yes I'm currently using the latest Beta as the link above. I used that exact method - File -> Import -> Blu-ray (.sup). Once I've done that I come to an OCR screen, I then remove the subtitle I want to exclude and then right click and export to blu-ray sup. I then come to a blu ray sup screen with font family, video res, frame rate etc. The video res was originally DCI 2K SCOPE (2048×858) so I changed to 1080p (1920×1080) which is what the actual video is. Once that's done I touch nothing leaving frame rate the same etc and click on export all lines. I wait maybe two minutes for the file to export.

[Janusz]

@DanDare1983
In your case, the optimal resolution for which the subtitles were made, is DCI 2K SCOPE (2048-858) - 2048/858 = 2.38 ...
You have this information in the original sup file and this is how the subtitles will be scaled.

You changed the resolution for the subtitles to Full HD (1920-1080) 1920/1080 = 1.77 ..., hence the change of the subtitle aspect ratio (width - height).
When saving a new sup, keep the original resolution - then you will have smaller subtitles on the screen,
or change the resolution to Full HD but keep the aspect ratio from the original (2.38) so that the subtitles are properly scaled.

[DanDare1983]

@DanDare1983
In your case, the optimal resolution for which the subtitles were made, is DCI 2K SCOPE (2048-858) - 2048/858 = 2.38 ...
You have this information in the original sup file and this is how the subtitles will be scaled.

You changed the resolution for the subtitles to Full HD (1920-1080) 1920/1080 = 1.77 ..., hence the change of the subtitle aspect ratio (width - height).
When saving a new sup, keep the original resolution - then you will have smaller subtitles on the screen,
or change the resolution to Full HD but keep the aspect ratio from the original (2.38) so that the subtitles are properly scaled.

Hi,

Thankyou for the very quick reply. So I've kept the subtitles at DCI 2K SCOPE and tried again but still no luck. However I've just realised that this only happens on VLC Player, (Subtitles higher and Narrower). MPC plays fine so the issue seems to be VLC but not sure if I'm doing anything wrong my end.

[Nikse555]

I used that exact method - File -> Import -> Blu-ray (.sup). Once I've done that I come to an OCR screen...

"File -> Import -> Blu-ray (.sup) subtitle file for edit..." is a new window (not the OCR window):

https://www.nikse.dk/se-bdedit.png

Main difference is that it keeps position + offers sync + preview.


Also, latest beta writes .sup files a little faster (which previously was pretty slow): https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

[DanDare1983]

"File -> Import -> Blu-ray (.sup) subtitle file for edit..." is a new window (not the OCR window):

https://www.nikse.dk/se-bdedit.png

Main difference is that it keeps position + offers sync + preview.


Also, latest beta writes .sup files a little faster (which previously was pretty slow): https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zip

Hi,

Thankyou so much for the very clear message you give me, very helpful indeed. It turns out I wasn't using the latest beta release which was why I was struggling. Everything is simple and the subtitles work as intended :-) Could you tell me if you can change font and colour also for sup subtitles? I have a few subtitles in a horrible yellow colour and would like a standard white with black border? Once again thankyou so much for the help, can see why subtitle edit is so highly rated.

[Nikse555]

Hi,
Could you tell me if you can change font and colour also for sup subtitles?

To change color:
In the "File -> Import -> Blu-ray (.sup) subtitle file for edit..." window list view, select all lines (ctrl+a), right-click and choose "Change color for selected lines...", choose new color and OK.
(it might not work with all subtitles)

If you want to change font, you need to OCR and then re-export.

[Janusz]

Also, latest beta writes .sup files a little faster (which previously was pretty slow): https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.18/SubtitleEditBeta.zipThanks for your work. :cool:

If we're talking about sup files and colors. This "weird" sup file (https://www.mediafire.com/file/cwgr15fcofrziu6/test_ts-d.zip/file) allows you to OCR and recreate the color of the subtitles
in the srt file because after loading it to the SE in the OCR window there is access to the [Greyscale] and [Use color ...] options.

From this point, I repeat my request that the SE should also be able to recreate the color from the sup files.

Why is this file "strange"?
- is not recognized as a subtitle file by tsMuxer, MKVToolNix or for example: MPC HC.
- subtitle timecodes are incorrect, performing OCR without access to timecodes - no sense. You can access the ts file in my e-mail from 15/12/2020.
- the file can be opened in SE via File -> Import -> Blu-ray subtitle file (.sup) for editing ... but nothing is displayed in the window,
and executing some menu items causes the program to crash.

[Janusz]

@Nikse555

Maybe it's just a curiosity to use, or maybe a bug in the program. Applies to the nOCR method.

https://www.mediafire.com/convkey/06ea/uh1k5wm9fwrur2h6g.jpg

On the left, the text from the first scan. On the right - correct text, obtained after the second full scan of the entire file.

Now I will do something like this: open the same sup file for OCR, start [Start OCR] and immediately stop [Stop] OCR.
I can do it without haste already on 7-8 lines. I open [Edit] and close [Cancel] the character base
and continue [Start OCR] from the line where the process stopped.
I can also immediately go back to the beginning of the text if I see errors in the first few lines.
Now, after the first scan, I get the correct text. There is no picture, because there are no differences in comparison.

Merely stopping and restarting the process, even several times, does not give the correct text.
The fact is that after the first scan is stopped or completed, the character "Ż" appears in the character database as the letter "ż".
However, reopening the character base shows that the character "Ż" is correctly assigned to the letter "Ż".
In this particular case, it fell to "żŻ". How will it be with the other signs? I do not know.
I think this will work for all files showing differences between the first and second scans.

That it works - here's another file:
on the left - text after one scan, on the right - the text after one scan obtained as described above.

https://www.mediafire.com/convkey/e3c8/oby3bvr3ftblzku6g.jpg

If you fail to achieve something similar, and you would like to take a look at this case, I will send the necessary files to an e-mail.
I can see that there are changes to the Compare subtitles. :) Greetings.

Edit 2/01/2021

This short video shows (https://www.mediafire.com/file/rwg1artpscy19tc/swap_S_for_s.mkv/file) what not to do in order not to lose control of your character base as the whole process is out of our control.
The middle part is important, where I open the Inspect nocr matches for current image ... window.
The start and end only show the state of our character base before and after calling this window.
The changes made by the program are saved permanently, which can be seen after reopening the file for OCR.

The errors seen in the examples above are probably the result of mine and the program working in the past.

[Janusz]

If possible, here's my suggestion (on the right) for the main window appearance.

https://www.mediafire.com/convkey/627b/0vpda0dcawot9806g.jpg

[Emulgator]

Maybe for the first glyph to be scanned the absolute relation to the Uppercase/Capital size is unknown.
Then after ingesting more glyphs the absolute Capital size can be deducted ? Would point to nOCR.