"ffmpeg -ss" supported formats for accurate seeking? mp3 does not appear to work, only .wav

2

ffmpeg -ss 00:00:00 -i 'input.mp3' -to 00:25:00 -c copy output.mp3

I noticed while scripting that this particular script that it works for mp3 files but not for .wav files. What happens is it copies (strangely) to a 25 minute .mp3 file but it clips the audio at the end intrinsically. Seems to stretch the actual audio beyond the 25-minute boundary for some reason thus clipping happens. This doesn't happen with .wav files though. Searching through the man pages I came across this below:

-ss position (input/output) When used as an input option (before -i), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.

My question is, first, it appears that .mp3 is not a supported format that seeks exactly, but it appears that .wav files are supported given what happened. Is this the reason why it clipped the audio? Second, is there any documentation regarding supported formats that have 100% accurate -ss times? I can't find that in any of the man pages. Maybe documentation exists but if it does I'm guessing it should have been listed in that section. This is bad documentation on ffmpeg and should be updated! Vague information that's not helpful.

Nathan

Posted 2019-07-19T05:14:56.930

Reputation: 23

How much is the clipping i.e. time missing? – Gyan – 2019-07-19T07:37:52.730

Answers

1

The only formats that are perfectly seekable, are non compressed formats. I.e. wav and pcm. All compressed formats encode into “frames” (because that’s how compression works). Using codec copy, you can only copy entire frames. Every codec uses a different number for samples per frame.

szatmary

Posted 2019-07-19T05:14:56.930

Reputation: 2 181

1Did not know that! Thanks for the fantastic answer. – Nathan – 2019-07-20T05:14:31.197

What relevance does this have in this scenario? This isn't about the quantization of media. MP3 frame duration for a 44100 Hz stream is 23 milliseconds. So even if the outpoint pts fell on an exact frame start, output would be only one frame short. FFmpeg seek is also not relevant as OP's command seeks from time 0. – Gyan – 2019-07-20T06:11:21.037

It’s relevant if you seek to 10 Milliseconds. – szatmary – 2019-07-20T06:28:19.227