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

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

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #15: 01 de Noviembre de 2016, 00:28 »
Efectivamente, el método sin recompresión está limitado a cortes por frames de audio con lo que se pierde precisión.

Yo prefiero decodifcar el audio y hacer los cortes con un editor de audio, la pérdida de calidad por la recompresión creo que se compensa garantizando que no entran audios de comerciales o cortes poco suaves. No obstante seguiré con la idea de generar el .bat desde Trim-TimeC.vbs, puede usarse o no, en este último caso puede servir para conocer los puntos de corte aproximados sin tener que buscarlos en el editor.

Adelante  :arriba:

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #16: 01 de Noviembre de 2016, 01:23 »
He cambiado la sintáxis que usa el compañero TheFluff en Split_AUD: --split timecodes:... por  :

--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

de manera que mkvmerge genera un único split.mka sin tener que unir las partes deseadas.

la sintáxis define los rangos a incluir y concatenar: T1-T2,+T3-T4,+T5-T6...
El caso particular: -T2,+T3-T4,+T5-
significa desde el principio hasta T2, más desde T3 hasta T4, más desde T5 hasta el final.

Lo comento para que se entienda como usarlo en un editor.
Para los no iniciados recuerdo que en un editor de audio hay que empezar a cortar por el final para no perder las referencias.
Primero cortar de T6 al final, luego cortar de T4 a T5, luego cortar de T2 a T3 para terminar cortando de T1 al principio.
La cantidad a cortar debe ser exacta pero el rango puede desplazarse ligeramente a izq o dcha buscando zonas de silencio que debe haber entre comerciales y peli.

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #17: 01 de Noviembre de 2016, 05:20 »
Excelente.

Supongo que en todo caso, si quiero cortes precisos en el audio, debo pasar el archivo completo a WAV para hacer el resto. Lo malo es que, por ejemplo, si quiero estar seguro de que los cortos estén correctamente sincronizados al video, éste ultimo debo cambiarlo a contenedor MP4 ya que en Sony Vegas no es posible importar los MKV. Sin mencionar lo impreciso que puede ser el ajuste si se trata de hacerlo con un video VFR, siendo que Vegas trabaja con videos CFR. No hay editores con interfez similar a Vegas pero que admita sin problemas contenedores Matroska. ¿Verdad?

Hay otra pregunta aparte pero relacionada con archivos TS. Conseguí unos que fueron ripeados en fragmentos de 2MB a 4MB de peso según el caso (ripeo de señal SD y HD respectivamente), todos estos fragmentos duran 4 segundos. Para unirlos todos, me proporcionaron este código para un .bat

Citar
copy /b *.ts Archivo.ts
PAUSE

¿Un codigo así sirve también para unir otro tipo de archivos? ¿Como dos archivos AC3?

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #18: 01 de Noviembre de 2016, 11:30 »
Lo malo es que, por ejemplo, si quiero estar seguro de que los cortos estén correctamente sincronizados al video,...
La técnica propuesta asegura la sincronía al milisegundo, con tres cortes el error no puede superar los 2 ms.

Empezando por el corte final de T6 al fin:
Si vemos que conserva audio no deseado (del siguiente comercial) o trunca audio deseado hay que suponer que todo el audio lleva algún delay o hemos elegido mal el Trim final.
Por el momento cortamos en el punto óptimo del audio. Tampoco importa mucho que el audio sea algo más largo o corto que el vídeo, aunque siempre puede ajustarse al final del proceso.

A continuación el corte a efectuar entre T4 y T5: 00:24:58.597,+00:29:08.847, en ms: 1498597 a 1748847
Hay que cortar exactamente 250250 ms comenzando en el punto 00:24:58.597 aproximado.
Si vemos que conserva audio no deseado (del comercial) o trunca audio deseado hay que suponer que hemos elegido mal el Trim.
Siempre suele haber algunas frames en fundido a negro para corregir el Trim.
Si fuera absolutamente imposible corregir el Trim cortar los 250250 ms donde menos daño hagan y suavizar el corte (mute de comerciales o fade-out fade-in de audio deseado).
Hay que cortar exactamente el mismo tiempo que se eimina en vídeo aunque esté desplazado, anotar el desplazamiento para un posible Delay inicial

Lo mismo para el corte entre T2 y T3.

