Don't use \fad on fades to black

Dear typesetters,

I have seen this countless times. Every time, it has bothered me. Please, don't do it anymore.

When the screen fades to black (or white, or any other solid colour, for that matter), DON'T use the \fad tag to fade the text along with it. When you use \fad, you're making the text translucent, and not darker. The result is that it will blend with the background - including all the usual associated bugs if you have borders and shadows - and get somewhat darker because the background itself is getting darker - it just won't get as dark as it SHOULD be, and the visual effect is that the text is getting brighter, relative to the background.

Original

With \fad

With \t(\c)

As you can see above, the CORRECT way to deal with this is by using \t to animate the colour (all relevant ones) to black (or whichever colour the screen is fading to). Also note that the background can be seen through the text in the \fad() case, which is not the correct behavior.

Keep in mind, though, \t(\c) is significantly slower than \fad() on VSFilter, so you might have softsub issues, depending on how complex is your text.

Read More...

Font hinting and you

... or why you should not use animation on the \fs override tag.

Do you know what font hinting is? If you haven't worked with digital typography you might not, but it's a technique used by (almost) all font rendering systems to make vector fonts (such as True Type, Open Type and Adobe Type 1) appear better on low-resolution mediums like computer monitors. (Actually CRT TV screens are even worse.)

Usually glyphs ("characters") in outline fonts have quite some detail in them, but if you only have 7x13 pixels to render a character in, you're going to have a hard time fitting all that detail in, even if you use sub-pixel rendering such as anti-aliasing and ClearType. That's where font hinting comes it. It's a technique for intelligently modifying the outlines of characters so they look better without completely losing the characteristics that makes the font face special. The basic idea in font hinting is to snap the outlines to the edges of pixels, such that stems and vertical lines take up a whole number of pixels instead of disappearing in quantisation or become a smudge of sub-pixel noise.

So what does that have to do with subtitles? Well, the amount of hinting applied to a glyph depends on the point size of it. The bigger the point size, the less strong the hinting needs to be. For example, here's some text in Verdana at different sizes:

Verdana 8 pixels

Verdana 12 pixels

Verdana 30 pixels

Depending on your font rendering system it might look different (eg. Windows and Macintosh OS X render quite differently) but at least if you're on Windows you should be able to see that the shapes of the letters actually change a bit. The smaller the text size, the more drastic the change.

It's this change of glyph shapes that's interesting in subtitle context. If you've ever needed to have some text change size on screen in ASS subtitles you might have considered whether you should use \t(\fs) or \t(\fscx\fscy). It's the latter that's correct. When you animate the \fs tag you're changing the actual font size requested of the font subsystem, and this also affects the hinting applied to the text.

This leads me to the image at the start of this post: Both of the top two lines with "Test" are rendered in what should have been Arial size 40. But the upper has been given its size with \fs1\fscx4000\fscy4000 while the lower has been given its size with \fs40\fscx100\fscy100. Because VSFilter internally works at 8 times resolution, the upper line is requested as Arial with a font-height of 8 pixels, so it's hinted to look best when rendered just 8 pixels tall, while the other line is requested as 320 pixels tall Arial. The red/blue at the bottom are the same two lines with the border removed, then laid over each other.

Do you now see why you shouldn't animate the font size, but rather the font scale?

Read More...

VSFilter hacks

There's lots of versions of Gabest's VSFilter subtitle renderer around, some people are even still using versions that are several years old and are missing features and bugfixes. There's cases of people still distributing these old versions around, sometimes as part of a package with other software such as VirtualDub.

Now it happens that some time in 2006, Gabest seems to have lost interest in working on VSFilter, so nothing has happened from his side, not even bugfixes. Fortunately VSFilter is open source, so we have picked it up and made a fork. We have included both some existing bugfixes and improvements that existed as patches, and also made our own bugfixes and further improvements.

I'm going to talk about some of the improvements we have made throughout this post.

First, I'm going to assume you're familiar with most regular ASS override tags, if not you can get a refresher in our manual. Second, not all of these improvements are available in the version of VSFilter we ship with the current release (2.1.2) of Aegisub, but they should all be in the next one (which will be 2.1.3 or 2.2.0, depending on circumstances.)

