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: 220
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,329
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,329
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: 220
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,329
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: 220
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,329
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: 220
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
Old 11th December 2018, 14:55   #14  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,774
Quote:
Originally Posted by manolito View Post
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).
According to the help file, when it's decoding audio, ffms2 adds silence to the beginning to account for any audio delay.
I don't use StaxRip, but ffms2 doesn't extract, so if a delay is being applied for ffms2, then it's probably wrong.

In theory ffms2 should be doing the right thing, but it'd depend on whether it counts orphaned B frames as frames.

int adjustdelay = -1
- **-1**: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at the same time as frame 0 of the first video track. This is the default, and probably what most people want.


If you remux one of your TS files as MKV, try checking the audio yourself with gMKVExtractGUI. It will show you the audio delay, and the audio delay relative to any video delay.
MediaInfo might show negative delays for MKV audio, but there's no such thing as negative delays for MKV, so when it's showing a negative audio delay, it'll be because there's a positive video delay.

I'd prefer it if both delays were written to the audio stream, but currently gMKVExtractGUI writes a delay that takes any video delay into account, under the assumption there won't be a video delay after encoding.

I've no idea if orphaned B frames would normally be substituted with an appropriate delay.
I think MKVCleaver can write the same audio delay as gMKVExtractGUI, although it probably needs to be manually configured to do so.

Anyway, it may have nothing to do with the problem, but it might be worth a look. If you find out whether gMKVExtract is counting orphaned B frames as a video delay, could you let us know?

Last edited by hello_hello; 11th December 2018 at 15:03.
hello_hello is offline   Reply With Quote
Old 12th December 2018, 03:53   #15  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,329
Here is a short discussion betweeen Mr. Graft and myself from an older thread:
https://forum.doom9.org/showthread.p...86#post1723386

For me the bottom line is that every source format / source filter combination treats orphaned B-frames differently. DSS2Mod and ffms2 generally delete them so the audio delay reported by MediaInfo should be discarded. DGDecode does not delete them so the audio delay should be honored.

I have never tested how audio tracks extracted with gMKVExtract behave when muxing them back. Especially when using HD TS files with HEVC video and AAC-LATM audio as the source I only found two working options:

1. No broadcast glitches in the source:
Repack to MKV, then use DSS2Mod or ffms2 and discard any reported audio delay.

2. When there are glitches keep the source in the TS format. The resulting audio delay is not related to the delay reported by MediaInfo. But the delay will be constant over the whole file (as opposed to using a repacked MKV source). Make a test conversion, determine the audio delay manually and apply the correction accordingly.


Cheers
manolito
manolito is offline   Reply With Quote
Old Today, 05:54   #16  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,329
Quote:
Originally Posted by hello_hello View Post
Anyway, it may have nothing to do with the problem, but it might be worth a look. If you find out whether gMKVExtract is counting orphaned B frames as a video delay, could you let us know?
Alright, I captured a short clip from DVB-T2 (1080p, HEVC video and AAC-LATM audio, 50fps). After repacking it to MKV using the current MKVMerge MediaInfo reported an audio delay value of -855ms. The captured MTS file as well as the repacked MKV file play correctly in all my software players.

Extracting the audio track with gMKVExtract resulted in an audio file with the same delay value as the one reported by MediaInfo. Muxing this extracted audio file back into the MKV with MKVMerge automatically honored the audio delay value which resulted in an MKV file with audio completely out of sync. MKVMerge should have discarded the delay value from the extracted audio file name.

This is the reason why I always remove the delay value from audio files extracted with gMKVExtract. The old MKVExtractGUI by pashin which did not care about audio delays worked better for me.


I am not sure if this has anything to do with orphaned B-Frames at the beginning of the file. I simply do not know if the file has orphaned B-Frames because I do not know the behavior of the source filter. I tried to open the captured MTS file as well as the repacked MKV in AviDemux, and for both files the first frame was indicated as an I-Frame.


Cheers
manolito
manolito 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 11:39.


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