Por fin el corte inicial hasta T1, si ya llevamos desplazamientos de los cortes anteriores ver si concuerdan con una nueva posición de T1 que correspondería con un Delay inicial global.
En cualquier caso intentar mantener la duración T1-T2 corrigiendo el Trim inicial si es posible para que el corte de audio esté en una posición óptima de silencio.
Si hubiera siempre ruido hacer mute en los primeros 50 ms y fade-in a los siguientes 50 ms.

Si más o menos todo ha cuadrado lo más probable es que la sincronía sea perfecta.
Como mucho puede haber un Delay global pendiente si los cortes intermedios se han hecho exactamente iguales a los cortes de vídeo.

Como dices con un VFR es difícil comprobar la sincronía perfecta. Solo se me ocurre lo siguiente:

- Buscar en el vídeo un fotograma coincidente con un ruido seco (golpe, cierre de puerta, comienzo de explosión, ...)
- Buscar en el timecode.txt a que milisegundo se comienza a visualizar ese fotograma.
- Verificar en el editor de audio a que milisegundo comienza ese ruido.
La diferencia será el Delay global necesario.

Citar
Citar
copy /b *.ts Archivo.ts
PAUSE

¿Un codigo así sirve también para unir otro tipo de archivos? ¿Como dos archivos AC3?

Sirve para unir ciertos tipos de archivos, aquellos que no tienen cabeceras globales sino cabeceras de datos distribuidas a todo lo largo del stream.
No vale para MP3, MP4, M4A, MKV, MKA, M2TS, AVI...

Vale para AC3, DTS, AAC (con cabeceras ADTS no en contenedor mp4 como .m4a) ...
Aunque deberán tener comunes ciertas características: Número de canales, Samplerate y Bitrate (en AC3 y DTS que son CBR, no necesario en AAC)

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #19: 01 de Noviembre de 2016, 18:05 »
Lo malo es que, por ejemplo, si quiero estar seguro de que los cortos estén correctamente sincronizados al video,...
La técnica propuesta asegura la sincronía al milisegundo, con tres cortes el error no puede superar los 2 ms.

Empezando por el corte final de T6 al fin:
Si vemos que conserva audio no deseado (del siguiente comercial) o trunca audio deseado hay que suponer que todo el audio lleva algún delay o hemos elegido mal el Trim final.
Por el momento cortamos en el punto óptimo del audio. Tampoco importa mucho que el audio sea algo más largo o corto que el vídeo, aunque siempre puede ajustarse al final del proceso.

A continuación el corte a efectuar entre T4 y T5: 00:24:58.597,+00:29:08.847, en ms: 1498597 a 1748847
Hay que cortar exactamente 250250 ms comenzando en el punto 00:24:58.597 aproximado.
Si vemos que conserva audio no deseado (del comercial) o trunca audio deseado hay que suponer que hemos elegido mal el Trim.
Siempre suele haber algunas frames en fundido a negro para corregir el Trim.
Si fuera absolutamente imposible corregir el Trim cortar los 250250 ms donde menos daño hagan y suavizar el corte (mute de comerciales o fade-out fade-in de audio deseado).
Hay que cortar exactamente el mismo tiempo que se eimina en vídeo aunque esté desplazado, anotar el desplazamiento para un posible Delay inicial

Lo mismo para el corte entre T2 y T3.

Por fin el corte inicial hasta T1, si ya llevamos desplazamientos de los cortes anteriores ver si concuerdan con una nueva posición de T1 que correspondería con un Delay inicial global.
En cualquier caso intentar mantener la duración T1-T2 corrigiendo el Trim inicial si es posible para que el corte de audio esté en una posición óptima de silencio.
Si hubiera siempre ruido hacer mute en los primeros 50 ms y fade-in a los siguientes 50 ms.

Si más o menos todo ha cuadrado lo más probable es que la sincronía sea perfecta.
Como mucho puede haber un Delay global pendiente si los cortes intermedios se han hecho exactamente iguales a los cortes de vídeo.

Como dices con un VFR es difícil comprobar la sincronía perfecta. Solo se me ocurre lo siguiente:

- Buscar en el vídeo un fotograma coincidente con un ruido seco (golpe, cierre de puerta, comienzo de explosión, ...)
- Buscar en el timecode.txt a que milisegundo se comienza a visualizar ese fotograma.
- Verificar en el editor de audio a que milisegundo comienza ese ruido.
La diferencia será el Delay global necesario.

