DVD2AVI vs DGIndex (audio synch probs)

[BangoO]

Hi there,

I took one TS file (1080i, 3:2 pattern), and created one D2V with DVD2AVI and one with DGIndex.
Then, I fixed them both (with FixD2V and DGFix).

Then, I used the same AVS script on both:
TFM()
Decimate()

Here are the lengths of the result video:
DVD2AVI not fixed: 221966 frames
DVD2AVI fixed: 221969 frames
DGIndex not fixed: 221993 frames
DGIndex fixed: 223996 frames

The audio in synched all along with the 1st one only, and of course it gets completely out of synch with DGIndex.
I use the ac3 file created by DVD2AVI with the D2V created by DVD2AVI, and the ac3 file created by DGIndex with the D2V created with DGIndex.

So... the question is... how I am supposed to fix the D2V or to use DGIndex and keep the audio synched ?

The other question is... when I fix the D2V created by DVD2AVI, I get repeated frames.
When I fix the one created by DGIndex, it seems to be ok.
Is this normal ?

Thx a lot ;)

PS: I read a lot today, but couldn't find the answers, forgive me if I missed it :)

[tritical]

I've been looking into this a little today, BangoO was able to send me the d2v files to look at. I think I've identified the cause of the problem with the repeated frames in the fixed dvd2avi d2v. First, the d2v does have a lot of illegal transitions (22 total), however most of those transitions are from 2 consecutive illegal transitions which re-correct the field order on the very next flag. i.e. things like these:

1 3 2 0 1 <--- 3-2 and 2-0 are illegal
3 0 2 1 3 <--- 0-2 and 2-1 are illegal
3 1 0 2 3 <--- 1-0 and 0-2 are illegal

Only 2 of the 22 total illegal transitions were standalone transitions that changed the field order for more then one frame.
Now, the method of fixing that fixd2v and dgfix use works ok for all of those transitions (corrects the sequence back to the usual 0 1 2 3 0, etc...) except for one, specifically:

3 0 2 1 3

Which, should be fixed by just swapping the 2 and 1, but fixd2v and dgfix end up changing it to:

3 1 3 1 3

While this does fix the field order change, it also introduces two extra fields and causes a frame to be repeated. This happens twice in the file, which is what causes the fixed version to have the extra frames. After fixing the handling for this case, the fixed dvd2avi d2v has only 1 more field then the original and no field order changes.

I'm not sure what is happening in the dgindex case. The original dgindex d2v has 33 illegal transitions total, a lot of which are two illegal transitions back to back (6 are standalones). As for why it has 27 more frames then the dvd2avi one I can't say for sure. Everyonce in a while there will be an extra trf flag in the dgindex d2v that the dvd2avi d2v doesn't have... interestingly, it's mainly these extra trf flags which are causing most of the illegal transitions :confused: in the dgindex d2v. Anyways, I don't know dgindex's or dvd2avi's internal workings enough to know what would cause the differences.

[BangoO]

And here is copy of my last private message to tritical:

By comparing the resulting video from the untouched D2V and the fixed D2V, there are 4 repeated frames after the TFM/Decimate.
I know the timing of those frames, but I don't know how to find them in the D2V file if I only know their timing.

Anyway, all those illegal transitions don't seem to cause any problem to TFM/Decimate, apart from the one which causes a field order change.
So why should I bother fixing them ?


Looking at the video, I found only one field order change, but you found 2 looking at the D2V.

Is there a way to make the relation between the hexadecimal address in the D2V and the actual number of the frame ?

What I do to find the field order changes is use azid on the extracted audio file, and it gives an "error" everytime there is a glitch in the video.
I've never seen a field order change anywhere else than in a glitch (when I use DVD2AVI).
So then I check the video in each place reported by azid.
This does not work at all if I use DGIndex as I get a lot more field order changes...

[BangoO]

Ok I finally understood how all this works...

I have an example of a frame that is added here:
- the original is: 0 1 2 3 0 1 2 0 1 2 3 0 1
- D2VFix gives this: 0 1 2 3 0 1 3 0 1 2 3 0 1
This adds a frame after doing TFM()/Decimate() and the audio gets a bit off synch.

Now, if I correct it that way:
0 1 2 3 0 1 2 2 2 2 3 0 1
I get the same number of frames as the original, and the audio stays synched.

PS: this example does not come from the previous D2V files.

[tritical]

