[BUG] Two output files produced when using sects option and ttxt output format #710

New Issue

claunia · 2026-01-29T16:51:46Z

claunia commented

2026-01-29 16:51:46 +00:00

Originally created by @dcwar on GitHub (Aug 3, 2022).

CCExtractor version: {0.94}

In raising this issue, I confirm the following:

I have read and understood the contributors guide.
I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present.
I have checked that the issue I'm posting isn't already reported.
I have checked that the issue I'm porting isn't already solved and no duplicates exist in closed issues and in opened issues
I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
I have used the latest available version of CCExtractor to verify this issue exists.
I have ticked all the boxes in this section and to prove it I'm deleting the section completely to remove boilerplate text.

Necessary information

Is this a regression (i.e. did it work before)? {YES/NO} YES, this behavior was not present in 0.88
What platform did you use? {Window/Linux/Mac} MAC
What were the used arguments? ccextractor INPUT.ts -in=ts -out=ttxt -sects -o OUTPUT.txt

Video links

Can provide private example if required (I do not own the copyright on these broadcasts).

Additional information

When making timed text transcripts with the -sects option from ATSC 1.0 broadcasts, CCextractor will not only produce an OUTPUT.txt file, it will also produce an OUTPUT.pX.svcYY file, where X and YY are numbers derived from the input file. That second transcript contains the same source information, but expressed in a different output format / presentation.

In this respect, CCextractor's unexpected production of a second, non-specified file has changed between 0.88 and 0.94, and seems neither expected or correct.

Originally created by @dcwar on GitHub (Aug 3, 2022). CCExtractor version: {0.94} # In raising this issue, I confirm the following: - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present. - [x] I have checked that the issue I'm posting isn't already reported. - [x] I have checked that the issue I'm porting isn't already solved and no duplicates exist in [closed issues](https://github.com/CCExtractor/ccextractor/issues?q=is%3Aissue+is%3Aclosed) and in [opened issues](https://github.com/CCExtractor/ccextractor/issues) - [x] I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion. - [x] I have used the latest available version of CCExtractor to verify this issue exists. - [x] I have ticked all the boxes in this section and to prove it I'm deleting the section completely to remove boilerplate text. # Necessary information - Is this a regression (i.e. did it work before)? {YES/NO} YES, this behavior was not present in 0.88 - What platform did you use? {Window/Linux/Mac} MAC - What were the used arguments? `ccextractor INPUT.ts -in=ts -out=ttxt -sects -o OUTPUT.txt` # Video links * Can provide private example if required (I do not own the copyright on these broadcasts). # Additional information When making timed text transcripts with the -sects option from ATSC 1.0 broadcasts, CCextractor will not only produce an OUTPUT.txt file, it will also produce an OUTPUT.pX.svcYY file, where X and YY are numbers derived from the input file. That second transcript contains the same source information, but expressed in a different output format / presentation. In this respect, CCextractor's unexpected production of a second, non-specified file has changed between 0.88 and 0.94, and seems neither expected or correct.

claunia added the GSOC-2023 label 2026-01-29 16:51:46 +00:00

claunia closed this issue

2026-01-29 16:51:46 +00:00

claunia commented

2026-01-29 16:51:47 +00:00

@PunitLodha commented on GitHub (Aug 22, 2022):

The file with .pX.svcYY extension is for CEA 708 subtitles, and the other one is for CEA 608 subtitles.
Earlier, 708 subs were extracted only if the -svc flag was passed. In 0.94, this behavior was changed and both 708 and 608 subs are extracted by default, as mentioned in the change log here, https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT#L14
Though I can understand, the changelog isn't clear that 2 files will be produced by default.

@PunitLodha commented on GitHub (Aug 22, 2022): The file with `.pX.svcYY` extension is for CEA 708 subtitles, and the other one is for CEA 608 subtitles. Earlier, 708 subs were extracted only if the `-svc` flag was passed. In 0.94, this behavior was changed and both 708 and 608 subs are extracted by default, as mentioned in the change log here, https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT#L14 Though I can understand, the changelog isn't clear that 2 files will be produced by default.

claunia commented

2026-01-29 16:51:47 +00:00

@PunitLodha commented on GitHub (Aug 22, 2022):

This is how it works now,

708 -svc and field 1(i.e. 608) -1 are enabled by default
if no params are provided:- extract whatever is available, if both(708 and 608) are available then extract both
If only -1/-2/-12 is provided:- extract only 608 subs
if only -svc is provided:- extract only 708 subs
if both -1/-2/-12 and -svc are provided:- extract both 608 and 708

I'll add this information maybe in the changelog, or the ccextractor --help command

@PunitLodha commented on GitHub (Aug 22, 2022): This is how it works now, - 708 `-svc` and field 1(i.e. 608) `-1` are enabled by default - if no params are provided:- extract whatever is available, if both(708 and 608) are available then extract both - If only -1/-2/-12 is provided:- extract only 608 subs - if only -svc is provided:- extract only 708 subs - if both -1/-2/-12 and -svc are provided:- extract both 608 and 708 I'll add this information maybe in the changelog, or the `ccextractor --help` command

claunia commented

2026-01-29 16:51:48 +00:00

@dcwar commented on GitHub (Aug 22, 2022):

Thank you for the clarifications about the changes in ccextractor's operation. I greatly appreciate it.

Since extracting both 608 and 708 by default is a fundamental change to how ccextractor operates, and is completely unexpected behavior when compared to the operation of previous versions, it would seem wise to add this information to the usage information (both in the --help output, and elsewhere). The single line in the changelog doesn't really address the full extent and magnitude of this set of changes.

@dcwar commented on GitHub (Aug 22, 2022): Thank you for the clarifications about the changes in ccextractor's operation. I greatly appreciate it. Since extracting *both* 608 and 708 by default is a fundamental change to how ccextractor operates, and is completely unexpected behavior when compared to the operation of previous versions, it would seem wise to add this information to the usage information (both in the --help output, and elsewhere). The single line in the changelog doesn't really address the full extent and magnitude of this set of changes.

claunia commented

2026-01-29 16:51:48 +00:00

@cfsmp3 commented on GitHub (Dec 31, 2025):

Closing this there's no action pending here.

@cfsmp3 commented on GitHub (Dec 31, 2025): Closing this there's no action pending here.

claunia referenced this issue

2026-01-29 17:17:02 +00:00

[PR #710] Modified formatting and did some changes- imp to merge #1539

Sign in to join this conversation.