evodemux audio delay problem

[musky5789]

hi all
can anyone tell me how to work out the audio delay need for the audio when evodemux says the following :




im trying to demux stream 0 from this evo.
+47721847ms is not the delay need for this dd!
ive had other evo file with similar delays and the audio is in syn, other delays say +180ms why is this one so large??
ive also seen this on the second part of the feature does that need a delay also???

[madshi]

Switch calculator into scientific mode. Then switch to "hex" mode. Then calculate D45 - 424. Switch back to "dec" mode. Divide by 90. The final result should be "25,9666". This is the audio delay. It's negative delay because the audio's first timestamp is earlier than the video's first timestamp. So that gives us "-26ms" delay.

[musky5789]

thanks madshi m8!!!!!!

[Icemaan]

Switch calculator into scientific mode. Then switch to "hex" mode. Then calculate D45 - 424. Switch back to "dec" mode. Divide by 90. The final result should be "25,9666". This is the audio delay. It's negative delay because the audio's first timestamp is earlier than the video's first timestamp. So that gives us "-26ms" delay.

Hi Madshi

Must i do this with the Audio source which i want have in the Final or everytime with the Audio 0
For Example when i want have the German Audio which is Audio 3 then I must calculate
First Video PTS and the First PTS from Audio 3
Must I do the same for the second Evo ,If so then i must Do Audio Delay 1 - Delay 2 = Final Delay?
And the Result ist the Delay which i must put in in MMMerge when i create a MKV?
Is this so Correct

Thanks for Help

Icemaan

[madshi]

For Example when i want have the German Audio which is Audio 3 then I must calculate First Video PTS and the First PTS from Audio 3
Yes, you must use the PTS values from the audio track you're interested in.

Must I do the same for the second Evo
No.

And the Result ist the Delay which i must put in in MMMerge when i create a MKV?
MkvMerge cannot delay E-AC3 tracks (yet). You'll have to use delaycut (newest version, see delaycut thread) to delay E-AC3 tracks.

[morphx2]

Can anyone understand the audio delay from this? I am really confused :-\ I am backing up my 300 hd-dvd to my harddrive and the audio just looks wacky from this.

VC-1 video stream 0 found!
First PTS = 2E191637 (+35791394ms)
Dolby Digital Plus audio stream 0 found!
First PTS = 6E191637

[saint-francis]

It's negative delay because the audio's first timestamp is earlier than the video's first timestamp.

Could you please explain how you determined that the audio's first time stamp is earlier than the video's?

[madshi]

Could you please explain how you determined that the audio's first time stamp is earlier than the video's?
From the screenshot:

VC-1 video stream 0 found
First PTS = 00000D45

Dolby Digital Plus audio stream 3 found
First PTS = 00000424
The DD+ stream has a smaller PTS value than the VC-1 stream. A smaller value means "earlier". The PTS values begin with 0 and get bigger with time. You might be confused by the "D45". EvoDemux shows the timestamps in hexadecimal format. hex:D45 = 3397. hex:424 = 1060. You can convert hex to "normal" numbers by using calc.exe in scientific mode.

[morphx2]

Hmm..for my problem it seems that the video delay is gigantic. Is it converting wrong? I tried converting it and it became huge!

VC-1 video stream 0 found!
First PTS = 2E191637 (+35791394ms)
Dolby Digital Plus audio stream 0 found!
First PTS = 6E191637

[madshi]

VC-1 video stream 0 found!
First PTS = 2E191637 (+35791394ms)
Dolby Digital Plus audio stream 0 found!
First PTS = 6E191637
If you substract those PTS values you end up with "-40000000". It's almost impossible that such a large delay value is necessary. I'm not sure where that "4" comes from, but I'm fairly certain that this HD DVD doesn't need any delay at all cause the lower 7 digits are all identical.

[morphx2]

Yeah. I thought it was pretty screwy too. I will give it a shot tonight without delays and let ya know.

[saint-francis]

From the screenshot:

VC-1 video stream 0 found
First PTS = 00000D45