Is there a way to make the relation between the hexadecimal address in the D2V and the actual number of the frame ? I made some modifications to Donald Graft's ParseD2V utility so that it reports the sector offset when it indicates gop starts. It already had the needed display to encoded frame mappings. I also changed it so it only reports the vob/cell numbers on gop starts, and changed the 3:2 pattern break output to only occur if a 3:2 pattern has occurred and then stops. So it also now reports 3:2 pattern starts. Another change is that td2vparse supports all types of d2vs... dvd2avi 1.76, 1.77, dvd2avidg, and dgindex d2v's. Link [removed]. td2vfix is also included in the zip. td2vfix is like DGFix and D2VFix but supports all d2v formats and includes the fix for the problem I mentioned above. It also includes a second fixing method that changes tff flags instead of rff, but I haven't gotten to test it yet (don't have any streams with illegal transitions)... so that method might do terrible things :devil:.

EDIT: nevermind

[tritical]

I have an example of a frame that is added here:
- the original is: 0 1 2 3 0 1 2 0 1 2 3 0 1
- D2VFix gives this: 0 1 2 3 0 1 3 0 1 2 3 0 1
This adds a frame after doing TFM()/Decimate() and the audio gets a bit off synch.

Now, if I correct it that way:
0 1 2 3 0 1 2 2 2 2 3 0 1
I get the same number of frames as the original, and the audio stays synched. Maybe this has been apparent to everyone but me for a while, but the problem lies in the fact that d2vfix/dgfix/td2vfix do not track the rff flag. Simply looking at the trf flags listed above I was for some dumb reason expecting the original to have 32 fields, however this is not necessarily the case. Once mpeg2dec/dgdecode process an rff flag, they ignore all subsequent rff's that have the same tff value until they hit an rff flag with the opposite tff value. i.e. your original sequence could effectively be this to mpeg2dec3/dgdecode (it depends on the sequence of flags that came before it though):

0 1 2 3 0 1 2 0 0 2 3 0 1

so then your fixed version, which would initially appear to have 1 less field then the original could have the same number of fields as the original version after decoding and the D2VFix version has 2 more fields instead of just 1. This does present an easy method for automatically achieving the fix you used.

ParseD2V/td2vparse suffer from this same problem of not tracking the rff flag correctly in such cases and giving incorrect frame mappings. However, cases like these are only possible when there are illegal transitions in the stream.

I'm gonna fix td2vparse to handle such cases correctly and correct td2vfix as well.

EDIT:

