Sound recovery delay

[Trev]

I am running detectads with crop in chaseplay (if that matters) and find that after the usual short period of pixellation around the crop point, the audio takes a good couple of seconds before it comes back on is this usual? And is there a fix/setting that I have missed?

 

[Black Hole]

This might be a natural consequence of the different frames in the video and audio data. It's all very well looking for an I-frame in the video feed and cropping at that point, but it is unlikely the audio stream data frame is also complete at that point (unless maybe the streams are designed that way?).

If I understand correctly, there is currently no backward interpolation from the next I-frame, only forward interpolation from the previous I-frame. In which case, if the cropped video starts with an I-frame, why is there any pixellation at all??

 

[MymsMan]

It is well known and the proper solution is unknown, sometimes there is no sound loss or pixellation other times it can be significant.

nicesplice does search backwards and forwards to find an I-frame and the end of ad should be a significant scene change requiring an I-frame so I don't understand why we sometimes have problems.

You can add padding to the ad-breaks using the -padSec option see https://wiki.hummy.tv/wiki/DetectAds#Options
Options can be different for each series https://wiki.hummy.tv/wiki/DetectAds#Folder_Flags

edit correct spelling it should be -padSec not -padSecs

 

[Trev]

Thanks BH and Myms.
I have looked at and had a 'play' with the -padSecs, but it doesn't seem to make any difference and I can't get it straight in my head exactly what it is supposed to do anyway. The picture has its little pixellation moment, that recovers and then after 2-3 secs the sound comes back.

 

[MymsMan]

The idea is to pad the break by a few secs so that the sound has recovered before the real programme restarts

 

[Trev]

Ah. I see it all now. Simples. I think I have been padding the wrong way. Doh
So to save me conducting extensive experiments, to bring the end of the crop 'further back' into the ad, do I need to use a negative value for -padSecs?

 

[Black Hole]

"-padSecs" does not imply a negative value - the "-" is simply the Linux/Unix convention for indicating a command option, and so far as I can see "-padSecs 3" would provide a 3 second guard window in the crop to allow that long for sound and vision to resync after the crop before the beginning of wanted material.

 

[Trev]

Thanks BH. Yes I realise that about the naming of -padSecs. To me, padding (as in recording) extends the recording by the number of padding mins both at the start and the end. This is not what I want to do with the ads.

I want to set the value so that it includes more of the end of the adverts (i.e. shorten the amount of stuff cut out by detect ads, preferably just at the end of the ad) so that the sound recovers at the start of the continuation, not 2-3 seconds later.
My question is, do I need a positive or negative value of -padSecs to end the crop earlier (without the inclusion of words such as "as far as I can see", "might", "should" etc. implying uncertainty about the answer given) thus include a bit more of the ad at the end of the crop to allow the sound to sync before the wanted stuff starts.?
I also appreciate that I could (can) ponce around with the values myself to find out, but if someone knows for sure, it will save me the trouble.
Having said that, I would probably saved myself a bunch of time by just doing the poncing around. However, the 'error' is not 100% repeatable as pointed out by MymsMan above, so I would still be unsure whether my poncing or variations of the crop routine have worked or not.

 

[Black Hole]

so I would still be unsure whether my poncing or variations of the crop routine have worked or not.

To see whether your poncing works, all you need to do is look at whether you get the end of the ad break left at the start of the next section of programme. Whether or not the disturbance remains present is irrelevant to whether the padding setting is correct.

do I need a positive or negative value of -padSecs to end the crop earlier

Ask yourself whether the pre-padding setting in the standard menus requires a positive or negative value in order to add a guard interval.

without the inclusion of words such as "as far as I can see", "might", "should" etc. implying uncertainty about the answer given

You want to have your cake and eat it. I am not in a position to test and confirm what I concluded from the wiki information, and if I had implied certainty I would have been (correctly) challenged for claiming knowledge. Nonetheless it seems clear to me (although examples of use for each switch would have clarified - until I looked into it I was not sure what the correct syntax is, it could have been "-padSecs=3" for example). I am not in any confusion that the value might need to be negative!

 

[Trev]

Thank you for your research. I am obviously going to have to ponce around with some stupid big numbers to be certain of what's going on. But someone with in depth knowledge of how it works could just say Yes or No to my question without any uncertainty.
I shall report back.

 

[MymsMan]

You need -padSecs 10

 

[Trev]

Thanks Myms. I just tried 15 earlier, but haven't checked the result. I'll change it to 10 and try again and report back.

 

[TimK2015]

You need -padSecs 10

Should this be 'padSec' or 'padSecs' - the entry in the Wiki doesn't have the 's' on the end or doesn't it matter?

 

[MymsMan]

Should this be 'padSec' or 'padSecs' - the entry in the Wiki doesn't have the 's' on the end or doesn't it matter?

Oops, well spotted the options are case insensitive but don't tolerate misspeelings which I am very likely to make.

So it should be -padSec 10

Apologies for misleading everyone