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: 54
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: 324
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
Location: Berlin, Germany
Posts: 3,078
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: 54
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
Location: Berlin, Germany
Posts: 3,078
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: 54
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: 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
Old 29th November 2018, 19:59   #8  |  Link
Vitality
Registered User
 
Join Date: Oct 2018
Posts: 54
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
Location: Berlin, Germany
Posts: 3,078
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: 324
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
Location: Berlin, Germany
Posts: 3,078
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: 324
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: 54
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: 4,823
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
Location: Berlin, Germany
Posts: 3,078
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 14th December 2018, 05:54   #16  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
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
Old 15th December 2018, 21:51   #17  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
It sounds like there's a video delay, given there's no such thing as negative delays for MKV. Does MTS allow negative delays?
The trouble is, if both the video and audio have delays, you need to know both values as the correct delay for remuxing the audio changes.

I made an MKV similar to the one you described, except in addition to specifying a video a delay of 855ms, I specified a delay of 55ms for the audio. MediaInfo reports an audio delay of -800ms.

gMKVExtractGUI shows the correct info in the GUI. At the end of the video stream it displays [855][855] and for the audio stream it displays [55][-800]. It writes -800ms to the extracted audio stream.

Audio_track2_[eng]_DELAY -800ms.ac3

MKVCleaver doesn't tell you anything in the GUI, but it can be configured to write either/both delays to the audio stream. I have it configured to do both. That way you can look at the extracted audio and know there's a video delay.

Audio 02 eng TDly 55ms Delay -800ms.ac3

It's configurable, so if you prefer you could change it to write something like this instead.

Audio 02 eng TDly -800ms Delay 55ms.ac3

My custom output configuration looks like this:
[Filename] [Track#] >[LNG3] TDly >[Delay] Delay >[aDelay]

What source filters do to compensate when decoding is a different matter, but the delay you'd use when remuxing the original audio depends on whether you're remuxing with the original video, where you should use 55ms, or with a re-encoded version, in which case the original video delay is usually lost, and the correct audio delay would be -800ms.

I downloaded your earlier sample (source.mkv). The audio sync isn't perfect anyway. To me, it seems to need an audio delay of around -250ms relative to the video to sync them up. That aside though.....
It has a video delay of 1249ms and no audio delay, so when remuxing the extracted audio with the original video you'd ignore the -1249ms delay written to the audio stream. Normally, after re-encoding the video, you'd apply the audio delay.

When I extracted the audio with MKVCleaver, the file name it created for the extracted stream was this:
source 02 TDly 0ms Delay -1249ms.aac

Or if you remux the original sample while applying a delay of -1249ms to both the audio and video streams, MKVToolNixGUI will remove the first 1280ms from the audio, and you'll be left with a "real" audio delay of 31ms and no video delay.

I almost never work with sources with orphaned B frames at the beginning so I'm not sure if MKVToolNix automatically drops them when remuxing. I suspect not because I think it'll split video with an open gop which can orphan B frames (I assume), but if those sources are easy to identify and don't have an open gop, the first thing I'd probably do is remux with MKVToolnix while splitting the video on the first keyframe. That should put the first keyframe at "0" and any audio delay shown by MediaInfo etc. should always be "real" or "correct". Are orphaned B frames at the beginning all that common?

Last edited by hello_hello; 16th December 2018 at 11:46.
hello_hello is offline   Reply With Quote
Old 15th December 2018, 22:36   #18  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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?
If Staxrip is indexing DVD VOB files and extracting the audio with DGIndex, you should apply the delay written to the audio stream when muxing. MKVToolNixGUI does it automatically. If I remember correctly, StaxRip was indexing VOBs with ffms2 at one stage, but I've never used ffms2 with VOB files myself.

MeGUI automatically applies an appropriate delay when re-encoding audio via Avisynth (after it's been extracted with DGIndex) using the value written to the audio stream, so the encoded audio has the delay value removed from the file name.

Last edited by hello_hello; 16th December 2018 at 09:44.
hello_hello is offline   Reply With Quote
Old 16th December 2018, 21:39   #19  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
manolito,

I finally got around to updating MKVCleaver, and it will show delays for the individual streams now. You have to configure it though, and unless I'm missing something, there's oddness. The way of setting it up.... configuring MediaInfo parameters from a parameters list, which are then used to create filename placeholders, which are then used to configure how streams display in the GUI..... it's a little convoluted, and I was getting errors about placeholders not being in square brackets when they were, so in the end I gave up trying to add the problem ones via the GUI and just edited the ini file instead.

The problem placeholders for me were created from these MediaInfo parameters: BitRate_Mode, FrameRate_Mode and Channel(s).

Here's what the relevant line in the ini file looks like. I'm pretty sure you could replace them directly if you haven't configured MKVCleaver like this before and want something to start off with.

line_video=( DELAY [Delay] ms ) [Duration/String3] ( [FrameRate] fps / [BitRate/String] / [FrameRate_Mode] ) [Language/String] ( [CodecID] )
line_audio=( DELAY [Delay] ms ) [Duration/String3] ( [Channel(s)] ch / [BitRate/String] / [BitRate_Mode] ) [Language/String] ( [CodecID] )

hello_hello is offline   Reply With Quote
Old 17th December 2018, 00:02   #20  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
This is all nice and interesting, but I simply don't want to deal with it...

If you and me are in a running contest, and you are in much better shape than I am, you can either look at it as
1. You are ahead of me by two seconds
or
2. I am behind you by two seconds

Both views are just different views of the same situation.

The conversion software I use (AVStoDVD and StaxRip) look at it like video as the reference and audio having a (positive or negative) delay. They use MediaInfo or the delay value from an audio demuxer to determine the audio delay. Video is considered to have no delay.

In my real life conversion world I do not want to demux the source, determine the delay values for audio and video and then remux the extracted streams with the corrected delay values. I just want my conversion software to take my souice and convert it without any sync problems. Is this too much to ask for?


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 12:38.


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