Subtitle Edit

[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/Segoe+Script+and+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 ... :p;):D

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

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

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/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.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/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.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.
...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/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.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).

[Ghitulescu]

I read the latest log, am I right to assume some improvements in supporting true BD subs have been achieved?

For ASS/SSA/SRT there are zillions of software supporting them...

[Nikse555]

I read the latest log, am I right to assume some improvements in supporting true BD subs have been achieved?

Probably not... what do you mean by "true BD"?
SE can import/export BD sup + BD TextST (import also from ts/m2ts/mkv/mp4).

[von Suppé]

Nikse, I found out something.

Before you furtherly go put a lot of effort in SUP output size, or waste tons of batteries :D calculating some size-equation between Aegisub and SE; this was never an issue in SE 353!

After some comparison tests, and having read back a few pages I realized that the SE 353 problems I initially posted were about the remembering of lineheights and some more. Because I'm so busy focussing on these issues, I plainly overlooked the fact that the SUP-preview, -quality and -size problems were introduced in later beta's. I was stunned, really... and I deeply apologize for the trouble you have taken to solve this non-problem :(
I could have prevented it if I had payed more attention when the non-issue became an issue when beta's came out.

So, keep whatever formula you had in SE 353 concerning the SUP quality & size.

But, when releasing a new version, please do add the better features the latest beta does have concerning:

1 - proper remembering of Line heigths for each ASSA Style
2 - proper list-view of different styles AND the "Style column" itself (these are great!)
3 - the Alpha setting, border- and shadow colors are greyed out in latest beta. As it should, my guess, as these features are defined bij ASSA style itself.
4 - posibility to chose pixels or percentage in bottom- and left/right margins (when working with srt, that is)

One thing concerning the SUP output still:
After a quick test with one ASSA Style only (because of the heigth setting remembering issue) and the same subtitle as SRT file, I experienced that the sizes of the subtitle windows (checked with BDSub2Sup) were the same, but some differences in positioning take place. I think this has to do with the "Left/right margin" settings, that are not greyed out in the SUP export window. As the horizontal and vertical margins are defined within an ASSA Style, maybe it must be "disabled"? I am not sure if these offset values do the same in Aegisub, compared to SE though...

[Nikse555]

@von Suppé: I think I'll keep the current beta sizes... fits somewhat with what mpv/vlc shows.
About the quality stuff - I cannot see anything here and I cannot see any reason why quality should be changed.
thx about the "margin" settings - was not taken from ASSA, but this should also be fixed in latest beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip

[Ghitulescu]

Probably not... what do you mean by "true BD"?
SE can import/export BD sup + BD TextST (import also from ts/m2ts/mkv/mp4).

These are "true BD" subs, not various formats mostly based on SRT or SSA ...

That it can import (then even process them eg via OCR) is known to me since a very old version I use from time to time.
But my old version rearrange them (it disregards the position on screen) and also does not change the colours but rudimentary ...

Anyway, thank you for this software...

[von Suppé]

Thanks for the latest beta, I'll go test again.


fits somewhat with what mpv/vlc shows.Do you mean during playback in the video-window? I have always experienced the same fontstyle, color and size, whatever Style I use.

Edit:
I think I'll keep the current beta sizes...I would highly regret that. When creating a style in Aegisub, the preview now approx. matches the way it looks in SE 353 preview. New beta preview doesn't look like it. Changing it like latest beta's has an overall effect on how the font looks. I think this has to do with ratio between the size itself and the numbers used in the "Outline" and "Shadow" boxes. I would hate to create an ASSA Style in Aegisub to look good, and then have to edit those styles in SE to meet my initially intended looks.

By the way, I found out that when opening an *.ass file and saving it again as [othername].ass file, I am unable to open that [othername].ass file with Aegisub. Whereas the other way around is going ok. Aren't .ass files supposed to be interchangeable in SE <--> Aegisub both in both directions?

[Nikse555]

And... a new beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip

Border/shadow code back to 3.3.5 build 1 release - better?

Thx for the info about the file not loading in Aegisub... was simply a bug in SE (could not handle [Events] being last). Should also be fixed in latest beta.

[von Suppé]

Thanks again, Nikse. I'll go testing again.

Cheers

Edit: First tests look good, thanks. During more verbose tests I found out that with SUP export the right margin value in ASSA style is off.
I created some styles with left - & right margins at 15. Left is okay, but right margin comes out too large? (Video reolution set to 1920x1080)

[Music Fan]

@ Nikse555 : when opening a TS containing 2 DVB-SUP, the parsing is done and we have to select one sup, then the OCR window appears. But after exporting it in Blu-ray Sup, we can't select the other sup without re-parsing the whole TS.
Could you add the possibility to select the sup's from the OCR window (or let the selection window opened) to avoid a new parsing ?
Thanks !

[Nikse555]

@Music Fan: Hm, I could add a "Save as..." button like in the DVD rip menu. Test version here: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip (it saves as raw PES packets - don't know if other programs will be able to handle this).

@von Suppé + any ASSA gurus: I've added support for right margin from ASSA files (used left margin earlier, beta above includes this fix), but now I'm even more confused about the ASSA font size.
If PlayResX/PlayResY is defined - how does that influence the font size? In your "Segoe Script and AgencyFB.ass" file the res is set to 1090x1080 which clearly makes the font size smaller. Any help is much appreciated ! :)

[jpsdr]

In SSA/ASS all positions are absolute according the video size defined within the file with PlayResX & PlayResY, but became after relative according the size of the video frame. Of course, if size of video frame match the size defined within the SSA, the positions become also absolute.
Rules are following :
If no resolution is set, video is considered PlayResX=384, PlayRexY=288, finaly SRT is considered as the same thing than SSA with no resolution set.
If only PlayResX is set :
- If value is 1280, PlayResY is set to 1024.
- for any other value, PlayResY is set to 3/4*PlayResX.
If only PlayResY is set :
- If value is 1024, PlayResX is set to 1280.
- for any other value, PlayResX is set to 4/3*PlayResY.

So, any "size" thing related is relative to PlayResX/Y. If your PlayResX/Y is set to 640x480, and a font size is set to 30. If your video is 1280x960, your font size will be adjusted to 60, on the other hand, if your video is 320x240, your font size will be adjusted to 15.
I don't know the rule for a change aspect ratio. If your video is 1280x720, i don't know if you adjust your font size by (1280/640) or (720/480) or the average or anything else...
There is no complete document spec for ASS/SSA (there is things, but not complete), the answer i've always found was finaly "the full spec for ASS/SSA is the code source of vsfilter"... :(

[Music Fan]

This reminds me the problem I have with DVB-SUP whose size is not the same after extraction by SE. When extracted to Blu-ray Sup and remuxed with TSMuxer (which doesn't convert sup), the subtitle is much smaller than when the original ts is played with VLC or MPC-HC. But I don't recode the video, thus the sup should have the same size.

@ Nikse555 : thanks, I will test it as soon as I record another video including 2 DVB-sup.

[jpsdr]

sup/sub/idx is even more troublesome that it's a layer picture displayed over the video, it's not text based, so, if you don't resize the picture, it will be smaller.

[Music Fan]

Why ? A simple extraction and format conversion without resizing should not induce size change.

[jpsdr]

My bad, i've misunderstood what you wrote. One test you can make in that case is to extract the sup also with eac3to for exemple, and compare the TSMuxer result with the sup extracted with SE. But indeed, a sup extracted and remuxed on a video with the same size it's extracted from should produce the same result.
Or maybe... i don't know exactly what is "DVB-SUP", so maybe my assumption is wrong... Is it a way to call a .sup extracted from a Blu-Ray ?

[Music Fan]

No, it's a sup extracted from a ts recorded with a STB (VU+).

[von Suppé]

...In your "Segoe Script and AgencyFB.ass" file the res is set to 1090x1080...I assume this is a typo??

Script properties in Aegisub states 1920x1080

Thanks for latest beta, will go testing again.

[Music Fan]

edit ;
@ Nikse555 : I tested the pes saving option, there is still a parsing when opening the ts, how to use it ?
If I open the pes file, it opens directly one of the subtitles and the timecodes are not good.:confused:

Instead of a "save as" button, could you make an automatic saving for ts parsings to avoid to save it each time ? Or add an option in the settings to activate it or not ?

[Crash82]

I'm hoping it's okay I'm asking

here I have a small issue in SE

I'm getting this now and then "<i>italic</i>... <i>?</i>" on one line in ocr and I don't know how to make it look like <i>italic...?</i> beside going through each line every time and fix it.
And it does not seem that fix common errors it's able to fix it either and I don't know if it's possible to manually add something to that function somehow.
I also looked into Multiple replace function but I'm not using that functions that much so I don't know exactly how to use it, but I see it's possible to add a regular expression so maybe that will work but I don't know anything about that, I have tried to Google it but I'm not sure what I'm looking for

Hope someone can help me
Thanks in advance

-----------------------------------update-----------------------------------------------------
After I posted about my issue I continue doing some testing
and of course I found out a way to fix my problem.

I don't know if any of you guys have try to have problems for days you can't fix
as soon as you're asking for help you'll find a solution.

I just added to the Multiple replace </i>... <i> to ...

[von Suppé]

Never mind, sorry...

[Nikse555]

I assume this is a typo??

Script properties in Aegisub states 1920x1080

Thanks for latest beta, will go testing again.
Yes, that was a typo?

Never mind, sorry...
?


@Music Fan: OK, good catch with the time codes... I guess that will not work then. What do you do with the TS image subs - resave or ocr?

[Music Fan]

@Music Fan: OK, good catch with the time codes... I guess that will not work then. What do you do with the TS image subs - resave or ocr?
Only resave in Blu-ray sup.
Thus you believe there is no way to save the parsing or let the parsing window opened after selecting one of the sups to select the second after dealing with the first ?

[von Suppé]

Hi Nikse

Been busy, sorry for late reply.

Latest beta's right offset value still doesn't work proper. Output is (still) too much to the left.
Left offset has stayed okay, though.

The 'Line height' value reacts weird IMHO.

You can imagine, when filling in this value, one tends to imagine a virtual frame around the line(s), in which the subtitle would fit. It would sort of represent the outsides of the rectangled image created (when exporting to SUP or XML-PNG).

Since you have altered the SUP size calculation, the Lineheight value doesn't behave in ratio to the used fontsize number, it feels.
To get my wanted space between lines, I now must use a number that often would be smaller than the fontsize number itself. This feels awkward and not logical. Did you take into account the function of the lineheight value, when you changed the image output size?

Furtherly, I assume that this Lineheight value (besides the space between two lines) also has influence on the amount of "extra, transparent" pixels around all 4 sides of the subtitle. So, IMO, it would somehow co-determine the total rectangle size of the subtitle-image. I hope you understand what I mean with this, it's a bit tricky to explain...

Now, in the Blu-ray SUP export window, would it be possible to implement a frame around the subtitle that would real-time and actively reflect the proper total image with the current Lineheight? I don't mean the preview after "Preview" button, but directly in the SUP-export window itself.

A reason for me wanting this, is because of the result when using (all four, but mainly the bottom -) offset settings.
You can imagine, seeing directly the total subtitle-image, one can make out for himself if adding or reducing offset pixels is necessary.

Thanks for your hard work,
cheers

[Nikse555]

@Music Fan: Ah, perhaps a context-menu will solve it? Try to right click on a track in the choose subtitle window in latest beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip


@von Suppé: thx for testing again :)
The line height calculation seems to work fine for me - can you supply an example where it works poorly?


Furtherly, I assume that this Lineheight value (besides the space between two lines) also has influence on the amount of "extra, transparent" pixels around all 4 sides of the subtitle. So, IMO, it would somehow co-determine the total rectangle size of the subtitle-image. I hope you understand what I mean with this, it's a bit tricky to explain...
cheers
Yes, SE calculates a height to use as a base-line in order to avoid too much jumping up and down of letters.
I guess it would be nice to be able to see this (and if it's too large/small)

[Music Fan]

@Music Fan: Ah, perhaps a context-menu will solve it? Try to right click on a track in the choose subtitle window in latest beta
There is no change compared to previous version :o : once I selected a subtitle, this window closes, the OCR window opens and when I have finished with this subtitle track, I have to make a new parsing to select to other subtitle track.

[Nikse555]

@Music Fan: Did you re-download the beta?
http://www.nikse.dk/se-ts.png

[Music Fan]

Great, you rule man ! :thanks:
Actually the beta version I downloaded yesterday could already do this but I hadn't understood what you meant with the right click.

If I need to OCR both tracks, I can simply begin to export them in Blu-ray sup to avoid 2 parsings, then I can load each sup separately.:)


There is still the size problem, we already discussed about it : after conversion in Blu-ray Sup (keeping 1920x1080 resolution) and remux in ts with TSMuxer, the subs are more little than in the original ts with the DVB Sup, look at these caps (click to get full size) ;
original :

http://nsa39.casimages.com/img/2017/09/29/mini_17092910483243629.jpg (http://www.casimages.com/i/17092910483243629.jpg.html)

after conversion :

http://nsa39.casimages.com/img/2017/09/29/mini_170929104943550113.jpg (http://www.casimages.com/i/170929104943550113.jpg.html)

If you look carefully, you will notice that the original subs are not as sharpened as subtitles that we find on Blu-ray's, as if their resolution was not in 1920x1080 but contained an additional information to be displayed in a greater resolution.
And SE probably detects only the actual resolution without the additional information (a sort of flag).
Or there are well in 1920x1080 and SE detects a lower resolution for some reason :confused:

Thus, after this conversion, I always resize sups with BDSup2Sub (but I could maybe do this with SE, never tried).

[von Suppé]

Hi Nikse,

Take a look at the 2 screenshots from SE 353 and SE beta export windows. Settings are so, that subtitles have same space between the lines and look the same. Same Lineheight values are used, whereas the fontsizes are differently chosen, because of the resizing you adapted.

SE 353 settings
https://preview.ibb.co/cOjYBG/export_SE353.png (https://ibb.co/fCVjJw)

SE beta settings
https://preview.ibb.co/dR1ryw/export_SE_beta.png (https://ibb.co/mtYh5b)

To be sure, I compared the two resulting .png files.

My findings:
Within the png's, vertical sizes of the text-lines themselves are the same (lucky shot on the different fontsizes :D).

Also they have the same spaces between the lines. Now, IMO this is (next to the fluke that vertical text size is the same) because of the same Lineheights being used.
The widths of the texts are approx. the same.
H/V number of pixels of the total .png files vary a little. I found out, that this is also because SE353 puts out more transparent pixels around the text than latest beta.

Can you imagine, that the ratio of lineheight/fontsize in SE353 is more logical to a person? Lineheight (46) is a bigger number than fontsize (37); this makes sense.

For the same output, in SE beta I had to choose a fontsize value (52) which is higher than the Lineheight (46). This feels awkward in the workflow.

can you supply an example where it works poorly?It is absolutely not working poorly. It does exactly what it needs to do.
I think it is about the auto-interpretation that the units of Lineheight and Fontsize should be the same and that the result (also in preview) should logically and in ratio follow the changes made.
As I earlier said, you can imagine one likes/tends to imagine a "Lineheight-settings dependent" frame around a subtitle, in which it would fit. Lineheight being smaller than fontsize makes no sense then and don't feel good.

[von Suppé]

@ Music Fan:

Sorry, can't help it, but what does happen to the spoon in the following frames? :D:D
You need subs.....?

[Music Fan]

The spoon is getting hotter, for sure :D

[Nikse555]

@von Suppé: I've done some more tests with font size and the beta has been updated with a more precise font size match with vlc/mpv - now the font size is multiplied by 0.895.
Beta link: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip

I don't think there's a relationship between font size and pixel size...

@Music Fan: I still believe that the player just upscales the ts-subtitles.
Sorry, no resize for images in SE atm...


EDIT: The above beta will probably be (or very close to) SE 3.5.4 - so please test :)