Sometimes you need sub-pixel precision when positioning text and drawings. Normally you've only been able to get this by setting the script resolution (PlayResX and PlayResY) to something larger than the video resolution, but the "float \pos" patch changes this. It allows you to use decimal/floating point numbers for positioning lines and gives you up to 1/8th pixel precision.

The image to the left shows four lines of text positioned at different X coordinates. You can see how they move ever so slightly, although not a full pixel.

The tags \fax and \fay allow you to do shearing operations on your text. This is a bit like rotations, except that it's not. They are especially useful for doing perspective correction when you are typesetting signs rotated in 3D.

Shortly before Gabest dropped development of VSFilter, he introduced the "ASS2" format. This isn't very well known, and it only has minor changes over the original ASS format. One of the things was a new karaoke timing tag, \kt. While Aegisub can read ASS2 files it can't write them, so if you edit them in Aegisub you will lose some information. It doesn't have support for timing with the \kt tag either, but you can of course still use that and use all the additional features of ASS2 if you edit the file with a text editor.

So what is \kt? It's "set absolute timing", it allows you to move both back and forth in time of highlight without highlighting other syllables. It is probably best illustrated with an example:

{\kf10}ABC {\kt20\kf10}DEF {\kt10\kf10}GHI

When you render this example, you will first see ABC highlight. Then GHI will follow, because its highlight is set to start at time 10 by \kt. Finally, DEF will highlight because its start time was set to 20 by \kt. You can also use \kt to make karaoke syllables overlap in timing.

Originally the \be tag (Blur Edges) only allowed blurring to be turned on or off, and was very "weak", the blur effect was hard to notice at all. We have updated it so it supports variable strength blur effects now, and you can also use it with \t to animate the blur strength.

Because \be doesn't look very high at high values we have also introduced the alternate \blur tag, which performs the blur effect using a two-pass gaussian blur algorithm. This gives a much nicer and wider blur, especially at high values.



I will discuss why \be and \blur are "blur edges" effects and not "blur everything" effects tomorrow.

If you've ever wanted the shadow to be positioned differently than just "X down and X right", the \xshad and \yshad tags are probably just what you want. These work like \shad except that they set only the X or Y displacement. You can even use negative values with them!

Finally there's the \xbord and \ybord tags. They can be useful for various things, but one of the intentions was to better support anamorphic video: The \xbord and \ybord tags allows you to control the border width in X and Y direction separately. You can even disable border in one direction entirely!

You can also combine this with strong \be or \blur and maybe some shadow for other interesting effects.

Again, remember that many of these tags require a very new version of VSFilter. For example, the \blur tag was only added yesterday..! The next release of Aegisub will ship with a VSFilter version that supports all of them, so if you want to safe you can wait until then. If you're impatient, you can follow development on the Aegisub forum.

Read More...

Universal Subtitle Format: a post-mortem?

The Universal Subtitle Format (USF) was an ambitious project. It was a XML-based subtitle format, supposed to replace the old and problematic community standard, Advanced Substation Alpha (ASS). It was chosen as the default subtitle format for the Matroska multimedia container, and was the primary format of Medusa's unfortunate successor, ChronoSub.

It failed to achieve that goal.

This is what its page on CoreForge has to say:

The format is based on XML for many reasons: flexibility, human readability, portability, Unicode support, hierarchical system and easier management.

While I can certainly understand "flexibility" and "portability", I don't see why you need XML to have a portable format, or Unicode support. But they go ahead and claim human readability and easier management. Is that supposed to be a joke? It sure is human readable - compared to binary formats. But it's still an incredibly verbose format that no sane person would try to edit by hand. And how is it easier to manage? Only if they mean that it's easier to avoid horribly misshapen subtitle files (you know, the kind of file that's always floating around the community and that VSFilter will happily eat). And what's with "hierarchical system"? It is true, but isn't it also completely irrelevant? Subtitles are NOT intrinsically hierarchical - forcing them to be only complicates matters.

But let's have a look at the format itself. This is a simple "Hello World" in USF:

<?xml version="1.0" encoding="UTF-8"?>
<!-- DOCTYPE USFSubtitles SYSTEM "USFV100.dtd" -->
<?xml-stylesheet type="text/xsl" href="USFV100.xsl"?>

