ERRORS @ Navigation Packs (might that be the freeze cause ?)

[jptheripper]

oh sweet.. :)

[archaeo]

yeah, some serious debugging work going on lately :devil:

[gm901]

Done a full reencoding using 0.77

It’s almost perfect.
No skips, now I can see every minute.
No long-time freezes.

The “almost” is because at some previously freezing points, to be exact at 8 out of 56, there is a peculiar attitude.
It’s difficult to express what I see. Imagine that reaching the specific point, the image is trembling for 2-3 frames and after ~30 frames it momentarily freezes, like showing the current frame 2 or 3 times. No audio effect.
Another thing. When I go backwards just after the tremble and then forward normal play, there is no freeze
What “bothers” me is that is not happening to all 56 (previous 00:00:00,00) points and only to 8 of them. It is not consistent.

Perhaps, I should compare these points against the RBxRB perfect movie

[jdobbs]

If you run it through "no compression" it should match exactly. Let me know if it doesn't.

[gm901]

The bloody #$@&^*%$ they don't match.
attach 4 .txt files from VobEdit
It is the navpack before and right on freeze for 077 and 077x077.
The second LBA is different
I can't, but I expect you can see immediately the attachments. If not let me know.

[XMEN3]

...77

[050d] Next 6.5 sec. VOBU with video 2436 -2147481212 [80000984]
[0511] Next 6 sec. VOBU with video 2261 -1073739563 [c00008d5]

and 77--->77
[050d] Next 6.5 sec. VOBU with video 2300 -2147481348 [800008fc]
[0511] Next 6 sec. VOBU with video 2130 -2147481518 [80000852]

[jdobbs]

Just got back from vacation. I'll get back on this.

[jdobbs]

What version of VOBEDIT are you using? I use v0.60 and I have no idea how you get it to print out the VOBU_SRI tables?

[DMagic1]

Hmm, I'm not sure what version this happened but now I can not run RB output thru CloneDVD2. I remember being able to run the output thru it a long time ago to fix the chapter sutter. I hadn't tried it in along time since I didn't have the sutter anymore. CloneDVD2 always complains about IFO format errors and dies without being able to complete the movie. I don't know if this is completely related to the navigation packs or not. Could this be related?

[gm901]

Originally posted by jdobbs
What version of VOBEDIT are you using? I use v0.60 and I have no idea how you get it to print out the VOBU_SRI tables?

0.60, Bottom Button "Copy2Clipb" (and checked the VOBU-SR checkbox)

[jdobbs]

@DMagic1

I don't think so. Any changes DVD Rebuilder makes to the IFO has remained pretty much consistent since the first versions. Has CloneDVD2 changed?

[gm901]

Well, you'll find it strange, but another movie that I transcoded 3 days before dnld my 1st RB (so it's not RB this time) has same nav problems (no zero BCDs, no pseudo-cells SRI, but freeze and skip some seconds-using LG of course).
Since it's a one disk movie without menus etc., then it should have been done with Shrink (which I used for compressions >90%, for heavier I just splitted).
Up to now, the only strange thing is that Shrink, which does not de/remuxe, presents freezes.
I'll try to get back my original to check it out.
But, the most strange is when trying to apply the well-proven method of RB 100%, it produced ERROR 006 !!! at Rebuild phase and the relative thread is talking about Quenc, which is clearly not the case here.
Right now I'm trying to understand how this SRI values are calculated, in order to add them to my check nav. program.
Too complicated for a newbbie, but it Shall Be Done. It seems I have to recheck all my movies.

[gm901]

BTW, if the text from VobEdit doesn't make it easier for you, I can extract any specific pack in binary (i.e. a 077.vob containing a requested amount of every or specific type of packs ---nav, video etc)

[jdobbs]

Have you reviewed the documentation at mpucoder's site? It is a very good source for understanding how they are calculated. It is simply a matter of pointing to the correct sector of the VOBU in the cell for the time offset in the table (in a positive or negative direction from the current VOBU).
Originally posted by gm901
Well, you'll find it strange, but another movie that I transcoded 3 days before dnld my 1st RB (so it's not RB this time) has same nav problems (no zero BCDs, no pseudo-cells SRI, but freeze and skip some seconds-using LG of course).
Since it's a one disk movie without menus etc., then it should have been done with Shrink (which I used for compressions >90%, for heavier I just splitted).
Up to now, the only strange thing is that Shrink, which does not de/remuxe, presents freezes.
I'll try to get back my original to check it out.
But, the most strange is when trying to apply the well-proven method of RB 100%, it produced ERROR 006 !!! at Rebuild phase and the relative thread is talking about Quenc, which is clearly not the case here.
Right now I'm trying to understand how this SRI values are calculated, in order to add them to my check nav. program.
Too complicated for a newbbie, but it Shall Be Done. It seems I have to recheck all my movies.

