Subtitle Edit 4.0.4

[Nikse555]

Originally Posted by von Suppé

Thanks Nikse, alpha box is greyed out now, but I'm encountering something new in the beta.
When I select first line and then go down to the second (with mouse or arrow down) SE beta freezes?

Hm, I cannot re-create this... could you email me the sub? (I presume it's only with one special subtitle?)

[von Suppé]

Originally Posted by Nikse555

...I presume it's only with one special subtitle?

I'm sorry, no it's not. I presumed we both realized that it's about working with more than one ASSA style. Sorry if I wasn't clear enough earlier.
I have created a small .ass file for testing purposes with (for now) two different styles/fonts and positioning.

One more thing, can I unwantedly import problems when the test-file (.ass) is created in Aegisub? My testfile comes from it because of the realtime preview in this software.

Thanks in advance

[von Suppé]

Has anyone ever tried to edit a XML+PNG-file in SE?
I mean: OCR it --> edit in text-editor --> then export to XML+PNG or SUP with honouring the X and Y offset-info that were in the original xml-file? (at least for the lines that are unchanged, and remove all data for lines that were deleted during edit?

[xKupo]

Hi,

I have a problem with the spell check and auto fix. For some reason SE changes the first letter of certain german verbs from like a to A, b to B and so on. And I just do not Understand (yea like this) why it does what it does.

I noticed that it's because of the 'Auto fix names where only casing differ'-function but my word lists are clean. The changed verbs do not appear in that lists.

It's annoying because it rarely happens so I just noticed it after like 80 subtitles and I do not have the idx files anymore.

The main problem is that I don't know what words have been changed. If I find out for what reason SE changed these words I maybe find the other changed words too.

So does anyone have an idea for what I need to search? Any certain rules the auto fix is following?

[Boulder]

What was the reason for removing OCR via image compare? I used it all the time without any issues on both VobSub and Blu-ray subtitles.

[Nikse555]

@xKupo: SE probably changed the "names" because your spell check dictionary only contains an uppercase version of the word.

@Boulder: I don't see any reason to keep "Image compare" (a lot of old code) and ppl might start using that instead of the newer "Binary image compare".
I think the "Binary image compare" OCR methods is better than "Image compare" - could you verify with your files?

[Boulder]

I tried it, and after a few rounds it seems to be working better. There were some issues with it detecting a hyphen as a colon for some reason and some other random things, but re-teaching them and setting the max error percentage very low (2 %) apparently fixed them.

Would it be possible to make the program remember the last selection? Now it's always offering Tesseract since it seems to be the first in the list.

[Nikse555]

@Boulder: thx for testing
Let me know if some of the defaults should be changed - and I might improve some detection if you e-mail/link the sub/image.
The remember OCR method should work in latest beta: https://github.com/SubtitleEdit/subt...leEditBeta.zip (should be out in 3.5.4 final soon)

[von Suppé]

Originally Posted by Nikse555

...(should be out in 3.5.4 final soon)

Any chance that the issue I spoke aboute here: https://forum.doom9.org/showpost.php...&postcount=542
will be addressed in latest final, Nikse?

[Nikse555]

@von Suppé: If I can re-create this, then I can probably fix it... how do I re-create this in latest beta: https://github.com/SubtitleEdit/subt...leEditBeta.zip ?

[von Suppé]

I'll go testing. Will let you know.

Thanks in advance, Nikse.

I have here xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

a small .ass file with two fonts. Loading it up in latest beta. Directly go to export --> bluray SUP, SE freezes

Edit: take this file https://nofile.io/f/qpGWVHh55qx/Sego...d+AgencyFB.ass

previous file had corrupt outline-pixel numbers (no whole numbers; apparently Aegisub can put that out??))).

Line height is not remembered and not shown in preview. Next to that font height is much much larger than preview in Aegisub, hence my previous question: Can I expect unwanted errors when imporitng .ass file that is created in Aegisub?

