View Single Post
Old 29th November 2018, 19:09   #7  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 324
Quote:
Originally Posted by manolito View Post
Sorry, I don't think so...

I have been using StaxRip for many years now, even though I still use the latest stable 32-bit version 1.1.9.0 (I need to use it under WinXP, and I also need to employ 32-bit AVS filters). I am aware that the current Revan versions are different beasts, but for handling audio delays they do have 2 things in common with older versions:
1. They use MediaInfo to retrieve the audio delay information
2. They allow users to choose from several source filters.

MediaInfo can be totally wrong about the audio delay information depending on the source format. As an example just take a captured HD transport stream in a TS or MTS container. You are likely to get audio delays of around 1000 ms, and letting StaxRip honor this delay information will result in files where audio is completely out of sync. You need to manually set the delay to 0 in such cases. (Repacking the transport stream to MKV before feeding it to StaxRip does not help, the value for the delay will be different, but still be ridiculously high).

For other source formats like MPEG2 or VOB the source filter plays a role. Using DGIndex / DGDecode will behave differently compared to ffms2 or DSS2Mod with LAV Filters. The reason is that orphaned B-Frames at the start of the source will be treated differently. In my experience the audio delay should be honored with DGIndex / DGDecode, but it should be discarded with other source filters.

The bottom line is that the automatic audio delay treatment of StaxRip cannot be trusted. Users need to make a test conversion and test the result for correct audio sync. This should be done for any combination of source formats and AVS source filters. A good method to test audio delay is to play the file with MPC-HC. During playback you can use the "+" and "-" keys on the numeric keypad to change the playback delay on the fly. Once you have found how to treat the delay for a given source format / source filter combination you can use the same delay treatment in the future.


Cheers
manolito
Your Only guessing, Which is how bad information gets spread.

Actually it doesn't use MediaInfo at all. It reads the data directly from the Stream.

It uses the generated audio file to read the delay.

There are dozens of Scenario coded into StaxRip for Different Formats and Usage.

I have yet to have an issue with StaxRip automatically Delay Technology creating desync issue.

There been many, many, many+ changes to audio section since the 32 Bit support was dropped.
Revan654 is offline   Reply With Quote