Feature request: Make subtitle conversion configurable

[PhilJFry]

It seems like all SRT plain text subtitles in a source file are transformed to SSA, which is not widely supported by home electronics players. While I acknowledge the advantages of SSA over SRT, I would prefer having the choice.

I suggest adding a configuration option in the preferences, whether or not to transform subtitles to SSA.

[bradleysepos]

At the moment, all soft subs are transformed to SSA internally. This will likely not change; however, converting back to SRT or other formats is possible in the future. Patches welcome.

[petr-ujezdsky]

I have been reencoding majority of my video collection to High@L4 because my TV does not support any better (eg. High@L5). Then I have been fiddling with missing subtitles for hours just to find out that they have been converted from SRT to SSA that the TV also does not support :(

I would not call this "SRT Passthru" as you state in
https://handbrake.fr/docs/en/latest/advanced/subtitles.html
because you are actually transforming them into another (less supported) format. Even though you say that in the description.

Is there any chance this would move up in your ladder of TODOs? :) I would assume the passthru would be easier to implement since you do nothing with the file...

Thanks in advance.

[bradleysepos]

Sorry for any confusion. The (draft, from the old wiki) documentation article does state that SRT is converted to SSA, but we don’t make that very clear elsewhere.

Anyway, SRT is fun to deal with because pretty much no SRT adheres to the basic standard that exists. So even your TV saying it supports SRT isn’t enough for us to know what specific formatting and character encoding it would require. It’s a bit of a mess, like playing Whack-A-Mole.

Anyway, still leaving this open as a possible future enhancement. Patches welcome.

[sneaker2]

So even your TV saying it supports SRT isn’t enough for us to know what specific formatting and character encoding it would require.

Text character encoding in Matroska is always UTF-8. All other encodings are forbidden by the spec.

[petr-ujezdsky]

SRT is fun to deal with because pretty much no SRT adheres to the basic standard that exists

Another reason to make the SRT-passthrough. You won't deal with it at all then :)

[sakis14]

This is a joke!
The developers are either lying or they are not telling us something.
OP, I am using VidCoder, what you ask for was already a feature on older versions of the program but they removed it afterwards.

[sr55]

Yes, this was a deliberate change as we have already stated ...

If you want to see the old behaviour, either use an old version of the software or contribute or wait until someone contributes a patch to make it configurable.

If you want to continue with this bad attitude, feel free to leave.

[sakis14]

I am sorry if you feel offended by this but I downloaded the newest version of VidCoder and I lost 2 hours of my life trying to figure out what was going on. It was frustration, nothing more. I rolled back to the previous version I was using and everything went back to normal. SRT support was there.

And correct me if I am wrong, I looked up at least 15 change logs and I never saw anything about this deliberate change. No mention of this on this thread too. You just told so.

[jstebbins]

I lost 2 hours of my life

🎻 Collectively, the HandBrake developers have "lost" tens of thousands of hours of their life in order to make this software available to you. So sorry if I have no sympathy. It's a good thing we do this more for ourselves than for others. Sometimes I think we should just keep our software private and spare ourselves the abuse users like you throw our way.

If you don't like something, be civil and say so. If a developer has time and interest, they may do something about it. Often, none of us has the time. HandBrake is a hobby and we all have regular jobs and lives outside of HandBrake that take higher priority.

Being rude is a sure way to be sure that nobody will be interested in your problem.

[gpuberos]

I hope that one day developers will integrate this option into the software. Because Smart TV currently has a real problem with ASS support.

[Kaan88]

Unacceptable behaviour, I wasted so much time because trying to adjust subtitles in Kodi because I was expecting them to be SRT.

[gacpac]

Wow, and I'm going crazy. Thinking why is handbrake doing this. I'll start looking for something else, although I praise handbrake for their ease of use. I should ask what the people are using this days

[Rumourd]

I hope that one day developers will integrate this option into the software. Because Smart TV currently has a real problem with ASS support.