<USFSubtitles version="1.0">

  <styles>
    <style name="NarratorSpeaking">
      <fontstyle italic="yes" color="#FFEEEE" outline-color="#FF4444"/>
    </style>
  </styles>

  <subtitles>
    <subtitle start="6.100" duration="4.900">
      <text style="NarratorSpeaking">This is a demo of<br/>The Core Media Player<br/>subtitle format</text>
    </subtitle>
    <subtitle start="00:00:11.000" stop="00:00:15.000">
      <text style="NarratorSpeaking">What can be done ?</text>
    </subtitle>
  </subtitles>

</USFSubtitles>

The above sample is the "official" sample included with the specs, stripped down to make a suitable "hello world". For comparison, I've re-created the script in ASS:

[Script Info]
ScriptType: v4.00+
PlayResX: 640
PlayResY: 480

[V4+ Styles]
Style: NarratorSpeaking,Arial,20,&H00EEEEFF,&H000000FF,&H004444FF,&H00000000,0,-1,0,0,100,100,0,0,1,2,0,2,10,10,10,0

[Events]
Dialogue: 0,0:00:06.10,0:00:11.00,NarratorSpeaking,,0000,0000,0000,,This is a demo of\NThe Core Media Player\Nsubtitle format
Dialogue: 0,0:00:11.00,0:00:15.00,NarratorSpeaking,,0000,0000,0000,,What can be done ?

Note: I removed the "Format:" lines from the above file. This is because, to the best of my knowledge, Sabbu is the only program that actually cares about those lines. Neither VSFilter nor Aegisub care if it's there or not, and both will, in fact, ignore it.

For further comparison, this is what the same script would look like in the current draft of AS5:

[AS5]
ScriptType: AS5
Resolution: 640x480

[Styles]
Style: NarratorSpeaking,,\i1\1c#FFEEEE\3c#FF4444

[Events]
Line: 0:00:06.10,0:00:11.00,NarratorSpeaking,,This is a demo of\NThe Core Media Player\Nsubtitle format
Line: 0:00:11.00,0:00:15.00,NarratorSpeaking,,What can be done ?

The first thing that we can notice there is that ASS is a much more "compact" format, and USF is more "readable" in the sense that you'll easily know what each thing does if you aren't familiar with the format - unless you are very familiar with the ASS format, the "Style" line should be incomprehensible. ASS is also more "horizontal" - that is, unless you cram things into the same line in USF, ASS will take less lines but those lines will be longer.

Here's the important point: USF is NOT designed to be written by hand. It's just too much effort to write all of that, and if you forget to close some tag somewhere, you'll break the entire file, which isn't an issue in an ASS-like format. And this is exactly where the problem is: there is no good editor that supports USF!

Lately, there has been a trend for XML-based subtitle formats. This is probably because XML is relatively easy to parse by a machine, and also because of the "buzz" associated with XML. But let's face it: subtitles are not best modeled by XML. The ASS format is a strange hybrid of an INI file, a CSV list, and TeX, and that works astonishingly well - that's why we have decided to base AS5 on the same combination, although that is a subject for another post.

So here's the situation that USF faced: there was no real editor that could deal with it and nobody wants to write or maintain USF files by hand. Because of that, nobody actually uses USF, so there is no renderer that accepts it. Finally, USF offers very few real benefits over ASS, feature-wise. All in all, it just wasn't interesting to support it, and it faded into oblivion.

But here's an idea: Athenasub (the library that will be the backend of Aegisub 3.x series) will be completely format-agnostic. That would make it feasible to make Aegisub fully support USF, even its fanciest features, except that there is no renderer to display it. Should we bother? Is there still any interest in this format? At the moment, I have little interest in attempting to resurrect it (especially since we have our own plans with AS5), but if there is popular demand for it, I might reconsider. Last time I checked, not even the Matroska team seemed to care much for it anymore.

AS5. USF. And let's not forget Gabest's SSF. Do any of those formats have a future in the community? Or will fansubbers linger to ASS until the rest of their days?

Read More...

So, what happened to the competition?

