Of course, you can use it also for the cutting part, so you wouldn't need ffmpeg at all to begin with in this case. Instead, you can use some audio editing program like audacity, which decodes the whole file in the beginning, so the timings should be accurate there. In summary, for getting the exact timing in an mp3, using the timestamps shown by a player like vlc or mplayer doesn't seem to be a good option. You can demonstrate this effect very good by running vlc and seeking close to the end and see vlc continue playing past 43 minutes (I tried seeking at 42:42 and it played until 43:08). I believe the actual problem here is the players showing the wrong timestamp when seeking (I tried both vlc and mplayer, and they seem to behave similarly): If I let vlc play the file from start without seeking forward (I actually let it run in the background for 20 minutes!), when it reaches 20:48 it is at exactly the same position where the file produced by ffmpeg starts! If instead I start playing in vlc, and skip forward, that location will be presented as 20:28 instead! My guess here is, that seeking on those players just skips to the next keyframe (or something similar? Not very familiar with the internals of the mp3 format) and just estimates the time passed based on the bitrate (which is variable). I did some tests with the file you provided, and I believe your ffmpeg command actually cuts the file at the exact location you are asking it to. I'm looking the understand the root cause of the error in the extracted snippets and correct it. I tried to reset this to zero anyway, trying variations of this answer, I wasn't successful. Within the output, I saw this:ĭuration: 00:43:00.09, start: 0.025057, bitrate: 141 kb/s I interpret this as the file is "tagged" as starting 25 milliseconds in.
Given the same results from both command line tools, this suggests the issue lies with the input file. This generates the same output, a file that is the correct length but 20 seconds early in terms of the expected start time. I am aware that this is an old version), with this command: mp3splt "/home/user/GQT_.mp3" -o GQT_Snippet1 20.48.00 24.46.00 Then I tried using Mp3Splt (version 2.6.2 on the same OS. This generates a file that is 3 minutes 58 seconds long but the start time corresponds to 20:28 in the original file.
I tried this first using FFmpeg (version 4.2.7-0ubuntu0.1 on Ubuntu 20.04), with this command: ffmpeg -i "/home/user/GQT_.mp3" -ss 00:20:48 -t 00:03:58 GQT_Snippet1.mp3 I would like to extract a snippet that starts at 20:48 and lasts 03:58, so it finishes at 24:46 The file is downloaded and plays correctly.
#MP3 EXTRACTION DOWNLOAD#
I start off by using yt-dlp to download a podcast, such as this one with this command: yt-dlp -x -audio-format mp3 -o GQT_.mp3 Problem Description / Reproduction steps: Note: I realise there are other approaches to share the content, I'm doing it this way to share the content with users who are either not very computer literate or geo-blocked from the raw content. I get consistent, unexpected results and I believe this is due to how the audio files were created/encoded. My transcoding options will be dynamic for sure so I need something a little more sophisticated than a one liner.I am trying to extract audio snippets using command line tools. FairStars CD Ripper also supports normalization when.
The interface is user-friendly and includes ID3 tagging, handles multiple CD/DVD drivers, and comes with audio playback controls.
#MP3 EXTRACTION SOFTWARE#
I've made a script similar to yours, however I want to get the best possible quality audio files I can without wasting any space. FairStars CD Ripper is a donationware Windows program that is a powerful software for ripping audio CD tracks to WMA, MP3, OGG, VQF, FLAC, APE, and WAV formats. If you get it sorted please do post what you've done because I'm not satisfied with the obvious methods of processing the 1000's of video files I need to demux. Perhaps you could extract the audio file in a lossless format and then transcode the audio file but there has to be a better way than that. Have you considered using a command like ExifTool to view information about the file and setting your options accordingly (perhaps even parsing the output & automating it in your script)? I've never tried it but the "remove_extra" filter sounds promising ) -absf bitstream_filterīitstream filters available are "dump_extra", "remove_extra", You may want to try setting an audio bit stream filter in ffmpeg. Restrict the transcoded/captured video sequence to the duration Have you tried the -t option? -t duration Have you tried it with other avi files? The audio track of the file might be longer than the video track (just a guess).
0 kommentar(er)