[DMagic1]

Originally posted by jdobbs
@DMagic1

I don't thinks so. Any changes DVD Rebuilder makes to the IFO has remained pretty much consistent since the first versions. Has CloneDVD2 changed?

Yes it has been many different releases since back then. I guess that could be why it worked then but not now. I still wonder what it could be deteching and not able to process about the RB output.

[DMagic1]

Originally posted by jdobbs
@DMagic1
I don't thinks so. Any changes DVD Rebuilder makes to the IFO has remained pretty much consistent since the first versions. Has CloneDVD2 changed?

Originally posted by DMagic1
Yes it has been many different releases since back then. I guess that could be why it worked then but not now. I still wonder what it could be deteching and not able to process about the RB output.
Yes it has been many different releases since back then. I guess that could be why it worked then but not now. I still wonder what it could be deteching and not able to process about the RB output.

Bad news, I tested a movie I did awhile back with RB. CloneDVD2 doesn't complain about anything wrong with that movie. So it seems to be something with the latest version of RB. The image is still on my HD and was created on November 13, 2004.

*Edit* Wrong date corrected.

*Update*
Went all the way back to v065 and still get the error so I don't know what the problem is with Clone and this movie.

[jdobbs]

It could be errors in the IFOs that were there in the original. There are areas that DVD doesn't change. You might try running IFOEDIT's "Update IFOs" on it and see if it finds any errors.

[DMagic1]

:confused:
I don't want to seem like I don't know any better but I don't know of that feature in IFOEdit. Do you mean the "Get VTS Sectors"? I know of "Update IFOs" only with IFOUpdate. You're not talking about a mock-strip with IFOEdit are you?

[jdobbs]

Sorry... yes I was talking about "Get VTS Sectors"

[gm901]

@jdobbs

The only thing i miss right now, concerning the vobu sri, is when/why the value 7FFFFFFF is used, instead of 3FFFFFFF, at timeline 16-19 (10 to 120 secs) nxt or prv.
I would be obliged if you could light this point.

[Sir Didymus]

Hi gm901! :)

bit 31 is set to indicate a valid pointer.

bit 30 is set to indicate one or more VOBU are present between the pointed VOBU and the reference closer to the current VOBU.

I would say bit 31 have the priority, so both 3fffffff and 7fffffff means "not valid pointer"...

Other than the very fundamental hint of Jdobbs [to get a look at the MpuCoder site, which is a precious source of DVD knowledge], for a clear description of the SRI tables contents you may also get a look at:

http://dvd.sourceforge.net/dvdinfo/dsi_pkt.html

Cheers
SD

By the way: good investigation!!!

[gm901]

@Sir Didymus
Thanks (with some delay though, like the Ran Tan Plan)

@jdobbs
Find out why the 077 didn’t produce perfect results.
The problem is that some of the SRCs are not correct.
See the example from 077 and 077x077. The LBA 40274 is where the “freeze” happens.

077
Type LBA SRC
Vi 40272 8.392.770,086
Au 40273 8.395.035,004
NAV 40274 8.393.133,000 <-- Error
ViG 40275 8.393.279,086
Vi 40276 8.393.425,172
Vi 40277 8.393.571,257
Vi 40278 8.393.718,043

077x077
Vi 40272 8.392.770,086
Au 40273 8.395.035,004
NAV 40274 8.395.200,000<-- OK
ViG 40275 8.395.346,086
Vi 40276 8.395.492,172
Vi 40277 8.395.638,257
Vi 40278 8.395.785,043


After a little reading, I’ve seen lots of SW players that use the offsets 0x4f1, 0x541 and 0x545, 0x595 ( 4 next-prv vobus) to navigate when playing. Therefore I can imagine that the LG does use this values, because the 076 fix for 00:00:00,00 didn’t change anything, but the 077 almost fixed that (but the above SRCs). And I find out that, because I wrote a utility that calculates all the VOBU_SRI values and checks them against the existing from the vob files (and of course corrects them). All the freezing points up to 076 had incorrect values at the specific offsets.

I wonder what values are looking the other standalones, the IFOs maybe ??

