Autor Tema: H264 con fps engañoso  (Leído 1484 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Naoto

  • Miembro senior
  • ***
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 117
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #30: 12 de Noviembre de 2016, 05:39 »
Si quieres tener todas las partes, no sé muy bien con que objetivo, bastaría editar el .bat y corregir la parte:

--split parts:00:00:06.473-00:11:31.257,+00:16:11.571-00:24:58.597,+00:29:08.847-00:31:12.704
por
--split timecodes:00:00:06.473,00:11:31.257,00:16:11.571,00:24:58.597,00:29:08.847,00:31:12.704

es decir cambiar 'parts' por 'timecodes', quitar los '+' y cambiar los '-' por comas ',' (salvo si están al principio o final que se eliminan sin más)

Es fácil cambiar el programa:

Sabes, horas después de haber escrito el post y de haber comparado los códigos de los *.bat, hice lo que comentaste y lo logré después de algunos intentos y cuando ya supe qué tenía que hacer, se me hizo algo tedioso tener que reemplazar los signos por las comas cada vez. Era algo que ya lo veía venir y por eso pensé en otro programa para que lo automatice. Traté de editar el Trim-Aud pero solo conseguí cambiar parts por timecodes ya que el resto del código no lo entendí.
« Última modificación: 12 de Noviembre de 2016, 16:02 por Naoto »

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.613
  • Valoración: 144
Re:H264 con fps engañoso
« Respuesta #31: 12 de Noviembre de 2016, 12:10 »
Ya que te has molestado en intentar editar el Trim-Aud.vbs puedo explicar su funcionamiento que es relativamente simple:

a) Inicializaciones varias, entre la que destaca el path a mkvmerge que cada usuario debe editar según donde esté en su sistema.

b) Chequeo si se ha ejecutado arrastrando uno o varios archivos sobre él. En caso de ejecución directa solo se crea un modelo con los puntos de corte para uso en un editor de audio.

c) Captura del FPS. Se guarda el valor de los milisegundos por frame como x = 1000 / FPS

d) Captura del Trim y cálculo del literal comentado en mi post previo. Es lo único que cambia entre Trim-Aud y Split-Aud, lo comento al final.

e) Bucle For - Next por cada uno de los archivos arrastrados. Analiza el nombre buscando el literal "DELAY" para incluir o no el parámetro " --sync 0:". Crea el "%_Aud.bat" para cada uno de los archivos.

En Split-Aud solo cambia la parte de construcción del literal mencionado. He dejado comentadas (sin uso si comienzan con ' ) las líneas de Trim-Aud y debajo el cambio introducido:

Empezamos con la evidente inicialización reemplazando el literal
'sp = " --split parts:"
sp = " --split timecodes:"

A continuación se analiza la línea de Trim y por cada Trim(F1,F2) se convierten a milisegundos T1 y T2 con:
T1 = x * F1  (recordemos que x era el número de milisegundos por frame, y se redondea a entero, precisión de ms)
T2 = x * (F2 + 1)  (recordemos que en un Trim se incluyen ambas frames, por tanto el tiempo acaba al empezar la siguiente F2 + 1)
Se formatean los tiempos en milisegundos al formato hh:mm:ss.mmm requerido

Las variantes entre Trim-Aud y Split-Aud son:
'  if t1 = 0 then
'      sp = sp & "-"
'  else
   if t1 > 0 then

Si el primer valor de un Trim es 0 el "parts" requeria un "-", con "timecodes" no es necesario

'       sp = sp & "." & i & "-"
       sp = sp & "." & i & ","

Tras un T1 con "parts" requeria un "-" para indicar un rango a guardar, con "timecodes" solo se necesita una coma ","

Si el segundo valor de un Trim es 0 indica continuar hasta el final con lo que había que preservar el último "-" para ello se añadían dos caracteres que ahora no son necesarios

'       sp = sp & "  "

El segundo valor distinto de 0 de un Trim (T2) requeria un ",+" para indicar fin de rango y comienzo del siguiente a guardar, con "timecodes" solo se necesita una coma ","

'       sp = sp & "." & i & ",+"
       sp = sp & "." & i & ","

Una vez que acaba el último Trim se eliminan los últimos ",+" (o los dos espacios si el último T2 es 0), con "timecodes" solo hay que eliminar la última ","

'sp = left(sp, len(sp) - 2)    ' borra ultimo ',+'
sp = left(sp, len(sp) - 1)    ' borra ultima ','

Y eso es todo.

Me sigue quedando la duda de para qué necesitas esto, preservar los audios de los comerciales me paqrece innecesario.
¿O es que piensas darle otro uso?

Naoto

  • Miembro senior
  • ***
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 117
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #32: 12 de Noviembre de 2016, 15:50 »
Me sigue quedando la duda de para qué necesitas esto, preservar los audios de los comerciales me paqrece innecesario.
¿O es que piensas darle otro uso?

Es porque quería editar audios de un video ripeado de DVD. El video se compone de 5 partes, pero las 2 ultimas van en el orden equivocado, por lo que en AviSynth les cambiaba el orden. Aunque lo del video era relativamente fácil, quedaba el tema del audio. Normalmente lo pasaba a WAV y lo cargaba a Vegas para editarlo y ajustarlo al nuevo orden de partes en el video encodeado.

Ayer mientras ripeaba otro DVD de la misma serie, recordé lo de los audios partidos y pensé que si cortaba el audio en partes y hacia una nueva unión sin comprimir pero con las partes reordenadas, tendría el audio editado en menor tiempo. En mis primeros 3 intentos después de editar Trim-Audio y el *.bat generado después de ingresar la linea de Trims que cité, se generaron 9 partes en total. De todas esas, 5 eran del audio bueno y las 4 restantes que estaban bajo números pares, eran audios de 32 ms cada uno. Cuando uní las 5 partes, noté como la duración del audio unido era mucho menor en ms respecto al original. Me di cuenta que hice todo mal y luego pensé que solo debí haber ingresado dos trims intermedios pares y tras eso obtuve las 5 partes como debió ser. Cuando uní las 5 partes, comparé su duración respecto al audio original y solo era menor por la diferencia de 32 ms.

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.613
  • Valoración: 144
Re:H264 con fps engañoso
« Respuesta #33: 13 de Noviembre de 2016, 12:26 »
Vale, es entonces para algún caso particular aislado.

Sí, ya he notado que puede haber algún error de corte debido a que solo puede hacerse por frames completas y puede faltar o sobrar alguna frame (32 ms an AC3), pero es un precio a pagar si no queremos recodificar.

De hecho mkvmerge debe tener algún pequeño bug de exactitud ya que he probado a enviarle timecodes exactos (múltiplos de 32 ms en AC3) y cortaba una frame de más al principio y sobraba otra al final (duración exacta pero desplazada). A ver si lo documento bien y le mando el bug a Mosu.