Tipo de solicitud:
NUEVA FUNCIÓN
Resumen del problema o sugerencia:
He estado utilizando cada vez más archivos SRT con mis vídeos de origen. He notado que estos se procesan y, en algunos casos, se elimina contenido de ellos. He probado la reproducción con el SRT procesado y el SRT original junto con el archivo de vídeo procesado y no he observado ningún problema al usar el SRT original. Me gustaría tener una opción para no procesar el SRT si se incluye en la ubicación de origen.
No entendí del todo. El único momento en que se ajusta un SRT es cuando la eliminación de comerciales está habilitada; en ese caso, el SRT se “recorta” para mantenerse sincronizado con la eliminación de comerciales; de lo contrario, el SRT quedará desfasado respecto al archivo convertido, que ya no incluye los comerciales.
Tengo Ad remover configurado en Sí (Usar marcadores) por si acaso tengo mi propio EDL creado con cortes personalizados, pero en estos casos recientes no he tenido ningún archivo EDL.
Aquí está un registro de conversión.
Rick and Morty - S02E08 - Interdimensional Cable 2- Tempting Fate.mp4-HEVC-MKV-00-Default-Stream-2021-06-02T08-40-28.log (1.4 MB)
Archivos SRT:
Rick and Morty - S02E08 - Interdimensional Cable 2 - Tempting Fate.eng.processed.srt (34.1 KB)
Rick and Morty - S02E08 - Interdimensional Cable 2 - Tempting Fate.eng.orig.srt (39.3 KB)
Revisé tus archivos de registro y SRT, no están relacionados con archivos EDL. Tus archivos SRT son el problema.
MCEBuddy valida y limpia los archivos SRT para eliminar datos inválidos.
Tus archivos SRT están creando marcas de tiempo que no están en el formato requerido, por lo que MCEBuddy las descarta:
INFORMATION> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Validating and cleaning SRT file
2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → SRT File D:\Temp\working0\Rick and Morty - S02E08 - Interdimensional Cable 2- Tempting Fate.eng.srt
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:4,405 00:00:6,006
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:6,006 00:00:8,509
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:8,509 00:00:10,778
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:00:59,093 00:01:1,762
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:01:1,762 00:01:4,632
WARNING> 2021-06-02T08:41:14 MCEBuddy.Transcode.CCandSubtitles → Invalid timestamps, skipping entry : 00:01:4,632 00:01:9,103
El problema es que las marcas de tiempo de tu archivo SRT son inválidas:
00:00:4,405 → 00:00:6,006
Los segundos deben ser números de dos dígitos rellenados con ceros, según lo especificado:
Mientras que tu archivo SRT tiene solo un dígito, por lo que se descarta. ¿Qué software está generando estos archivos SRT?
Gracias por echarle un vistazo. Me pasé por completo el valor de segundos de un solo dígito.
A Plex no parece importarle, ya que sigue funcionando.
Informaré del problema al proveedor del software que generó el archivo.
¿Mi solicitud sigue siendo válida para tener una opción para omitir el procesamiento (validación y limpieza) de los SRT? Si crees que no es necesario, ya que solo sería necesario en las ocasiones más raras, estoy bien con eso y podemos marcar esto como resuelto.
Hemos implementado un parche para manejar estas marcas de tiempo malformadas y recuperarlas para hacerlas válidas cuando sea posible. No puedes probar la versión BETA 2.5.7 de hoy.
No podemos ignorar archivos SRT defectuosos, sino que los registramos para referencia del usuario. Ha habido casos de software de reproducción de terceros que se bloqueaba o no reproducía archivos debido a archivos SRT malformados que fueron copiados o extraídos tal cual desde la fuente por MCEBuddy (lo que nos llevó a implementar la validación de archivos SRT).
Gracias por la respuesta rápida.
Probé la versión 2.5.7 en un archivo nuevo y, salvo una excepción, funcionó muy bien. Échale un vistazo a lo que hizo con el 22 (línea 98). No estoy seguro de si se debe al salto de línea adicional en el original o a qué.
22
00:00:53,966 → 00:00:54,924MYKA.
22
00:00:00,000 → 00:00:00,000
MYKA.
Warehouse 13 - S02E12 - Reset.eng.orig.srt (62.1 KB)
Warehouse 13 - S02E12 - Reset.eng.output.srt (66.9 KB)
Warehouse 13 - S02E12 - Reset.mp4-Orig-MKV-00-Default-Stream-2021-06-04T13-57-30.log (498.6 KB)
Para añadir a este post que podría estar relacionado:
Estoy recibiendo muchos/archivos SRT extraídos de 1 KB que no funcionan. Normalmente son de 10-30 kb.
PD: uso buddy para remuxear mkv menores de 500mb y
Convertir MKV mayores de 500mb a hevc mp4.
saludos
Por favor, sube un video de origen de muestra donde estés viendo este comportamiento y los registros para que podamos ver qué está sucediendo.
El problema aquí es que el archivo SRT no cumple con las especificaciones. No debería haber una línea vacía entre el texto del subtítulo. Una línea vacía indica el final de un bloque de subtítulo, por lo que esto se convierte en un bloque inválido.
Si se dejan líneas en blanco, otros programas fallan, así que MCEBuddy ignora las líneas vacías.
ACTUALIZACIÓN: Ahora MCEBuddy maneja las líneas vacías sin problemas registrando un mensaje de advertencia y descartando el bloque/contenido inválido. Puedes probar la versión BETA 2.5.7 de hoy.
¡Gracias @Goose!
Good Witch - S07E04 - The Exchange.mkv-REMUX TV 500 to 264-1900-01-01T00-00-00.log (11.6 KB)
Good Witch - S07E04 - The Exchange.mkv-convert tv 500 to HEVC-1900-01-01T00-00-00.log (13.9 KB)
Good Witch - S07E04 - The Exchange.mkv-convert tv 500 to HEVC-2021-06-08T19-03-44.log (15.0 KB)
Este título creó archivos SRT de 1 KB
El archivo MKV real es demasiado grande
Good Witch - S07E04 - The Exchange.srt (527 Bytes)
Por favor configura tus registros en modo depuración, no hay mucho en estos registros para analizar.
Puedes subir el archivo MKV original a nuestro servidor de carga aquí: Welcome to MCEBuddy - README BEFORE POSTING
mcebuddy.log|adjunto (494.3 KB)
He comenzado otro post propio relacionado con esto, así que olvídate de este…