[Music Fan]

@Music Fan: I still believe that the player just upscales the ts-subtitles.
I'm not sure about this because on my STB (VU+), the subtitles with the original TS do have the same size than on my pc with MPC-HC.
Thus if MPC-HC makes resize for these DVB-SUB, my STB also does. At the very same size, strange.
Why would this format have to be encoded with a lower resolution than the video and be resized ? This does not make sense to me.
And if it's the case, the information about the resize has to be written somewhere in the stream.
As MPC-HC and VLC do the same resize, you could maybe find informations about this in VLC's codes.

[Nikse555]

Yes, I guess it's possible some scaling info exists somewhere in the ts file - if anybody knows about this, please do share!
I guess the VLC source contains this info, but it's probably not super easy to find - also I'm not very good at reading C code.

SE now includes the option to resize in the export window: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.3/SubtitleEditBeta.zip

[Music Fan]

Great, you didn't lose time !
240 % gives good results.
But strange thing : with the resized sups, some lines are grey, others are white, while they all look similar in the non-resized sup. :confused:

Other suggestion : could you add synchro support for sups ?
If no there is a trick which is not very practical : in the OCR window, push on OK without making OCR, the timecodes appears without text. Make synchro, save, re-load the sup and in the OCR window, right click, import new timecodes, right click, export, Blu-ray sup, export all lines.

