Add the "Delay" Parameter Feature about ffmpeg-audio-encoder HOT 11 OPEN

I'll take a look at this tomorrow and see what can be done

from ffmpeg-audio-encoder.

Look at the latest release, let me know if this solves your issue/concerns.
Also, read in depth of the above to ensure you are doing what you'd need. As Time Modification is usually not used that often.

Hello, I'm wondering what do you think about it, please.

I'll keep this tab open so I can look at this and give you a proper respone sometime tomorrow.

from ffmpeg-audio-encoder.

I'll take a look at this tomorrow and see what can be done

Hello, some news regarding this?

from ffmpeg-audio-encoder.

Hey, sorry for the late response, this got list in my huge to do list spread over many projects.

I was looking into the code, what you want to achieve can easily be done with custom command line commands. I can certainly add 29 conversions to the code base, but first we need to ensure that you're using the command to achieve exactly what you want.

Generally best practice when it comes to negative/positive delays, this is done by the container itself. So if you was encoding your audio and putting it back into the container, you'd just feed the delay amount to the container/muxer and it would be in sync when you play it. This is why my default if you don't provide an output filename to FFMPEG Audio Encoder it will parse the language/detected delay from the input.

Once you split a video/audio file apart, they are no longer relative to each other. So, somewhere this delay needs to be stored if you plan to put them back together. This is the default/best practice way that 99% of people would do it.

However, what it appears you're asking for here is a way to essentially speed up/slow down the audio to match with the video. This is what the atempo command does, it has it's uses but I'm not 100% certain this is what you want. If so, I'll work on adding the values to atempo if it's not to difficult this morning and get a release out for it.

So to go over what we discussed:
atempo = speeding/slowing down the audio to match a desired framerate.
itsoffset = adds silence to the audio to sync (example if an input was 60 seconds and you used itsoffset 5 the output would be 65 seconds).
ss = removes part of the audio to sync (example if an input was 60 seconds and you used ss 5 the output would be 55 seconds).

BUT none of the above is needed at all what so ever, if you are encoding audio from a souce, then putting it back in. You'd only need to feed the delay ms to the muxer for it to be in sync as it originally was.

from ffmpeg-audio-encoder.

Look at the latest release, let me know if this solves your issue/concerns.

Also, read in depth of the above to ensure you are doing what you'd need. As Time Modification is usually not used that often.

from ffmpeg-audio-encoder.

Hello, thanks for your explanations, I already tried your tool's last version and now the framerates' conversion
works fine (I tried 23,976 > 24). What you mention respect adding a desired delay value to the container itself
is alright, but the thing is, I'm trying to avoid that, precisely because some players (mostly relatively old HDTVs)
will have problems when dealing with certain delay amount (let's say more than 2 o 3 seconds). And as you said,
exact delay values might get lost once the tracks/containers get repacked. So, in order to bypass that issue, once I
have a needed dubbing track correctly converted to match the target's movie framerate, in case a few hundreds
milliseconds or more are still needed to make it matches exactly with the original track's timings, I would have to load it
in a sound editor, to make the needed change. For example, right now I dealing with a movie's BD which includes a
dubbing track which I would need to add to another edition of the same movie (4K version), but despite both versions of
the movie have the same content, they differ in framerates and one of them have an additional "~ 3 seconds" delay at the beginning; so, ideally, I would like to use your tool to make all the needed changes at once, i.e., framerate's conversion (23,976 > 24) and introducing a permanent delay of "3000 ms" in the form of "digital silence" at the track's start.

If you could add a new option regarding the delays (+/-) values introduction, that would be great. Otherwise, please
tell me what exact command I should use, in order to achieve the delay use.

By te way, I see tools like the aforementioned "MeGUI" and another one (clever ffmpeg gui), have an additional "pitch correction" option (besides just a length related one) when dealing with framerate's conversions. So, I'm wondering if your tool
does the pitch correction by default, after applying one of the "time modification" options?

Thanks.

from ffmpeg-audio-encoder.

Look at the latest release, let me know if this solves your issue/concerns.

Also, read in depth of the above to ensure you are doing what you'd need. As Time Modification is usually not used that often.

Hello, I'm wondering what do you think about it, please.

from ffmpeg-audio-encoder.

@jlw4049

Look at the latest release, let me know if this solves your issue/concerns.
Also, read in depth of the above to ensure you are doing what you'd need. As Time Modification is usually not used that often.

Hello, I'm wondering what do you think about it, please.

I'll keep this tab open so I can look at this and give you a proper respone sometime tomorrow.

Hello, yesterday I needed to do some synchronization task with an audio file of certain movie, which has a "23,976"
framerate, and I needed to convert it to "24". I used your program with the relevant option an it did the conversion correctly,
but the resultant file needs an additional "3000 ms" delay value at the track's beginning, to compensate some seconds' difference present at the source audio. The thing is, I used the next custom command:

-af "adelay=1s:all=true"

but despite it worked (3 silence seconds were added at the track's beginning),
that screwed the synchronization. I think this problem might be due to the framerate conversion
(23,976 > 24) is taking into account those "3 seconds" as well, and not simply adding the needed
delay value as a separate step, after the conversion was done.

Do you know how should be added the above custom command in order it works properly? Or which one
would be the exact custom command to use, in order to add any desired delay, but without changing a
previous framerate conversion's task result?

Thanks.

from ffmpeg-audio-encoder.

Hello @Jack1789. I've been very very busy with other tools and work so I haven't done any work on what we talked about before.

In general when you're doing something like this you'll want to do this in a couple steps.

Step 1) You can use the GUI to do your frame rate conversion.

Step 2) You will likely want to feed this command directly to FFMPEG since atm my tool doesn't really do a codec copy, it's for encoding only for almost all codecs. What you need to do here is a command like:

ffmpeg -itsoffset 3 -i INPUT.mkv -c copy -map 0:v -map 1:a OUTPUT.mkv

Those above steps should achieve your desired results. If you need to get ahold of me quicker than this you can contact me on discord @jlw_4049

from ffmpeg-audio-encoder.

@jlw4049

For the time being, I'm using the tool I mentioned before (MeGUI), which despite its limitation regarding converting framerates between "23,976<>24", with the help of an external command (-af "atempo=24/23.976"), can still be used with the desired results and it will all involve just a single process. I don't mind about the recoding process, since any framerate conversion task will imply that, but I do care about it being just one single process, instead having to deal with other tools, containers (MKV) or additional repacks or recodifications.

I think since "MeGUI" can actually do the process correctly, your program should also be able to do it, but maybe it needs the relevant delay command to be applied properly.

Thanks.

from ffmpeg-audio-encoder.

I'm going to leave this open. Eventually I will add the delay add/strip features when time allows.

I'm pretty busy so it'll be quite some time without some incentive to work on it. Once I finish up some projects I don't mind taking a look at this again though.

from ffmpeg-audio-encoder.