Al volver a revisar los datos avanzados de MediaInfo antes posteados, en la parte de audio, tanto en el TS como en NUEVO.MKV hay un delay de 00:00:00.008 y 00:00:00.009 respectivamente.

Lo que entiendo es que debería reutilizar los trims iniciales y que serán aplicados al audio, pero ajustando las partes según ese delay. ¿No?

Citar
Citar
Citar
copy /b *.ts Archivo.ts
PAUSE

¿Un codigo así sirve también para unir otro tipo de archivos? ¿Como dos archivos AC3?

Sirve para unir ciertos tipos de archivos, aquellos que no tienen cabeceras globales sino cabeceras de datos distribuidas a todo lo largo del stream.
No vale para MP3, MP4, M4A, MKV, MKA, M2TS, AVI...

Vale para AC3, DTS, AAC (con cabeceras ADTS no en contenedor mp4 como .m4a) ...
Aunque deberán tener comunes ciertas características: Número de canales, Samplerate y Bitrate (en AC3 y DTS que son CBR, no necesario en AAC)

Comprendo. Si eso sirve automatizar una unión de archivos, en el caso de un solo TS constante al contrario del caso expuesto en este tema y al que se le desea quitar partes sin comprimir. ¿Como podría hacerlo? Una vez bajé TSSniper pero al tratar de importar el video, el programa muestra un error. ¿O se puede hacer algo con AviSynth cargandolo directamente sin indexarlo?

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #20: 01 de Noviembre de 2016, 19:49 »
Al volver a revisar los datos avanzados de MediaInfo antes posteados, en la parte de audio, tanto en el TS como en NUEVO.MKV hay un delay de 00:00:00.008 y 00:00:00.009 respectivamente.

Lo que entiendo es que debería reutilizar los trims iniciales y que serán aplicados al audio, pero ajustando las partes según ese delay. ¿No?
Claro esos 9 ms de delay se los puedes restar a todos los tiempo. No obstante son unos valores despreciables.
Siempre que no se haya usado un decodificador que ya haya compensado el Delay.
Por ejemplo si se usa eac3to para decodificar ese delay ya está incluido en el .wav y no hay que modificar los tiempos.

Citar
... en el caso de un solo TS, de fps constsnte, y al que se le desea quitar partes sin comprimir. ¿Como podría hacerlo? Una vez bajé TSSniper pero al tratar de importar el video, el programa muestra un error.
Puedes probar Avidemux, pero no te garantizo nada, apenas uso archivos .ts

Citar
¿O se puede hacer algo con AviSynth cargandolo directamente sin indexarlo?
No, en AviSynth siempre se carga a través de decodificadores, solo maneja audio/vídeo descomprimido.

Continuando con el tema del Trim he creado un Trim-Aud.vbs para vídeos de fps constante, es decir necesita el fps del vídeo y la línea de Trim, no los timecodes.
Se le arrastran los audios a cortar y genera los .bat.
Incluso ejecutandolo sin arrastrar nada crea un .bat modelo para usar los tiempos en un editor.
Sería el equivalente al Split_AUD de TheFluff pero sin necesidad de instalar Perl.

EDITO: bug en Trim-Aud.vbs (contaba una frame menos en cada Trim, en Trim-TimeC estaba bien)
Incluido más adelante.
« Última modificación: 03 de Noviembre de 2016, 02:16 por tebasuna51 »

wolf

  • Miembro milenario
  • ******
  • Desconectado Desconectado
  • Registrado: 06/07/2007
  • Mensajes: 1.420
  • Valoración: 43
Re:H264 con fps engañoso
« Respuesta #21: 02 de Noviembre de 2016, 00:22 »
Al final os está quedando un hilo muy, pero que muy interesante y didáctico. Nada, me he colado un momentito para agradecer y descargarme la herramienta que se ha currado tebasuna, que a mi me va a venir de 'perlas'. :si: :arriba:

Saludos. :saludo:

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #22: 02 de Noviembre de 2016, 06:48 »
Al volver a revisar los datos avanzados de MediaInfo antes posteados, en la parte de audio, tanto en el TS como en NUEVO.MKV hay un delay de 00:00:00.008 y 00:00:00.009 respectivamente.