[von Suppé]

The above beta will probably be (or very close to) SE 3.5.4 - so please test :)
Will do! Thanks Nikse :)

Edit: Nikse, nowadays I use export to XML_PNG a lot. It appears that this export mode has a timecode bug?
Seeing back the result in BDSup2Sub the timings are off (at least for 23.976 fps).
Whereas the SUP export timings always were okay (within 1/1000 sec), now in latest beta the timecodes are more off (approx. 45/1000 sec)??

SE353 suffered the same XML_PNG bug btw.

[Zetti]

Thanks for new release:
https://github.com/SubtitleEdit/subtitleedit/releases/tag/3.5.4

[von Suppé]

Hi Nikse,

Thanks for your hard work :thanks: I'll go test 3.5.4 extensively.

Quick test still shows timings bug with XML_PNG export, at least for 23.976 framerate. I guess you didn't read my yesterday's post yet before launching latest. It sure looks famaliar to BDSup2Sub's bug.

[varekai]

Having a weird issue with displaying video and audio.
When selecting
Options -->
Settings -->
Videoplayer -->
Video engine -->
Selecting DirectShow I get video but no audio.
Selecting MPC-HC I get audio but no video.
I can't figure this one out.
Probably got something to do with codecs.
I got LAV Filters, MPC-HC, PotPlayer installed.
No extra (evil) codec packs that I know of.
Any ideas how to solve will be much appreciated.