[mbcd]

*lol* Cant hold this for myself ...

You have lots of "X", a small ".ass" and two "fonts" ???
Youre a woman ?
What size are those two "fonts" ? D-Size or DD ?

[von Suppé]

Ooooooh yeah, rub it in!!! And you haven't seen the footage yet the subs belong to...

Maybe Nikse will be so kind to create the possibility to "save as..." custom-made "DD-Cinema" format for you?? LOL

[Nikse555]

He, I do wonder why ASS was chosen as file extension - maybe to keep the format a bit underground ?

@von Suppé: thx for the file - new beta upped: https://github.com/SubtitleEdit/subt...leEditBeta.zip

[jpsdr]

Original name is SSA : Sub Station Alpha. When they improved it, they just chose for the improved version the reverse name ASS, for Advanced Sub Station.
Well in case your question was a real question...

[von Suppé]

A quick test with your latest beta still show problems, Nikse.

After opening and directly go to --> export as BD SUP, in the list window all (7 in this case) lines are shown in "Segoe Script Red shadow alpha 160" font. This makes it hard to choose another style to select and edit the lineheight from.

The size in the preview looks more reasonable now, but... read further.

In this example test, changing the first line's lineheight goes very troublesome, direct keyboard input reacts erratically crazy? It does however remembers the lineheight for different styles, it seems. However, the preview doesn't react on changing lineheight though and that is a pitty; "I don't see what I get."

After that, I can't change the lineheight of the second style with direct keyboard input whatever I try and I'm stuck with the up/down arrows.

After clicking "Export all lines", it seems SE hangs and output SUPfile goes incredibly slow. First I thought it was freezed. No change in progress bar. After output finished, the preview window shows a change-back to abnormal big size again. (Video resolution settings was 1920x1080).

SUP ouputfile, opened with BDSub2Sup shows too big subs. First line is 1767x317 pixels. Line 6 is 1920(!)x354 px and is cropped.

[Nikse555]

OK, new beta up: https://github.com/SubtitleEdit/subt...leEditBeta.zip

The list view font issue should now be fixed - also shows style name now as that might help.
The export "hang" should also be fixed (or at least better).

Font size... OK, in latest beta SE now just uses the raw size - but I don't know if that is better.

The no-preview-stuff I cannot re-create.

[von Suppé]

Input issues are solved. Very nice to see the proper style AND "Style column" in export listview! Big improval, thanks.

Output SUP is faster, but still shows too large subtitles, same as first test. I wonder if the font size unit in Aegisub is in pixels.

Originally Posted by Nikse555

...in latest beta SE now just uses the raw size...

How must I interpret "raw"?

Still, no change in preview when changing the line height though. Maybe this is baked in the style in Aegisub and the same reason that the fontsize still has issues?
The differences between Aegisub's preview and the SUP output of SE are HUGE.

Edit: My believe that something is wrong with the way your latest beta is handling both the preview in the SUP export window and the SUP output itself, grows stronger. In SE 3.5.3 the preview flawlessly reacts on lineheight changes. SUP output still gives too big lines, but my guess is that this still is a size-interpretation issue between Aegisub and SE.

When downsizing the ASS Style fonts in SE 3.5.3, the quality in the preview (SUP export window) stays good

In latest beta however, changing fonts to same size, the quality is bad, like SE hasn't pixels enough to create proper quality.

[Nikse555]

New beta up again: https://github.com/SubtitleEdit/subt...leEditBeta.zip

I've tried to calculate an equation between ASSA (no ass here) font size and the .NET text render font size and the result is hopefully that the font sizes matches better?
(If this works I'll have to do the same for "Simple rendering")

Do you still have problems with the preview/input? Perhaps a screenshot can show what the problem is?

[Nikse555]

Also, if you use libmpv as video player in SE then subtitle preview (even ASSA) on the video should be displayed correctly (by libmpv).