Request Type:
NEW FEATURE
Summary of the problem or suggestion:
I have been using more and more SRT files with my source videos. I’ve noticed that these get processed and in some cases content is removed from them. I’ve tested playback with the new processed SRT and the original SRT with the processed video file and have not seen any issue using the original SRT. I’d like an option to not process the SRT if it is included in the source location.
I didn’t quite understand. The only time an SRT is adjusted is when commercial removal is enabled, it will “cut” the SRT to keep it in sync with the commercial removal otherwise the SRT will be out of sync with the converted file which doesn’t have commercials.
I have Ad remover set to Yes (Use markers) just incase I have my own EDL created with custom cuts but in these recent cases I have had no EDL file.
Here is a conversion log.
Rick and Morty - S02E08 - Interdimensional Cable 2- Tempting Fate.mp4-HEVC-MKV-00-Default-Stream-2021-06-02T08-40-28.log (1.4 MB)
SRT files:
Rick and Morty - S02E08 - Interdimensional Cable 2 - Tempting Fate.eng.processed.srt (34.1 KB)
Rick and Morty - S02E08 - Interdimensional Cable 2 - Tempting Fate.eng.orig.srt (39.3 KB)
I check out your log and SRT files, it’s not related to EDL files. Your SRT files are the issue.
MCEBuddy validates and cleans up SRT files to remove invalid data.
Your SRT files are creating timestamps which aren’t in the required format so MCEBuddy is dropping them:
INFORMATION> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Validating and cleaning SRT file
2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → SRT File D:\Temp\working0\Rick and Morty - S02E08 - Interdimensional Cable 2- Tempting Fate.eng.srt
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:4,405 00:00:6,006
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:6,006 00:00:8,509
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:8,509 00:00:10,778
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:59,093 00:01:1,762
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:01:1,762 00:01:4,632
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:01:4,632 00:01:9,103
The issue is that your SRT file timestamps are invalid:
00:00:4,405 → 00:00:6,006
The seconds needs to be a 2 digit padded numbers as defined in the specifications:
Where as your SRT file has only one digit so it’s being dropped. Which software is generating these SRT files?
Thanks for taking a look. I completely overlooked the single digit seconds value.
Plex doesn’t seem to care about it as it still works.
I’ll report the issue to the vendor of the software that generated the file.
Is my request still valid to have an option to bypass processing (validating and cleaning) of SRTs? If you feel that it is not necessary as it would only be needed in the rarest of occasions, I’m fine with that and we can mark this as resolved.
We’ve put in a patch to handle these malformed timestamps to recover them to make them valid where possible. You can’t try out today’s 2.5.7 BETA build.
We can’t ignore bad SRT files but instead log it for users reference. There have been instances of third party playback software crashing or not playing file due to malformed SRT files that were copied or extracted from the source as is by MCEBuddy (which lead to us implementing validation of SRT files).
Thanks for the quick turnaround.
I tested out 2.5.7 on a new file and all but 1 exception it worked great. Take a look at what it did for 22 (line 98). Not sure if this is due to the extra linefeed in the original or what.
22
00:00:53,966 → 00:00:54,924MYKA.
22
00:00:00,000 → 00:00:00,000
MYKA.
Warehouse 13 - S02E12 - Reset.eng.orig.srt (62.1 KB)
Warehouse 13 - S02E12 - Reset.eng.output.srt (66.9 KB)
Warehouse 13 - S02E12 - Reset.mp4-Orig-MKV-00-Default-Stream-2021-06-04T13-57-30.log (498.6 KB)
To add to this post which might be related !
I am getting many /most extracted SRT files are 1 KB and do not work. Usually they are 10-30kb.
FYI I use buddy to remux mkv under 500mb and
Convert MKV over 500mb to hevc mp4.
cheers
Please upload a sample source video where you’re seeing this behavior and the logs so we can see what’s going on.
The issue here is that the SRT file isn’t compliant with the specs. There shouldn’t be an empty line in between the subtitle text. An empty line indicates the end of a subtitle block, so this becomes an invalid block.
If blank lines are left in there it causes other programs to choke so MCEBuddy ignores empty lines.
UPDATE: MCEBuddy now handles empty lines gracefully by logging a warning message and dropping the invalid block/content. You can try out today’s 2.5.7 BETA build.
Thanks @Goose!
Good Witch - S07E04 - The Exchange.mkv-REMUX TV 500 to 264-1900-01-01T00-00-00.log (11.6 KB)
Good Witch - S07E04 - The Exchange.mkv-convert tv 500 to HEVC-1900-01-01T00-00-00.log (13.9 KB)
Good Witch - S07E04 - The Exchange.mkv-convert tv 500 to HEVC-2021-06-08T19-03-44.log (15.0 KB)
This title created 1KB SRT files
ACtual MKV file is too big
Good Witch - S07E04 - The Exchange.srt (527 Bytes)
Please set your logs to debug, there isn’t much in these logs to analyze.
You can upload the original MKV to our upload server here: Welcome to MCEBuddy - README BEFORE POSTING
mcebuddy.log (494.3 KB)
I have started another post of my own related to this so forget this one …