24.12.0 subtitle editing

@antimidia - I’m picking up on this: Kdenlive 24.12.0 released - #8 by antimidia in a separate thread here so that we’ve got a place to talk about just things related to the new subtitle implementation for all the people using it.

Having had a chance to use it for a real project now - I do think it is a huge step in the right direction, but like anything new there’s still a few rough edges to it …

I’m not sure what you were looking at in the subtitle manager when you said: “there seem to be an option to change the subs to all the clips in a track, only it doesn’t work.” - I’m not seeing anything there that lets you edit individual subtitles… You can add new styles, but that on its own doesn’t do anything to change any existing clips (which is as I would expect it to be), it just adds a new style to the set of them that you can later use.

So I’d stick what I originally said for that one, that if you want to change the style properties of all existing clips, like you might have in older versions using SRT subtitles, then you should just edit the style they are using rather than create a new style and change them all to it. It might be nice to be able to do the latter, but I don’t see a way to do it now except to manually change each of them one at a time, or a clear and simple UI change which would enable doing that. And I think once people grok the difference(s) between SRT and ASS, this won’t be an actual thing they’d commonly want to do. (you can always do any major change you like along those lines by just editing the *.ass in your favourite text editor in the unusual cases).


I do have a list of things (some wishlist stuff, some sharp edges, and some real bugs) that I stumbled on when using it though so, in only a roughly particular order:

  • The biggest gripe I currently have for long term usability is that there appears to be no way to save ‘genuinely global’ Custom Styles - in the manner of custom effects and presets that you can reuse in later projects.

The ‘global’ space for styles is still local to the project - which appears to be needed if you want to copy styles between sequences. I get that this is a bit like the “storage” and “current script” spaces in the aegisub styles manager interface - but it would be much more useful if, like that one, you are able to select from multiple named “storages” - which possibly includes a ‘project local’ option, but mostly lets you keep sets of commonly used styles in share/kdenlive/ for all projects to use, along with your custom effects etc.


  • There is no simple way to just rename a style.

Which becomes most annoying if you do something like click the “Duplicate” button in the styles tab. That creates a duplicate with a placeholder name - but if you then edit it and change the style name in the edit dialog, then rather than changing the name it creates yet another copy with the new name and then you need to go delete the placeholder.


  • Copying styles between the ‘global’ and (per-sequence) ‘subtitles’ space is a bit clunky and glitchy.

If you drag a style to one of those spaces you first get a copy to / move to context menu. Then when you select one of those you get a popup dialog with a dropdown to “select the subtitle file to copy/move to” - but that selection actually does nothing except give you yet another chance to cancel the operation because no matter what you choose in the dropdown box it still move/copies to whichever namespace you originally dropped the style you dragged to.

I’d probably just get rid of that dialog altogether as an unnecessary extra hoop to jump through to do a simple copy/move - but maybe it has some future envisaged use case and until that is implemented it’s just buggy? I can’t really imagine what that might be right now though.


  • The ‘drag a subtitle down in the timeline to create a new layer’ needs a safety catch. Maybe needing a shift or alt drag or the like to do that?

It’s a cute feature, but it’s just way too easy to do it by accident - and the time saved for doing something that most people will rarely (or ever) need to do is hugely overshadowed by the relatively major operation needed to delete that unwanted layer again in the case of doing it by accident.


  • copying a subtitle clip between layers is buggy.

If I copy a clip in layer 1 and paste it into layer 0, then in the UI it is displayed in layer 0 - but in its properties and the subtitle manager etc. it remains in layer 1.

This seems to be combined with a bigger bug where all subtitles except those explicitly dragged down are displayed in layer 0 regardless of what layer their properties say they are in.

If I try to create a new subtitle in layer 1, or copy one to it, the UI displays it in layer 0. And if I open a project that saved subtitles in layer 1, they are all displayed in layer 0 in the timeline (but their properties still correctly say they are in layer 1).


  • It would be nice if the style editing dialog allowed more things (at least Outline and Shadow, but maybe also the margins) to have fractional rather than just integer values.

