Converting SCC/Scenarist to SubStation Alpha while preserving positioning info

[yukichigai]

The title sums it up, but I'm trying to find a way to convert Closed Caption information from Scenarist (SCC) to SubStation Alpha (SSA/ASS) or any other commonly supported format that includes X-Y positioning information. Every utility I've tried either does not preserve positioning information at all, or "positions" the text by adding leading whitespaces and hard returns, which are easily thrown off by font and font size differences between devices.

Also I should specify I'm looking for a way to do this without shelling out a few hundred on a piece of software. Free if at all possible.

EDIT: I'm hoping for a text-based format (SSA, VTT) but image-based (PGS, IDX/SUB) is fine as long as the positioning is preserved.

[Emulgator]

Text-based subtitles like SSA, ASS by design do not store positioning other than MarginL, MarginR, MarginV, if at all.
CC positioning you will achieve only within Image-based formats.

How ? This can be derived from my following writeup:
CC are transmitted separately and overlaid on display.
Zilog Z86229 NTSC Line 21 CCD Decoder (DIP18-300)
Can decode and overlay for 525- and 625-line systems
NTSC fH = 15,734.265kHz tH=63.555µs
Generated Output:
The active line width is divided into 48 cells, each giving total width for 16 dots.
Character Cell Width: 1.324 µs (tH/48)
Dot: 1/768*fH -> Dot Period: 82.75ns (12.0839MHz)
We sacrifice 2x 7 cells on the sides and use only 34 cells width for the CC canvas.
Box Row Width: 45.018µs 34chars = 34/48*tH
On the sides we further sacrifice 2x 1 cell width for canvas border and yield 32 cells net width for filling with characters.
Char Row Width: 42.370µs 32chars = 2/3*tH
Character Cell: 16x26 dots (2+Character+2, top+2 bottom+6.
The 2px headroom is never used, underlengths will use the 6px Footroom fully
Normal Capital Character: 12x18 dots, stroke thickness: 2 dots

Vertical Rendering is per field upon scan lines 43..237 of 262 (195 scan lines per field in total)

FCC: Caption data can appear in any of the 15 display rows, but a single caption may consist of no more than 4 rows.
Pop-on: After the buffering is completed: 1 complete caption is rendered
Paint-on: As characters are buffered, they are rendered one by one.
Roll-up: As lines are buffered completely, the old line is shifted up and the new one becomes base line,
up to 4 rows are filled, then the upper is deleted as the next moves up.
The Z86229 can display single captions spanning up to 8 rows.

0x00: x is row number. 8 is centered, there are 7 rows above (195 scanlines) and 7 rows (195 scanlines) below.
The canvas height would be 390 scanlines, 81,25% of the total 480 scanlines.
Using all video lines would yield 18,46 cell rows height, so there is headroom/footroom ~1 3/4 cell height each.
The canvas width would be 34/48 total (510 video pixel, 70,83% of the total 720 video pixel).
Characters can use 2/3 total (480 video pixel width, 66,66% of the total 720 video pixel).
Per side 1/6 width stays empty. Top and Bottom: 9/96 (9,375%) height stay empty.

[yukichigai]

Text-based subtitles like SSA, ASS by design do not store positioning other than MarginL, MarginR, MarginV, if at all.

ASS allows for pixel-specific text placement and even image placement. It was designed for use in Anime fansubs where text overlays sometimes need to be VERY precise. It's capable of storing positioning info... though I can't speak to how complicated it is to do that.

WEBVTT on the other hand is much easier to do simple positioning using the "Line" and "Position" (and possibly "Size") parameters. The W3 Community Group even has a draft document discussing transitioning from CEA-608/708 to WEBVTT. (https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html) It's quite doable, I just can't find a tool which does it.

EDIT: Also, the WEBVTT spec was modified to store Position/Line/Size information as a Double rather than a Long specifically to enable conversion from CEA-608 to WEBVTT while preserving position information (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19836).

[cubicibo]

WebVTT specifies a lot of things but most players won't process anything past the usual tags and metadata found in SRTs. You need an entire web browser back-end to support it all (and browsers don't even support the full spec regardless). It's okay for streaming services watched on a PC, and completely unusable with anything else.

[Emulgator]

It's capable of storing positioning info... though I can't speak to how complicated it is to do that.
True. One can override all 3 margins per event, and \pos(<X>,<Y>) is there as well. Not complicated at all, this should solve it.

[yukichigai]

WebVTT specifies a lot of things but most players won't process anything past the usual tags and metadata found in SRTs. You need an entire web browser back-end to support it all (and browsers don't even support the full spec regardless). It's okay for streaming services watched on a PC, and completely unusable with anything else.

MPC, MPV, and VLC all seem to support most WebVTT tags. Not sure about Jellyfin, Plex, Emby and so on. And yeah, set-top players are always a mixed bag.

Ultimately I'm more concerned with the positional info being preserved in whatever format it's converted to so that something that IS fully compliant will display them as intended. A subset of players not supporting spec fully (or properly) is to be expected. Hell, some TVs and set-top players don't even parse CEA-608 positioning info correctly as it is.

[yukichigai]

True. One can override all 3 margins per event, and \pos(<X>,<Y>) is there as well. Not complicated at all, this should solve it.

So it's achievable. Neat.

Next hurdle though: is there any tool that already does this? I mean it's not like I've never written code myself, but I'd rather not re-invent the wheel, y'know?

[yukichigai]

Argh, alright, fine, I'll make my own. I've gotten my hands on the source code for McPoodle's CCASDI script and I'm adapting it to output to various formats with positioning derived from the Closed Caption positioning information. So far it's working alright, though certain captions are processed by the script as though they start on Line 1 when they're clearly Line 14 or 15. Not sure if that's my issue, an existing problem, or something with the SCC files I'm working with. In any case, I'm on my way. I'll post again when I have something usable.

EDIT: It's the version of CCExtractor I'm using, which has a bug that drops positioning info on some lines when outputting to SCC. Outputting to Grid 608 format (*.g608) shows the correct positioning however, so it's some sort of encoding issue when CCExtractor saves the SCC file, not an issue with decoding the captions themselves. Given that, I think I'm actually going to add an option to convert from Grid 608.

EDITx2: Alright, I have a functioning conversion from SCC and g608 to ASS and SSA. Still need to dial in the font scaling and positioning, and I'm going to go for a slightly different approach to ensure that subtitles are at least centered at the location they're supposed to be if something goes wonky with the font used by the player. I've also only done basic stuff for WebVTT and I haven't even attempted adding positioning info to SAMI (which is actually possible, believe it or not). I should have something release-worthy this weekend or so.

EDITx3: Okay, got something functional, at least for converting SCC and g608 to ASS and SSA. WebVTT needs some work, and SAMI support is theoretical: IN THEORY I'm outputting compliant subtitles, but I can't even find a player that parses the specification example SAMI subtitles properly. I'll post a release thread once I get a basic Readme up on github.

EDITx4: Posted. yyC2Swp has been released to the world. Huzzah.

[borgdm]

I had the same problem, it works best with Aegisub in combination with CCExtractor, because the positioning is preserved much better. Although it is not quite perfect, it is really useful for the free setup.

Mini Militia (https://www.minimilitia.mobi/) App Lock (https://www.applock.ooo/)

[Emulgator]

yyC2Swp has been released to the world. Huzzah.
And many thanks for going through that !