[question] Badly corrupted .SRT file from TiVo units #31

New Issue

claunia · 2026-01-29T16:33:16Z

claunia commented

2026-01-29 16:33:16 +00:00

Originally created by @dwhe on GitHub (Jun 24, 2014).

Originally assigned to: @rkuchumov on GitHub.

I hope this question here is permissible - I am having trouble with subtitles generated by ccextractor (although I have determined that ccextractor is likely NOT the cause) and could use some guidance on where to take this for resolution.

I have been observing badly corrupted subtitles/caption files being generated from recordings downloaded from TiVo lately - I have been using Tivo + ccextractor as part of my workflow for years, and while there were frequently the occasional corrupted line (there are almost always about 4 to 5 dialogue lines corrupted), it has recently become very bad.

Lately the corruption issues with my TiVo downloads have been so bad that nearly every line (99% percent) is corrupted. The corruption sometimes appear as if part of one (left) half of the subtitles are somehow overlapping the other (right) half.

Here is an example of the .SRT output:

00:04:37,077 --> 00:04:38,377
SOUNDS GRE!                     

33
00:04:38,379 --> 00:04:40,545
     AND CAN I PRACTICE         
     MY SPANI.                  

34
00:04:57,797 --> 00:04:59,765
WHAT DO YOU THINK?              

35
00:05:00,566 --> 00:05:03,035
            OF COUE! IRS'D LOVE 
            TO GO TOEXIC MO!    

36
00:05:03,037 --> 00:05:04,403
                    YE

I have determined that the issue is NOT a result of the decoding/encoding/ccextractor process (which was my belief previously) as I have found that the corrupted captions appear this way on the .tivo video file itself.

I previously surmised, with my limited understanding of ccextractor, that perhaps the problem was related to the analog vs. digital captions on the video and that ccextractor was possibly pulling captions from "the wrong one", however, from my efforts in reading up on this, it appears that this hypothesis is unlikely to be correct.

I welcome anyone's help in identifying why this is happening and where I should bring this for further resolution.

Originally created by @dwhe on GitHub (Jun 24, 2014). Originally assigned to: @rkuchumov on GitHub. I hope this question here is permissible - I am having trouble with subtitles generated by ccextractor (although I have determined that ccextractor is likely NOT the cause) and could use some guidance on where to take this for resolution. I have been observing badly corrupted subtitles/caption files being generated from recordings downloaded from TiVo lately - I have been using Tivo + ccextractor as part of my workflow for years, and while there were frequently the occasional corrupted line (there are almost always about 4 to 5 dialogue lines corrupted), it has recently become very bad. Lately the corruption issues with my TiVo downloads have been so bad that nearly every line (99% percent) is corrupted. The corruption sometimes appear as if part of one (left) half of the subtitles are somehow overlapping the other (right) half. Here is an example of the .SRT output: ``` 32 00:04:37,077 --> 00:04:38,377 SOUNDS GRE! 33 00:04:38,379 --> 00:04:40,545 AND CAN I PRACTICE MY SPANI. 34 00:04:57,797 --> 00:04:59,765 WHAT DO YOU THINK? 35 00:05:00,566 --> 00:05:03,035 OF COUE! IRS'D LOVE TO GO TOEXIC MO! 36 00:05:03,037 --> 00:05:04,403 YE ``` I have determined that the issue is NOT a result of the decoding/encoding/ccextractor process (which was my belief previously) as I have found that the corrupted captions appear this way on the .tivo video file itself. I previously surmised, with my limited understanding of ccextractor, that perhaps the problem was related to the analog vs. digital captions on the video and that ccextractor was possibly pulling captions from "the wrong one", however, from my efforts in reading up on this, it appears that this hypothesis is unlikely to be correct. I welcome anyone's help in identifying why this is happening and where I should bring this for further resolution.

claunia closed this issue

2026-01-29 16:33:16 +00:00

claunia commented

2026-01-29 16:33:17 +00:00

@cfsmp3 commented on GitHub (Jun 24, 2014):