I’ve been using aegisub for subtitles since before kdenlive got its initial subtitle support - and then later to take SRT subtitles that I had positioned in kdenlive to style them for actual use - and I have several styles where a shadow of 2.5 was the goldilocks choice between too thin and too heavy.

The dimensions of subtitles are always scaled as a function of the sizes given, the declared resolution those sizes are relative to, and then the actual display size the video is being played with - so none of those values are in actual integer pixel units, they all get multiplied by a bunch of things before they need to be rounded to an integer.


  • Related a bit to the previous point, I always use external subtitles (either as separate files or merged into a mkv container as a separate thread) rather than burning them in at render time, so that people have the option to turn them on or off at playtime as they prefer (or even to select between multiple subtitle options for the same video at playtime).

It might be nice to better support that at rendering time, but for now I can just symlink or copy the relevant *.kdenlive.ass file for <rendered file>.ext to <rendered file>.ass myself easily enough.


  • It would be nice to be able to delete (or at least rename) the “Default” style.

Each layer needs “a default style”, and it took me a while to find how to set that (and that you really could do it already and I didn’t need to wishlist that ability too! :smiley: [oh … maybe that’s what @antimidia was changing and expecting to propagate automatically instead of just being the new default for newly added subtitles?]) - but as long as at least one style exists there is no reason that it needs to be called Default or that a style by that name needs to exist if it is entirely unused.

This kind of goes back to my desire for “system wide” custom styles - in most of my projects I’ll use 3 - 5 subtitle styles, and I have a set of my own styles that I use for that - so once I’ve imported them, and set the default that I want for each layer from that set, I don’t need a style named Default being just unused clutter that I can’t delete.

There might currently be some implementation reason for this, but there shouldn’t be any fundamental reason to have a magic immutable style name that must always exist.


The little voice in my head says there was something else that I’ve forgotten here - but if that’s true I’ll bump into it again soon enough :slight_smile: So for now I’ll cap this here as my initial beta-test feedback…

It’s not impossible that there’s still something I’ve missed which might make some of these things Not the Problem I Thought They Were - and there’s surely other users of subtitles with their own use cases who might have better ideas about some of these things than I do - so I’m opening this topic to toss things around here, and if we get consensus on some details of wishlist things or confirmation of bugs, I’m happy to push them off to the bug tracker as needed.

2 Likes

I previously posted this in the Kdenlive matrix room, and I was asked to post a comment here in this topic.

I believe that I will be filing a bug against Kdenlive, seen in 25.04.3. In subtitle files exported in *.srt format, italicized, bold, underlined, and strikethrough text are incorrectly formatted. For example, with italicized text the correct formatting should be “<i>Text</i>". But, instead what is incorrectly seen in the exported file is “{\i1}Text{\i0}”.

Steps to Reproduce, using italicized text as an example:

  1. Start a new Project.
  2. Project → Subtitles → Add Subtitle. (A new subtitle with the text “Add Text” is created.)
  3. Edit the subtitle text to add italics formatting to the word “Text”.
  4. Project → Subtitles → Export Subtitle File. (Export the subtitle file in *.srt format.)
  5. Open the *.srt subtitle file with a text editor.
  6. Observe that the file contents have the incorrect “{\i1}Text{\i0}”, instead of the correct and expected “<i>Text</i>".
  7. The same behavior also occurs with bold, underline, and strikethrough formatted text.

Hi Benjamin!

Yes, it was me who asked them to ask you to bring it here - this is where I’m collecting the wishlist things for the new subtitle code that I’m working on - and it’s good to have these conversations somewhere that other people with the same problem can see them, instead of repeating them transiently.

There’s no need to file a bug for this one, though you are correct that it is a bug in the current code. When the ASS support was added, it was implemented mostly as a one-way transformation. Existing files would be converted to ASS, but support for converting them back to SRT was very limited.

In the new code I’ve implemented a more structured internal format, with more complete handling for importing and exporting it to on-disk formats. So this bug is already fixed in that, I just need to finish polishing the last few things in it for release and get it landed, so this will be fixed in a future release.

It only supports the very basic styles, since ‘officially’ (or as official as something without a formal spec can actually be) SRT doesn’t actually support them at all, though several implementations now do to various degrees. But that’s another thing we can look at more if there is real demand in the future.

Here’s the same timeline exported to ASS and SRT with that code:

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,00:00:06.60,00:00:11.60,Default,,0,0,0,,{\s1}Add{\s0} {\i1}Text{\i0}
Dialogue: 0,00:00:20.84,00:00:25.84,Default,,0,0,0,,{\u1}Add{\u0} {\b1}Text{\b0}

1
00:00:06,600 --> 00:00:11,600
Add <i>Text</i>

2
00:00:20,840 --> 00:00:25,840
<u>Add</u> <b>Text</b>

If you look carefully, you’ll see that strikethrough isn’t currently supported for SRT, but unsupported styling is omitted, not copied verbatim from ASS.

Do I need to add strikethrough to the supported styles for SRT? Is it widely supported (or supported at all) by players?

And can I ask, why exactly do you want them exported to SRT? What’s your use case? What players support it (with styling) but not ASS (or is there some other reason)? Most of the value in switching to ASS is that it can represent things that are impossible in SRT, while being at least as (if not more) well supported by the majority of players.

If you’ve got any other wishlist things for how you work with subtitles, please do feel free to share them here. I’ve got much more freedom to add support for things for use cases that I hadn’t already considered now than I will have after this lands and ties itself to compatibility promises to other users.

My use case for exporting to .srt format is to add subtitles when uploading videos to PeerTube. PeerTube supports .srt but not .ass. The only subtitle formatting I’ve personally used is italics, for things like book titles. (Italicized subtitles do appear correctly on PeerTube.)

For the wider population, I believe the main use case for .srt format would be to add subtitles when uploading videos to YouTube. As I understand it, YouTube also supports .srt but not .ass. (However, on their support page Google says about .srt files, “Only basic versions of these files are supported. No style info (markup) is recognised”, and from a brief internet search it does seem that formatting like italics and bold subtitles aren’t available on YouTube when using .srt files.)

I’m not sure about strikeout formatting. Until yesterday, I didn’t know that a strikeout HTML tag even existed.

There were two other bug-like behaviors that I saw with Kdenlive subtitles:

One was that subtltles (and exported .srt subtitles) seemed to contain leading and trailing newlines (blank lines). The behavior I expected was that leading and trailing newlines entered in the subtitle text input field would be automatically omitted/removed, not saved. Similar to how leading and trailing space characters are automatically omitted from each subtitle line.

The other behavior that initially looked like a bug was when entering subtitle text on a Mac using the Unicode Hex Input keyboard, I initially wasn’t able to enter Unicode characters. For example, holding down the Opt key and pressing the keys “2”, “0”, “7”, “f”, did not type the U+207f “Superscript Latin Small Letter N” character as I expected. The problem was that there were default keyboard shortcuts mapped to Opt-1 to Opt-9 (to select audio tracks 1-9). Removing these keyboard shortcuts resolved the issue and allowed Unicode characters to be entered.

That caught me by surprise … I wonder what their rationale for that was. There are liberally licenced implementations, and I’d bet some of their backend software supports it.

But you are correct about that, and that their SRT implementation doesn’t support styling at all - so I wonder if we should add a “strip all styles” option for SRT export for that sort of degraded use.

The new code has limited support for SBV and VTT (to maintain the historical behaviour of being able to import those to kdenlive) - but I hadn’t added explicit support for exporting to them (SBV is just SRT with a different timestamp header, and at its most basic level so is VTT, so there didn’t seem to be much value in promoting confusion over what to use if they were effectively all equivalent in functionality).

In its Full Committee Imagined Glory VTT very browser-centric - which might go some way to answering my first question, but google only supports b, i, u tags for it too. But for your use, that probably makes adding VTT exports a useful thing too - which should pretty much literally just take replacing a call to toSrtTime with one to toVttTime in the new code, and adding an option to select it to the export dialog.

Looks like google doesn’t support strikeout in any format, so we can probably safely leave it to just ASS players for now until someone reports differently. It would be interesting to know if they strip out unsupported tags, or just blurt them out verbatim.

subtltles (and exported .srt subtitles) seemed to contain leading and trailing newlines

I’m not quite sure I follow you here? Can you paste an example. In SRT-style files, whitespace is significant and trailing empty lines are end of field markers. (some implementations are strict enough about that to not show the final subtitle if there isn’t one between it and EOF).

The behavior I expected was that leading and trailing newlines entered in the subtitle text input field would be automatically omitted/removed

They should be getting stripped out in the edit dialog - though the existing code is somewhat buggy and inconsistent about that too.

In the new code, leading and trailing whitespace is chomped, and internal newlines get consistently escaped.

But if you’re seeing something different (or Mac specific?) we should probably investigate a little more.

on a Mac using the Unicode Hex Input keyboard, I initially wasn’t able to enter Unicode characters

Ok, that seems like something we should either fix or warn about, but it’s probably something we can’t directly do much about in the subtitle code as such. Will put this one out for suggestions.

I now see that the leading/trailing blank lines issue is a bug that occurs when using the “Split subtitle at cursor position” function. If you split a subtitle before or after a linebreak, the linebreak does not get chomped and unexpectedly remains in one of the split-off subtitles.

Procedure to reproduce:

If you manually create 2 separate subtitles, even if you try to enter leading or trailing blank lines in the text field these blank lines are not saved, and you get the correct and expected .srt file:

1
00:00:23,066 --> 00:00:51,366
This is line 1.

2
00:01:00,700 --> 00:01:30,566
This is line 2.

However, if you create a single subtitle with the text…

This is line 1.
This is line 2.

… if you put the cursor at the beginning of line 2 and split the subtitle, the first subtitle is left with a trailing blank line, resulting in this incorrect .srt file:

1
00:00:23,066 --> 00:00:51,366
This is line 1.


2
00:01:00,700 --> 00:01:30,566
This is line 2.

… if you put the cursor at the end of line 1 and split the subtitle, the second subtitle is left with a leading blank line, resulting in this incorrect .srt.file:

1
00:00:23,066 --> 00:00:51,366
This is line 1.

2
00:01:00,700 --> 00:01:30,566

This is line 2.

Ah, yes - I can reproduce that - though the actual bug isn’t that the split doesn’t chomp.

It’s perfectly legal for ASS to have leading or trailing newlines (or other whitespace) - which means I can also reproduce your problem just by adding an explicit (escaped) newline to the beginning or end of a subtitle, without doing any splitting at all. It probably doesn’t make a whole lot of sense to have them - but if we arbitrarily prohibit them, then eventually someone will come along who says that breaks some special use they have…

So I think there’s two issues here (which do need addressing in the new code):

  • When we export as SRT, we need to sanitise newlines even harder, stripping any off at the beginning or end. The new code already collapses sequences of internal ones to at most one, because that would otherwise create an invalid SRT, but I didn’t consider the case where someone ‘explicitly’ has a leading or trailing one in the text.

Not doing that is definitely a bug.

  • and we probably should strip any leading or trailing whitespace either side of a split when one occurs.

It’s not really a bug not to - it’s perfectly legal to keep it with ASS - but its probably not the most commonly desired behaviour. If someone is splitting at a space, the intention is almost certainly to split on the word break, not the the character break.

They can always add the space back if that’s wrong, which seems like the exception case, and we should err one the side of not making people manually remove them when splitting.

Good catch - thanks for that!

Hello

I would like to suggest an UI improvement in terms of subtitles transform control in Kdenlive. As you can see in the image below there is a separate panel which holds all the data about transform position.

Also the subtitles should be grabbable by mouse to manually change their position (so the transform panel also updates while grabbing).