SmartTVs' support of ASS is ass lol.

[Rumourd]

Unacceptable behaviour, I wasted so much time because trying to adjust subtitles in Kodi because I was expecting them to be SRT.

Why not just use MKVToolNix and remux your SRT back into the encoded file?

[Jbartu]

Unacceptable behaviour, I wasted so much time because trying to adjust subtitles in Kodi because I was expecting them to be SRT.

Why not just use MKVToolNix and remux your SRT back into the encoded file?

Because this is extra time, For one chapter, one movie... it's ok, but if you encode all you get, is a lot of time.
Why do not allow to user can choose which format prefer in subtitles?
Just leave "change to SSA" by default and one option to do passthrough to SRT if user need it. The only way to reproduce with SSA using plex (with transcoding off) for example is from computer, iPhone, iPad (from iOS 11) or some Androids, but Smart TV's, TV Box... can not.
I don't know to program, HB is amazing, and all the work have behind, but, why not allow subs passthrough.
I just read the admin coment, and I understand his point, but maybe people don't care if is real SRT, people just want to reproduce their movies o whatever, whit no problems in TV's, etc...
Thanks for reading, thanks for te amazing HB, but please, leave subs passthroug.
Greetings!!

[masterblaster256]

Hi @ALL
i just stumbled across this here after i finished encoding 150+ files just to find out at the end that all the SRT Subtitles have been converted to ASS (instead of Passthrough).
I wouldnt really care personally since i dont use those subtitles (in that case) but want to keep them (just in case)
Now i need to manually go through over 150 files and swap the converted ass to the original SRT .... mhhhh
I maybe missed the point why it is easier (or better) to go through the efforts of converting a thing into another instead of just passing it through untouched.
Please, this should really be an option - Subtitle passthrough

Thx in advance
Also Thanks once again for an awsome piece of software.

[Bardmaster2]

Hi, I am hoping for this functionality as well for full output flexibility.

[ChemicalNRG]

I maybe missed the point why it is easier (or better) to go through the efforts of converting a thing into another instead of just passing it through untouched.

Same here, i missed the explanation why it is done?
Also can someone tell what the latest version is which keeps srt?

[Jbartu]

Unacceptable behaviour, I wasted so much time because trying to adjust subtitles in Kodi because I was expecting them to be SRT.

Why not just use MKVToolNix and remux your SRT back into the encoded file?

Because this is extra time, For one chapter, one movie... it's ok, but if you encode all you get, is a lot of time. Why do not allow to user can choose which format prefer in subtitles? Just leave "change to SSA" by default and one option to do passthrough to SRT if user need it. The only way to reproduce with SSA using plex (with transcoding off) for example is from computer, iPhone, iPad (from iOS 11) or some Androids, but Smart TV's, TV Box... can not. I don't know to program, HB is amazing, and all the work have behind, but, why not allow subs passthrough. I just read the admin coment, and I understand his point, but maybe people don't care if is real SRT, people just want to reproduce their movies o whatever, whit no problems in TV's, etc... Thanks for reading, thanks for te amazing HB, but please, leave subs passthroug. Greetings!!

Hi again.
Seems they dont's care about it for the moment. Anyway, that is small solution maybe helps someone. After you encode your files, probably goes to folder. With ffmpeg and this script (I'd use on macOS), can convert in a couple of seconds ssa to srt:
#!/bin/bash for i in *.mkv do ffmpeg -y -i "$i" -map 0:v -map 0:a -map 0:s -c copy -c:s srt "/path of folder you want to output/${i%.*}.mkv"; done
I think is a little bit funny because HB use ffmpeg, so, maybe is not dificult to add in app...
I do not know really how to make scritps, but looking everywhere, I'd found this and modify for me. The only thing I do not like is I have to do on terminal "cd /path of encoded files", and also, I don´t know how to use the script with subfolders, for that reason, script.sh have to be in the same folder of encoded files.
PD: If anyone knows how to use script.sh from any folder and use with subfolders, I appreciate little bit help on this.
Like I said, I hope this helps someone :)
Greetings!!

