[ACTOR BETA] SRT Subtitle Player v0.9.3 (New Version: 18 June 2020)

jfg

I downloaded this file

and it doesn't work. No text. I load the file in the subtitle software Aegisub (http://www.aegisub.org) and export it as .srt without any change…and it works. I suppose the export function changes something but I don't know what.

Subtitles-exported.srt.zip

best, Jean-François

mark_m

@mark

Thank you so much. I've done a brief test on three short films, and it seems to work fine: happy with the .srt files and syncs with the movie as it should... When time permits I'll test with a long-form one, but I've no reason to think it won't work. Thanks a million!

DillTheKraut

@jfg

.srt files are just txt files with a different ending. You could open it in a text editor and compare the files internals.

jfg

@dillthekraut

I already done it. No difference on this level.

Michel

@jfg

Both of your files are working fine for me. Does the output give an error for the file that does not work?

Best Michel

DusX

@jfg

I have used Aegisub regularly, and it generally works very well.
It may be that there are some custom elements added to the format you are using.
I will take a look and let you know what I find.

DusX

@jfg

As I suspected, you have a CPS field, and this seems to be causing the SRT to not be read correctly.
You can correct this by right clicking on the headers in Aegisub and unchecking 'Characters Per Second' and exporting an SRT file with the column hidden.
That fixed it for me.

mark

@dusx said:

As I suspected, you have a CPS field, and this seems to be causing the SRT to not be read correctly.

Ryan, I don't think this is correct. The CPS is a calculation of how many characters per second the viewer must read, to help you gauge if your subtitles are too fast. Unchecking this column in Aegisub does not change the actual text in the file.

I am looking at @jfg's two files. As @Michel reported they both play fine for me, and a text comparison shows them to be identical. (The are also both UTF-8 files with a BOM header, and unix line feed as the newline character.)

I don't know why the first one (Moses und Aron.en.srt) crashed for @jfg

Best Wishes,
Mark

jfg

@DusX

My explanation was perhaps not clear but I use the file I downloaded direct and it was not working. Only after I opened it in Aegisub and export it it has worked. Sorry for my bad english

@mark

After I read your answer I decompress the .zip file I sent you and wonder the decompressed file works fine. I don't understand what's happening but it comes from the srt file I download or from the downloading process.

Thank you

best, Jean-François

mark

@jfg said:

I don't understand what's happening but it comes from the srt file I download or from the downloading process.

Can you give us a link where you downloaded the file so we can try also?

Best Wishes,
Mark

jfg

@mark said:

Can you give us a link where you downloaded the file so we can try also?

it is difficult because I used the Software "Submarine" https://www.bitfield.se/submar... and it doesn't give the possibility to show or copy the link.

I have tried with another file from the same source with the same result. I can only see the text after opening the file with Aegisub and directly export as srt (only save doesn't work).

From another source (same result): https://opensubtitles.online/l...

best, Jean-François

mark

@jfg said:

From another source (same result): https://opensubtitles.online/l...

I guess I can see the problem with this link. If I open this text file in BBEdit, it shows the following in terms of the text file format:

So the first problem is that the file is stored in the Mac OS Roman file format, which is really ancient and not used any more. To make matters worse, it uses Windows line endings (CRLF) instead of MacOS as the format indicates.

If I take that text file and save it as:

<<<< THIS IS HOW THE FILE SHOULD BE SAVED >>>>

then the file loads fine.

However if I save it this way as UTF-8 but with Windows line endings:

It does not read properly on macOS. This last problem I have fixed for the next version. But this won't solve the fact the issue with a Mac OS Roman file. The file data must really be saved as UTF-8 so that the full character set can be used.

In addition, I've added a 'count' output that shows the number of captions that were read. If you feed in your file and this shows "0", then a new error will appear in the error output:

empty (incorrect encoding?)

In any case, if you don't have BBEdit, get the free version. It allows you to adjust these settings (encoding, line endings) easily in the toolbar at the bottom of the window.

I'll post the new version that deals with the line endings once I hear back from others about any other bugs.

Best Wishes,
Mark

jfg

@mark

Dear Mark,

thank you very much. I have BBEdit or I can export with Aegisub, now that I know where it is coming from.

best, Jean-François

mark

Dear All,

The original post has been updated with v0.9.1 of the SRT Subtitle Player. I think I've fixed all the known bugs. But please let me know if you find anything else.

Remember: the SRT file must be either pure ASCII or a UTF-8 Encoded file! If you feed in a Mac OS Roman or some other weird/ancient encoding, the plugin will crash!

Best Wishes,
Mark

jfg

@mark

got a new problem: if I delete the name of the file in "srt files" without to add a new one (typing or copying) Isadora crashes. It doesn't happen if I hit "Enter" before I click outside of the text window. It looks like the window doesn't be empty.

For the rest it works very well.

Thanks

Jean-François

mark

@jfg

Your crash is solved with v0.9.2 -- new download in the first post here.

Best Wishes,
Mark

jfg

@mark

Work perfect.

Thank a lot

best, Jean-François

deflost

@mark,

sorry but how do the projector realize the linefeed?

when we feed the srt player text out to text in of the text drawer we get a 2 line entry from the srt in one line

and without space, when we than put the textdraw video out to projector, the entry shows up in two lines.

where is the linefeed made like the srt format gives it?

thx.

r.h.

mark

@deflost said:

where is the linefeed made like the srt format gives it?

Probably this is a Windows specific issue because it wants CR/LF line feeds. I will investigate this.

Best Wishes,
Mark

mark

@deflost said:

when we feed the srt player text out to text in of the text drawer we get a 2 line entry from the srt in one line

The first post in this thread now has SRT Subtitle Player v0.9.3 for Mac and Windows.

I have done a slight modification of the actor to ensure it works with any linefeed sequence: Mac OS (carriage return), Windows (carriage return + line feed) and Unix (line feed.) Note that this only works for the ASCII characters 13 (carriage return) and 10 (line feed). It will not work for the actual characters "\n" (a backslash followed by an 'n'). As far as I can tell from the SubRip Wiki, that pair of characters is not part of the SRT standard.

I tested this new version on Windows to ensure that it worked with CR, CRLF, and LF, and it performed as expected.

If your file continues not to work, then please post it here or send it to me in a private message and alert me that you sent that message by posting here.

Best Wishes,
Mark