But there is another thing. With that utility I’ve scanned almost 50 original DVDs and another 20 backups from RB.
The originals produced 0 errors, but the RB too many. The util except the above next-prv vobus checks also the 2 x 19 next / prv seconds timeline (0x4f5 to 0x53d and 0x549 to 0x595).

The errors fall to 3 categories.
A : 4 next-prv VOBU
B : 15+15 next / prv sec. (0.5 to 7.5 seconds)
C : the rest 4 + 4 next / prv sec (10 to 120 secs)

Well, the original were not all perfect. A 5% of them had some bit 30 errors (0x40000000), using 3ffffff instead of 7fffffff.
It seems that this does not affect anything, so each authoring SW has it’s way.

As for the RB, even the RBxRB, produces:
None for cat. A (except for the damn movie that started this thread)
Many for B
Less for C

See an example for 14083 VOBUs (total checked values are 19 x 2 x 14083 = 535,154)
Cat A: none
Cat B:
TOTAL ERR : next = 88752, previous = 164446 (16.5% and 30.7%)

Cat C:
TOTAL 3FFFFFFF : next = 144, previous = 236
TOTAL 7FFFFFFF : next = 5593, previous = 5550 (RB simply does not use 7FFFFFFFs)

Some first thoughts (not concluded yet the search)
Seems that almost all the cat. A errors, were mostly one (or more) Vobu further, that is +1 for the next, -1 for the prv,
Errors that (I think) I’ve seen, trying to develop the SearchVobus function, when I’ve used the
if ( StartPT < VOBU_NAV_list[i].StartPT (0x039)
instead of the correct
if ( StartPT < VOBU_NAV_list[i].EndPT ) (0x03d)
(for the forward this)

That is for now. Waiting your feedback.

[jdobbs]

I will take a look at what you've written -- I'm sorry but I'm having a little trouble deciphering it. Are you positive your scanning software is right? I assume what you meant to say is SCR? How are you calculating the SCR? I mean, based on what?

If there is a problem I definitely want to fix it -- but I have to be sure there is a problem.

[Sir Didymus]

If you think it may be useful, a possibility is to use the Philips Verifier for looking at SRI pointers errors. It'll take some time, but it may help to verify the possible presence of glitches into these search tables.

I'll do some testing on the matter and report...
Maybe it will give confirmation (or confutation...) to the gm901 findings...

Cheers,
SD

[jdobbs]

Well, he was right on earlier tests, so I'm working on the assumption that he's right now on the SRI information. I've been very careful with calculation of SCR values -- so there I'm not as sure. I probably won't have time to work on it until this weekend, though.

[gm901]

After midnight hours makes it difficult for me sometime, so let’s try to make it more clear (before it gets too late…)

I’m talking about 2 different issues, one concerning ONE specific movie and the other concerning ALL the movies I’ve done with RB.

FIRSTOriginally posted by jdobbs
I assume what you meant to say is SCR?
Yes. Doing this lots of times, especially when I’m tired.
I mean SCR (System clock reference), 6 bytes @ pack header’s offset 4 (after 0x1ba).
The calculations agree with the DEC values shown by VobEdit.
Besides, I first located that with VobEdit, cause, when my utility fixed all the VOBU_SRI errors, the image was still a little freezing there (see prv post about results from 077).

Well, this thread is too long, so I’d better remind you that it all started with the backup of movie Condor, which had 56 freezes/skippings, due to 56 more pseudo-cells (BCDs and VOBU-SRIs). The real cells were 26, but there were created 82 avs files, which in turn produced, when remuxing, 82 cells or better cell-like patterns i.e 56 pseudo-cells that freaked one of my standalones, the LG.

Version 0.76 fixed the BCD 00:00:00,00s and version 0.77 fixed the SRIs.

I do have the RB output folders for versions 0.69, 0.76 and 0.77 and scanning them:

Results:
RB069_CCE
Number of Pseudo Cells = 56
Next/Prv Vobu Errors(0x4f1, 0x541 / 0x545, 0x595)
Next= 56,
Prv = 56
ERROR SCR: Next Values less than previous = 0

LG watching: 56 long freezes & skippings

RB076_CCE
Number of Pseudo Cells = 56
Next/Prv Vobu Errors
Next = 56
Prv = 56
ERROR SCR: Next Values less than previous = 9

LG watching: 56 long freezes & skippings

RB077_CCE
Number of Pseudo Cells = 0
Next/Prv Vobu Errors
Next = 0
Prv = 0
ERROR SCR: Next Values less than previous = 9

LG watching: 9 very fast freezes (no skippings)

RB077_X_ RB077
Number of Pseudo Cells = 0
Next/Prv Vobu Errors
Next = 0
Prv = 0
ERROR SCR: Next Values less than previous = 0

LG watching: OK


So, it was the 0x4f1, 0x541 and 0x545, 0x595 errors that caused the long freezes & skippings and not the BCD 00:00:00,00s.

And checking the 077 vs 077x077 discovered the SCRs, which are like:

File TotSector Cell VOBU FileSector PackSCR
1 40272 1 195 40272 8392770.086
1 40273 1 195 40273 8395035.004
1 40274 1 196 40274 8393133.000<----ERROR
1 40275 1 196 40275 8393279.086
1 40276 1 196 40276 8393425.172
1 40277 1 196 40277 8393571.257
…
2 539668 6 3057 15381 131662364.001
2 539669 6 3057 15382 131664836.122
2 539670 6 3058 15383 131664251.000<----ERROR
2 539671 6 3058 15384 131664397.086
2 539672 6 3058 15385 131664543.172
2 539673 6 3058 15386 131664689.257
…
Points of error, agrees exactly with watching errors, and in fact are the Vobus that presented the BCD errors.
Cannot understand why there only 9 errors instead of 56.

Therefore, I have to assume that the fix for BCDs in 0.76 caused the SCR errors (if not anything else between 0.69 and 0.76). If you have trouble tracking it, I could backup with any versions to locate it.
That’s for the SCR.
BTW which value should I calculate for the Pack Header SCR of a navpack? Of course, I can see the SCRs of previous packs or next, but what's the lenght of the navpack, is it prv + some fixed value, related to the other packs ???

SECOND
Originally posted by gm901
But there is another thing. With that utility I’ve scanned almost 50 original DVDs and another 20 backups from RB. From that point on, in my previous post, I’m talking EXCLUSIVELY about the SRI next/prv seconds pointers, which are not correct for ALL movies, not only the Condor. My backups start from 0.67

I can never be sure that my scanning software is right. I'm still developing it and developing, as you know much better than me, is nothing but Try-Catch-Correct.
Before finally scanning these 50 orig. movies, tried hundreds of times to achieve a result that would conform both to the specs and of course to real world, to original movies. The results should be 0 errors, since it’s original. And correcting for one specific movie, produced errors for another. So finally, I understood(??) how things work, and the SW runs smoothly (until a new movie comes out and freaks me like the LG).


Thanks

[jdobbs]

Points of error, agrees exactly with watching errors, and in fact are the Vobus that presented the BCD errors.The question I'm trying to get to is: What makes it an error? Compared to what? How do you calculate what you think it should be?

I have the same question on the SRI tables... For example, if you have .5 second increment in offset -- the offset could change depending upon which VOBU is nearest and what might have happened in scene detection... VOBUs don't necessarily fall on even .5 second boundaries. The original and the backup also won't necessarily match -- I assume you're not making that assumption.

I'm not doubting that there may be something that needs to be fixed -- I just need to know what to look for.

At any rate I will give it a good look this weekend. I'm still shocked that the BCD values were actually used by a player for timing.

[gm901]

What makes it an error? Compared to what?
1. 077 vs 077x077 at first (all other vobu values are related, didn't say the same)
2. after adding SCR check to the util, it's the only points that a next pack has a SCR value smaller than the previous (and I'm not talking about navpacks, but all packs)
3. scanning lots of movies afterwards, never seen it elsewhere.
4. it freezes there, all 9 points, 077x077 does not ((practical reason)
5. think it's logical for the SCR value to keep growing from pack to pack, no matter what type of pack
6. MPEG-2 Pack Header: SCR and SCR_ext together are the System Clock Reference, a counter driven at 27MHz, used as a reference to synchronize streams.
7. Does not agree with the related same pack PTM values ( 27MHz / 300 to get 90KHz), which keep growing

The extract from scanning does not compare with anything. just shows selected SCR values which are smaller than those of the previous (video) pack.
same question on the SRI tables
I do not compare. I recalculate the values from scratch. And I don't take for granted the IFO's. I assume that they may be wrong (and in fact if they are, I correct them). The utility checks for all navigation errors, so
A. scans all the vob files and creates new lists for evrything that finds.
B. from those lists gets the necessary info as to calculate everything (by everything I mean everything that I do have the knowledge up to now)
C. if nessecary, may create new vob/ifo files, correcting the error areas (and copying intact the others)

I'm still shocked that the BCD values were actually used by a player for timing.
Never said that. ButSo, it was the 0x4f1, 0x541 and 0x545, 0x595 errors that caused the long freezes & skippings and not the BCD 00:00:00,00s.
and
I’ve seen lots of SW players that use the offsets 0x4f1, 0x541 and 0x545, 0x595 ( 4 next-prv vobus) to navigate when playing.

[jdobbs]

2. after adding SCR check to the util, it's the only points that a next pack has a SCR value smaller than the previous (and I'm not talking about navpacks, but all packs) I didn't notice that -- I can't imagine how that could happen. That's definitely a problem. Did that happen on any other discs besides the one you mentioned?

[jdobbs]

Another question. Were the points where the SCRs go backwards related to segment starts?

[jdobbs]

I'm digging through the code as I write this.

An additional request... but it could save me a lot of time. Could you check the points where the SCR is being set backward and whether the value you've found matches the SCR value found for that segment in the REBUILDER.INF file (found in the D2VAVS directory)?

I'd like to get this resolved once and for all.

[jdobbs]

Another: When you say the values in the SRI table are wrong, what is the criteria? Are the values correctly pointing to NAVPACKS? Are you saying they aren't pointing to what you believe to be the right NAVPACKS, or are they pointing to a sector that is other than a NAVPACK?

[jdobbs]

A. scans all the vob files and creates new lists for evrything that finds.
B. from those lists gets the necessary info as to calculate everything (by everything I mean everything that I do have the knowledge up to now)
C. if nessecary, may create new vob/ifo files, correcting the error areas (and copying intact the others) How are you determining which NAVPACK (VOBU) is correct when it isn't exactly .5 seconds apart? Are you selecting the earlier, later, or closest?

[jdobbs]

(RB simply does not use 7FFFFFFFs) It's a question to me as to whether you really should put 7FFFFFFF in the VOBU_SRI tables? 3FFFFFFF indicates there is no VOBU within the cell for this span. Setting bit 30 would indicate there is one or more VOBUs between the current point and the one referenced. So how could you say there were one or more VOBUs between this point and a point that doesn't exist?

I know I've seen the 7FFFFFFF in headers and I can add it easily. If mpucoder is out there, I'd really like to hear a ruling on that one. My guess is that it is probably fine either way.

[jdobbs]

On your category B and C errors... I don't think they are truly "errors". I think it is a matter of how you are determining the next offset as compared to how I am. I select the VOBU that is at least the specified time from the current reference point, and I think you are choosing (perhaps) the one immediately preceding the reference offset (where the offset time is within the VOBU). Or are you choosing the VOBU that has a value nearest the offset? The method I use would be equally accurate to the former, one or the other off by the difference between the calculate SCR (within the VOBU) and the NAVPACK.

I think either way will work fine. If it didn't I would have gotten reports of problems long ago -- and I haven't. But, if your testing has indicated the original DVDs use one of the other two methods, let me know which one and I will modify my code to match it.

I still haven't found a possible cause for the SCR error you mentioned -- but as I understand it you've only seen it on one disc, right?

Thanks for the work -- it's nice to look as something every now and then that isn't self-inflicted user error. It also forces me to go back and reexamine my code.

By the way, don't I remember your saying you were just learning this stuff? If so, you are a helluva fast learner....

[Sir Didymus]

Originally posted by jdobbs
I didn't notice that -- I can't imagine how that could happen. That's definitely a problem. Did that happen on any other discs besides the one you mentioned?

Checked on few titles (all PAL, R2); SCR is reset to 0 sometimes (and this is normal) but did not see, up to now, any instance of SCR decreasing...

For people interested, the check was performed using this program:

http://webmail.libero.it/r.php?d=libero.it&wr=3zqcxucf&ws=3zqcxucf&e=libero.it&c=lMwhN6qtgTlmVlWWi4PPkdqyMUsl0FP956226

link valid until 17.03.2005 at 14:44.

[Sir Didymus]

Originally posted by jdobbs
How are you determining which NAVPACK (VOBU) is correct when it isn't exactly .5 seconds apart? Are you selecting the earlier, later, or closest?

It should be EARLIER (Philips Verifier Manual, page 144).

>>> In principle it is required (for forward references):
VOBU_S_PTM[Target_VOBU] = VOBU_S_PTM[Current_VOBU] + (n * 0.5 sec.)

>>> In practice this becomes:
VOBU_S_PTM[Target_VOBU] <= VOBU_S_PTM[Current_VOBU] + (n * 0.5 sec.)
VOBU_E_PTM[Target_VOBU] > VOBU_E_PTM[Current_VOBU] + (n * 0.5 sec.)

>>> For backward references the plus sign should be repalced by a minus sign...

[Sir Didymus]

Originally posted by jdobbs
Another: When you say the values in the SRI table are wrong, what is the criteria? Are the values correctly pointing to NAVPACKS? Are you saying they aren't pointing to what you believe to be the right NAVPACKS, or are they pointing to a sector that is other than a NAVPACK?

Just want to report some findings related to the work of gm901 on the subject.

Performed two verifying sessions, using the Philips DVD-R Verifier, on a single movie: HERO, PAL, R2.
Used RB078, OPV mode, using CCE as encoder.

PLEASE CONSIDER:
1. THE REBUILT TITLE PLAYS PERFECTLY ON MY TWO STANDALONES.
2. THE VERIFIER IS VERY PICKY, REPORTING ALSO MINOR AND (SOMETIMES) TOTALLY ININFLUENT GLITCHES
3. THE VERIFIER IS A SOFTWARE, AND IT ISN'T BUG FREE. THIS HAS BEEN CLEARILY REPORTED,
FOR EXAMPLE, IN SOME INCORRECT COMPUTATION OF DTS & PTS TIMINGS, INVOLVING TFF & RFF
FLAGS, FOR NTSC TITLES.

First session: full logging of the source title.
Second session: full logging of the rebuilt title.

See the attached picture for reference:

[img=http://img233.exs.cx/img233/8725/image17xz.th.gif] (http://img233.exs.cx/my.php?loc=img233&image=image17xz.gif)

It is evidenced in Green the errors, present in the original title, and corrected by DVD-RB.
In Red the errors, not present in the original, and introduced by DVD-RB.

Here is some "red error" examples:

>>> [MPEG] ERROR 1450 (ref. MPEG Systems 2.4.5.1 | 2.5.2.3):
First byte of AU in Video PES_packet 1944 arrives at 353771 or 362 ticks after its decoding time 353409.
in PES stream 0xE0 at byte 3841583 bit 0 (byte 12 of packet 1892);
byte 26 of pack 2006 (PS stream byte 4108314).

These #1450 errors are indicating an incoherence between SCR and DTS values; specifically that the decoding time for the Access Unit has already past, but the first byte was just received. This could result in some decoding problems and associated Audio or Video playback errors.

>>> [DVD] ERROR 3022 (ref. DVD-3 5.1.1):
The previous VOBU presentation period is 0.360 seconds; must be at least 0.40 sec.
at byte 2048 bit 0 of pack 4380 (PS stream byte 8972288).

This is a known glitch: A VOBU should represent a presentation period of at least 0.4 seconds.

>>> [DVD] ERROR 4616 (ref. DVD-3 4.5.1 (4,5,6)):
DSI_GI : The VOBU_3RDREF_EA value 129 must be zero when there is no third reference picture
for DSI unit 218 at byte 20 bit 0;
PES stream-byte 439193 (byte 27 of packet 437);
PS stream byte 46781467 (byte 1051 of pack 22842).

These errors, IMHO, are minor ones, representing just a secondary consequence of the "short" VOBU presence in the encoded stream; in the specific reported error, the GOP structure have 7 frames: IBBPBBP, and the VOBU lenght is 280 ms.

The errors related to the SRI tables are the ones from 4673 to 4686:

>>> [DVD] ERROR 4673 (ref. DVD-3 4.5.4 (1,4)):
VOBU_SRI : BWDI 20 V_BWD_Exist2 flag 0 specifies incorrectly non-existing video data between the VOBU to be presented just before the predecessor at pack 245 and the first VOBU in this Cell at pack 0 for DSI unit 17 at byte 382 bit 1;
private_stream_2 byte 17689;
PES ($BF) stream-byte 35545 (byte 389 of packet 35);
byte 1413 of pack 4130 (PS stream byte 8459653).

>>> [DVD] ERROR 4675 (ref. DVD-3 4.5.4 (1,4)):
VOBU_SRI : FWDI 15 V_FWD_Exist2 flag must be 0 for FWDI1..15 for DSI unit 5 at byte 254 bit 1;
private_stream_2 byte 5345;
PES ($BF) stream-byte 11297 (byte 261 of packet 11);
byte 1285 of pack 1279 (PS stream byte 2620677).

>>> [DVD] ERROR 4682 (ref. DVD-3 4.5.4 (1,4)):
VOBU_SRI : BWDI 1 addresses a VOBU presented from 180609 to 223809 which is not at an offset of 1 times 0.5 sec from the presentation start time (223809) of the VOBU containing this DSI, which is 178809 for DSI unit 5 at byte 322 bit 2;
private_stream_2 byte 5413;
PES ($BF) stream-byte 11365 (byte 329 of packet 11);
byte 1353 of pack 1279 (PS stream byte 2620745).

>>> [DVD] ERROR 4685 (ref. DVD-3 4.5.4 (1,4)):
VOBU_SRI : FWDI 5 specified a non-existing destination VOBU at time 81592809, while a VOBU being presented from 81565809 to 81605409 exists at pack 321251 for DSI unit 1963 at byte 294 bit 0;
PES stream-byte 3946917 (byte 301 of packet 3927);
PS stream byte 656606509 (byte 1325 of pack 320608).

>>> [DVD] ERROR 4686 (ref. DVD-3 4.5.4 (1,4)) :
VOBU_SRI : BWDI 1 specified VOBU address 172 must be 0x3FFFFFFF when the target VOBU presentation start time (43200) exceeds the Cell's presentation start time 81605409. for DSI unit 1970 at byte 322 bit 2;
private_stream_2 byte 2005783;
PES ($BF) stream-byte 3961015 (byte 329 of packet 3941);
byte 1353 of pack 321538 (PS stream byte 658511177).

[Sir Didymus]

Originally posted by jdobbs
It's a question to me as to whether you really should put 7FFFFFFF in the VOBU_SRI tables? 3FFFFFFF indicates there is no VOBU within the cell for this span. Setting bit 30 would indicate there is one or more VOBUs between the current point and the one referenced. So how could you say there were one or more VOBUs between this point and a point that doesn't exist?

I know I've seen the 7FFFFFFF in headers and I can add it easily. If mpucoder is out there, I'd really like to hear a ruling on that one. My guess is that it is probably fine either way.

Agreed. I see no complain from the Verifier about 3FFFFFFF versus 7FFFFFFF.

[gm901]

Too many assignments boss!!! I’ m exhausted…

So First things first, because it’s very easy to mix them.

EXTRA SEGMENTATION ISSUES

(Title that means BCDs, 4 nxt/prv VOBU pointers, and lately SCRs)

The SCR issue is a new check for me, so I’m not sure what’s going on with all other RB movies. I’ve checked only a couple done with 0.77 (no extra segments) and are OK.
Does not exist in 0.69 (Condor), don’t know in between, Exists in 0.76 (and 0.77…) and does not exist in RBxRB
Since my first report (using then 0.67), all my backups are RBxRB, so there is no reason to check them. They are OK.
I have to presume that this issue was introduced somewhere between 0.70 and 0.76, and since the only modification concerning my case happened to 0.76, I would guess that this is the guilty.
Another guess is that SCR does not concern other backups, but only extra segmentation.


Can’t quote everything, so I attach a zip to see for yourself.
Contains:
For Original, 069, 077, 077x077:
Extracts from VOBUs list, the points exactly of 82 segments (so as to make it small)
-I have included 5 navpacks before and 5 after each point
-So the middle row of each group is the crucial.
The file Errors.txt where all SCR errors are shown, since in the VOBUs extracts are only navpacks, but here is all packs.
The file gmVU_log.txt which is the general logfile, where all errors are reported. There you can see what every RB version changes.
And of course the REBUILDER.INFs


You’ll see that the original has an unusual IBP structure
It uses [Gc]IPBBPBBPBBPB[Gc]IPBBPBBPBBPB, where [Gc] means GOP closed
2 closed GOPs in one VOBU!
That’s why the navpacks of the RB (14084) are double than those of the orig (7243), since the structure becomes [Go]IBBPBBPBBPBB (o for open).
Can’t understand though, why the segments are 82 (only 26 cells). For all other movies, segments and cells are the same.
(Just thinking openly: when cells == segments everything is ok, therefore for some reason, this movie belongs to an unusual case where many parameters have to be set from “scratch”, not taking too much into account the already existing nav info…)

SRI 19x2 POINTERS

The formula I currently use, is the one that after checking many orig. DVDs, produced no errors.

For forward
if ( StartPT < VOBU_NAV_list[j].EndPT )
(where startPT is the value of StartPTS (off 0x039) + (whichever_seconds *90000))

and for backward
if ( StartPT >= VOBU_NAV_list[j].StartPT )
here is StartPTS - (whichever_seconds *90000)

Practiced a lot using combinations of StartPT and EndPT AND < or <= (or >, >=).

This result produces no errors (except a few and only to a 5% of scans, which mostly are “original” dvd5s –i.e official distributor but locally reauthored and compressed, incl adds- issued as gifts to other purchases). With original original (no””), produces 0 errors.


whether you really should put 7FFFFFFF

Well, there is a logic. After X seconds there is nothing, but between here and nothing, there is something. Technically, I would like to know if between me and nothing, exist something or my next step is to hell.
Anyway that’s the practice for every dvd I've scanned, and if you see patterns of 7Fs and 3Fs you’ll clearly notice that when reaching a new cell, first there are only 7Fs and from some point come the 3Fs, for all offsets.
But I really don't care too much about 7Fs.

There are more questions to answer, but thats for now.

[jdobbs]

@gm901

I honestly think the way it's working is ok, and no players are objecting that I know of. But I want DVD-RB to be clean -- so I'll make a test version tonight and if you want to test it I'll send it to you.

@Sir Didymus

Never noticed that in the verifier... I'll modify so I select the VOBU that is earliest.

I always cringe when verifier results are posted. Most people don't realize that even well made studio originals don't pass every test and the uninformed can read a lot more into it than they should.

Interesting that it found some audio packets that arrived later than their decoding time... as long as it isn't too late to decode before its presentation time it should work ok. The reason I say it is interesting is that the audio stream is read from the original and integrated using the same (only adjusted relatively as a group when needed) SCR/DTS/PTS as was on the master disc. It isn't modified in any way.

[gm901]

But I want DVD-RB to be clean
That's our common objective.
Since I’ve decided that RB is the premium SW for my expectations, having tried almost everything else, at least anything important, that’s why I try to help as to make it more solid than a rock.
My only drive is nothing but:
I don’t want ever again, Never, to feel so embarrassed, as the night I’ve made arrangements as to enjoy the 3 Days of The Condor, and the damn machine didn’t like the DVD.
NEVER.
I'm not a programmer, don't know DVD/mpeg/whatever stucture, never seen before C++...
But I'll do whatever it takes for that.It's personal now.

You see, it’s your project, but it’s my video, our entertainment.

Of course I’ll test anything you suggest.

Keep in mind, that all my tests for SRIs are just Book consistency, theoretical. Never noticed anything in FF or Back (which I rarely use).
All I’ve noticed is the freezes of the 1st subject. And that was the 4 nxt/prv VOBU pointers. And you fixed it. The SCR, you'll fix it too.
For some reason though, there are enough complaints for stuttering etc
Don’t now what they mean. I do know what I see and try to locate it.

Thanks again for your efforts and open mind.

[gm901]

SRI 19x2 POINTERSOriginally posted by jdobbs
Another: When you say the values in the SRI table are wrong, what is the criteria? Are the values correctly pointing to NAVPACKS? Are you saying they aren't pointing to what you believe to be the right NAVPACKS, or are they pointing to a sector that is other than a NAVPACK?
Could't check it manually, so

VOBU_SRI POINTERS
Next/Prv Vobu (2x2) Diffs
Next = 0
Prv = 0

Next/Prv Seconds (19x2) Diffs
Next/Prv 7FFFFFFF : 3929 /3907
Next/Prv 3FFFFFFF : 94 /151
Next/Prv Other : 85216 /156780



Diffs categories:
to VOBUs rel distances:
Next Distance +1=84283, +2=0, +3=0 -1=670, -2=0, -3=0 >+-3=0
Prv Distance +1=6, +2=0, +3=0 -1=148825, -2=121, -3=0 >+-3=0
to bit30, bit31, bit30 & 31, FFs:
Next: More/Missing 7FFFFFFF= 0/3929, 3FFFFFFF= 76/18
Next: More/Missing 40000000= 263/0, 80000000= 0/0, C0000000= 0/0
Prv: More/Missing 7FFFFFFF= 0/3907, 3FFFFFFF= 0/151
Prv: More/Missing 40000000= 7828/0, 80000000= 0/0, C0000000= 0/0


Analyzed Total=250077, Next=89239, Prv=160838, foundVOBU= 241996, calcVOBU= 241996
Pointers: Not_to_Navpack= 0, Out_of_Cell= 0, Not Found(?)= 0

Same structure for other movies I've checked.