Audio Offset

[YellowYeti]

> I hadn't when he asked, but have since noticed it on last Thursday
> night's _This Week_ downloaded on Friday.  I adjusted the syncing
> between the audio and video streams within the file to fix with
> something like
>
>      ffmpeg -itsoffset 0.4 -i foo.mp4 -i foo.mp4 \
>          -map 0:1 -map 1:0 -c copy new-foo.mp4
>
> IOW, have ffmpeg read the same file twice, taking the audio from one,
> and the video from another, copying them into a new file, so no
> transcoding, but with an "input time offset" applied to one of them of
> 0.4 s.  The corrective delay is found through experimentation and adding
> a `-to 00:00:30' after the `-c copy' helps that by quickly producing
> just a 30 s snippet of programme to check.
>
> No, I don't know how to get the get_iplayer GUI to do this.  :-)
The 'old' recording of HIGNFY has the sound starting somewhere in the 
middle of the continuity announcement before the programme itself starts.
The video starts with the programme titles. The 'new' recording, with no 
offset, starts with the programme titles - i.e. the video is the same 
for both recordings, it is the audio that is different.

Is there perhaps some automated up-loading that takes place by the beeb, 
on a timed basis, which is eventually edited by someone to correct to 
the start of the programme?

If that is the case, it may be possible to compare audio & video length 
after downloading? My concern is that this appears to be something that 
can happen at random times, and give random offsets - and means either 
not using hq audio, or having to check each download.