Common error logs in MeGUI + eac3to. Unfixable?

[jfromeo]

Hello there.

I'm currently demuxing my BluRay dumps and I have encountered some problems while using MeGUI 0.3.4.13 along with eac3to 3.18.

I'm getting three kind of "errors" which I don't know if they are fixable by using some additional parameters on eac3to or definitely I have to redump my BD.

[aXX] Removing AC3/DTS dialog normalization
[aXX] Patching bitdepth to 24 bits
[aXX] A remaining delay of +Xms could not be fixed

Would any of them have an influence on the posterior mkv remux?

The first one happen on every audio track encoded to AC3/DTS so I guess it's not exactly an error. The second one is common on DTS tracks @ 16bit, I guess the demuxing introduce 8 empty bits (but why?).

The last one is the one that seems more annoying, do I need to introduce manually the delay after the demuxing? If i directly mux it with mkvmerge 3.3.0 will the track be delayed?

Thanks in advance.

[Inspector.Gadget]

The first two are not errors. The third is not strictly an error either, since frame lengths for audio do not always round to the desired millisecond increment. You should take this remaining delay into account when muxing.

[jfromeo]

Thanks Inspector.Gadget.

So if for example, I get a "A remaining delay of +9ms could not be fixed" on an AC3 audio track, I should add a +9ms delay under the field "Format specific options" for that track on mkvmerge as it follows, right?

http://img19.imageshack.us/img19/9144/jfro.png

A more in-depth question would be, why does eac3to have delay issues with some tracks and with others doesn't? I mean, which conditions make an audio track for eac3to to be not delay fixed? As I see it doesn't happen with most of my audios.

[Inspector.Gadget]

Yes, that would be the correct value to add.

eac3to only displays such messages when the delay required to reproduce the sync as it exists on the disc doesn't line up with the duration of an audio frame. If eacto just arbitrarily chopped off that data, then the last audio frame would be invalid. As you've noticed, this doesn't happen when transcoding the audio because the delay can be applied during decoding to PCM. IMO eac3to's approach is the best way to handle this situation.

[jfromeo]

Thanks a lot for your answer, now I know a little more :D

[jfromeo]

Mmm... One of my dumps is giving me these errors while demuxing on eac3to 3.18:

[a09] Audio overlaps for 10ms at playtime 0:21:43. <WARNING>
[a09] Audio overlaps for 10ms at playtime 0:45:09. <WARNING>
[a09] Audio overlaps for 9ms at playtime 0:46:59. <WARNING>
[a09] Audio overlaps for 12ms at playtime 0:55:06. <WARNING>
[a09] Audio overlaps for 9ms at playtime 1:00:39. <WARNING>
[a09] Audio overlaps for 9ms at playtime 1:02:56. <WARNING>
[a09] Audio overlaps for 6ms at playtime 1:03:40. <WARNING>
[a09] Audio overlaps for 6ms at playtime 1:08:03. <WARNING>
[a09] Audio overlaps for 8ms at playtime 1:09:37. <WARNING>
[a09] Audio overlaps for 9ms at playtime 1:12:00. <WARNING>
[a09] Audio overlaps for 10ms at playtime 1:14:02. <WARNING>
[a09] Audio overlaps for 8ms at playtime 1:16:25. <WARNING>
[a09] Audio overlaps for 13ms at playtime 1:41:02. <WARNING>
[a09] Audio overlaps for 7ms at playtime 1:45:20. <WARNING>
[a09] Audio overlaps for 6ms at playtime 1:47:45. <WARNING>
[a09] Audio overlaps for 9ms at playtime 1:52:03. <WARNING>
[a09] Audio overlaps for 7ms at playtime 1:59:16. <WARNING>
[a09] Audio overlaps for 6ms at playtime 2:01:06. <WARNING>
[a09] Audio overlaps for 9ms at playtime 2:44:49. <WARNING>
[a09] Audio overlaps for 45ms at playtime 2:48:33. <WARNING>
[a09] Starting 2nd pass...
[a09] Realizing DTS gaps...
[a09] Creating file "K:\American Gangster\F1_T9_Audio - Spanish.dts"...

Should I understand the gaps got fixed after the 2nd pass? Or is there something else I must do to correct them? I have tried to redump it twice, and I get exactly the same errors at the identical playtimes.

[nurbs]

Yes, eac3to will do its best to fix the overlaps.

[jfromeo]

Thanks nurbs, and congrats on your incoming 1000 posts :P

[gskill]

I apologize for bumping a very old thread, but I just wanted to confirm that say if eac3to reported the following "[a12] A remaining delay of -13ms could not be fixed." you would have to input a delay of -13ms in mkvmerge to offset the difference? Wouldn't it make more sense to add a delay of +13ms to negate the delay? Anyway, just want some confirmation that you'd in fact input "-13" and not "+13" for peace of mind, thank you.

Edit: didn't want to bump this again, just wanted to say thanks for clearing that up tebasuna51, I was wondering how the process worked as well.

[tebasuna51]

"[a12] A remaining delay of -13ms could not be fixed." you would have to input a delay of -13ms in mkvmerge to offset the difference?

Yes.

- But some muxers, like mkvmerge, don't store negative delays, cuts the necesary frames and store a positive delay.
After remux your AC3 track have a frame less, and a delay of +19ms (duration of each frame 32ms).

- Delays below a video frame duration (40ms for fps 25) are unnoticeable. Maybe you can forget delays below 20ms.