[ChemicalNRG]

Thanks for your code.
But if i have to use ffmpeg to undo a handbrake action, then i can just as easily skip handbrake alltogether and do the whole conversion with ffmpeg. Especially since handbrake is using ffmpeg too.

[sr55]

It's not a feasibility / difficulty problem. It's a lack of interested developers with time to invest problem.

HandBrake simply doesn't have a large developer community around it. You can count on 1 hand the number of people that "regularly" (used loosely) contribute code.

[madkatz01]

Would love to see this change, but it will never happen. It's been requested heavily for years and the developers are very stubborn about it and "insist" they are correct in the conversion and just get mad when users suggest otherwise. Sad, since it pretty much renders Handbrake useless to people trying to convert large collections.

[bradleysepos]

This issue is open, not closed, and tagged "Patch / Help Welcome".

As sr55 recently wrote, "It's not a feasibility / difficulty problem. It's a lack of interested developers with time to invest problem. HandBrake simply doesn't have a large developer community around it. You can count on 1 hand the number of people that "regularly" (used loosely) contribute code."

However frustrated this issue leaves some of you, characterizing our developers as stubborn, mad, etc. is inaccurate, inappropriate, and disrespectful. The sense of entitlement here is especially toxic. This is a volunteer project, for crying out loud.

I suggest everyone reread the project's code of conduct.

[carnager]

if the resulting ass subtitles would at least be valid. For me latest stable handbrake produces corrupt ass subtitles 100% of the time. (Shadows with huge offsets)

[galad87]

@carnager that's an issue with the current locale on that happens only on Linux. Either use a snapshot or wait for 1.7 or compile from master branch.
Please open new issues and don't add unrelated posts to existing ones.

[UnidentifiedTag]

it states on the website documentation :

Please note, SRT tracks are converted to SSA in the output file. This behavior is not currently configurable.

please could the developer team respond and tell everyone why SRT Subtitles can not be passed through, as of now. it seems like a choice. no technical response has been given as to why a passthrough for SRT can not be done? it comes across as a dictatorship. if we get a technical explanation as to why this option has not been made for SRT, this will change perspective.

[sr55]

As I stated above and has been repeated, it's simply a lack of interested volunteers to make the change to add support for this. It's not a technical problem.

This is an open feature request and we'd welcome patches from anyone wishing to contribute it.

[UnidentifiedTag]

As I stated above and has been repeated, it's simply a lack of interested volunteers to make the change to add support for this. It's not a technical problem.

This is an open feature request and we'd welcome patches from anyone wishing to contribute it.

surely it's a matter of adding an option in the gui (user interface) surely you have someone that can add this option and it would be some sort of flag that would be activated in ffmpeg, which i believe is what you use to make most of the outputted files in handbrake. are you telling us you have no one who has the ability to do such things? this was opened all the way back in 2016, we are now in the year 2024, this request is only going to get up voted more as plex needs .SRT.... .SSA or .ASS will not do! get in contact with someone over at the subtitle edit team, ask for help with making this thing a possibility for all here. i don't mean to come across rude if i have, or insulating but this feature is a obvious one

[sr55]

HandBrake is not an ffmpeg front-end. We have our own engine which works along-side many 3rd party libraries, including libavformat/codec among others. Bit more complicated than just a "flag" and not a 5 minute task but nothing massively difficult.

[UnidentifiedTag]

HandBrake is not an ffmpeg front-end. We have our own engine which works along-side many 3rd party libraries, including libavformat/codec among others. Bit more complicated than just a "flag" and not a 5 minute task but nothing massively difficult.

I'll end it on this, having only one output type of subtitles for a multi output converting program isn't exactly inline with what handbrake stands for is it? Please contact someone to sort this out, waiting isn't obviously working.

[feahnor]