Fixed versions: td2vparse and td2vfix (http://bengal.missouri.edu/~kes25c/d2v_utilities.zip)

td2vparse now correctly handles the above cases and returns the correct mappings. It now also reports the total # of fields at the bottom of the parsed output (both counting and not counting the ignored rff entries). Also made the needed fixes to td2vfix, both method 0 and method 1. Fix method 1 had some other problems causing it not to work correctly.

After thinking about it seems like fix method 1 should be the safest and most accurate method to use. It always keeps the total # of fields in the decoded stream the same as the original and keeps the # of fields in the decoded stream from each original frame (or picture) the same. Method 1 can sometimes achieve both of these as well (for cases where there are two illegal transitions back to back it usually can, but for single illegal transitions it cannot), but most of the time it cannot. However, I still haven't been able to actually test method 1 :D.

[BangoO]

I tested it on an amazingly shitty D2V.
With the original D2V, after TFM/Decimate, I get 123916 frames.
If I use the "old" D2VFix, I get 123931 frames.
If I use TD2VFix 0, I get 123926.
If I use TD2VFix 1, I get 123916.

Now I'm gonna have a look at the stream fixed with TD2VFix 1, but it would be really helpfull if I could make the ling between the hexadecimal address and the frame number :)

Thx for you work tritical, it's really appreciated even if I don't have enough time to test it properly untill the year is here :D

[BangoO]

Ok I tested it on the stream corresponding to the D2V file I posted earlier.
I compared the stream fixed by TD2VFix 1 to the stream I fixed by hand and I know works.
After a TFM/Decimate, they seem to be identical.
That would mean that you TD2VFix 1 works great, but I still have to test it on other streams.

[BangoO]

Here is an example, on the D2V I posted earlier:

Original: 0 1 2 3 0 1 3 2 0 1 2 3
My fix: 0 1 2 3 0 1 2 3 0 1 2 3
TD2VFix 1 : 0 1 2 3 0 1 3 0 0 1 2 3

Original: 0 1 2 3 0 1 2 3 1 0 2 3
My fix: 0 1 2 3 0 1 2 3 0 1 2 3
TD2VFix 1 : 0 1 2 3 0 1 2 3 1 2 2 3

Original: 0 1 2 3 0 1 2 3 0 0 2 3
My fix: 0 1 2 3 0 1 2 3 0 1 2 3
TD2VFix 1 : 0 1 2 3 0 1 2 3 1 2 2 3

Original: 0 1 2 3 0 1 2 3 1 0 2 3
My fix: 0 1 2 3 0 1 2 3 0 1 2 3
TD2VFix 1 : 0 1 2 3 0 1 2 3 1 2 2 3

Original: 0 1 2 3 0 2 1 3 0 1 2 3
My fix: 0 1 2 3 0 1 2 3 0 1 2 3
TD2VFix 1 : 0 0 1 3 0 1 2 3 0 1 2 3

*Original: 0 1 2 3 0 1 0 1 2 3 0 1
*My fix: 0 1 2 3 0 1 2 3 1 3 0 1
*TD2VFix 1 : 0 1 2 3 0 1 2 3 0 1 2 3

Original: 3 1 0 2 3 0 1 2 3 0 1 2
My fix: 3 0 1 2 3 0 1 2 3 0 1 2
TD2VFix 1 : 1 3 0 0 1 2 3 0 1 2 3 0

And so on...
The one where I put the * is the one where the whole streams changes after it.
The other ones are just fixed locally, and the stream remains the same after the fix.

After checking the streams on several places, there is one place where, with my fix, I have a frame repeat...
I don't have it with your fix.
It's at 1:58:07.537.
They both have the same total time, but the very last frame is different, you have one more than me.
I compared yours to the original, and they are identical in this place, and at the very last frame.
So it looks like I did something wrong, and your fix works great :D

If you could tell me what is the corresponding hexadecimal address of 1:58:07.537, It would be helpfull.

[tritical]

It is good to know that method 1 works... it seemed like the most accurate/correct way, but never know till it is actually tested. I'm gonna replace the d2v fixing in TIVTC with method 1 from td2vfix. And thanks for bringing this topic up or probably never would have noticed the old method did not produce correct results. If you could tell me what is the corresponding hexadecimal address of 1:58:07.537, It would be helpfull. You should be able to get this information using the latest version of td2vparse. It includes the offsets to the gop starts so just search for the hexdecimal address in the output file from td2vparse and you'll be at the start of that line. Then follow the flags and frame mappings out to the flag you want. The #'s you'd be interested in would be the display frame mappings (the ones after the ':'). They indicate which frames in the output would go with the current trf flag.

[BangoO]

It's probably safer to wait untill I actually watch the whole video before including TD2VFix to your filters :)
But yes, it seems to be working great.

[BangoO]

Just one other thing...

For example, I have a file which contains lots of errors like those:

0 1 3 2 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3 1 0 2 3

Your fix fixes them that way:
0 1 3 0 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3 1 2 2 3

Of course, the pefect fix would be:
0 1 2 3 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3 0 1 2 3


Does the difference between your fix and "the perfect fix" matters ?
I mean... will it make any difference on the result video (after TFM()/Decimate()) ?

[tritical]

It is debatable whether that last option is indeed the perfect fix. While it does keep the pattern and look nice, it also changes the # of fields from a couple of the original encoded pictures that will be present in the final stream. To know if this is how it should be you'd have to know what was causing the illegal transitions in the first place and afaik no one knows that? So, I would say it would instead be best to fix the transitions by keeping the # of fields from each original encoded picture in the final stream the same.

That said, I don't think there will be any difference after ivtc between the two fixes in this case, but can't know with absolute certainty without testing it. There could be a difference after field matching if you were matching from the top field because that last fix would repeat a different frame then the first one. The first one should be exactly the same as the original after field matching (no matter which field you match from). However, after decimation both fixed versions should be the same.

[BangoO]

Originally posted by tritical
While it does keep the pattern and look nice, it also changes the # of fields from a couple of the original encoded pictures that will be present in the final stream.
I don't see why it would change the number of fields.
Could you enlighten me ? :)

[BangoO]

Here is another example, this is what TD2VFix says:

------------------------------------------------------------------
Using tff (1) method to fix illegal transitions.

Illegal transition: 0 -> 2
7 7 3007 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1
7 7 3395 2 3 0 1 2 3 0 1 2 3 0 2 1 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
count = 1

Illegal transition: 2 -> 0
7 59 157A 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1
7 59 1837 2 3 0 1 2 3 0 1 2 3 0 1 2 0 3 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
count = 1

Illegal transitions found in dvd2avi project file!
A fixed d2v file has been created.
All processing completed successfully.
------------------------------------------------------------------

"Your fix" is:
7 7 3395 2 3 0 1 2 3 0 1 2 3 0 0 1 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
7 59 1837 2 3 0 1 2 3 0 1 2 3 0 1 2 2 3 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3

"My fix" is:
7 7 3395 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
7 59 1837 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3