Edit:
Last thing I wanted was to install another mediaplayer but that's what I did.
Installed VLC 2.2.6 win64 and now I got both video and audio...
It's a workaround for now, strange thing is it used to work with MPC-HC alone.

[mbcd]

Beside of my study, I am working on a new app to handle this feature.
I cant promise you anything, it will take still a long time until I get a release of anything that is worth its name "program" ... because only very less time free to work on it.

Problem is, I cant test anything, because I dont have such a file that contains those multiple text-items.

Is here anyone who could provide me a sample sup-file, please ?
Then I could at least test if my parser is working fine with it right now.

And again: It will take a long time until I get something managed to release.

For first, I plan to do basic stuff, like convert to bdn-xml (both directions), extracting forced, merge normal + forced, and as its best I will implement a way to use a cutlist, so you can adjust a video you edited in an Video-Editing-Software, using the EDL-file-format as cutlist.
So mostly basic stuff that old BDSup2Sub did, but with bugs. It will be forced to work only with bluray-subtitles, not the oder DVD (at least for exporting, not sure about importing).

This are my plans for commandline-options.

[Nikse555]

@Music Fan: Don't know about the color in the resized subs - seems okay to me, but I guess SE might make the inner color darker, if the sub has a lot of dark outline/shadow. If you have an image sub that's very bad I could take a look.
About the sync in export - would just "move" be okay - like this https://github.com/SubtitleEdit/subtitleedit/releases/download/3.5.4/SubtitleEditBeta.zip - or what did you expect/need?

@von Suppé: Could you explain more about the 23.976 problem? Perhaps a source file, and a target file with the expected result?
Do you mean to multiply all times with 0.999 ? Drop frame is annoying... ;)

@mbcd: You can probably find the examples you seek in the BDSup2Sub thread. Is your program written in C# ? On github?

@varekai: I'm not sure about what's the problem is with codecs... you could try to re-install latest version of LAV filters. Also, libmpv is an excellent media player and can be installed from inside SE via Options -> Settings -> Video player.
Normally I prefer DirectShow or libmpv as the seeking is very precise unlike VLC.