On July 9 2006, the last actively maintained ASS-Based General-Purpose Subtitling Software (henceforth ABGPSS) competition that Aegisub had - Sabbu - was dropped by its creator, kryptolus. Sabbu was an important program in the sense that it was the first ABGPSS to support Unicode and to be cross-platform. With Medusa and SubStation Alpha long dead, Subtitles Workshop being far from usable for anime fansubbing purposes, and SSATool designed for very specific purposes, Aegisub obtained monopoly on the ABGPSS business.

But what really happened? Was that a good thing? Let's take a quick look at all the related software.

Substation Alpha started it all. Written in Visual Basic, it had many advanced features for its time, and many timers still think that it's the best timing tool ever made (I was recently shocked to learn that some old-school fansubbing groups have been using Aegisub even for timing!). As revolutionary as it was, it was essentially useless for typesetting and had too many quirks for most users.

• What happened to it? It was discontinued many years ago by its creator, Kotus.
• Who still uses it? Many old-school timers still do, apparently, and won't replace it with anything else.
• Why was it important? It supported genlocks, but it also helped ignite the digisubs revolution. The current standard subtitles format is a direct descendant from SSA's own version 4 format, which is the source of many oddities in the format.
  

Medusa is the tool that I actually used when I was a "fansubber" (it's worthy pointing out that I was also a fansubber [sans-quotes] for a brief while). Medusa is infamous for its instability. Not only was it also written in Visual Basic, like its predecessor, but it managed to exploit that fact in new unique ways, making it infamous for its instability and propensity for misbehavior. It was such a marvelous tool that I (and many other typesetters) decided that it was better to simply typeset with good old Notepad+VirtualDub. This technique would later inspire Aegisub's video mode.

• What happened to it? kaiousama, its creator, apparently attempted to rewrite it from scratch into a greater abomination known as "ChronoSub", which would use the dreadful USF format as its primary format. He vanished after that.
• Who still uses it? Masochists. Aegisub was designed to replace Medusa specifically, so there is no real reason to use it, unless you are on Windows 9x.
• Why was it important? It was the first ABGPSS to support the Advanced Substation Alpha (ASS) format, and the first to include a video display for typesetting.

Sabbu was an important step in the right direction. This was the only program still in active development when Aegisub started, and that competition probably helped both programs grow faster - I know that Aegisub did benefit from it! This program made fansubbing in UNIX systems a possibility, and solved many of the problems from the older tools. However, it suffered from an unusual GUI, that many people could not get used to.

• What happened to it? It was discontinued 3 years ago.
• Who still uses it? Many timers believe that Sabbu's audio timing mode is as good as audio timing can get, and so they stick to it. Because of that, Aegisub 2.x series basically copied Sabbu's timing mode, so now both programs are almost identical on that aspect. (Except that Aegisub supports a few extra tools.)
• Why was it important? It was the first time that an ABGPSS was developed following modern trends and it was, for a while, the only option that UNIX fansubbers had.

So the situation now is that Aegisub has nothing to compete against. I do not deny that this is somewhat frustrating - many people claim that the entire fansubbing community is driven by fierce competition between groups, and the same holds true of its tools.

Sure, Subtitles Workshop does many of the things that Aegisub does - but it does many essential things very poorly, and has horrible support for ASS. Certainly, there are specific tools (many kept "in house" by paranoid fansubbers who actually believe that they have much to gain from that practice) to do many tasks, especially karaoke. Even SSATool is being incorporated into Aegisub ever since its developer joined our staff. But I miss the thrill of having a real, actively-developed tool to compete against.

Since the dawn of time (since before I started Aegisub in June 2005, that is), there have been rumors that a certain fansubber has been working on a certain fansubbing tool whose ultimate goal would be to replace Medusa (even the name implies that). Well, Medusa has, I believe, been replaced. Perhaps there is still hope for some fun game in the back stage of the community?

Maybe it's only natural that such projects would eventually die out - Sabbu was the only open-source amongst them, but, even then, kryptolus was the only developer. I hope that Aegisub survives for as long as subtitles and fansubbers are around, but I have to keep in mind that, statistically speaking, the odds aren't in my favor...

That said, remember that Aegisub is a free project - if you develop tools for the fansubbing community and would like to join our staff, we will always welcome developers who prove themselves capable of helping us. Ultimately, the goal of the Aegisub project is to be THE tool for all subtitling needs in the anime community.

Read More...