I compared both videos frame by frame in VDubMod with the following script:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")

At the place of the illegal transitions, calling P the progressive frames and I the interlaced one, I get:

With "your fix":
PPPIIIPPIIPPPII for the 1st one
PPPPIPPPII for the 2nd one

With "my fix":
PPPIIPPPIIPPPII for the 1st one
PPPIIPPPII for the 2nd one

So mine looks better but...
Then, if I add TFM() and Decimate() to the script, I get the exact same result :)


Last thing, TD2VParse says:
13299: 16602,16603 -- 2 [3:2 pattern break] [ILLEGAL TRANSITION (0->2)]
13300: 16603,16604,16604 -- 1 [ILLEGAL TRANSITION (2->1)]

So, running the first AVS script I gave earlier, I have to look at frame 16602 and followings.
Now, if I use the AVS script with TFM() and Decimate(), TD2VParse says I should look at frame 13299 and following.
But, looking at the time displayed in VDubMod, the corresponding frames are 13282 and followings.


Well... the main issue here is to know if your fix can sometimes give bad results which could be avoided by fixing the D2V by hand.
On the above cases, it's not really a problem as the 2 illegal transitions are really close to eachother and as the 2nd one cancels the 1st one anyway.
I'm more concerned about the illegal transitions which have lots and lots of fields between them. In this case, you change lots of things in the D2V...

What do you think about all that ? :D

[tritical]

I don't see why it would change the number of fields.
Could you enlighten me? Hm, I'm not being too clear cause I don't know exactly how to say what I mean. You are correct that it won't change the total number of fields present in the output stream, but it does change the # of fields that some of the original pictures in the encoded stream contribute to the output stream. For example with these trf flag sequences:

0 1 3 2 0 1 = original
0 1 3 0 0 1 = td2vfix method 1
0 1 2 3 0 1 = your fix

You get these # of fields from each original picture:

2 3 3 2 2 3 = 15 total (original)
2 3 3 2 2 3 = 15 total (td2vfix method 1)
2 3 2 3 2 3 = 15 total (your fix)

For cases like these that have two back to back illegal transitions it doesn't really matter because after ivtc they will all turn out the same. And it might be a moot point to begin with, since in the end as long as your keeping the total # of fields the same then the result should be the same after ivtc (both field matching and decimation), though I can't prove that with 100% certainty. Last thing, TD2VParse says:
13299: 16602,16603 -- 2 [3:2 pattern break] [ILLEGAL TRANSITION (0->2)]
13300: 16603,16604,16604 -- 1 [ILLEGAL TRANSITION (2->1)]

So, running the first AVS script I gave earlier, I have to look at frame 16602 and followings.
Now, if I use the AVS script with TFM() and Decimate(), TD2VParse says I should look at frame 13299 and following.
But, looking at the time displayed in VDubMod, the corresponding frames are 13282 and followings. The encoded frame given by td2vparse does not necessarily line up with the frame # of the output stream after decimation. If it is 100% pure film then it will, but if there are any sequences that aren't (say runs of 2's or 0's) then they wont. To get the actual frame (or pretty close estimate) you'll have to use the usual method... multiply the display frame mappings by 4/5. Well... the main issue here is to know if your fix can sometimes give bad results which could be avoided by fixing the D2V by hand.
On the above cases, it's not really a problem as the 2 illegal transitions are really close to eachother and as the 2nd one cancels the 1st one anyway.
I'm more concerned about the illegal transitions which have lots and lots of fields between them. In this case, you change lots of things in the D2V...

What do you think about all that ? Off hand, I would say after ivtc there would not be any difference between the fixed version by td2vfix method 1 and if you fixed it yourself. Though there is always the possibility for a really weird stream or other strange things so its not an absolure guarantee. All I can say it is definitely better then any other automatic method, but there could be times where it would not produce the same results as manual inspection/fixing.

[BangoO]

Ok :)
If I see a place where your fix does something wrong, I'll tell you.

[BangoO]

I'm sorry tritical, but there are places where your fix just does not work :(

Here is an example:
7 0 16C4 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1

There is forbidden 3 3.


Your fix is:
7 0 16C4 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3

This changes the whole D2V file after the error and, unfortunatly, it brings a lot of repeated frames during the whole video.


I tested with this instead:
7 0 16C4 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1

And I don't get repeated frames where I get some with your fix.


The total length of the video is the same between the original, your fix, and my fix.
That means that your fix is also dropping some frames (as it is repeating some and as the total length is the same).

[tritical]

Well, just looked at that sequence and I'm pretty sure what the problem is. But, would it be possible for you to send me the d2v to test on? if so just pm me, thanks.