Invitation to discuss with the MCF development team about subtitles specs

[ChristianHJW]

Hi there,

some of you may know me, i am mod here in the 'New A/V formats' section.

While one of the new formats, Ogg ( .ogm ), does support subtitles already, thanks to Tobias Waldvogel, some members of the MCF development team are still uncertian about the quality of the subtitles specification for MCF ( Multimedia Container Format ).

The specs are here : http://mcf.sourceforge.net/trackt.htm#0x11

Besides PNG as graphical format the specs will currently also allow unicode ( UTF-8 ), but not vobsub.

I'd love to get feedback from you subtitles experts here : what is the best subtitles specs we could go for ( ease of use, size, quality, etc. ) ?

If you'd like to discuss live with us on this subject, please join us on IRC, openprojects, #mcf and talk to our developers there. Thanks for your support.

Christian

[ChristianHJW]

No reply ? So, what you guys think about SSA ?

http://forum.doom9.org/showthread.php?s=&threadid=24437

Thanks for your help.

Christian

[dblmask]

I have been on the subject for quite some time and found that the best subtitles choices has to have:

0. Text over Graphics. We want to save space, it's a valuable thing. Don't get LAZZY. OCR ripping is boring, hard and takes time. But is the BEST. don't listen to those who complains: "don't wanna make my homework". Since the people become lazy for programming we got Gb progs that runs super-slow. Compare the prog made before 1995, pure DOS gems. they work ligthing faster than their counterparts today, ok now are "nicer", but faster ?? optimized ??? hell, no. Don't let the lazzy-sick catch this beautifull art. Images are easy, but we need to be REALLY optimized, we need tho work for that, that will cost us, yeah, but it's worth the WORK. besides, we can "correct" the text streams to fit our "local" languaje. ie: Spain spanish <> SudAmerican spanish.

1. Time format over Fram Format. So we can use the subs without worring if the movie is at 25fps or 29.97fps. Somethig like subrip97, the .srt format

2. format fonts over plain text. So we can put color fonts where is music, italics when people talks withou been seen. Something like MicroDVD Sub formats, which lets you choose the color anf format in each line

3. been able to put the subs in ANY place, not just the bottom. Like the microDVD sub format, which again, lets you put individual subs in any place of the windows, just putting the x,y coords

4. Different streams for different languajes over one stream, multiple languajes. It's better, because most times, when we are editing the subs, we are concentrating in only one languaje. but we also have the problem that when we are TRASNLATING the subs, we want to see the counterpart languaje to mek the translation. This is a especial case, but only for editing. When playing, I preffer diferrent streams.

So basically is like the Tobias format, with more tags, like font format, color and pos. Now that I think more ;) we can use the vb code ! like when we post in here.

