Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th November 2018, 16:12   #1  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 25
StaxRip audio delay - am I doing it right?

When ripping DVDs sometimes I will have an audio delay. I use StaxRip and DVD Shrink. One time, when StaxRip demuxed a VOB rip; it generated a file named "VTS_01_1 ID0 2ch 192Kbps -115ms.ac3". What I would do is set the audio delay from -115 or whatever number it is to 0. Is this the right way to do it, or leave it at -115 or whatever number?
Vitality is offline   Reply With Quote
Old 28th November 2018, 20:47   #2  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 219
Quote:
Originally Posted by Vitality View Post
When ripping DVDs sometimes I will have an audio delay. I use StaxRip and DVD Shrink. One time, when StaxRip demuxed a VOB rip; it generated a file named "VTS_01_1 ID0 2ch 192Kbps -115ms.ac3". What I would do is set the audio delay from -115 or whatever number it is to 0. Is this the right way to do it, or leave it at -115 or whatever number?
First StaxRip has it's own Thread: https://forum.doom9.org/showthread.php?t=175845&page=5

Secondly, StaxRip takes care of all the delays automatically.
Revan654 is offline   Reply With Quote
Old 29th November 2018, 00:55   #3  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,321
Quote:
Originally Posted by Revan654 View Post
Secondly, StaxRip takes care of all the delays automatically.
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

Last edited by manolito; 29th November 2018 at 15:06.
manolito is offline   Reply With Quote
Old 29th November 2018, 17:48   #4  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 25
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
Does this mean I shouldn't set the delay to 0? I'm working with animation here (MPEG2 VOB) so if there is any delays it's hard to notice.

Last edited by Vitality; 29th November 2018 at 17:52.
Vitality is offline   Reply With Quote
Old 29th November 2018, 17:58   #5  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,321
No idea...

A delay of -115 ms is quite easy to detect on a normal movie clip where people are talking. Maybe you should (just for testing) use a normal movie VOB rip and check the correct audio delay with it.

But then after all, if your animation clip does not allow you to detect an audio sync error at all, why does it matter?

Last edited by manolito; 29th November 2018 at 18:02.
manolito is offline   Reply With Quote
Old 29th November 2018, 18:16   #6  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 25
Quote:
Originally Posted by manolito View Post
No idea...
Maybe you should (just for testing) use a normal movie VOB rip and check the correct audio delay with it.
Do you mean like an actual movie instead of animation?
Vitality is offline   Reply With Quote
Old 29th November 2018, 19:09   #7  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 219
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
Old 29th November 2018, 19:59   #8  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 25
Quote:
Originally Posted by Revan654 View Post
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.
So does this mean to leave the audio delay as-is? Is it bad to set it to 0ms? StaxRip uses DGIndex to demux the VOBs
Vitality is offline   Reply With Quote
Old 30th November 2018, 04:42   #9  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,321
Quote:
Originally Posted by Revan654 View Post
I have yet to have an issue with StaxRip automatically Delay Technology creating desync issue.
Have a look at this source file:
https://we.tl/t-DzFGofDblJ

This is a standard captured DVB-T2 clip, repacked from MTS to MKV for better seeking capability. I tested it with your latest stable version 1.9.0.0 from GitHub.

Result:
StaxRip automatically picks ffms2 as the source filter, this takes care of the audio delay. Specifying LWLibavVideoSource also produces a resulting file without sync problems. But using DSS2 as the source filter messes up audio sync badly.

This confirms my statement that the source filter plays a big role in correcting audio delays.

Quote:
There are dozens of Scenario coded into StaxRip for Different Formats and Usage.
There been many, many, many+ changes to audio section since the 32 Bit support was dropped.
I do not really see any improvements in this area since 32-bit support was dropped. The older 32-bit versions of StaxRip can do almost anything which the 64-bit versions can do, and then something more...

Cheers
manolito
manolito is offline   Reply With Quote
Old 1st December 2018, 00:32   #10  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 219
Quote:
Originally Posted by manolito View Post
Have a look at this source file:
https://we.tl/t-DzFGofDblJ

This is a standard captured DVB-T2 clip, repacked from MTS to MKV for better seeking capability. I tested it with your latest stable version 1.9.0.0 from GitHub.

Result:
StaxRip automatically picks ffms2 as the source filter, this takes care of the audio delay. Specifying LWLibavVideoSource also produces a resulting file without sync problems. But using DSS2 as the source filter messes up audio sync badly.

This confirms my statement that the source filter plays a big role in correcting audio delays.



