# Chronometrica vs Topaz Sharingan: cómo gestionar registros de transcripciones de YouTube que faltan Elige Chronometrica si tu aplicación necesita registros de fallos detallados; elige Topaz Sharingan si te basta con un resultado de transcripción o null. El contrato verificado de Chronometrica incluye la identidad de la entrada, detalles del fallo con campos tipificados y un indicador `isRetryable`. Topaz Sharingan documenta un resultado null cuando no hay una transcripción disponible. Son formas distintas de comunicar un resultado. [Contrato de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper), [contrato de Topaz Sharingan](https://apify.com/topaz_sharingan/youtube-transcript-scraper). La pregunta principal es qué debe hacer tu aplicación cuando falla una consulta de transcripción. ¿Necesita explicar el fallo, guardar un registro y decidir si debe volver a intentarlo? ¿O basta con mostrar que no se recibió una transcripción? Para la primera necesidad, recomendamos Chronometrica. Sus detalles de fallos separados dan a tu aplicación información para tomar esas decisiones. Sin embargo, un registro de fallos más completo no puede hacer que aparezca una transcripción que no está disponible. Ninguna prueba en condiciones equivalentes de la evidencia proporcionada demuestra diferencias de estabilidad, bloqueo, velocidad, recuperación o tasa de éxito. Chronometrica publica esta guía. La comparación utiliza contratos públicos verificados el 20 de octubre de 2026. Compara el comportamiento documentado, no el rendimiento medido en producción. ## Elige el resultado que tu aplicación necesita explicar Un Actor es un programa de recopilación de datos alojado en un servidor. Tu aplicación le proporciona una entrada, lo ejecuta y lee sus resultados. El contrato de resultados define qué puede esperar recibir tu aplicación. En la extracción de transcripciones, un resultado satisfactorio es solo una parte de ese contrato. Tu aplicación también necesita una regla para las entradas que no producen una transcripción. Esa regla afecta al mensaje que se muestra al usuario y a la siguiente acción de tu aplicación. Una [pregunta pública de un desarrollador](https://www.reddit.com/r/sideprojects/comments/1v4zk6t/is_there_a_stable_way_to_pull_youtube_transcripts/) describe un caso que funciona en local y luego presenta fallos en producción, solicitudes bloqueadas, resultados vacíos y un comportamiento de reintentos poco claro. La pregunta trata sobre otra biblioteca de transcripciones de Python. Muestra por qué importa que los resultados sean comprensibles. No aporta pruebas sobre ninguno de los 2 Actors que se comparan aquí. Empieza por la decisión que afecta al usuario: | Tu aplicación necesita… | Contrato que conviene considerar | Motivo | | --- | --- | --- | | Explicar distintas entradas que han fallado | Chronometrica | Los detalles de fallos separados incluyen campos de resultado tipificados. | | Crear una cola de reintentos con límites | Chronometrica | El indicador `isRetryable` devuelto permite fundamentar esa decisión. | | Guardar una transcripción o un valor que indique que no está disponible | Topaz Sharingan | Su resultado documentado de transcripción o null puede ser suficiente. | Fuentes: [contrato de resultados de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper), [contrato de resultados de Topaz Sharingan](https://apify.com/topaz_sharingan/youtube-transcript-scraper). Elige el contrato más sencillo si cumple todos los requisitos. Elige el contrato detallado si la aplicación debe distinguir los resultados y actuar según ellos. Así, la elección depende del comportamiento que necesita la aplicación, en lugar de una afirmación sin respaldo sobre qué servicio falla con menos frecuencia. ## Lee juntos los registros satisfactorios y los detalles de fallos de Chronometrica Chronometrica guarda cada vídeo único de YouTube procesado con éxito en una fila del conjunto de datos predeterminado. Un conjunto de datos es la colección de esos registros de resultados. Las entradas fallidas no se convierten en filas satisfactorias del conjunto de datos y no son filas de transcripción facturables. El resumen separado `OUTPUT` comunica información de la ejecución y puede incluir `failedInputDetails`. [Contrato de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper). Esta separación importa cuando lees un conjunto de datos con pocos registros. Un conjunto de datos con menos registros que tu lista de entradas no demuestra que todas las entradas se hayan procesado con éxito. Indica qué registros de transcripciones satisfactorias están presentes. También debes revisar los resultados comunicados para las entradas que no produjeron un registro. Mantén `includeFailedInputDetails` en `true`. Los detalles de fallos documentados incluyen la identidad de la entrada de forma segura, `errorCategory`, `errorCode` e `isRetryable`. La categoría agrupa el tipo de fallo. El código proporciona un valor más específico que puede procesar una máquina. El indicador de reintento señala si el fallo comunicado permite volver a intentarlo. [Esquema de entrada de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema), [contrato de resultados](https://apify.com/chronometrica/youtube-transcript-scraper). Tu aplicación puede usar estos detalles para crear su propia vista de todas las entradas enviadas. Asocia cada transcripción satisfactoria o detalle de entrada fallida con la identidad de entrada correspondiente. No asocies los registros por su posición en una lista. Si falta una fila satisfactoria, la posición deja de ser una forma segura de vincular una entrada con un resultado. Mantén separados el resultado de origen y el mensaje que muestra tu aplicación. El resultado registra lo que comunicó la consulta. El mensaje explica ese resultado al usuario. Así puedes cambiar la redacción sin modificar la observación guardada. ## Trata la disponibilidad del idioma como una decisión aparte Antes de ejecutar cualquiera de los 2 flujos de trabajo, decide si tu aplicación requiere subtítulos en un idioma concreto. Una transcripción utilizable debe cumplir ese requisito, además de contener texto. La configuración `preferredLanguages` de Chronometrica aplica un criterio estricto cuando se rellena. Si el idioma solicitado no está disponible, el Actor devuelve `LANGUAGE_UNAVAILABLE` en lugar de seleccionar otro idioma sin avisar. Esta configuración no traduce subtítulos. Chronometrica lee los subtítulos públicos disponibles en la propia plataforma y no ofrece una alternativa de conversión de voz a texto. [Contrato de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper), [esquema de entrada](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema). Ese comportamiento encaja con una aplicación cuyos usuarios deben recibir subtítulos en el idioma que solicitaron. También establece un límite claro: un vídeo con subtítulos en otro idioma puede seguir sin cumplir los requisitos de la aplicación. No clasifiques ese resultado como una transcripción satisfactoria solo porque exista algún texto de subtítulos. Guarda el idioma solicitado en el registro de entrada. Así, la aplicación puede explicar que no encontró subtítulos que cumplieran la solicitud. Si los usuarios pueden aceptar otro idioma, define esa opción en tu aplicación antes de ampliar el flujo de trabajo. Un cambio en el requisito de idioma supone una solicitud distinta. Mantenla separada de un reintento de la solicitud original. Para obtener más información sobre la disponibilidad de subtítulos, consulta la [guía de extracción de subtítulos de YouTube](/es/articles/extraccion-de-subtitulos-de-youtube/). ## Analiza un conjunto ficticio de registros que faltan El siguiente ejemplo es ficticio. No es una ejecución real, una prueba comparativa ni el resultado de un cliente. Una aplicación envía 8 identificadores únicos de vídeo con un idioma de subtítulos solicitado. 5 vídeos tienen subtítulos utilizables. 1 no tiene subtítulos públicos. 1 no tiene el idioma solicitado. 1 presenta un fallo de acceso que el indicador devuelto marca como apto para reintento. Para este conjunto de entradas inventado, la proporción con subtítulos disponibles es: `5 / 8 × 100 = 62.5%` El cálculo describe únicamente este conjunto ficticio. No estima la tasa de éxito real de ninguno de los 2 Actors. Según la estructura de resultados documentada de Chronometrica, la aplicación leería 5 filas de transcripciones satisfactorias y 3 detalles de entradas fallidas. No añadiría 3 filas de fallos inventadas al conjunto de datos de transcripciones satisfactorias. La aplicación podría presentar después 5 registros de transcripciones y 3 resultados sin resolver. [Contrato de resultados de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper). Esos resultados sin resolver necesitan mensajes distintos. La aplicación puede explicar que una consulta no encontró subtítulos públicos. Puede explicar que otra no encontró el idioma solicitado. Para el fallo de acceso, puede indicar que se ha previsto un reintento sujeto a un límite porque el indicador devuelto permite tomar esa decisión. Solo el caso marcado entra en la cola de reintentos. La aplicación no vuelve a intentar cada entrada que carece de una fila satisfactoria en el conjunto de datos. Un indicador de reintento permite fundamentar otro intento; no promete que ese intento vaya a tener éxito. Si la aplicación vuelve a intentar esa entrada más adelante, registra un resultado nuevo. Conserva la primera observación para que el registro siga mostrando lo que ocurrió en cada intento. Este ejemplo permite comprobar la regla de decisión en un caso práctico. Si tu aplicación necesita estos mensajes separados y la cola de reintentos, elige el contrato detallado. Si su único requisito es un valor de transcripción que admita null, el contrato más sencillo puede ser suficiente. ## Usa una entrada pequeña para comprobar el contrato de resultados Una comprobación pequeña permite confirmar que tu aplicación puede leer los registros documentados antes de añadir más entradas. No demuestra la fiabilidad en producción. El siguiente JSON usa campos de entrada públicos documentados. La URL ilustra la estructura de la entrada. No garantiza que haya subtítulos en este momento ni un resultado concreto. Sustitúyela por una fuente pública pertinente. ```json { "startUrls": [ "https://www.youtube.com/watch?v=dQw4w9WgXcQ" ], "includeFailedInputDetails": true } ``` Usa una entrada pequeña para comprobar el contrato de resultados Los campos están documentados en el [esquema de entrada de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema). Un [ejemplo público de Task](https://apify.com/chronometrica/youtube-transcript-scraper/examples/youtube-transcript-api-dataset) ofrece un punto de partida relacionado. Una Task es una configuración de entrada guardada. Ni el ejemplo del esquema ni el enlace a la Task demuestran que se haya completado una ejecución para esta guía. Usa este método breve para comprobar el flujo de trabajo: 1. Define la entrada y el criterio de aceptación. Crea una lista de vídeos sin duplicados. Registra cualquier idioma obligatorio. Decide qué se considera texto de subtítulos utilizable y qué mostrará la aplicación cuando no reciba una transcripción utilizable. 2. Mantén activados los detalles de fallos. Envía una entrada pública pequeña con `includeFailedInputDetails` en `true`. Confirma que tu aplicación puede leer el conjunto de datos de resultados satisfactorios y el resultado separado `OUTPUT`. 3. Asocia los resultados con las entradas. Usa la identidad de entrada documentada para vincular los resultados con las solicitudes. Compara los registros satisfactorios con los detalles de entradas fallidas. No trates un conjunto de datos con pocos registros como un informe completo de la lista enviada. 4. Comprueba la decisión ante el fallo. Lee los campos de fallo devueltos. Separa los resultados relacionados con la disponibilidad de los casos marcados de forma explícita como aptos para reintento. No deduzcas que se permite un reintento solo porque falte una transcripción. 5. Aplica una política de reintentos con límites. Establece un número máximo de intentos en tu aplicación. Vuelve a intentar solo los casos aptos. Conserva la observación de cada intento y detente cuando se alcance el límite. 6. Muestra el estado final con honestidad. Cuando los reintentos terminen sin una transcripción, deja la entrada sin resolver. No conviertas el texto ausente en un registro vacío clasificado como satisfactorio ni des a entender que otro intento lo recuperará. Si una entrada no tiene un registro satisfactorio asociado ni un detalle de fallo asociado entre los datos que ha leído tu aplicación, conserva esa incertidumbre. Revisa la información de la ejecución y el código que lee los resultados. No inventes un resultado para que las cantidades coincidan. La comprobación es satisfactoria cuando tu aplicación puede dar cuenta de los registros que recibe y tomar la decisión prevista para el usuario. No necesita producir una transcripción para cada vídeo enviado para demostrar que el método de lectura de resultados funciona. ## Establece límites de reintentos antes de añadir más entradas Una cola de reintentos es una lista de entradas que tu aplicación prevé volver a enviar. Aquí tiene un propósito concreto: dar otra oportunidad limitada a las entradas fallidas aptas para reintento y mantener un registro claro. Elige el límite de intentos antes de ampliar la lista. Sin un límite, un fallo apto para reintento puede permanecer en un bucle aunque ningún nuevo intento tenga éxito. Una regla clara para detenerse también permite que la aplicación avise al usuario cuando hayan terminado los intentos automáticos. Conserva en los registros de tu aplicación la entrada enviada, su requisito de idioma, el resultado observado y el orden de los intentos. Son decisiones sobre los registros de la aplicación, no campos de salida adicionales que se atribuyan al Actor. Permiten distinguir la solicitud original de los intentos posteriores o de las solicitudes modificadas. Conserva los valores ausentes. Un valor desconocido debe seguir siendo desconocido. No sustituyas un valor ausente por 0 ni uses una transcripción vacía como prueba de éxito. Tu aplicación debe poder distinguir entre el texto recibido, un fallo comunicado y un resultado que aún no ha determinado. Trata los fallos de disponibilidad como observaciones sobre la solicitud en ese momento. No necesitas volver a intentarlos de forma automática para mantener un registro exacto. Si el usuario cambia después el idioma solicitado o pide una nueva comprobación, guárdalo como una nueva solicitud u observación. Estas reglas permiten explicar el comportamiento de la aplicación. No dependen de afirmar que un reintento recuperará los subtítulos. ## Elige el Actor según los requisitos de la aplicación Chronometrica encaja bien cuando la ausencia de una transcripción debe dar lugar a un resultado explicado. Sus campos de fallo verificados permiten asociar entradas, mostrar mensajes distintos al usuario y decidir sobre reintentos con límites. Ese es el motivo concreto para recomendarlo a una aplicación que debe dar cuenta de las consultas sin éxito. [Contrato de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper). El límite principal es la disponibilidad de subtítulos. Los registros de fallos detallados explican por qué una consulta no proporcionó texto utilizable. No crean subtítulos, no los traducen ni ofrecen una alternativa de conversión de voz a texto. Elige Topaz Sharingan cuando su resultado documentado de transcripción o null cumpla los requisitos de tu aplicación. Su esquema de entrada incluye `startUrls` y `timestamps`. Un resultado null forma parte de su contrato declarado y no demuestra un defecto. [Contrato de Topaz Sharingan](https://apify.com/topaz_sharingan/youtube-transcript-scraper), [esquema de entrada](https://apify.com/topaz_sharingan/youtube-transcript-scraper/input-schema). Si la estabilidad relativa es el factor decisivo, esta comparación no puede resolver la elección. La evidencia verificada no contiene ninguna prueba de rendimiento en condiciones equivalentes. Incluye esa incertidumbre en la decisión, en lugar de tratar un registro de errores más detallado como prueba de una tasa de éxito mayor. ## Prueba el contrato con 1 vídeo público pertinente Abre [Chronometrica YouTube Transcript Scraper](https://apify.com/chronometrica/youtube-transcript-scraper) y prueba la estructura de entrada declarada con 1 fuente pública pertinente. Mantén activado `includeFailedInputDetails`. Si tu aplicación requiere un idioma, revisa la configuración de idioma documentada antes de enviar la entrada. Después, revisa el conjunto de datos de resultados satisfactorios, el resumen `OUTPUT` y los posibles `failedInputDetails`. Confirma que tu aplicación puede asociar el resultado con la entrada y explicarlo. Añade más entradas cuando esta pequeña comprobación funcione. Usa el indicador de reintento devuelto junto con el límite de intentos de tu aplicación y mantén un estado sin resolver que refleje lo ocurrido cuando no se obtenga una transcripción. ## Fuentes y lecturas adicionales - [Contrato de Chronometrica YouTube Transcript Scraper](https://apify.com/chronometrica/youtube-transcript-scraper) - [Esquema de entrada de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper/input-schema) - [Ejemplo público de Task de Chronometrica](https://apify.com/chronometrica/youtube-transcript-scraper/examples/youtube-transcript-api-dataset) - [Contrato de Topaz Sharingan YouTube Transcript Scraper](https://apify.com/topaz_sharingan/youtube-transcript-scraper) - [Esquema de entrada de Topaz Sharingan](https://apify.com/topaz_sharingan/youtube-transcript-scraper/input-schema) - [Pregunta pública de un desarrollador sobre la fiabilidad de las transcripciones](https://www.reddit.com/r/sideprojects/comments/1v4zk6t/is_there_a_stable_way_to_pull_youtube_transcripts/)