Illegal .srt being created from DVBs #166

Closed
opened 2026-01-29 16:36:47 +00:00 by claunia · 1 comment
Owner

Originally created by @cfsmp3 on GitHub (Jun 22, 2016).

Originally assigned to: @anshul1912 on GitHub.

Lines like this (processing 01-BBC1.EastEnders.ts):

334
00:16:49,197 --> 00:16:51,966
Jane had squeezed my hand.

Yeah. . .was it just that?

Are illegal in .srt (there cannot be empty lines in a subtitle frame in .srt)

I think we're just adding an extra \n at the end of each line.

Also, we're not consistent with \n vs \r\n, the same .srt contains both.

Originally created by @cfsmp3 on GitHub (Jun 22, 2016). Originally assigned to: @anshul1912 on GitHub. Lines like this (processing 01-BBC1.EastEnders.ts): 334 00:16:49,197 --> 00:16:51,966 Jane had squeezed my hand. Yeah. . .was it just that? Are illegal in .srt (there cannot be empty lines in a subtitle frame in .srt) I think we're just adding an extra \n at the end of each line. Also, we're not consistent with \n vs \r\n, the same .srt contains both.
Author
Owner

@cfsmp3 commented on GitHub (Jul 5, 2016):

The line separators in Windows must be \r\n, not just \n... I've corrected this by passing encoded_crlf to add_ocrtext2str.

In fact I believe for .srt it's always CRLF regardless of the platform

See
http://www.textfiles.com/uploads/kds-srt.txt

@cfsmp3 commented on GitHub (Jul 5, 2016): The line separators in Windows must be \r\n, not just \n... I've corrected this by passing encoded_crlf to add_ocrtext2str. In fact I believe for .srt it's always CRLF regardless of the platform See http://www.textfiles.com/uploads/kds-srt.txt
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#166