If possible, generate a .bin file (they're quite small) and post it here -
that will allow us to see if the problem is with the 608 decoder or
somewhere else.

Anyway, the CC display OK in the TV when playing this recording on tivo?

On Mon, Jun 23, 2014 at 6:46 PM, dwhe notifications@github.com wrote:

I hope this question here is permissible - I am having trouble with
subtitles generated by ccextractor (although I have determined that
ccextractor is likely NOT the cause) and could use some guidance on where
to take this for resolution.

I have been observing badly corrupted subtitles/caption files being
generated from recordings downloaded from TiVo lately - I have been using
Tivo + ccextractor as part of my workflow for years, and while there were
frequently the occasional corrupted line (there are almost always about 4
to 5 dialogue lines corrupted), it has recently become very bad.

Lately the corruption issues with my TiVo downloads have been so bad that
nearly every line (99% percent) is corrupted. The corruption sometimes
appear as if part of one (left) half of the subtitles are somehow
overlapping the other (right) half.

Here is an example of the .SRT output:

00:04:37,077 --> 00:04:38,377
SOUNDS GRE!

33
00:04:38,379 --> 00:04:40,545
AND CAN I PRACTICE
MY SPANI.

34
00:04:57,797 --> 00:04:59,765
WHAT DO YOU THINK?

35
00:05:00,566 --> 00:05:03,035
OF COUE! IRS'D LOVE
TO GO TOEXIC MO!

36
00:05:03,037 --> 00:05:04,403
YE

I have determined that the issue is NOT a result of the
decoding/encoding/ccextractor process (which was my belief previously) as I
have found that the corrupted captions appear this way on the .tivo video
file itself.

I previously surmised, with my limited understanding of ccextractor, that
perhaps the problem was related to the analog vs. digital captions on the
video and that ccextractor was possibly pulling captions from "the wrong
one", however, from my efforts in reading up on this, it appears that this
hypothesis is unlikely to be correct.

I welcome anyone's help in identifying why this is happening and where I
should bring this for further resolution.

—
Reply to this email directly or view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/53.

@cfsmp3 commented on GitHub (Jun 24, 2014): If possible, generate a .bin file (they're quite small) and post it here - that will allow us to see if the problem is with the 608 decoder or somewhere else. Anyway, the CC display OK in the TV when playing this recording on tivo? On Mon, Jun 23, 2014 at 6:46 PM, dwhe notifications@github.com wrote: > I hope this question here is permissible - I am having trouble with > subtitles generated by ccextractor (although I have determined that > ccextractor is likely NOT the cause) and could use some guidance on where > to take this for resolution. > > I have been observing badly corrupted subtitles/caption files being > generated from recordings downloaded from TiVo lately - I have been using > Tivo + ccextractor as part of my workflow for years, and while there were > frequently the occasional corrupted line (there are almost always about 4 > to 5 dialogue lines corrupted), it has recently become very bad. > > Lately the corruption issues with my TiVo downloads have been so bad that > nearly every line (99% percent) is corrupted. The corruption sometimes > appear as if part of one (left) half of the subtitles are somehow > overlapping the other (right) half. > > Here is an example of the .SRT output: > > 00:04:37,077 --> 00:04:38,377 > SOUNDS GRE! > > 33 > 00:04:38,379 --> 00:04:40,545 > AND CAN I PRACTICE > MY SPANI. > > 34 > 00:04:57,797 --> 00:04:59,765 > WHAT DO YOU THINK? > > 35 > 00:05:00,566 --> 00:05:03,035 > OF COUE! IRS'D LOVE > TO GO TOEXIC MO! > > 36 > 00:05:03,037 --> 00:05:04,403 > YE > > I have determined that the issue is NOT a result of the > decoding/encoding/ccextractor process (which was my belief previously) as I > have found that the corrupted captions appear this way on the .tivo video > file itself. > > I previously surmised, with my limited understanding of ccextractor, that > perhaps the problem was related to the analog vs. digital captions on the > video and that ccextractor was possibly pulling captions from "the wrong > one", however, from my efforts in reading up on this, it appears that this > hypothesis is unlikely to be correct. > > I welcome anyone's help in identifying why this is happening and where I > should bring this for further resolution. > > — > Reply to this email directly or view it on GitHub > https://github.com/CCExtractor/ccextractor/issues/53.

claunia commented

2026-01-29 16:33:18 +00:00

@dwhe commented on GitHub (Jun 24, 2014):

The cc displays perfectly on the TV when playing the recording on TiVo which is why this is so frustrating.

I have raised this issue on a parallel track with the Tivo downloading/decoder app developers (cTivo and KMTTG) and one suggestion was that the videos may need to be downloaded in transport stream (.ts) format.

I tried downloading the recording as a .ts earlier today, but unfortunately running the resulting .tivo file through ccextractor with the -ts option on still resulted in a badly corrupted .srt file (but not identical to the .srt file generated with the recording run through program stream (.ps) format.

It is definitely a conundrum - as I said its clear the source file (.tivo) has bad corruption issues so its not caused by ccextractor. Something is going on during the download process.

I generated a .bin file and its 2.1 mb. How do I upload it here, or do I email it to you?

@dwhe commented on GitHub (Jun 24, 2014): The cc displays perfectly on the TV when playing the recording on TiVo which is why this is so frustrating. I have raised this issue on a parallel track with the Tivo downloading/decoder app developers (cTivo and KMTTG) and one suggestion was that the videos may need to be downloaded in transport stream (.ts) format. I tried downloading the recording as a .ts earlier today, but unfortunately running the resulting .tivo file through ccextractor with the -ts option on still resulted in a badly corrupted .srt file (but not identical to the .srt file generated with the recording run through program stream (.ps) format. It is definitely a conundrum - as I said its clear the source file (.tivo) has bad corruption issues so its not caused by ccextractor. Something is going on during the download process. I generated a .bin file and its 2.1 mb. How do I upload it here, or do I email it to you?

claunia commented

2026-01-29 16:33:18 +00:00

@cfsmp3 commented on GitHub (Jun 25, 2014):

Attach it to the ticket so it's available for everyone's reference. Thanks.

On Tue, Jun 24, 2014 at 3:35 PM, dwhe notifications@github.com wrote:

The cc displays perfectly on the TV when playing the recording on TiVo
which is why this is so frustrating.

I have raised this issue on a parallel track with the Tivo
downloading/decoder app developers (cTivo and KMTTG) and one suggestion was
that the videos may need to be downloaded in transport stream (.ts) format.

I tried downloading the recording as a .ts earlier today, but
unfortunately running the resulting .tivo file through ccextractor with the
-ts option on still resulted in a badly corrupted .srt file (but not
identical to the .srt file generated with the recording run through program
stream (.ps) format.

It is definitely a conundrum - as I said its clear the source file (.tivo)
has bad corruption issues so its not caused by ccextractor. Something is
going on during the download process.

I generated a .bin file and its 2.1 mb. How do I upload it here, or do I
email it to you?

—
Reply to this email directly or view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/53#issuecomment-47039883
.

@cfsmp3 commented on GitHub (Jun 25, 2014): Attach it to the ticket so it's available for everyone's reference. Thanks. On Tue, Jun 24, 2014 at 3:35 PM, dwhe notifications@github.com wrote: > The cc displays perfectly on the TV when playing the recording on TiVo > which is why this is so frustrating. > > I have raised this issue on a parallel track with the Tivo > downloading/decoder app developers (cTivo and KMTTG) and one suggestion was > that the videos may need to be downloaded in transport stream (.ts) format. > > I tried downloading the recording as a .ts earlier today, but > unfortunately running the resulting .tivo file through ccextractor with the > -ts option on still resulted in a badly corrupted .srt file (but not > identical to the .srt file generated with the recording run through program > stream (.ps) format. > > It is definitely a conundrum - as I said its clear the source file (.tivo) > has bad corruption issues so its not caused by ccextractor. Something is > going on during the download process. > > I generated a .bin file and its 2.1 mb. How do I upload it here, or do I > email it to you? > > — > Reply to this email directly or view it on GitHub > https://github.com/CCExtractor/ccextractor/issues/53#issuecomment-47039883 > .

claunia commented

2026-01-29 16:33:18 +00:00

@dwhe commented on GitHub (Jun 25, 2014):

I don't see any way to attach files here, so here is a dropbox link to the .bin file, if this helps.

https://www.dropbox.com/s/hpv6ua77bn93t7o/Scooby-Doo%21%20And%20the%20Legend%20of%20the%20Vampire.bin

@dwhe commented on GitHub (Jun 25, 2014): I don't see any way to attach files here, so here is a dropbox link to the .bin file, if this helps. https://www.dropbox.com/s/hpv6ua77bn93t7o/Scooby-Doo%21%20And%20the%20Legend%20of%20the%20Vampire.bin

claunia commented

2026-01-29 16:33:19 +00:00

@canihavesomecoffee commented on GitHub (Jul 10, 2014):

Hello,

would it be possible to make the .bin file available again? When trying to access it, I get an error from Dropbox...

@canihavesomecoffee commented on GitHub (Jul 10, 2014): Hello, would it be possible to make the .bin file available again? When trying to access it, I get an error from Dropbox...

claunia commented

2026-01-29 16:33:20 +00:00

@hardikchoudhary12 commented on GitHub (Mar 9, 2015):

Was the .bin file made available in some other forum?(email) Because the dropbox link still doesn't work?

@hardikchoudhary12 commented on GitHub (Mar 9, 2015): Was the .bin file made available in some other forum?(email) Because the dropbox link still doesn't work?

claunia commented

2026-01-29 16:33:20 +00:00

@cfsmp3 commented on GitHub (Mar 9, 2015):

On Mon, Mar 9, 2015 at 10:43 AM, hardikchoudhary12 <notifications@github.com

wrote:

Was the .bin file made available in some other forum?(email) Because the
dropbox link still doesn't work?

No. Anyway I think the .bin file is not going to help - it's generated
after sorting has happened so if there's a bug in code the .bin would
suffer from it anyway.

@cfsmp3 commented on GitHub (Mar 9, 2015): On Mon, Mar 9, 2015 at 10:43 AM, hardikchoudhary12 <notifications@github.com > wrote: > > Was the .bin file made available in some other forum?(email) Because the > dropbox link still doesn't work? > > No. Anyway I think the .bin file is not going to help - it's generated > after sorting has happened so if there's a bug in code the .bin would > suffer from it anyway.

claunia commented

2026-01-29 16:33:21 +00:00

@cfsmp3 commented on GitHub (Jan 7, 2016):

Closing due to lack of sample - please reopen when a sample is made available.

@cfsmp3 commented on GitHub (Jan 7, 2016): Closing due to lack of sample - please reopen when a sample is made available.

claunia referenced this issue

2026-01-29 16:57:15 +00:00

[PR #31] [CLOSED] moved up enum mode in 608.h #920

claunia referenced this issue

2026-01-29 16:57:17 +00:00

[PR #31] moved up enum mode in 608.h #925

Sign in to join this conversation.