Closed Captions and ProjectX

[sambat]

My Hauppauge card saves in .tp format.
These particular files contain (NTSC) closed captions.
I can partially extract them using CCExtractor - but it chokes after a short time (the partial .srt file is saved ok).

Using ProjectX to demux all the streams, I don't get a .srt file for the CC.

The log file seems to indicate the CC ("Subpict" ???)are not present.
My question is:does ProjectX detect Closed Captions or is the supic reference alluding to something else.

+> Input File 0: 'D:\Beyond TV Videos\Mentalist-2009-03-24-0.tp' (10,930,573,612 bytes)
-> Filetype is TS (generic PES Container)
-> demux
-> Service ID 0x1
-> PMT 0x30 refers to these usable streams:
Video:
PID: 0x31
Audio:
PID: 0x34(AC-3)(eng)[PD]
Teletext:
n/a
Subpict.:
n/a

[usually_quiet]

Your log says subpict is not applicable. Unlike subtitles, CCs are not present as a subpict, and are not human-readable. They are encoded in line 21 of the VBI. That's why you need CCExtractor, and can't simply demultiplex.

[sambat]

Thank you.
Back to square one.
CCExtractor chokes on the .tp stream, so I guess I am out of luck.

[usually_quiet]

I don't work with .tp files, so I don't know what kind of elementary video stream results from demultiplexing, but have you tried using CCExtractor on the demuxed video file from the .tp? It may work better, assuming the elementary video file is an m2v.

[sambat]

I tried and it processes the file ok, but no subs.

[usually_quiet]

Are you sure it is an NTSC SD transport stream and not an ATSC HD transport stream? Either way, you might look to see if there is a support forum for CCExtractor at sourceforge.net, or maybe there is an email address for the author.

[ccguy]

Yes, the author would very much love to these one of those files that make ccextractor choke

[sambat]

The file is 10GB and extraction stops at the 12 minute mark (17% processed).

[usually_quiet]

Judging by the log, it looks like the .tp file contains one or more errors. Do you have any reason to think this is not the case? Has CCExtractor always failed when you tried it for other HD TV recordings?

Whether the errors are real or not, I think the only ones who could help you are the developers. I don't know of a way to split a .tp file in two past the point where the error is located so you could try extracting the CCs from the two pieces separately.

[sambat]

I can record another program later and test CCExtractor on it - but it was this particular episode that I wanted - and ProjectX is the program I want to use to demux the files.

[sambat]

I tried CCExtractor on another .tp file without a problem.

I then took the original problem file and opened it in HDTV2MPEG2 and saved as a .ts file.

Opened the new .ts file with CCExtractor and recovered the captions without a hiccup - whatever was in the .tp file was fixed in the .ts file.

I haven't come across anything yet for ProjectX that would suggest that it works on anything other than Teletext files.

[usually_quiet]

I haven't come across anything yet for ProjectX that would suggest that it works on anything other than Teletext files.

Teletext isn't used in N. America, so you are correct. Project X will not be useful for anything but demultilexing .tp files from ATSC broadcasts. Other programs would be needed for extracting either 608 (analog) or 708 (digital) closed captions. As far s I know, there is nothing like CCExtractor available yet that extracts digital closed captions.

Well, at least you found a soulution. I thought about conveting the .tp to a .ts too, but I fgured it might strip the closed captions, since they did not survive demultiplexing.

[ccguy]

Other programs would be needed for extracting either 608 (analog) or 708 (digital) closed captions. As far s I know, there is nothing like CCExtractor available yet that extracts digital closed captions.

ccextractor is already able to parse 708 data just fine. In fact, if you use the -708 switch you can see all the text on the console.

It doesn't export to .srt yet, but it's coming. Not in the next version (0.54) but probably the next one.