[ b ] = bold
[ color= ###### ] = change color
[ i ] = italics
[ x,y ] = position maybe ?

PD: I think the format must suggest the Font Name, but not force the use of that Font, because some systems migth not have them or users don't want to use them.

[bill_baroud]

hmm, have you think to the edit tools ?


well, if you got new specs, that's a good idea, but do editing in text edit, it's a lot of pain (well, i sub anime, so it's not the same case as a ripping sub from a DVD).

To have a implementation of SSA (or Advanced SSA perhaps ;) ) would be really great, because
1. we have already a powerful tool to edit our subs,
2. the subs always looking good and are not dependant of the encoding (but there is always the "special" fonts problem ...)


after that, it's just a selfish wish from myself, i know that the MCF/ogg developpers are human (hmm, really ? ;) ) and don't really have the time/energy to do it.

[N-Bomb]

I completely agree with SSA.

It's flexible, functional, and the results are good-looking.

If you take VirtualDub's implimentation in the subtitle filter, you know what I mean. You can position the subs, change colours, fonts, sizes, styles, etc...

However, I'd think the rendering engine for these would have to be in the decoder or DSF maybe? Because you'll need the subs to scale for full-screen, otherwise size and alignment could get thrown off.

Also, the ability to embed fonts in the .MCF? That way you're not limited to the standard Windows fonts (comic sans, arial, etc) and having to worry how your subs translate over to other systems.



-Nick

[midi]

Almost everyone I know who does live action movies uses VobSub idx/sub/rar. It is about as direct and hassel free as possible. Its open source, or at least available source, and just ripped from the dvd data anyway. Why would you not support it in addition to whatever else your planning? Some sort of vindictive, lets make them use our own format instead of what works, plan? ^^ The file sizes for any subtitle method out there are so small that I would focus on usability and compatibility rather than some ideal compression that requires users to jump through hoops or somone to write a whole new slew of subtitle utilities. Neither is likely to happen at any great rate.

On the other hand. For myself, doing mostly super high quality anime backups in divx/avi stored on dvd-r, I use SSA. Some DVD rippers use this or another script format to rise above those ugly DVD subs as well. It would take an enormous amount of work to make your own script format and editing tool that could match what SSA does. Timing from wave graphs, karaoke/sing-along subs, fonts and embedding, animation, placement, an editor that can manage and apply all these things effectively and quickly, and most important of all its already well know and used. Also, again, I've seen SSA rendering implemented in available source code in the virtualdub subtitler plugin thats available and probably in direct vobsub as well.

SSA is actually terribly supported out there in the video formats available and is still used by almost every digital anime fansubber due to its abilities. What I currently do is render the SSA to bitmaps using MaestroSBT, author them as a DVD, rerip it into idx/sub/rar, and finally mux into my finished AVI. Encoding the nice sharp rendered text straight to video is bad for compression and clearness and prevents you from turning them on and off. Muxing the SSA into the file and using direct vobsub SSA rendering is problematic as well as windows allows you to change font sizes on a system wide basis among other things. Rendering the SSA at play time therefore requires computer specefic tweaking that gets really annoying. I just want to play the file when I'm done, eh? So your PNG method originally mentioned may, in the end, help me more than either of the two aboce formats I'm pushing. Still I would prefer you just support Maestro DVD format subs or similar, basically bitmaps, over PNG. Simply because we already have tools using this format. Still, there is nothing saying you can't support multiple formats or push on with your own plans. Making your format compatible with whats out there, be it vobsub or ssa or dvd authoring, seems much more usable to me, however.

[Yusaku]

From my point of view, I think it would be best to avoid direct SSA, because as said it is computer dependent (not everyone has all my fonts installed, not to mention asian fonts...), but IMHO best would be to enhance a bit on ASS format.

It can already store polygons, it'd just need a "bit" of size/speed optimizations. And when displaying in DVobSub/Subtitler (rasterizer.cpp), all the fonts are converted to vectors before rasterizing anyway, so it should not be that hard to make SSA (or other text)>Polygonized ASS converter (and maybe abandon ASS format and just store polygons in some binary form...).

And also do not forget other platforms - going the SSA way will mean next to nil possibility of linux/mac or even standalone black box port, while it is not THAT hard to display beziers.

If you want maximum compatibility, which should be IMHO the goal, you have to abandon even remote possibility of unrendered text leaking into the format... it means that it WILL mess up on different codepages (linux fans from east europe having to convert subs code page before each movie will aggree with me...), on absent fonts etc. Of course it means that the end product will be uneditable (or that you'll have to OCR it), but that is the price to pay, not to mention that I think that most subtitles creators (fansubbers etc.) will be happy about that ^_^.

IMHO the goal should be to create format that will be easy to convert subtitles INTO, but once they're done, you can leave them and just play the output... If the creator wishes you to edit them, he can easily include the source SSA/VobSub/whatever source, but the format itselves should be as much hasslefree and compatible as possible.

Gabest, if you're reading this thread - what is your opinion? You speak from quite an experienced point of view :)

[Yusaku]

another possibility how to get in text could be SSA, but making the appending of fonts (the .TTF files) not optional but mandatory. This could easily make ~100MB subtitles with unicode fonts though (japanese ^_^), not to mention that it would be just impossible to make truetype implementation in any blackbox MCF player

[BlackSun]

SSA and PSB2 (that I am creating with Toff)

PSB2 will be a sort of SSA but much easier

[Tri]

I don't understand what's the problem with different fonts in ssa-scripts. SSA supports embedded fonts so maybe the muxer could check whether the fonts used are embedded or not before muxing.

[Yusaku]

yeah, but
1) AFAIK current subtitler implementations (VDub+TextSub) ignore embedded objects (not just fonts, everything!)
2) it would be I think quite complicated to display Truetype fonts on linux/mac (not sure, I don't have experience with those...), and just plainly impossible on any blackbox (i.e. if/when there ever will be working Xbox/PS2 DivX player, do not even think about it supporting TT fonts... in SSA subs or wherever else)

<edit>
Ad outline storing vs. copyrights: I think that as long as it is impossible to restore the font back (which certainly is), it is OK... look at .PDF files - everyone is including the fonts in them (acrobat reader comes with just a basic set of ~5 fonts), and there is no legality problems with PDFs I've heard of....

And acrobat quite often includes WHOLE font in the PDF, not just used chars.
</edit>
<edit number="2">
...and that's not mentioning the size of unicode fonts... I bet that some fansub releases would be ~100MB in size with embedded fonts :(
</edit>

[yoshikunai]

Just my two cents:

The editing tools, general familiarity with, and flexibility of SSA make it my first choice, BUT:

For a serious long-term solution, what Yasuku has said about an enhanced ASS format (polygons) sounds reasonable (and forgive me, I really don't know anything about this format), as long as it can be converted to accurately, and display everything an SSA can. A more universal compatibility would be one of the main reasons for choosing this, I suppose.

Polygons would be the only viable solution for japanese text besides hard-subbing in the japanese text, I think (or using .png's or whatever in the subs). I'm curious, though, how much space would, say, 24 minutes of subtitles in polygons take?

EDIT: Another little opinion for polygon subs: I think that some fansubbing groups might be turned off to a muxed textual format because of how easy it might be for someone to get their full scripts from the video file through demuxing. A format like this would want to be easily converted to, but not easily converted from.

[primitive]

@Yusaku: Umm, our fansub group uses vdub + subtitler plugin for SSA subtitle processing on our fansubs. It certainly doesn't ignore embedded objects.

As for right now, SSA is the standard. However, if you've ever used SubStation Alpha, you'll know that it's getting OLD. Hell, on the download site there's still a download for a 16-bit version of SSA for Windows 3.1!

The most important things to a subtitle format for me would be the following:

1. Software support. No matter what subtitle spec you pick to implement, if the software isn't out there for making and editing subtitles in this format no one's going to use it. This means you need a subtitle ripper that can save subtitles in your format, a subtitle editing utility (akin to SSA), and a playback filter that can display rendered subtitles over a video in arbitrary format (like using vobsub to superimpose subtitles which are in a separate file over video).

2. Textual subtitles. A subtitle format is totally worthless to me if I can't edit the subtitles! If you really need to, you can render the textual subtitles to bitmaps / PNGs / whatever before you multiplex them into the final file; however, I want to be able to take an arbitrary MCF, demultiplex the subtitles, edit them, remultiplex them, and have a valid, viewable file.

3. Use the standards! There have been a million subtitling and captioning standards. If you use an existing XML standard, you basically get lots of compatibility and extensibility that you never knew you had all for free. It looks to me that you could throw together a few SMIL modules and get a boatload of potential functionality.

http://www.w3.org/TR/smil20/

/two_cents

-p

[Nightweaver]

Just a couple things I think is important in subs:

1. Size
For me at least (I know some people have slightly different needs), the subs aren't the main part of a movie, just a nice feature to have. Because of this I like them to take up as little room as necessary. This is one of the main reasons I like plaintext subtitles (ala SubRip)

2. Broad character support
This is one place where SubRip is lacking ... there's a lot of characters that appear in movies and can't be translated properly. I only rip english subs, so the only one I really miss is the musical note that a few movies use to indicate a song. Of course, this applies for other languages, as well.

3. Special text effects
These are handled to an extent by Tobias' implementation, with the html-like syntax he uses. Bold, italics, underline and (changing) colour are all pretty important.

1 and 2 could be implemented fairly easily if the subs follow an XML-ish format and allow you to specify a default character set, and for places they're different, have the ability to specify the character is in a different character set. 3 gets a little tricky when dealing with colour that changes within a single subpicture, since there's no obvious way (to me at least) to get that to work without the subs needing a lot more space, but for the situations you need those effects I guess the subs are much more important so it's tolerable to sacrifice more space to them. XML is nice too, since you can (if you're willing to sacrifice some processing power) compress them so they take even less space, and then decompress them on the fly. (Hooray for text compression!)

That does seem like an awful lot of work to me, though, even if it is quite an elegant solution. 'Re-inventing the wheel' is the phrase stuck in my head now.

Oh, and then there's the problem of dealing with the different character set specifications, fonts, etc. Nonetheless, it's an idea.

Hmm ... looks a fair bit like the existing spec, now that I look. Just a little more 'special character' friendly.