7

I have a hard time trying to figure out how to cut a file with avconv. Here's the command I use:

avconv -ss 52:13:49 -t 01:13:52 -i RR119Accessibility.wav RR119Accessibility-2.wav 

But it doesn't work. I get the whole file as a result. Well, almost the whole file. Somehow the resulting file has duration 1:16:31 instead of 1:17:23. Also I believe I executed this command in every possible way: with -ss and -t after -i, with -t specifying ending point, with mp3 files, with specifying audio codec, with ffmpeg. Am I doing it wrong?

UPD Thanks to bodhi.zazen this works (I corrected the offset and duration reported by mp3splt-gtk, they were wrong for some reason or other, and the goal was to cut mp3 file)

avconv -i RR119Accessibility.mp3 -ss 00:52:08 -t 00:01:08 RR119Accessibility-2.mp3

But this doesn't:

avconv -ss 00:52:08 -t 00:01:08 -i RR119Accessibility.mp3 RR119Accessibility-2.mp3

The resulting file start at 00:52:08 and goes until the end of the original file. I thought -ss and -t are related to input file if specified before -i. And to output file otherwise. Could someone explain this?

  • 1
    the time format is HH:MM:SS, is the file really 50+ hours long? personally I use ffmpeg – Panther Nov 2 '13 at 21:41
  • Oh, you're right. I remember I thought about it but somehow I decided that I'm not mistaken. – x-yuri Nov 2 '13 at 22:13
  • so is it working now? – Panther Nov 2 '13 at 22:19
  • Basically, yes. But there is one minor thing I don't understand. I've updated the question. But anyway, you can turn your comment into answer and I'll accept it. And I use avconv because ubuntu's ffmpeg says that it's obsolete. – x-yuri Nov 2 '13 at 22:26
8

I think the original problem was with the formatting of your time stamp.

The format is HH:MM:SS

I am not sure I am understanding your question about the order of the options. I do not think it matters as long as -i is followed by the input file name and -ss HH:MM:SS followed my -t HH:MM:SS

The -ss HH:MM:SS is the starting point, and -t HH:MM:SS is the duration

so -ss 00:01:00 -t 00:05:00 would start at the one minute mark and run for 5 minutes.

On my system, using ffmpeg, order does not matter (you can specify time or input file in any order so long as -ss is followed by the duration (-t) )

| improve this answer | |
  • 1
    Well, out of 4 variants (ffmpeg -i -ss -t, ffmpeg -ss -t -i, avconv -i -ss -t, avconv -ss -t -i), only the last one doesn't work as expected. That is, instead of getting [offset:offset+specified-duration] I get [offset:original-duration] (if that clarifies matters). If you've got any ideas, I'm all ears :) – x-yuri Nov 2 '13 at 23:06
  • And this way it works: avconv -ss ... -i ... -t ... ... – x-yuri Nov 2 '13 at 23:17
  • 3
    Consider adding -acodec copy to stream copy instead of re-encoding. This avoids re-encoding and therefore avoids the potential of quality loss. The placement of -ss can change the behavior of this option (depending on several factors). -t is an output option, so placement should not matter as long as it is used as an output option (after -i). There is also the -to option. (None of my comments may apply to libav's junk). – llogan Nov 3 '13 at 1:57
2

The problem comes from the different meaning of -ss depending upon where in the command line it is. It's a carry over from the days when avconv was still a part of ffmpeg project, and i believe it is being fixed in the newer versions.

In the olden days if you said something like

 ffmpeg -ss 5 -i input

What you meant was "skip to the 5 second mark in the file and begin to read there".

But if you said

ffmpeg -i input -ss 5

You meant "open the input file and skip all the data until the five second mark".

As you can understand the first approach will actually fail quite often, because you are skipping in the file without reading it. It works well only on the files which have timestamps in them, allowing you to read the frame and know if you've gone too far already or not.

Basically the way it worked in ffmpeg was "Guess the bitrate by the first second, and then assume that all other seconds are the same". But, of course, not all the seconds are the same, and if we are talking about a 52 hours of "drift" the error can be quite large.

So if you are using the early post-split version of avconv you should always put -ss after the file that is being read. But in the newer versions (to the best of my knowledge) this bug was fixed.

| improve this answer | |
  • This seems to be some other issue. Both variants start with the right offset, it's the duration that is wrong in the first variant. – x-yuri Nov 15 '14 at 16:57
0

Try:

avconv -i RR119Accessibility.wav -ss 52:13:49 -t 01:13:52 RR119Accessibility-2.wav

The options of ffmpeg and avconv are position sensitive.

In your example ffmpeg starts reading the file and starts outputting from timestamp -ss
(which ffmpeg does well on my system and avconv does not, call it a regression of sorts).

In the example I have given here, avconv (or ffmpeg for that matter) seeks first to the right offset and then starts reading and outputting. This works for both.

You can find more documentation about avconv on http://libav.org these guys have forked off ffmpeg and are also responsible for the extremely old ffmpeg version in Ubuntu.

The REAL ffmpeg is not in the ubuntu repositories but in a PPA:
ppa:jon-severinsson/ffmpeg
You can find more documentation about ffmpeg on http://ffmpeg.org

Consider the man pages out of date

| improve this answer | |
  • I do not think ffmpeg is depreciated. Unless you have a specific need for an updated verson of ffmpeg, you should probably stay with the version in the repos. – Panther Nov 2 '13 at 22:32
  • But that's what it says: "*** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead." But yes, unless I have a specific need, I can probably use the version in the repos. – x-yuri Nov 2 '13 at 22:48
  • 1
    It appears it's libav's ffmpeg that is deprecated. For details, see these questions – x-yuri Nov 2 '13 at 22:57
  • Yes x-yuri, that is correct. The current ffmpeg (by ffmpeg) is many versions newer than the old (depricated) hog shipped by libav. Pity they don't co-exist in the repo's – thom Nov 2 '13 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.