Audio sync issue - PCM (AC3) audio in mpeg

[yetanotherid]

I'm in Australia and I've recorded some HD TV programs telling my tuner card to record the mpeg program stream. When I open it with Media Player Classic is plays without any issues, and MPC tells me it contains PCM (AC3) 6ch audio.

The problem starts when I try to convert to AVI. I get an audio sync issue whereby it's fine at the start, but by the end of a two our video it's around a second out.
When I look at AutoGK's temp folder the demuxed audio file is labelled as T80 2 channel audio. When opening that with MPC it again lists it's properties as PCM (AC3) 6ch audio, while if I open the AC3 file with foobar it tells me it's 2ch audio using the ATSC A/52 codec. I don't understand the 6ch v 2ch anomaly, and I've tried demuxing the original mpeg's audio stream with VirtualDubMod, but the resulting file won't open in any of my players.

At one stage I tried converting the AC3 file that AutoGK put in it's temp folder myself with foobar, and then adding the resulting CBR MP3 to the avi AutoGK produced. When I did that, I had the opposite problem where the audio was a second out of sync at the beginning, but perfectly in sync at the end.

Lastly I tried converting it to a wave file and adding it to the avi. The wave file itself plays normally using MPC and foobar, but when I open the AVI to which I've added the audio, the video is fine but the audio sounds like it's playing at about one quarter speed (slow and low in pitch).

So I'm at a bit of a loss as to what to do. I've tried resaving the various AVIs using VirtualDubMod while unchecking the offset audio setting under interleaving but it made no difference.

My next step will be to try a different program (such as StaxRip) altogether to see how it goes, but regardless of whether it works or not I'd really like to work out what's going on so I can use AutoGK for the job.

Anyone with any ideas?

Thanks.

PS I've checked the frame rates to make sure there's no issue there. According to MPC both the mpeg and the AVI produced by AutoGK are 25fps.

[yetanotherid]

An update on the mpeg info. I opened it using Super Converter and looked at it's detailed analysis of the audio. Below it what it showed. What I don't understand is the different (and multiple) delay times. It's lists delays of 220ms and 600ms. When AutoGK put the ac3 file in it's temp folder, it labelled it with "Delay -168ms" in it's file name.
I'll try converting with Super and see what happens. I guess if it gives me audio that's in sync, I can swap the audio stream it produces in it's AVI for the one AutoGK produced, but it'd be nice not to have to go to all that trouble.

Count : 121
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
ID : 128
ID : 128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Codec : AC3
Codec : AC3
Duration : 7379360
Duration : 2h 2mn
Duration : 2h 2mn 59s 360ms
Duration : 2h 2mn
Duration : 02:02:59.360
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 384000
Bit rate : 384 Kbps
Channel(s) : 2
Channel(s) : 2 channels
Channel positions : L R
Channel positions : 2/0
Sampling rate : 48000
Sampling rate : 48.0 KHz
SamplingCount : 354209280
Delay : 220
Delay : 220ms
Delay : 220ms
Delay : 220ms
Delay : 00:00:00.220
Video delay : -600
Video delay : -600ms
Video delay : -600ms
Video delay : -600ms
Video delay : -00:00:00.600
Video0 delay : -600
Video0 delay : -600ms
Video0 delay : -600ms
Video0 delay : -600ms
Video0 delay : -00:00:00.600

[yetanotherid]

Another update.
No luck using Super unfortunately. The AVI it produced has exactly the same sync issues as the one AutoGK produced.
It seems it's not a gradual loss of audio sync. It's all fine up until about the 90 minute mark, then the audio seems, as best as I can tell, to wander ahead of the video in stages.
I loaded up the mpeg using Gspot, which showed discontinuities I don't understand but which don't seem to be abnormal (aside from maybe the quantity of them), and they don't seem to effect the playing of the original mpeg. Maybe someone can tell me if it's likely to be what's effecting the audio sync when converting.

