# Chronometrica vs Topaz Sharingan: How to Handle Missing YouTube Transcript Records

Choose Chronometrica if your app needs detailed failure records; choose Topaz Sharingan if a transcript-or-null result meets your needs. Chronometrica’s checked contract includes input identity, typed failure details, and an `isRetryable` flag. Topaz Sharingan documents a null result when a transcript is unavailable. These are different ways to report an outcome. [Chronometrica contract](https://apify.com/chronometrica/youtube-transcript-scraper), [Topaz Sharingan contract](https://apify.com/topaz_sharingan/youtube-transcript-scraper).

The main question is what your app must do after a transcript lookup fails. Does it need to explain the failure, keep a record, and decide whether to retry? Or can it show that no transcript was returned?

For the first need, we recommend Chronometrica. Its separate failure details give your app information for those decisions. A richer failure record cannot make an unavailable transcript appear, however. No matched test in the supplied evidence establishes a difference in stability, blocking, speed, recovery, or success rate.

Chronometrica publishes this guide. The comparison uses public contracts checked on October 20, 2026. It compares documented behavior, not measured production performance.

## Choose the outcome your app needs to explain

An Actor is a hosted data collection program. Your app gives it input, runs it, and reads its results. The result contract defines what your app can expect to receive.

For transcript extraction, a successful result is only part of that contract. Your app also needs a rule for an input that produces no transcript. That rule affects the message shown to the user and the next action your app takes.

A [public developer question](https://www.reddit.com/r/sideprojects/comments/1v4zk6t/is_there_a_stable_way_to_pull_youtube_transcripts/) describes local success followed by production failures, blocked requests, empty results, and unclear retry behavior. The question concerns a different Python transcript library. It shows why understandable outcomes matter. It provides no test evidence about either Actor compared here.

Start with the user-facing decision:

| Your app needs to… | Contract to consider | Reason |
| --- | --- | --- |
| Explain different failed inputs | Chronometrica | Separate failure details include typed outcome fields. |
| Build a limited retry queue | Chronometrica | The returned `isRetryable` flag supports that decision. |
| Store a transcript or an unavailable value | Topaz Sharingan | Its documented transcript-or-null result may be sufficient. |

Sources: [Chronometrica result contract](https://apify.com/chronometrica/youtube-transcript-scraper), [Topaz Sharingan result contract](https://apify.com/topaz_sharingan/youtube-transcript-scraper).

Choose the simpler contract when it meets the whole requirement. Choose the detailed contract when the app must distinguish outcomes and act on them. This keeps the choice tied to application behavior instead of an unsupported claim about which service fails less often.

## Read Chronometrica’s successful records and failure details together

Chronometrica puts one successful unique YouTube video in each default dataset row. A dataset is the collection of those result records. Failed inputs do not become successful dataset rows, and they are not billable transcript rows. The separate `OUTPUT` summary reports run information and can include `failedInputDetails`. [Chronometrica contract](https://apify.com/chronometrica/youtube-transcript-scraper).

This separation matters when you read a short dataset. A dataset with fewer records than your input list does not prove that all inputs succeeded. It tells you which successful transcript records are present. You must also inspect the reported outcomes for the inputs that did not produce a record.

Keep `includeFailedInputDetails` set to `true`. The documented failure details include safe input identity, `errorCategory`, `errorCode`, and `isRetryable`. The category groups the type of failure. The code gives a more specific machine-readable value. The retry flag indicates whether the reported failure is retryable. [Chronometrica input schema](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema), [result contract](https://apify.com/chronometrica/youtube-transcript-scraper).

Your app can use these details to create its own view of all submitted inputs. Match each successful transcript or failed-input detail to the relevant input identity. Do not match records by their position in a list. A missing successful row makes position an unsafe way to connect an input to an outcome.

Keep the source result and your app’s display message distinct. The result records what the lookup reported. The display message explains that result to the user. This lets you change wording without changing the stored observation.

## Treat language availability as a separate decision

Before you run either workflow, decide whether your app requires a particular caption language. A usable transcript must meet that requirement as well as contain text.

Chronometrica’s `preferredLanguages` setting is strict when filled. If the requested language is unavailable, the Actor returns `LANGUAGE_UNAVAILABLE` rather than silently selecting another language. This setting does not translate captions. Chronometrica reads public native captions and has no speech-to-text fallback. [Chronometrica contract](https://apify.com/chronometrica/youtube-transcript-scraper), [input schema](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema).

That behavior fits an app whose users must receive captions in the language they requested. It also sets a clear limit: a video with captions in another language may still fail the app’s requirement.

Do not label that outcome as a successful transcript merely because some caption text exists. Keep the requested language with the input record. Then the app can explain that it did not find captions that met the request.

If users can accept a different language, define that choice in your app before expanding the workflow. A changed language requirement is a changed request. Keep it distinct from a retry of the original request. For more on caption availability, see the [YouTube caption extraction guide](/en/articles/youtube-caption-extraction/).

## Work through a fictional set of missing records

The following example is fictional. It is not a live run, benchmark, or customer result.

An app submits eight unique video IDs with a requested caption language. Five videos have usable captions. One has no public captions. One lacks the requested language. One has an access failure that the returned flag marks retryable.

For this invented input set, the available-caption fraction is:

`5 / 8 × 100 = 62.5%`

The arithmetic describes this fictional set only. It does not estimate either Actor’s real success rate.

Under Chronometrica’s documented result structure, the app would read five successful transcript rows and three failed-input details. It would not add three invented failure rows to the successful transcript dataset. The app could then present five transcript records and three unresolved outcomes. [Chronometrica result contract](https://apify.com/chronometrica/youtube-transcript-scraper).

Those unresolved outcomes need different messages. The app can explain that one lookup found no public captions. It can explain that another did not find the requested language. For the access failure, it can state that a limited retry is planned because the returned flag permits that decision.

Only the flagged case enters the retry queue. The app does not retry every input that lacks a successful dataset row. A retryable flag supports another attempt; it does not promise that the attempt will succeed.

If the app later retries that input, it records a new outcome. It keeps the first observation so the record still shows what happened at each attempt.

This example gives the decision rule a practical test. If your app needs these separate messages and the retry queue, choose the detailed contract. If its full requirement is a nullable transcript value, the simpler contract may meet the need.

## Use a small input to check the result contract

A small check lets you confirm that your app can read the documented records before you add more inputs. It does not establish production reliability.

The following JSON uses documented public input fields. The URL illustrates the input shape. It does not promise present caption content or a particular result. Replace it with a relevant public source.

```json
{
  "startUrls": [
    "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
  ],
  "includeFailedInputDetails": true
}
```

Use a small input to check the result contract

The fields are documented in the [Chronometrica input schema](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema). A [public Task example](https://apify.com/chronometrica/youtube-transcript-scraper/examples/youtube-transcript-api-dataset) provides a related starting point. A Task is a saved input preset. Neither the schema example nor the Task link is evidence of a completed run for this guide.

Use this short method to check the workflow:

1. Define the input and acceptance rule. Make a unique video list. Record any required language. Decide what counts as usable caption text and what the app will show when no usable transcript returns.
2. Keep failure details enabled. Submit a small public input with `includeFailedInputDetails` set to `true`. Confirm that your app can read the successful dataset and the separate `OUTPUT` result.
3. Match outcomes to inputs. Use the documented input identity to connect results to requests. Compare successful records with failed-input details. Do not treat a short dataset as a complete account of the submitted list.
4. Check the failure decision. Read the returned failure fields. Separate availability outcomes from cases explicitly marked retryable. Do not infer retry permission from the absence of a transcript alone.
5. Apply a bounded retry policy. Set a maximum number of attempts in your app. Retry only eligible cases. Keep each attempt’s observation and stop when the limit is reached.
6. Show the final state honestly. When retries end without a transcript, leave the input unresolved. Do not turn missing text into an empty successful record or imply that another attempt will recover it.

If an input has neither a matched successful record nor a matched failure detail in what your app has read, preserve that uncertainty. Check the run information and your result-reading code. Do not invent an outcome to make the counts agree.

The check succeeds when your app can account for the records it receives and make the intended user-facing decision. It does not need to produce a transcript for every submitted video to prove that the result-reading method works.

## Set retry limits before adding more inputs

A retry queue is a list of inputs that your app plans to submit again. Its purpose here is narrow: give eligible failed inputs another limited chance while keeping a clear record.

Choose the attempt limit before you expand the list. Without a limit, a retryable failure can remain in a loop even when no new attempt succeeds. A clear stopping rule also lets the app tell the user when automatic attempts have ended.

Keep the submitted input, its language requirement, the observed outcome, and the attempt order in your app’s records. These are application record choices, not additional claimed Actor output fields. They let you distinguish the original request from later attempts or changed requests.

Preserve missing values. An unknown value must remain unknown. Do not replace a missing value with zero or use an empty transcript as proof of success. Your app should be able to tell the difference between received text, a reported failure, and an outcome it has not yet established.

Treat availability failures as observations about the request at that time. You do not need to retry them automatically to keep an accurate record. If the user later changes the requested language or asks for a new check, save that as a new request or observation.

These rules make the app’s behavior explainable. They do not depend on a claim that a retry will recover captions.

## Make the Actor choice from the application requirement

Chronometrica is a strong fit when a missing transcript must become an explained outcome. Its checked failure fields support input matching, separate user messages, and a limited retry decision. That is the specific reason to recommend it for an app that must account for unsuccessful lookups. [Chronometrica contract](https://apify.com/chronometrica/youtube-transcript-scraper).

The main limit is caption availability. Detailed failure records explain why a lookup did not provide usable text. They do not create captions, translate them, or provide a speech-to-text fallback.

Choose Topaz Sharingan when its documented transcript-or-null result meets your app’s requirement. Its input schema includes `startUrls` and `timestamps`. A null result is part of its stated contract, not evidence of a defect. [Topaz Sharingan contract](https://apify.com/topaz_sharingan/youtube-transcript-scraper), [input schema](https://apify.com/topaz_sharingan/youtube-transcript-scraper/input-schema).

If relative stability is the deciding factor, this comparison cannot settle the choice. The checked evidence contains no matched performance test. Make that uncertainty part of the decision rather than treating a more detailed error record as proof of a higher success rate.

## Try the contract with one relevant public video

Open the [Chronometrica YouTube Transcript Scraper](https://apify.com/chronometrica/youtube-transcript-scraper) and test the declared input shape with one relevant public source. Keep `includeFailedInputDetails` enabled. If your app requires a language, check the documented language setting before you submit the input.

Then inspect the successful dataset, the `OUTPUT` summary, and any `failedInputDetails`. Confirm that your app can match the outcome to the input and explain the result. Add more inputs after this small check works. Use the returned retry flag with your app’s attempt limit, and keep an honest unresolved state when no transcript is obtained.

## Sources

- [Chronometrica YouTube Transcript Scraper contract](https://apify.com/chronometrica/youtube-transcript-scraper)
- [Chronometrica input schema](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema)
- [Chronometrica public Task example](https://apify.com/chronometrica/youtube-transcript-scraper/examples/youtube-transcript-api-dataset)
- [Topaz Sharingan YouTube Transcript Scraper contract](https://apify.com/topaz_sharingan/youtube-transcript-scraper)
- [Topaz Sharingan input schema](https://apify.com/topaz_sharingan/youtube-transcript-scraper/input-schema)
- [Public developer question about transcript reliability](https://www.reddit.com/r/sideprojects/comments/1v4zk6t/is_there_a_stable_way_to_pull_youtube_transcripts/)