Audio/Video Sync Issues Suddenly?!

[slim_j]

I have been ripping blu-rays with no issues for about 2 years, the process i use is as follows:

makemkv - rip blu-ray
Handbrake - crop video
mkvmerge - merge cropped video and audio from original rip

I have never had any problems doing this but over the last 3 months the sync has started getting about 1.5s out (consistently through the film). This seems to be with new films (Brighton Rock, Neds, The Kings Speech) and i wondered whether anyone else has has similar issues?

I have tried to find the lengths of both the audio and video tracks to compare them but no software seems to give me this information?

Any help or suggestions appreciated. Thanx slim_j

[setarip_old]

Hi!

Check the synch after each step in your stated procedure.

I'd be EXTREMELY surprised if MakeMKV will appear to be the culprit. I'd sooner suspect "Handbrake" and its compression procedure(s)...

[slim_j]

Hi!

Check the synch after each step in your stated procedure.

I'd be EXTREMELY surprised if MakeMKV will appear to be the culprit. I'd sooner suspect "Handbrake" and its compression procedure(s)...

I have checked the sync after each step and like you say it is fine after the initial makemkv rip so it must be down to Handbrake. I just posted here as i am more likely to find users who follow the same procedure as me and might have encountered the same issue. It has never done it before i haven't changed any settings so it doesn't make any sense.

[setarip_old]

it is fine after the initial makemkv rip so it must be down to Handbrake

Although that may prove to be the case, how/why are you excluding MKVMerge as the possible culprit?

[slim_j]

[/quote]Although that may prove to be the case, how/why are you excluding MKVMerge as the possible culprit?[/color][/quote]

I am not excluding MKVMerge as such i just think it is more likely to be one of handbrake or makemkv. This issue has never occured before and it still only occurs with new blu-rays. Mkvmerge will do what its told and doesnt amend and the audio or video in anyway, it certainly wouldnt shorten one of the tracks as far as i am aware.

I can pass the DTS and DTS HD audio through handbrake (only just found this out) as well as the video so im hoping that will correct the issue (just trying now). I dont know what to do about TrueHD yet and i still dont know why this issue has suddenly arisen.

[Watson]

I've had the similar issues, and am pretty sure I also found the reason why it happens. There also is no real culprit, it's just that programs are expected to handle stuff that they cannot handle.

I've been encoding the .mkv files in different ways, and on some titles the audio ran "slower", in terms of falling behind for almost a second after a 2 hour film.


Firstly, you have to check if the bluray title you ripped spans multiple .m2ts files. Certainly it does.

To find the reason you'd have to encode the audio stream directly from the mkv using eac3to. It will probably give you an "audio overlaps" warning for every seam between .m2ts files (usually between 5 and 25 ms each time for me). Since mkv uses timecodes for the streams inside, there's initially no issue with playback.

But most conversion tools will demux the audio, encode it and then remux the stuff together again.

Now, demuxing tools like mkvextract are expecting the audio stream to be a continous stream. They normally cannot look inside the stream and tell you how long each packet is, since they only handle streams, and not the encoded data inside the streams.

Adding to that, audio files (like .ac3) are continous streams aswell, usually not knowing timecodes.

So, the audio gets saved as a continous stream, and every overlap is no overlap anymore, but instead the packets get padded together back-to-back. Every overlap drives the audio behind more and more this way.

-------------------------------

As an example:

Timecode 0: Audio packet of 1.01 seconds (seam between Timecode 0 and 1)
Timecode 1: Audio packet of 1.00 seconds
Timecode 2: Audio packet of 1.02 seconds (seam between Timecode 2 and 3)
Timecode 3: Audio packet of 1.00 seconds

No issues with playback, each Audio packet gets played at the timecode it's bound to (resulting in overlaps). Whole stream lasting 4.00 seconds.

Demuxing the stream with the usual tools though will result in 1.01+1.00+1.02+1.00 = 4.03 seconds of audio playback, since the timecodes are not preserved.

------------------------------

So far the only solution I found to that is to encode the audio with eac3to without demuxing it.