HandBrake is not an ffmpeg front-end. We have our own engine which works along-side many 3rd party libraries, including libavformat/codec among others. Bit more complicated than just a "flag" and not a 5 minute task but nothing massively difficult.

So has no one had the time to implement this in 8 years? You already do pgs passthrough, the lines of code are already there, just need to adapt them to srt.

I want to use handbrake, I love it, but changing the srt subs to ssa makes all my files transcode on Plex. I’ve started using staxrip because of that, but I hate the interface, handbrake is so good that I don’t understand why go all the way out to convert something when users don’t want this behavior as it causes problems.

[UnidentifiedTag]

Just to be clear to the developer team watching, no one is angry with you, the users here are frustrated. if it wasn't for the few of us, like me and @feahnor you wouldn't hear about it or see it. people just wouldn't use the program at all.

I love HandBrake, it makes unusable files useable on devices that wouldn't have supported the original format, and to me that's what HandBrake is all about. it's got most video encoding formats done (you just need to allow passthrough there too) it's got most if not all audio formats done (full passthrough seems to be there) it just needs more work on subtitles and then the program will be feature complete, it's as I said frustrating...

Edit :

Unfortunately for me I've got to encode with what's currently been developed, which means if .srt is added for subtitles, I will also need h.264 passthrough, so that I can add the subtitles to my already made files... Can you see the knock on effect that is being caused 👍🏻

[bradleysepos]

if it wasn't for the few of us, like me and @feahnor you wouldn't hear about it or see it

It is misguided to think this is helping. We are fully aware, and further development depends on both priorities and available resources. Piling on badgering people won't get this done in another 8 years.

Linking this again: #160 (comment)

The sense of entitlement being expressed here is quite rich. 20 years of free software, folks. It could be better. The fact that it isn't doesn't give one license to behave this way.

[feahnor]

if it wasn't for the few of us, like me and @feahnor you wouldn't hear about it or see it

It is misguided to think this is helping. We are fully aware, and further development depends on both priorities and available resources. Piling on badgering people won't get this done in another 8 years.

Linking this again: #160 (comment)

The sense of entitlement being expressed here is quite rich. 20 years of free software, folks. It could be better. The fact that it isn't doesn't give one license to behave this way.

It’s not entitlement, it’s willing to make it better because right now it does not work for many people. Making files not compatible with 99% tvs is not “working fine”.

I’m not mad, but I guess lots of you have the privilege of being native English users with no need for subs as most of content is done in your language. Thinking this is not important shows that people have never give a thought about non English users. We need subs, and if they don’t work on tv apps there is a problem. Either subs work or I can’t watch the content as everything I get is not on my native language.

Asking for a solution (even if I have to pay, that’s not the problem) is normal. Being told for 8 years that’s “it’s easy but we don’t care about disabling the function that converts the subs instead of just using the ffmpeg built in passthrough feature” is a bit of mocking the users.

Please don’t tell me that passing through subtitles is harder that developing a subtitle conversion function that was not needed, not when ffmpeg has the function already in place.

[UnidentifiedTag]

@bradleysepos I feel required to respond to that last comment you made :

The sense of entitlement being expressed here is quite rich. 20 years of free software, folks. It could be better. The fact that it isn't doesn't give one license to behave this way.

Us folks don't feel entitlement to anything, I and others appreciate the work the team have put in to this project, you've missed the point completely.
Which is the whole point of handbrake, the spirit of handbrake, I quote :

HandBrake is a open-source tool, built by volunteers, for converting video from nearly any format to a selection of modern, widely supported codecs.

Reasons you’ll love HandBrake:

Convert video from nearly any format
Free and Open Source
Multi-Platform (Windows, Mac and Linux)

Let's focus "video from nearly any format to a selection of modern, widely supported codecs."

.ass or SSA. Is not modern or widely supported

[bradleysepos]

Sigh.