http://s5.tinypic.com/34diur7.jpg

http://s5.tinypic.com/dbh9bq.jpg

http://s5.tinypic.com/975x78.jpg


Off to try Staxrip now to see how it goes....

[yetanotherid]

One more piece of information before I'm off to try Staxrip.....

When I open with VirtualDubMod the avi AutoGK produced while I got it to convert the audio to MP3, and then look at the AVI's audio stream, VDM tells me the video length is 2:02:59:000. It tells me the MP3 Audio Stream is 2:02:58:560. I reloaded the MP3 from the temp folder into the avi and VDM says it's length is 2:02:58:728. That accounts for the -168ms by which AutoGK thinks it needs to delay the audio I guess, so all seems normal aside from sync actually wandering out.
When I load the demuxed AC3 audio into the AVI however, VDM tells me it's 2:14:28:529. Something I believe as when I saved the avi with that audio stream it was so out of sync near the end I was listening to commercials while watching the program. But when I play that same AC3 stream with foobar, it tells me the playing time is the same as the video length.

Anyone have any idea why VDM would show different lengths for the demuxed AC3 audio and the MP3 created from it? And why it'd think the demuxed AC3 audio would be around 12 minutes longer than the original recorded video (2:02:59)? I'm guessing it's the audio stream causing the sync problems, I just don't know why as yet.

[yetanotherid]

Well, I hope it's just been quiet around here and there's still someone out there who'll come along with a solution..... or at least an answer as to why.

In the mean time I tried StaxRip and once I got my head around it I converted the mpeg in question. When I first tried StaxRip I didn't let it update any of the components that had been installed by AutoGK (AviSyth, DGIndex VirtualDubMod & XviD, from memory) When trying to convert the mpeg, StaxRip would demux it, index it and convert the audio okay, but would crash at the beginning of the compressibility test. So I let it update AviSynth, install it's own versions of DGIndex and VirtualDubMod in it's own directory, and kept it using the version of XviD that comes with AutoGK.
When trying the conversion again, it completed and the resulting AVI was around 2 seconds shorter than the one AutoGK produced, and the audio was perfectly in sync from start to finish. Only problems was, the de-interlacing was horrible and the video contained a lot more motion blur than the video AutoGK produced. While I guess that's a question for a different forum, if anyone now has any ideas why StaxRip produces a properly synchronised avi while AutoGK can't (it seems to relate to ProjectX and the way it dumps useless frames... at a guess) I'd be interested to know.

Thanks.

[kippy]

I found that for AutoGK to correctly process streams recorded from broadcast it was necessary to rename the source file from .mpg to .ts

Apparently the broadcast format is not typical MPEG, but MPEG-TS which adds error-correcting information. If not correctly removed, this causes problems with audio sync.

I'm not 100% sure this is the source of your problem - usually I can see/hear the sync drift within a couple of minutes of starting playback, rather than the 90 minutes you mentioned, but it might be worth a try.

Kippy

[yetanotherid]

Thanks for that kippy. I've still got the original mpeg, so I'll give that a shot and see how it goes.

[yetanotherid]

Well I gave changing the extension to .ts a shot, but unfortunately for some reason when I did that AutoGK wouldn't acknowledge there was an audio stream in the file, so that wasn't the answer in this case.

I did try looking at the different files again. Gspot reports the duration and number frames of video to be the same for the original mpeg as well as the AVI AutoGK produced. When I opened the mpeg with VirtualDubMod however, it played the mpeg with the audio losing synch towards the end just like the AVI. (VurtualDubMod actually did report the original mpeg as being 3 frames shorter than the AVI to be exact, but that's hardly anything that'd cause a problem in itself)

I guess it's time to simply give up on that video and next time I'll try recording the program stream rather than as an mpeg and I'll see if I have any more luck that way. Or maybe just hope there was something peculiar with that particular mpeg I'm never going to experience again.