Lo que entiendo es que debería reutilizar los trims iniciales y que serán aplicados al audio, pero ajustando las partes según ese delay. ¿No?
Claro esos 9 ms de delay se los puedes restar a todos los tiempo. No obstante son unos valores despreciables.
Siempre que no se haya usado un decodificador que ya haya compensado el Delay.
Por ejemplo si se usa eac3to para decodificar ese delay ya está incluido en el .wav y no hay que modificar los tiempos.

Citar
... en el caso de un solo TS, de fps constsnte, y al que se le desea quitar partes sin comprimir. ¿Como podría hacerlo? Una vez bajé TSSniper pero al tratar de importar el video, el programa muestra un error.
Puedes probar Avidemux, pero no te garantizo nada, apenas uso archivos .ts

Citar
¿O se puede hacer algo con AviSynth cargandolo directamente sin indexarlo?
No, en AviSynth siempre se carga a través de decodificadores, solo maneja audio/vídeo descomprimido.

Al final opté por el proceso de editar el audio en un editor (Audacity) desde el final hasta el principio como lo mencionas. Hice comparativa de los tiempos a cortar que fueron generados por el primer .bat que dividía en varias partes el audio, y los tiempos de corte realizados en el editor.

Tiempos de los timecodes del video
Citar
00:00:06.473,00:11:31.257,00:16:11.571,00:24:58.597,00:29:08.847,00:31:12.704

Tiempos del audio
Citar
00:00:06.405,00:11:31.209,00:16:11.452,00:24:58.525,00:29:08.754,00:31:12.626

Cabe mencionar que el audio fue cargado directamente siendo un AAC en lugar de haber previamente pasado a WAV (supongo que hice todo al revés). Después de los cortes, exporté el audio a WAV para posteriormente convertirlo a AAC con eac3to. Tuve unos inconvenientes con este paso ultimo ya que sus tiempos eran más que el video en ns y tuve que quitarle ms varias veces al WAV para que el AAC tuviera tiempo similar al video. Sin mencionar que el delay de 20ns que MKVToolNix GUI agregaba sin que yo lo hiciera, complicó un poco las cosas pero al final quedó bien.

Citar
Continuando con el tema del Trim he creado un Trim-Aud.vbs para vídeos de fps constante, es decir necesita el fps del vídeo y la línea de Trim, no los timecodes.
Se le arrastran los audios a cortar y genera los .bat.
Incluso ejecutandolo sin arrastrar nada crea un .bat modelo para usar los tiempos en un editor.
Sería el equivalente al Split_AUD de TheFluff pero sin necesidad de instalar Perl.

Genial, eso es muy practico y gran aporte.
« Última modificación: 02 de Noviembre de 2016, 14:22 por Naoto »

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #23: 02 de Noviembre de 2016, 13:13 »
Cabe mencionar que el audio fue cargado directamente siendo un AAC en lugar de haber previamente pasado a WAV
Eso depende del decodificador que use Audacity, algunos añaden un delay del orden de 40 ms.

Citar
Tuve unos inconvenientes con este paso ultimo ya que sus tiempos eran más que el video en ns y tuve que quitarle ms varias veces al WAV para que el AAC tuviera tiempo similar al video.
Efectivamente, viendo los cortes, cabría esperar un audio 82 ms más largo:
Código: [Seleccionar]
         Trim(193,20663)     ++    Trim(28974,44768)    ++  Trim(52151,55862)
       ----------------------    ----------------------    ----------------------
Vid 00:00:06.473,00:11:31.257,00:16:11.571,00:24:58.597,00:29:08.847,00:31:12.704
Aud 00:00:06.405,00:11:31.209,00:16:11.452,00:24:58.525,00:29:08.754,00:31:12.626
       ---------    ---------    ---------    ---------    ---------    ---------
              68           48          119           72           93           78
              ---------------          ----------------           ---------------
Total +82 ms:      + 20 ms                 + 47 ms                     + 15 ms
En cada Trim has seleccionado algo más de audio que de video, hay que procurar mantener los segmentos de igual duración, incluso reajustando los Trim si el audio necesita esos cortes. Con una frame más en cada Trim se hubiera ajustado más.

