I'm just starting to use DVDFab over other software, which never has audio sync issues that I can see, and DvdFab's 8225 and 9016 are both giving me major audio sync issues no matter what type of "rip" I do: Blu-Ray to DVD, Blu-Ray Rip to WMV, Blu-Ray Rip to H264, Dvd Rip to H264, etc.
This morning, I scoured the forums for audio sync issues and found many, many posts, and fairly snarky and non-informational replies from DVDFab's moderators, with no actual suggestions about 1. why it's happening, and 2. how to work around it.
I work on the audio/video encode/decode team at Microsoft. In fact, I'm one of their senior engineers. I know about how timestamps work in most of the SDK software Microsoft provides, but I am not a DVD or Blu-Ray MPeg2 PS or TS expert, and I don't know if the decoded streams contain presentation timestamps. If they do contains presentation timestamps, then quite obviously, DvdFab has a major glaring bug. It should decode each stream individually, then look at the timestamps and recombine as necessary. It shouldn't matter if the files are on a DVD or "slow media" or on the hard disk.
If the streams don't contain timestamps, then I'm pretty sure that professional DVD creation labs ensure that when decoding each stream will give you an exact and matching amount of data per second, the streams are always sync-locked in terms of how much data they provide per stream, per second.
One other thing I saw online was that some "rippers" don't understand the difference between MPeg's "open" and "closed" GOPs and a misunderstanding of these can lead to dropped frames across VOB boundaries, causing an additive delay the farther you get into the movie, and more VOB boundaries you have to cross. If an Open Gop is treated timestamp-wise like a closed GOP across a VOB boundary, at least a frame's worth of video time will be dumped. This doesn't account for the half-second sync issues I'm seeing in DvdFab's output though.
A last, and less likely problem might be that the input streams are being synced correctly, but the output muxer/writer isn't behaving correctly and is timestamping the samples wrong, or if it's not writing timestamps along with the packets, then it's not ensuring the streams are following the exact same master clock correctly (a common problem), or it's just plain got some weird ol' bug.
But foremost importantly: It shouldn't matter a damn if the source video comes off the hard drive or a slow-read source like a DVD.
If anybody at DvdFab wants to hash this out w/ me, (FengTao), I'd be happy to sling some ideas around.
This morning, I scoured the forums for audio sync issues and found many, many posts, and fairly snarky and non-informational replies from DVDFab's moderators, with no actual suggestions about 1. why it's happening, and 2. how to work around it.
I work on the audio/video encode/decode team at Microsoft. In fact, I'm one of their senior engineers. I know about how timestamps work in most of the SDK software Microsoft provides, but I am not a DVD or Blu-Ray MPeg2 PS or TS expert, and I don't know if the decoded streams contain presentation timestamps. If they do contains presentation timestamps, then quite obviously, DvdFab has a major glaring bug. It should decode each stream individually, then look at the timestamps and recombine as necessary. It shouldn't matter if the files are on a DVD or "slow media" or on the hard disk.
If the streams don't contain timestamps, then I'm pretty sure that professional DVD creation labs ensure that when decoding each stream will give you an exact and matching amount of data per second, the streams are always sync-locked in terms of how much data they provide per stream, per second.
One other thing I saw online was that some "rippers" don't understand the difference between MPeg's "open" and "closed" GOPs and a misunderstanding of these can lead to dropped frames across VOB boundaries, causing an additive delay the farther you get into the movie, and more VOB boundaries you have to cross. If an Open Gop is treated timestamp-wise like a closed GOP across a VOB boundary, at least a frame's worth of video time will be dumped. This doesn't account for the half-second sync issues I'm seeing in DvdFab's output though.
A last, and less likely problem might be that the input streams are being synced correctly, but the output muxer/writer isn't behaving correctly and is timestamping the samples wrong, or if it's not writing timestamps along with the packets, then it's not ensuring the streams are following the exact same master clock correctly (a common problem), or it's just plain got some weird ol' bug.
But foremost importantly: It shouldn't matter a damn if the source video comes off the hard drive or a slow-read source like a DVD.
If anybody at DvdFab wants to hash this out w/ me, (FengTao), I'd be happy to sling some ideas around.
Comment