I do not really see any improvements in this area since 32-bit support was dropped. The older 32-bit versions of StaxRip can do almost anything which the 64-bit versions can do, and then something more...

Cheers
manolito
Site Does not work and Poor example to start with since DVB is source is feed through FFMPEG. DVB does not have an exclusive format, It can be from MPEG-2 to MPEG-4.

DSS2 is not standard Source filter that's part of StaxRip, it's only added in with extra installer files. Which is not required to be installed.

Hows that HDR, 4K, AVX2, etc... Support working out. VS basically requires 64Bit to run most of the filters.

Last edited by Revan654; 1st December 2018 at 00:39.
Revan654 is offline   Reply With Quote
Old 1st December 2018, 03:46   #11  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,321
Quote:
Originally Posted by Revan654 View Post
Site Does not work
Strange, WeTransfer is a Dutch site, and AFAIK they do not use any geo-blocking. The download link works for me, and a friend in the US also never had a problem downloading files I uploaded for him. But whatever, if you are interested I reuploaded the file to 2 other file hosters:
https://www.zeta-uploader.com/2105335280
https://www.sendspace.com/file/jdfm48

At least one of them should work for you...

Quote:
Poor example to start with since DVB is source is feed through FFMPEG. DVB does not have an exclusive format, It can be from MPEG-2 to MPEG-4.
The video format is HEVC, audio is AAC. The captured MTS file does not work well when feeding it to software like StaxRip (editing out commercials is a pain because you get garbled frames when seeking). So I always repack such Transport Streams zo MKV using the current MKVToolnix.

Quote:
DSS2 is not standard Source filter that's part of StaxRip, it's only added in with extra installer files. Which is not required to be installed.
This is a very strange statement. The DSS2Mod plugin IS part of the downloaded StaxRip archive, like all other software in the applications folder it does not need to be installed. Right-clicking on the "Source Filters" entry brings it up without any further action by the user. And in the documentation DSS2Mod is listed under "Supported Tools". And you still say that it is "not standard Source filter that's part of StaxRip". I think this is just ridiculous...

Quote:
Hows that HDR, 4K, AVX2, etc... Support working out. VS basically requires 64Bit to run most of the filters.
All this latest and greatest new stuff is something I absolutely do not need. And looking at the forum entries after StaxRip added these capabilties all I can see is that this new stuff causes many issues, StaxRip used to be way more stable than it is today.

I wish you all the best for the future StaxRip development, but for my part I prefer to stick with the older and trusted 32-bit version.


Cheers
manolito
manolito is offline   Reply With Quote
Old 1st December 2018, 08:16   #12  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 219
Quote:
Originally Posted by manolito View Post
Strange, WeTransfer is a Dutch site, and AFAIK they do not use any geo-blocking. The download link works for me, and a friend in the US also never had a problem downloading files I uploaded for him. But whatever, if you are interested I reuploaded the file to 2 other file hosters:
https://www.zeta-uploader.com/2105335280
https://www.sendspace.com/file/jdfm48

At least one of them should work for you...



The video format is HEVC, audio is AAC. The captured MTS file does not work well when feeding it to software like StaxRip (editing out commercials is a pain because you get garbled frames when seeking). So I always repack such Transport Streams zo MKV using the current MKVToolnix.



This is a very strange statement. The DSS2Mod plugin IS part of the downloaded StaxRip archive, like all other software in the applications folder it does not need to be installed. Right-clicking on the "Source Filters" entry brings it up without any further action by the user. And in the documentation DSS2Mod is listed under "Supported Tools". And you still say that it is "not standard Source filter that's part of StaxRip". I think this is just ridiculous...



All this latest and greatest new stuff is something I absolutely do not need. And looking at the forum entries after StaxRip added these capabilties all I can see is that this new stuff causes many issues, StaxRip used to be way more stable than it is today.

I wish you all the best for the future StaxRip development, but for my part I prefer to stick with the older and trusted 32-bit version.


Cheers
manolito
Supported is very different then required.

DGIndexIM / NV is also supported tool, but it's not required.

StaxRip is just as Stable as it was before.
Revan654 is offline   Reply With Quote
Old 5th December 2018, 23:29   #13  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 25
Quote:
Originally Posted by Revan654 View Post
Supported is very different then required.

DGIndexIM / NV is also supported tool, but it's not required.

StaxRip is just as Stable as it was before.
So set it to 0ms or leave it as -XXXms? I've encoded some DVDs with 0ms, but now I"m leaving it as -XXXms
Vitality is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.