unable to burn SRT to video file

[CosmicKetchup]

For the past few months, I've been going through my library burning any forced English subs. It's been great so far, until today. I've tried burning this SRT on two separate machines now -- the primary one that I've been using is Windows 7, but I also tried with latest updates on my MBP running macOS 10.14.2.

Here is the log from the last failure.

Any help is greatly appreciated, as is the toolset in general.

[lisamelton]

@seventhaxis Thanks! I'm glad you find my tools useful.

Unfortunately, I don't see anything wrong in your .log file. This line:

[15:51:43]  * subtitle track 1, Unknown [SRT] (track 0, id 0xff, Text) -> Render/Burn-in, offset: 0, charset: ISO-8859-1

... indicates that your .srt file was correctly burned into your video. Do you not see any subtitle at all?

It would help if I could see the command line you used and if you could attach the .srt file here.

Thanks.

[CosmicKetchup]

Thanks @donmelton for your quick reply. I do not see any burned subs when viewing the file. I've zipped up and attached the subtitle file I'm using, and below is the command line I use when burning subs into files:

transcode-video --no-log -q --target big --no-auto-burn --burn-srt "Subtitles\Television\Silicon Valley\s04e10.Server Error.srt" path\to\video.mkv

[lisamelton]

@seventhaxis Thanks the extra information! Unfortunately, nothing stands out as being a problem. So I have no idea why it wouldn't be working.

I'll try to burn your subtitle into a different piece of video to see what happens once I'm back at my development machine.

[klogg416]

I don't have an answer, but I can tell you how I troubleshoot when burning .srt files appears to work but the results don't agree. Open the srt file in a text editor to a) make sure there is content in it, and b) look at the first could of time stamps with text, then jump to those time stamps in the video file and see if it burns in.

Almost always when I have problems it is because the .srt file is for a different cut of the video and the timestamps and scenes don't align, e.g. theatrical versus extended release, or TV shows where I didn't include the title sequence/chapter when ripping from the source disc. Since the srt file is sourced off-disc there is lots of opportunity to them to not be in sync.

Good luck.

On Sun, Dec 30, 2018, at 6:37 PM, Don Melton wrote:

@seventhaxis https://github.com/seventhaxis Thanks the extra information! Unfortunately, nothing stands out as being a problem. So I have no idea why it wouldn't be working.

I'll try to burn your subtitle into a different piece of video to see what happens once I'm back at my development machine.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/239#issuecomment-450594440, or mute the thread https://github.com/notifications/unsubscribe-auth/AHAaMDyqdDeVuexI8J7oU06VoLJLIF5jks5u-U4vgaJpZM4ZlFrP.

[CosmicKetchup]

Thanks @klogg416 -- yeah I'm trying to put as much effort into making sure each file is perfect, so I'm definitely aligned with your thinking. After extracting the subtitles, I go in and proofread, then I make sure the timestamps align with the speaking.

For this specific SRT file, if I am playing the video within VLC and import the subtitles, they work fine. It's only when attempting to burn them that I'm not seeing anything. I checked a lot of the video to see if maybe they were displaying elsewhere, but I couldn't find anything.

[lisamelton]

@seventhaxis Sorry I took so long to get back to you about this, but I finally noticed something odd about your subtitle file. My system identifies it as being in "Little-endian UTF-16 Unicode text" format. Which may work in VLC but might be what's giving HandBrake problems with it. I would suggest using a text-editing utility to convert it into UTF-8 format and trying again.

Does that help?

[CosmicKetchup]

@donmelton No worries! So this makes a lot of sense. I used a new program to extract the subs for this episode and I guess the encoding is different. Attempting to transcode now and will report back later today!

[CosmicKetchup]

@donmelton All good! I will move forward with one more check for my project but this has been very helpful and I greatly appreciate your efforts!

[lisamelton]

@seventhaxis No problem! I'm glad that helped. Let me know if you run into any other problems.

[ravedoglv]

I know this topic is "closed" but I just had the same issue where subtitles appeared to be added, but nothing was there. The file was encoded "Little-endian UTF-16 Unicode text" as well. So I'm going to try it again as UTF-8 and see if it works. Is there a way for your script to detect this issue before encoding and then quit with an error message? Because as you know, the script runs and appears to work with no indication that the SRT file was an issue.

