Extracción de fragmentos de audio de un archivo mp3: resultados inesperados

Extracción de fragmentos de audio de un archivo mp3: resultados inesperados

Estoy intentando extraer fragmentos de audio utilizando herramientas de línea de comandos. Obtengo resultados consistentes e inesperados y creo que esto se debe a cómo se crearon/codificaron los archivos de audio.

Nota: Me doy cuenta de que existen otras formas de compartir el contenido. Lo hago de esta manera para compartir el contenido con usuarios que no tienen muchos conocimientos de informática o que están bloqueados geográficamente para acceder al contenido sin procesar.

Descripción del problema/pasos de reproducción:

  • Empiezo usandoyt-dlppara descargar un podcast, comoÉstecon este comando:
    yt-dlp -x --audio-format mp3 -o GQT_2012-10-14.mp3 https://www.bbc.co.uk/programmes/b01n6vnh

  • El archivo se descarga y se reproduce correctamente. Me gustaría extraer un fragmento que comienza a las 20:48 y dura 03:58, por lo que termina a las 24:46

  • Probé esto primero usandoFFmpeg(versión 4.2.7-0ubuntu0.1 en Ubuntu 20.04), con este comando:
    ffmpeg -i "/home/user/GQT_2012-10-14.mp3" -ss 00:20:48 -t 00:03:58 GQT_2012-10-12_Snippet1.mp3
    Esto genera un archivo que tiene una duración de 3 minutos 58 segundos pero la hora de inicio corresponde a las 20:28 en el archivo original.

  • Luego intenté usarMp3Splt(versión 2.6.2 en el mismo sistema operativo. Soy consciente de que esta es una versión antigua), con este comando:
    mp3splt "/home/user/GQT_2012-10-14.mp3" -o GQT_2012-10-12_Snippet1 20.48.00 24.46.00
    Esto genera el mismo resultado, un archivo que tiene la longitud correcta pero 20 segundos antes en términos de la hora de inicio esperada.

Dados los mismos resultados de ambas herramientas de línea de comandos, esto sugiere que el problema radica en el archivo de entrada. Intenté inspeccionarlo usando ffprobe. En el resultado, vi esto: Duration: 00:43:00.09, start: 0.025057, bitrate: 141 kb/slo interpreto como que el archivo está "etiquetado" como si comenzara en 25 milisegundos. Ciertamente, no en 20 segundos.

Intenté restablecer esto a cero de todos modos, probando variaciones deesta respuesta, no tuve éxito.

Estoy buscando comprender la causa raíz del error en los fragmentos extraídos y corregirlo.

Respuesta1

Hice algunas pruebas con el archivo que proporcionó y creo que su comando ffmpeg en realidad corta el archivo en la ubicación exacta que le solicita.

Creo que el problema real aquí es eljugadoresmostrando la marca de tiempo incorrecta al buscar (probé ambos vlcy mplayerparecen comportarse de manera similar): si dejo vlcreproducir el archivo desde el principio sin buscar hacia adelante (¡de hecho, lo dejo ejecutar en segundo plano durante 20 minutos!), cuando llega a 20 :48 ¡está exactamente en la misma posición donde comienza el archivo producido por ffmpeg! Si en lugar de eso empiezo a jugar vlcy salto hacia adelante, ¡esa ubicación se presentará como 20:28! Supongo que la búsqueda en esos reproductores simplemente salta al siguiente fotograma clave (¿o algo similar? No estoy muy familiarizado con los aspectos internos del formato mp3) y simplemente estima el tiempo transcurrido en función de la tasa de bits (que es variable). Puedes demostrar muy bien este efecto ejecutando vlc y buscando cerca del final y viendo que vlc continúa reproduciéndose más allá de los 43 minutos (intenté buscar en 42:42 y se reprodujo hasta 43:08).

En resumen, para obtener la sincronización exacta en un mp3, usar las marcas de tiempo mostradas por un reproductor como vlco mplayerno parece ser una buena opción. En su lugar, puedes utilizar algún programa de edición de audio comoaudacity, que decodifica todo el archivo al principio, por lo que los tiempos deben ser precisos allí. Por supuesto, también puedes utilizarlo para la parte de corte, por lo que ffmpegen este caso no necesitarás nada.

información relacionada