Dolby Digital Plus audio stream 3 found
First PTS = 00000424
The DD+ stream has a smaller PTS value than the VC-1 stream. A smaller value means "earlier". The PTS values begin with 0 and get bigger with time. You might be confused by the "D45". EvoDemux shows the timestamps in hexadecimal format. hex:D45 = 3397. hex:424 = 1060. You can convert hex to "normal" numbers by using calc.exe in scientific mode.

Ok thanks. The hexadecimal readings are a little confusing for me but I think I have a handle on transforming them to a number I can read with windows calculator. I didn't know "a smaller value means earlier". Thanks for clearing it up for me (and other's I assume).

Also can you explain to me why to divide by 90?

[woah!]

3397 / 90000 = 0.0377 ms video = 37ms delay

2377 / 90000 = 0.0264 ms audio = 26ms delay stream 0


-11ms delay difference on audio....


you divide by 90000 not 90

[woah!]

i hate old threads... anyways 300 was weird if i remember right, i think evodemux is bugged on this reading. problem is i did this backup a while ago and cant remember how i synced it and what delays were needed... i will rip the audio off the disc again and see what i did...

[madshi]

0.0377 ms = 37ms
0.0264 ms = 26ms
I think you need to improve your math skills... :p

Also can you explain to me why to divide by 90?
That's just the definition of timestamps.

1 second = 1000ms
60 seconds = 1 minute
90 PTS = 1ms

[saint-francis]

That's just the definition of timestamps.

1 second = 1000ms
60 seconds = 1 minute
90 PTS = 1ms

Thank you very much!
It's all clear now.

[woah!]

I think you need to improve your math skills... :p


That's just the definition of timestamps.

1 second = 1000ms
60 seconds = 1 minute
90 PTS = 1ms


1.000 would be 1 second so how am i wrong??? 0.037 is 37ms

[序列人]

3397 / 90000 = 0.0377 ms video = 37ms delay

2377 / 90000 = 0.0264 ms audio = 26ms delay stream 0


-11ms delay difference on audio....


you divide by 90000 not 90

Is there anything opposite? Why doesn't Audio delay 11ms? THANKS!

[madshi]

1.000 would be 1 second so how am i wrong??? 0.037 is 37ms
0.037s = 37ms

But you wrote "0.037ms = 37ms".

[madshi]

Is there anything opposite? Why doesn't Audio delay 11ms? THANKS!
Yeah, audio needs to be delayed by +11ms in this situation.

[saint-francis]

I have encountered this:

PTM of first video frame = 00001282
PTM of last video frame = 0DDE4DA2
Duration = 0:43:05.199
H.264 (AVC) video stream 0 found!
First PTS = 00002FD6 (+83ms)

Dolby Digital Plus audio stream 3 found!
First PTS = 00001282

Which is the starting PTS of the video, 1282 or 2FD6? It is roughly +83 ms like it says if I go by 2FD6. is EVODemux giving me the correct delay?

[madshi]

The "PTM of first video frame" is in reality the "PTM of the first frame with any data (video or audio)". In your case there is audio data earlier than video data. That means you need to delay audio by -83ms.

Which movie is that?

[saint-francis]

The movie is old School.
Since the number for the audio is earlier why does EVODemux say +83 ms?

[madshi]

Since the number for the audio is earlier why does EVODemux say +83 ms?
EvoDemux says "+83ms" for video and "0ms" for audio. So you should delay video by "+83ms". But since you cannot really delay video, in this situation you have to delay audio by "-83ms". Understood?

[saint-francis]

Got it. Is EVODemux pretty reliable in this fashion?

[madshi]

Got it. Is EVODemux pretty reliable in this fashion?
Not sure what you mean. The timestamps posted by EvoDemux are usually correct. Except that sometimes they're extremely (unreasonably) large. See earlier posts in this threads for how to handle that situation.

[saint-francis]

What I mean is if EVODemux can fairly reliably display the offset between tracks in ms then there is almost no need for the end user to tinker with a calculator and hexadecimals.

[madshi]

What I mean is if EVODemux can fairly reliably display the offset between tracks in ms then there is almost no need for the end user to tinker with a calculator and hexadecimals.
Yes. The timestamps posted by EvoDemux are usually correct. Except that sometimes they're extremely (unreasonably) large. See earlier posts in this threads for how to handle that situation (with the help of the calculator and hexadecimals).