Add option to stop writing at position relative to EOF

[clone206]

Summary of the bug:
Feature request
How to reproduce:
N/A

Add main option to allow stopping of writing to output at position relative to "end of file", where 0 is eof, and negative values are earlier in the file.

Proposed switch: "-toeof", like "-sseof" but for stopping point instead of beginning point.

Background: I have ripped SACD audio tracks with extraneous loud noises at the last few hundred milliseconds of each track, and want to chop off that duration from the end of each file as part of a batch process. I would like to do something like the following on each file:

ffmpeg -i input.flac -toeof -00:00:00.9 output.flac

[Carl Eugen Hoyos]

Replying to clone206:
No new options can be requested for releases and I don't think this can be implemented.

Background: I have ripped SACD audio tracks with extraneous loud noises at the last few hundred milliseconds of each track, and want to chop off that duration from the end of each file as part of a batch process. I would like to do something like the following on each file:

Instead, please explain how we can reproduce (and fix) this bug.

[clone206]

This is not a bug that needs fixing. It's a feature request. Are you saying you don't accept feature requests, or rather that because I chose a release number the feature request is invalid?

I'm quite certain it could be implemented, since you already basically did the same thing with the -sseof option.

[withmorten]

Hi clone206,

I ran into a similar problem this week when I wanted to cut off one second of silence at the end of some files which I had added earlier (with ffmpeg).

It wasn't too hard to implement and can probably be improved on sanity check-wise, but it works for my purposes and can probably be used as a good starting point for properly implementing this by somebody who knows how ffmpeg is supposed to work:

​https://gist.github.com/withmorten/ea585798076fa020b757437f23aca768

Diffed against ffmpeg 3.4.2.

It only works as input option (duration seemed to be unknown in open_output_file), so you'll have to use it like:

ffmpeg -toeof -00:00:00.9 -i input.flac output.flac

It basically makes the input file shorter by whatever amount you tell it.

Not entirely sure why this would be impossible to implement ...?

[clone206]

Thanks, withmorten! That's basically exactly the way I would've done it. Might be worth forking the current github and making a pull request, though I don't know if Gyan is already working on it.

[Gyan]

Generate a patch against git master and send it to the mailing list.

[withmorten]

Should I modify the ffmpeg.texi file as well to include the new commandline switch?

Such as:

@item -toeof @var{position} (@emph{input})
Stop writing the output at @var{position} relative to the "end of file". That is negative
values are later in the file, 0 is at EOF.

[Gyan]

Please do. Thanks.

[Carl Eugen Hoyos]

I didn't consider -sseof working for any interpretation but if that is what you need, it may be possible.

Please do not forget to report the original bug, it would be nice to fix it.

[clone206]

cehoyos,

In what way is -sseof not working? For those of us interested in possibly contributing, it would be good to know, as I haven't had any issues with that option, which has been available for some time now.

Also, sorry if it wasn't clear, but I never reported a bug that needs fixing, but rather a feature request. If there is any documentation on how to properly make a feature request I would gladly familiarize myself with it.

[Carl Eugen Hoyos]

Replying to clone206:

Also, sorry if it wasn't clear, but I never reported a bug

This is not true, you just didn't explain how we can reproduce.

[clone206]

Reproduce what?

[GfE]

I was about to file the same feature request.
(Almost gave up, after losing over an hour on failing to understand where exactly ffmpeg wants FRs to go. Finally found this one, disguised as a /bug/.)

Alas, 7 years in, -sseof is still missing its -toeof counterpart.

Given ffmpeg's oftentimes steep learning curve, -ss, -to, and -sseof are amazingly simple and useful options. If exact frame accuracy doesn't matter and you e. g. quickly want to remove a fixed-length intro from a series of videos,
ffmpeg -y -ss -01:23.456 -i "${indir}"/*.mkv -c:copy "${outdir}"/*.mkv
is as efficient as can be.

Doing the same with outros needlessly requires /much/ more studying and dedication to ffmpeg concepts and features - if you succeed within your time constraints, at all.

Granted, solutions to complex problems tend to be complex. Also, complex solutions for simple but niche problems might not be worth the simplification effort.

However, the task of stopping to read input N seconds before its EOF isn't any more niche or complex than -sseof.

What happened to ​https://gist.github.com/withmorten/ea585798076fa020b757437f23aca768 why has it been ignored/stalled/dropped?

It's hard to imagine for a dozen lines' patch to provide more usability improvement to the less-advanced. People like me would greatly appreciate if the patch was

• updated as necessary to match the current codebase
• then applied/merged

[clone206]

Replying to GfE:

I was about to file the same feature request.
(Almost gave up, after losing over an hour on failing to understand where exactly ffmpeg wants FRs to go. Finally found this one, disguised as a /bug/.)

Alas, 7 years in, -sseof is still missing its -toeof counterpart.

Given ffmpeg's oftentimes steep learning curve, -ss, -to, and -sseof are amazingly simple and useful options. If exact frame accuracy doesn't matter and you e. g. quickly want to remove a fixed-length intro from a series of videos,
ffmpeg -y -ss -01:23.456 -i "${indir}"/*.mkv -c:copy "${outdir}"/*.mkv
is as efficient as can be.

Doing the same with outros needlessly requires /much/ more studying and dedication to ffmpeg concepts and features - if you succeed within your time constraints, at all.

Granted, solutions to complex problems tend to be complex. Also, complex solutions for simple but niche problems might not be worth the simplification effort.

However, the task of stopping to read input N seconds before its EOF isn't any more niche or complex than -sseof.

What happened to ​https://gist.github.com/withmorten/ea585798076fa020b757437f23aca768 why has it been ignored/stalled/dropped?

It's hard to imagine for a dozen lines' patch to provide more usability improvement to the less-advanced. People like me would greatly appreciate if the patch was

• updated as necessary to match the current codebase
• then applied/merged

Yeah tbh I had forgotten about this. What an odd exchange. Don't know if I've ever felt so gaslit. I'm actually working on my own audio format conversion software, which is on github under the same username, so that I can work with more modern c++ and rust code and hopefully avoid such bafflement going forward.