[lisamelton]

@ravedoglv Thanks for the comment! Please let us know how it goes. You can just comment again here.

And, yes, transcode-video doesn't consider this an error since no error is reported from HandBrakeCLI. It might be possible to detect UTF-16 encoding ahead of time on macOS and Linux, but I'm not sure how to do that in a cross-platform way on Windows.

[samhutchins]

@donmelton I think that detecting encoding is what they call a "non-trivial task" :-P.

@ravedoglv Rather than converting it to UTF-8, does adding --bind-srt-encoding utf-16le fix the issue?

[ravedoglv]

Sorry for dealy boys. I'm not sure about your --bind-srt-encoding utf-16le an whether it will work - what I have done is that I just double check an SRT file before using it. It's funny that I lasted all this time without hitting one of the Endian files. Shrug, what can you do.

Thanks again!

[CosmicKetchup]

Hope all is well @donmelton. So I'm having the same issue, only this time I feel like I ensured the SRT is encoded to UTF-8. If you have the time, please see the attached log file and let me know what you think is going on.

Log File

[lisamelton]

@seventhaxis Welcome back! When you write "the same issue," do you mean that the subtitle is not being burned or that the text looks missing or that it looks garbled or what?

Because there doesn't appear to be anything odd that I can see in your .log file. Your subtitle is being interpreted in ISO-8859-1 format (i.e. latin1) and correctly burned into your video. Have you tried adding --bind-srt-encoding utf to your command line?

[CosmicKetchup]

Wow, thanks for the quick reply @donmelton -- always super impressed. Seriously, where's the tip jar?

Yeah I meant that it's not being burned to the output file. I'm attaching another log from a subsequent try this morning and the SRT I used.

log file subtitle.zip

Is that param being used in place of '--bind-srt' or in addition to? For example, if I use the following command...

transcode-video --no-log -q --target big --no-auto-burn

...would I just append that at the end there before specifying the target MKV file?

i.e. transcode-video --no-log -q --target big --no-auto-burn --burn-srt /subtitle/file.srt --bind-srt-encoding utf /pending/video/file.mkv

Update: tried the above and it errored out immediately (error 3).

[lisamelton]

@seventhaxis No problem. That's what I'm here for. :) And sorry for the delay this time but I just got up.

Looking at your .srt file:

0
00:00:00,000 --> 00:00:00,000

1
01:37:46,579 --> 01:37:47,905
Of course, brother.

...It appears to contain an empty subtitle at the beginning which might be confusing HandBrake. Have you tried deleting that? I just OCR-ed the forced subtitle in my copy of "Avengers_ Infinity War (2018)" and it doesn't contain that "0" entry.

The --bind-srt-encoding option would be used immediately after the --burn-srt option, which you seem to be doing. But the .srt you included appears to be in utf8 format anyway so it's unnecessary.

My apologies for the error that you saw! I made a typo in my haste to write that previous comment. The command should have been: --bind-srt-encoding utf8

Also, you should know that always adding --no-log -q to your transcode-video command line is not a good idea since you will never be aware of certain problems that can occur during transcoding.

I'm burning your subtitle now into my copy of "Avengers_ Infinity War (2018)" to see what happens. Stay tuned...

[CosmicKetchup]

Okay thanks for the update - of course this is no rush! Yeah for most of my subs I add an empty 0 line but I can try without. Will report back.

[lisamelton]

@seventhaxis Don't edit those blank lines from your subtitles yet. Because you probably need to edit something else.

Your original subtitle didn't burn for me either. But it wasn't because of the empty line. I just noticed your subtitle contained bogus characters between the line feed and the 1 to start the actual subtitle.

Here's the output of hexdump -C on your subtitle file:

00000000  30 0a 30 30 3a 30 30 3a  30 30 2c 30 30 30 20 2d  |0.00:00:00,000 -|
00000010  2d 3e 20 30 30 3a 30 30  3a 30 30 2c 30 30 30 0a  |-> 00:00:00,000.|
00000020  0a ef bb bf 31 0a 30 31  3a 33 37 3a 34 36 2c 35  |....1.01:37:46,5|
00000030  37 39 20 2d 2d 3e 20 30  31 3a 33 37 3a 34 37 2c  |79 --> 01:37:47,|
00000040  39 30 35 0a 4f 66 20 63  6f 75 72 73 65 2c 20 62  |905.Of course, b|
00000050  72 6f 74 68 65 72 2e 0a                           |rother..|
00000058

On line 00000020 you can easily see ef bb bf, a string of bogus characters, between the 0a of the linefeed and the 31 of the number 1.

Editing this out with BBEdit results in the subtitle being burned. Problem solved.

So, how did you get this subtitle?

[CosmicKetchup]

I got this by using mkvextract on the file and targeting the forced subtitle.

I use Atom text editor on macOS to edit my subs; should I be using something else to ensure I don't run into this issue again?

[lisamelton]

@seventhaxis Sorry I took so long to respond. AFK for most of the morning.

So this was a movie you got from Uncle Torrance instead of a Blu-ray rip? The usual way that happens is that the file has already been transcoded from someone else's Blu-ray rip. Which means that burning the subtitle is not a good idea. I would suggest that you don't bother transcoding this movie.

I've never used the Atom editor on macOS because of its poor reputation about memory footprint and performance. But if the Atom editor is not showing you at least some kind of character that you can delete in front that 1 in your .srt file, then I would certainly use a native editor like BBEdit instead.

[CosmicKetchup]

Could you go into more detail as to why retranscoding my Uncle’s file is not a good idea? I’ve honestly been using this method for a few months now, on over 500 video files because it reduces the file size and I can hardcore the English subtitles into the movie.

[lisamelton]

@seventhaxis Every time you transcode, you degrade quality. That's the problem. But if you're able to significantly reduce the bitrate, it might be worth that depending on your storage needs.

However, I notice that you're using --target big on your command line. Which means for 1080p content, you're probably not saving more than about one third in bitrate when applied to the typical files available from our favorite uncle.

Just out of curiosity, with what are you viewing your video library? Plex or maybe Kodi?

[CosmicKetchup]

Plex. Your tools here are consistently able to save about half the space while maintaining a 8-9 Mbps rate.

I realize this is getting a bit off-topic, but should I just forego all this retranscoding effort? If so, how do I effectively manage subtitles? I love having them burned in and not having to juggle the dozens of different kinds per file.

[lisamelton]

@seventhaxis No problem. Off-topic is allowed. :)

If you have subtitles in a test-based format (like .srt, .ssa, etc.), either within your video file or externally as a separate file, then Plex can display them for you without re-transcoding depending on your player.

See: https://support.plex.tv/articles/200471133-adding-local-subtitles-to-your-media/

Are you using a Roku or other device like that? If so, it can handle text-based subtitles easily.

[CosmicKetchup]

Thanks man. Yeah I’ve been using Plex for a long time. I got tired of my uncle not having standardized audio codecs, dozens of unnecessary subtitles attached, and sometimes those subs are just wrong.

I guess I can look for another solution. Does mkvextract allow you to remove embedded sub files?

For example, I would watch a movie and realize 3/4ths through the movie that I DID actually need subs on for the foreign parts. Hard coding it gave me a chance to proofread before burning them.

What is your opinion?

[lisamelton]

@seventhaxis The mkvextract tool is for, well, extracting tracks as the name implies. But if you want to actually remove tracks then you need to remux your movie without those tracks using mkvmerge, essentially creating a whole new new, smaller movie.

I just let Plex handle any file I get from Uncle Torrance automatically since those usually don't require the video track to be dynamically transcoded. Even a puny NAS device running Plex server can usually handle dynamic audio transcoding without too much effort.

I only transcode my Blu-ray and DVD rips. My two cents.

[CosmicKetchup]

Thanks @donmelton. I'm going to have to sit and think about this one. I don't want to waste my time but it seems like if the guy that created these tools says not to use them in this scenario, I need to defer to the expert hah!

As always, thanks for your help and all the best in the world.

[lisamelton]

@seventhaxis LOL! :) You are very welcome, sir.