Again, much misunderstanding about HandBrake's internals and the FFmpeg library in HandBrake, grossly general assumptions about devs' native languages and subtitles needs/preferences and about the user base, and literally quoting text from an article I wrote to justify an ask that is not rejected (!) but simply not yet implemented for reasons that have been communicated.

Sorry the functionality you want isn't in HandBrake and this affects your workflow. If multimedia software development is not your area of expertise and you are unable to materially assist with development, you'll have to wait until someone else does. If anyone has a problem with this, please look up the definition of entitlement and search for information about entitlement in open source software.

And no, this issue is not the place to discuss/debate those topics. This issue, which is still marked Patch / Help Welcome, remains open (for now) so people can help in material ways, such as development discussion, testing feedback, etc. So thanks for the input, please be reasonable, and definitely quit while you're ahead.

[Rumourd]

I just wash the completed encode thru MKVTOOLNIX and quickly add back the SRTs, but also I'm able to insert the new filename into the metadata, so I'm killing two birds with one stone. Easy.

…

On Wed, Jan 10, 2024, 4:21 AM UnidentifiedTag ***@***.***> wrote: @bradleysepos <https://github.com/bradleysepos> I feel required to respond to that last comment you made : The sense of entitlement being expressed here is quite rich. 20 years of free software, folks. It could be better. The fact that it isn't doesn't give one license to behave this way. Us folks don't feel entitlement to anything, I and others appreciate the work the team have put in to this project, you've missed the point completely. Which is the whole point of handbrake, the spirit of handbrake, I quite : HandBrake is a open-source tool, built by volunteers, for converting video from nearly any format to a selection of modern, widely supported codecs. Reasons you’ll love HandBrake: Convert video from nearly any format Free and Open Source Multi-Platform (Windows, Mac and Linux) Let's focus "video from nearly any format to a selection of modern, widely supported codecs." .ass or SSA. Is not modern or widely supported — Reply to this email directly, view it on GitHub <#160 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOGDCUBS2IMPPXESXJKIWTYN2BVPAVCNFSM4CBSMKJKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGQ3TINZSGQ2A> . You are receiving this because you commented.Message ID: ***@***.***>

[Informationator]

I know this isn't intended to be a discussion thread, so I'll try not to be too longwinded, but you guys would be my hero if you put this one at the top of your priority list. I can understand how the frustrations expressed here would make you want to put it at the bottom, but if the effort isn't too large, and one of the devs would be willing to pause something they're working on for a bit to knock this out, I know we'd all be extremely grateful.

I've spent hours and hours in MKVtoolnix just adding SRTs back in to replace converted SSA subs over the last few years. almost 200 movies and many full TV series. It's such a slog to have to do all of that manual work on the tail end just to put things back the way they were before Handbrake processed them. It's not that hard to alter things onesy-twosy, but when you're dealing with the volume of media I am, it really adds up.

All that said, I never think we "deserve" anything, least of all from volunteer devs. I'm just saying that if one of you has the technical capability to make this change, and you make fixing this a priority in response to the community... You'd be a legend. I would personally be extremely grateful because you would be saving me hours and hours and hours of work that's still ahead, and multiplied across your entire userbase, well, I can't even imagine the time saved. Thanks for reading.

[kwambono]

I've spent hours and hours in MKVtoolnix just adding SRTs back in to replace converted SSA subs over the last few years. almost 200 movies and many full TV series. It's such a slog to have to do all of that manual work on the tail end just to put things back the way they were before Handbrake processed them.

lol, I can SO relate to this as someone who loves foreign language movies a lot more than hollywood fare :) and who made his own subtitle font just because...(wish I could use it on apple tv tho)

[sr55]

Locking this thread to contributors only. Votes and voicing the same concerns repeatability do not build patches unfortunately.

To be clear to anyone reading this:

• Yes we know the current implementation is annoying to many of you.
• This is an Accepted Feature Request to make this behaviour configurable.
• No one has volunteered to implement it yet. If you are interested in implementing it, please contact us and we can point you in the right direction to submit a Pull Request.