No obstante, a efectos prácticos, no se suele notar asincronía por 82 ms.

Citar
Sin mencionar que el delay de 20ns qye MKVToolNix GUI agregaba
No sé a que te refieres con eso, en cualquier caso 20 ns es indetectable.

Citar
... pero al final quedó bien.
Pues nada, eso es lo importante. Al menos se ha solucionado el problema.


Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #24: 02 de Noviembre de 2016, 16:23 »
Cabe mencionar que el audio fue cargado directamente siendo un AAC en lugar de haber previamente pasado a WAV
Eso depende del decodificador que use Audacity, algunos añaden un delay del orden de 40 ms.

Eso explica las dudas que tenía cuando usaba Audacity anteriormente con más frecuencia y notaba que había algo de asincronia en los multiplexados que hice.

Como decía, no estaba seguro al principio si era correcto el proceso que seguí, o si debí primero pasar a WAV y editar este ultimo en Audacity para después exportar el proyecto a un nuevo WAV que sería codificado a AAC con eac3to. De cualquier manera, supongo que habría tenido que quitar muchos ms extra al principio del audio.

Ya que menciono a Audacity. ¿Conoces de otros editores que use de plugins externos para soportar varios formatos? Tengo instalado también Adobe Audition pero éste está limitado en soporte de formatos. También usaba el viejo Cool Edit y le instalé algunos plugins, pero por sus limitaciones y obsolescencia, lo dejé.

Citar
Citar
Tuve unos inconvenientes con este paso ultimo ya que sus tiempos eran más que el video en ns y tuve que quitarle ms varias veces al WAV para que el AAC tuviera tiempo similar al video.
Efectivamente, viendo los cortes, cabría esperar un audio 82 ms más largo:
Código: [Seleccionar]
         Trim(193,20663)     ++    Trim(28974,44768)    ++  Trim(52151,55862)
       ----------------------    ----------------------    ----------------------
Vid 00:00:06.473,00:11:31.257,00:16:11.571,00:24:58.597,00:29:08.847,00:31:12.704
Aud 00:00:06.405,00:11:31.209,00:16:11.452,00:24:58.525,00:29:08.754,00:31:12.626
       ---------    ---------    ---------    ---------    ---------    ---------
              68           48          119           72           93           78
              ---------------          ----------------           ---------------
Total +82 ms:      + 20 ms                 + 47 ms                     + 15 ms
En cada Trim has seleccionado algo más de audio que de video, hay que procurar mantener los segmentos de igual duración, incluso reajustando los Trim si el audio necesita esos cortes. Con una frame más en cada Trim se hubiera ajustado más.

No obstante, a efectos prácticos, no se suele notar asincronía por 82 ms.

Después de cortar la parte del T1 y exportar a WAV con Audacity, al WAV lo edité en Adobe Audition eliminando ms del inicio y sobrescribiendo el archivo cada vez que convertía ese WAV a AAC y comparaba con los tiempos del video pero no conseguía que fueran similares hasta después. Al final, cuando lo logré, me di cuenta que eliminé como 153 ms aproximadamente.

A falta de una linea de tiempo y video para asegurar que los cortes del audio estarían acordes con el video, tuve que depender de la suerte y revisar varias veces esas partes en el video para saber donde tenía que cortar

Usé Audition para editar el WAV en lugar de seguir en Audacity debido a que en Audition e incluso Cool Edit, es más cómodo navegar y hacer zoom en el gráfico de picos con la rueda del mouse.

Citar
Citar
Sin mencionar que el delay de 20ns qye MKVToolNix GUI agregaba
No sé a que te refieres con eso, en cualquier caso 20 ns es indetectable.

No se si tiene que ver algo el encoder que usa eac3to, pero cuando revisaba con MediaInfo el AAC dentro del M4A, no había nada referente a un delay añadido. Pero después de multiplexar el video y audio, al revisar el MKV con MediaInfo, noté que en la parte de audio se le añadió un delay 20 ms. Revisé en MKVToolNix y en Delay no escribí nada como para que en el MediaInfo del MKV diga que tiene un delay de 20 ms.

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #25: 02 de Noviembre de 2016, 17:08 »
A propósito del delay codificando con eac3to lee este post http://www.mundodivx.org/foro/index.php?topic=44202.0

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #26: 03 de Noviembre de 2016, 02:37 »
He probado Trim-Aud.vbs capturando el episodio de Velvet (Antena 3 HD) y he descubierto que contaba una frame de menos en cada Trim (en Trim-TimeC está bien).

