Archive: Manuskript of Bringing the SDH audience closer to the sound

Coloring; speechbubble-oriented positioning; and simultaneously appearing, time-shifted subtitles in movie subtitling

 

[Zur deutschsprachigen Übersetzung]

When we watch conventionally subtitled movies, we always get our subtitles positioned in the same area of the screen: centered at the bottom, or centered at the top. Now, that appears to be the ideal compromise since we don't want the subtitle text to consume the major composition of the movie picture. But is the centered bottom/top position really always the ideal position for our subtitles or are we just too lazy to put our subtitles where they fit best? In this post, I'll try to demonstrate why we should spend (more) time on subtitle positioning, coloring and simultaneously appearing text when designing our translations. I'll also outline problems that we currently have, even if we do that.

So, before I'll officially question the standards of movie subtitling again, I ironically may have to defend the subtitling conventions first--at least to a certain degree. There is movie material where the standard positioning of subtitles remain ideal throughout the movie. Most of the time, we actually only have to contemplate subtitle positioning when there are dynamic dialogues (I'll explain in a second what is meant by that). For instance, in ordinary Discovery Channel documenaries, there might not be a single dialogue taking place in the entire movie. Most of the time, there are several scenes of the place where action takes place. A single person might say something in between, but the rest of the time, there are pictures describing the environment and the sound file is stuffed with comments of the narrator--the ideal environment for conventional subtitling positioning. So, let's start with the argument where troubles occur: sequences with dialogue.

For the listening audience, participants of a dialogue are generally distinguishable through the different sounds of the participants voices. For the watching audience, the movement of the speaker's lips makes visible who is talking. It just gets complicated if the audience can't hear or if the lips of the dialogue's participant aren't visible in the shot -- and here is where creative subtitling tools make a difference. If we want to make clear who is talking and precisely saying what and when in a dialogue in subtitling (which might be important f.e. when telling a joke), we have to make it visible through the position of the subtitle, through coloring subtitles in order to distinguish speakers from one another, and by using the instruments we have to take into account time-shifts in speech and simultaneously appearing single utterances.

I did three things:

1. I put the subtitles (--ideally condensed to the gist, so that they consume little of the picture material--) where you'd put speech bubbles in a comic or graphic novel.
2. I used colors to distinguish several speakers from one another. (already perceived pros doing that in Netflix subtitle translations f.e. for "House of Cards")
3. I let subtitles occur simultaneously and divided sentences into smaller portions when f.e. speakers stop their sentences in between.

Here's the outcome:

So, as you see, such subtitling makes sense. The problems I'm still facing economically are outlined below:

In order to produce such SDH-friendly subtitles and later make it available for streaming services and the like, we can't provide products that can compete with conventional subtitling products in price and data volume. Up to this day, most of the established streaming services... Netflix, Disney Plus, Flimmit, you name it, are good with the well-known .srt-files and comparable established alternatives. Such files are not much more than .txt-files, need ridiculously little data volume and can be sent entirely to customers with a single e-mail attachment; nothing easier done than that.

To produce the translation above, I used Aegisub. Aegisub is an advertising-free open source subtitling software that whoever wishes to use can download from the internet. Maybe it's not quite user-friendly; there is still a great deal of space to improve to make it easier to use. However, it provides lots of tools to design subtitles creatively. Once you save your subtitles, the software creates an .ass-file that saves positioning, coloring and many other basic parameters that make creative subtitling possible. Those parameters wouldn't bring about significantly more data volume than a .txt or .srt-file...

The big problem we're actually facing is that there might not be a single streaming service out there that can read and project an .ass-file over his or her available video material. In order to produce that cheep video above I had to use Handbrake, also an advertising-free open source software that, among other things, can "imprint" .ass-content on common video files. Unfortunately, that means that once you've completed your subtitling project, your valuable market-relevant product is a huge video file that you can't send via e-mail and that your customer can't tread like a conventional subtitling file.

An exclusive SDH-oriented streaming service that makes available particularly such translations might be a great start-up project since sending big files online isn't the biggest problem anymore. But you as a translator may need a bigger, better, faster personal computer with tons of disk space left to manage and to document your work. On top of that, your customer needs a good lawyer in order to not get in trouble with the owners of the original video material you manipulated for commercial use.

In order to establish this kind of subtitling product, you're best finding a software engineer first who develops a video broadcasting software that streaming services can easily integrate, thereby replacing existing ones. This software should be able to fully read and project not only established subtitling files but formats like the mentioned .ass-file. Once that is done, we're good to go.

Thanks for your time

Participate if you want to make a difference

Share this post with professional software engineers

Inform your local SDH community about the idea

Yours,

Michael