Page 1 of 1

Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 4:28 am
by mrob
Description of problem or question:

Under some conditions, the Burned In option is greyed out, or only available if I select Foreign Audio Search, but this latter doesn't give me burned-in subs.

Is there a work-around for this? Why is this happening?

Steps to reproduce the problem (If Applicable):

Unclear. I've seen it happen with some MKV files, and some VIDEO_TS rips.

HandBrake version (e.g., 1.0.0):

1.3.3

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

macOS Mojave

HandBrake Activity Log ***required*** (see How-to get an activity log)

N/A, since I can't even get the option selected.

Re: Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 8:05 am
by Ritsuka
What are the conditions? Are you trying to set Burned In to multiple tracks?

Re: Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 8:12 am
by mrob
I'm just trying to burn in a single set of subtitles. I.e., I just want to choose one.

Re: Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 8:25 am
by mrob
P.S. Hope I understood your question correctly.

Re: Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 9:22 am
by Ritsuka
Maybe there is something useful in the scan log, please post it if you can.

Re: Trouble getting Burned In Subtitles

Posted: Wed Sep 16, 2020 1:01 pm
by Woodstock
Since the GUI is smarter than it used to be about not showing "impossible" options, there can be a number of reasons you can't change the "burned in" option.

For example, if you have a BD source with PGS subtitles, and have selected "MP4" as your output type, the subtitles can ONLY be burned in, so you cannot change that setting. If you change the output file type to MKV, though, the option would reappear.

This is where the required logs would help - they tell us what handbrake saw, and what you were asking it to do with it.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 1:15 am
by mrob
Thanks all. Here's the activity log:

https://pastebin.pl/view/b928319d

HTH

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 2:05 am
by Woodstock
Given your source, if you select "MP4" as your target, you have the choice of ONE subtitle, which must be burned in, so the "burn in" checkbox will be grayed out. You would still have the "forced only" checkbox available, but "default" will also be grayed out.

Selecting "MKV", you should have all of the options available. MKV does not force PGS subtitles to be burned in, so the GUI does not limit your options.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 2:09 am
by mrob
I'm a little confused. So, if I'm writing an MP4 and I select a subtitle from the dropdown menu, it will be burned in on the MP4, even if "Burned In" isn't enabled/selected?

I normally use MKV, but for this task I must use MP4, unfortunately.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 2:12 am
by Woodstock
Correct. MP4 does not allow PGS subtitles, so they must be burned in. And the current GUI will make the burn-in checkbox unavailable.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 12:37 pm
by mrob
I tried again. It's not working. The subs are PGS. They're not burning in.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 1:02 pm
by Woodstock
Can you post the encode portion of the activity log? The scan portion tells us what was in the file, but the encode portion tells us what you asked handbrake to do.

Re: Trouble getting Burned In Subtitles

Posted: Thu Sep 17, 2020 9:52 pm
by mrob
A friend advised me to downgrade to HandBrake 0.10.5. He said the newer versions have a bunch of problems.

I tried that, and it worked.

Re: Trouble getting Burned In Subtitles

Posted: Fri Sep 18, 2020 2:32 am
by Woodstock
Now it gets weird. 0.10.5 is years old, and the 1.x and later series fixed a lot of problems it had. They also improved the codecs available. But 0.10.5 GUI won't prevent you from trying "impossible" combinations.

Having access to the encode logs from both 1.3.3 and 0.10.5 might reveal why it "suddenly" works.