Adjunto nueva versión.

La verdad es que funciona perfectamente, he capturado un ts de 5 gb, lo he indexado con DGIndexNV que me ha generado además el audio:
aud DELAY -1432ms.mp2

Arrastrado sobre Trim-Aud.vbs me ha generado el .bat, y ejecutado un .mka que sincroniza perfectamente con el vídeo de Trim:
Trim(1445,14480) + Trim(16199,67645) + Trim(88496,127476)

Parece que aplica correctamente incluso el Delay del nombre y, decodificado, los cortes son suaves y sin que incluya audios de comerciales ni parece que falte nada.
Lo usaré algunas veces más a ver si hay algún problema. Si va bien incluiré la función en UsEac3to (que ya conoce donde está mkvmerge).
Podéis editar el .vbs para poner la ruta exacta de mkvmerge en vuestro PC (la que hay es la ruta en el mio) y ya no tendréis que modificar cada .bat

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #27: 05 de Noviembre de 2016, 19:53 »
A propósito del delay codificando con eac3to lee este post http://www.mundodivx.org/foro/index.php?topic=44202.0

Muy informativo el post y me sacó de dudas a otras que tenía, como esta.

Citar
El motivo es que el soft del codificador necesita inicializarse codificando silencio, para garantizar que cuando lleguen las muestras reales de audio no se produzca un cambio abrupto que genere una distorsión inicial.

Creo que eso explica por qué a veces en Sony Vegas al importar un audio, o un video con más de una pista de audio, éstos al inicio del audio hay un golpe de ruido de algunos ms.

He probado Trim-Aud.vbs capturando el episodio de Velvet (Antena 3 HD) y he descubierto que contaba una frame de menos en cada Trim (en Trim-TimeC está bien).

Adjunto nueva versión.

La verdad es que funciona perfectamente, he capturado un ts de 5 gb, lo he indexado con DGIndexNV que me ha generado además el audio:
aud DELAY -1432ms.mp2

Arrastrado sobre Trim-Aud.vbs me ha generado el .bat, y ejecutado un .mka que sincroniza perfectamente con el vídeo de Trim:
Trim(1445,14480) + Trim(16199,67645) + Trim(88496,127476)

Parece que aplica correctamente incluso el Delay del nombre y, decodificado, los cortes son suaves y sin que incluya audios de comerciales ni parece que falte nada.
Lo usaré algunas veces más a ver si hay algún problema. Si va bien incluiré la función en UsEac3to (que ya conoce donde está mkvmerge).
Podéis editar el .vbs para poner la ruta exacta de mkvmerge en vuestro PC (la que hay es la ruta en el mio) y ya no tendréis que modificar cada .bat

Estupendo.

Naoto

  • Miembro junior
  • **
  • Desconectado Desconectado
  • Registrado: 23/10/2015
  • Mensajes: 99
  • Valoración: 0
Re:H264 con fps engañoso
« Respuesta #28: 11 de Noviembre de 2016, 15:04 »
He probado la nueva versión de Trim-Aud con algunos TS JP que son más fáciles de trabajar y va bien, un gran trabajo y simplificaste el proceso que antes se seguía para estos casos.  :arriba:

Una cosa. ¿Podrías preparar otra variante de Trim-Aud que haga algo similar que el Timecodes_Aud original que preparaste? Es decir, que al arrastrar el audio y después de ingresar el numero de FPS y la linea de Trims, pero que en lugar de omitir las partes no incluidas en los Trims, se conserve los audios de todas las partes cortadas para poderlas unir como desee. ¿O tranquilamente es esa variante se podría ingresar una linea como esta "Trim(0,3239)+Trim(3240,22434)+Trim(22435,40524)+Trim(40525,43404)+Trim(43405,44319)" para tener cada una de esas partes?

tebasuna51

  • Colaborador
  • ******
  • Desconectado Desconectado
  • Registrado: 22/02/2010
  • Mensajes: 3.416
  • Valoración: 120
Re:H264 con fps engañoso
« Respuesta #29: 11 de Noviembre de 2016, 22:50 »
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: