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

[gm901]

Trying to figure out why some standalone players may not play a DVD-RB movie (freezes etc) I found out the following.

Original Movie (in fact Main Movie from Shrink)
Number of Video Packs=2267323
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=7243
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=82 <------

Transcoded of transcoded Movie (DVD-RB 0.72 "No Compression (100% Video)" – to correct any errors)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26 <------ (now corrected)


Checking (viewing) the (82-26=)56 Nav Packs with Zero Cell Elapsed Time (BCD 0x40), there were the freezes.

Is that eventually the problem?

Any comments please…


---------------------------------
Edited according to next 2 posts.

[jdobbs]

I, for one, am confused. How can you have 26 cells of which 82 have a zero elapsed time?

[gm901]

Sorry, copy-paste error...

Instead of
Number of Cells with Zero Cell Elapsed Time (BCD 0x40)
you should read
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)

[jdobbs]

Let me make sure I understand...

In the last example you took the output from DVD-RB and then ran it through DVD-RB using "No Compression" and the result was different?

Does the transcoded transcode work correctly (after two times through DVD-RB)?

[gm901]

Yes. Because No Compression (100% Video) “is also a way in which previously created discs can be demuxed and remuxed to fix possible errors “ as you say.
As you see there is no Phase II, just demuxing and remuxing (and correcting…)
Now the movie is (navigation) error free.

Transcoding...
-----------------
[19:32:13] Phase I, PREPARATION started.
- VTS_01: 2.282.646 sectors.
-- Scanning and writing .D2V file
-- Video demultiplexing...
-- Processed 168.381 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 98,4%
- Overall Bitrate : 4.973Kbs
- Space for Video : 4.088.962KB
- HIGH/LOW/AVERAGE Cell Bitrates: 5.778/3.875/4.973 Kbs
[19:38:54] Phase I, PREPARATION completed in 6 minutes.
[19:38:54] Phase II ENCODING started
[19:38:54] Phase II ENCODING completed in 0 minutes.
[19:38:54] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Rebuilding segment 3 VOBID: 1 CELLID: 4
- Rebuilding segment 4 VOBID: 1 CELLID: 5
- Rebuilding segment 5 VOBID: 1 CELLID: 6
- Rebuilding segment 6 VOBID: 1 CELLID: 7
- Rebuilding segment 7 VOBID: 1 CELLID: 8
- Rebuilding segment 8 VOBID: 1 CELLID: 9
- Rebuilding segment 9 VOBID: 1 CELLID: 10
- Rebuilding segment 10 VOBID: 1 CELLID: 11
- Rebuilding segment 11 VOBID: 1 CELLID: 12
- Rebuilding segment 12 VOBID: 1 CELLID: 13
- Rebuilding segment 13 VOBID: 1 CELLID: 14
- Updating NAVPACKS for VOBID_01
- Rebuilding segment 14 VOBID: 2 CELLID: 1
- Rebuilding segment 15 VOBID: 2 CELLID: 2
- Rebuilding segment 16 VOBID: 2 CELLID: 3
- Rebuilding segment 17 VOBID: 2 CELLID: 4
- Rebuilding segment 18 VOBID: 2 CELLID: 5
- Rebuilding segment 19 VOBID: 2 CELLID: 6
- Rebuilding segment 20 VOBID: 2 CELLID: 7
- Rebuilding segment 21 VOBID: 2 CELLID: 8
- Rebuilding segment 22 VOBID: 2 CELLID: 9
- Rebuilding segment 23 VOBID: 2 CELLID: 10
- Rebuilding segment 24 VOBID: 2 CELLID: 11
- Updating NAVPACKS for VOBID_02
- Rebuilding segment 25 VOBID: 3 CELLID: 1
- Updating NAVPACKS for VOBID_03
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
Correcting VTS Sectors...
[19:49:27] Phase III, REBUILD completed in 11 minutes.

Done.

[jptheripper]

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)

what does that mean.. its the same with .69 and .72?

interesting that running through twice fixes, too bad there isnt an easy way to see what changed.

[gm901]

0.69, 0.70 and 0.72 produced exactly the same encoding Phase I results (binary compared all files in D2VAVS).
And the “No Compression (100% Video)” demuxing produced the same Phase I results, but obviously the remuxing is different.

That’s the point.
The differences between the two remuxing procedures.

And, I know, there isn’t an easy way. I used Vobedit, copy to excel to ascii compare …
Until I modified a free program + source I’ve found so as to auto check all nav packs.

[jdobbs]

Yes. Because No Compression (100% Video) “is also a way in which previously created discs can be demuxed and remuxed to fix possible errors “ as you say. That's what throws me off. In the quote you give I'm talking about remuxing from a source that was created by a different DVD-RB version.

Both methods (No Compression or Reencoding) use the exact same remuxing routines. The only difference is the generation of the .M2V files (one demuxes them from the source, the other uses AVS files for decoding and reencoding).

So the question is (assuming what you are saying is accurate): What the hell could be changing by running it through the exact same algorithm twice? That is, of course, for me to figure out...

[robot1]

I think he run the first time DVD-RB 0.69.
The second time (with no compression) DVD-RB 0.72
With the same .m2v, the results are different (and without stutters) because DVD-RB 0.72 have a better muxing engine.

[jdobbs]

Now that could make sense.

Just for the record... I would never recommend anyone stay with any of the older versions. This is a beta, and every new release can make a lot of difference.

[gm901]

I’ve transcoded the movie 3 times using 0.69, 0.70 and 0.72 expecting that each new version might have solved the problem.
Each time the results were the same.
The “No Compression” was applied to BOTH 0.69 and 0.72 results.
Specifically, the 0.70’s “No Compression” to 0.69’s output, and the 0.72’s to 0.72’s
The resulting movie in both situations was OK and identical.
Therefore it’s not the 0.69 engine.
The 0.72 created 56 more zero navpacks and the same 0.72 corrected them.

...one demuxes them from the source, the other uses AVS files for decoding and reencoding.

So there at least one difference.

And the most important point is, I think, why these zero navpacks were created in the first place.

[jdobbs]

@gm901

Please check your PM.

[jptheripper]

i just want to complement on gm901 and jdobbs for awesome troubleshooting.

good luck and thanx for sticking thru it.

I wonder if its a error in the cce generated m2v file that is fixed while demuxing (as opposed to something that rebuilder is specifically doing). That is, rebuilder on intial run assumes its correct and uses it, but the demux fixes it. Not that i have any idea what it might be.

Regardless, for an extra 20 mins or so i am tempted to suggest a pseudo 4 click mode with fourth click the "no compression" as a temporary patch until the problem is fixed for anyone experiencing the studder.

again thanx and good luck

[jdobbs]

Hmmm... since I've never actually seen this problem on any of several players or experienced it myself -- I have to believe recommending using this as a fix for what I'm not even sure is really a problem is a little premature.

As was found in several other instances of problems -- sometimes it comes down to something a lot more simple (like using the right decoder).

[gm901]

“The specific movie was OK when I’ve tested it to my pc dvd drives (Sony and LG) and to a standalone Pioneer. However, when I’ve tried to watch it to another standalone LG (7600 or 8600 ?) there were freezes, skippings and stops. Lots of them.
The only way to reproduce the error back home is to play it Fast Forward (32X) to PowerDVD 6 (Show Information ON, Bitrate drops from 20Mbps to 0, timer and image freezes and after a while skips some minutes and so on).”

For details see:
http://forum.doom9.org/showthread.php?s=&threadid=89467

An idea would be, while processing, to count zero time navpacks against number of cells, and issue a warning at log whenever there are differences. This is what I’m doing now after reencoding each movie using a little program, just to be sure.
As a matter of fact, I’m checking both original + DVD-RB’s output packs, to find any differences.
BTW, why are there so many more (7243 - > 14084, almost double) nav packs at DVD-RB’s output comparing to original?

[gm901]

YES YES YES


Both methods (No Compression or Reencoding) use the exact same remuxing routines. The only difference is the generation of the .M2V files (one demuxes them from the source, the other uses AVS files for decoding and reencoding).


Up to now, me the @#*!&%#$, I’ve compared all Phase I: Prepare outputs (D2VAVS files) of each DVD-RB version I’ve used (0.69 to 0.72). And they were identical.
But, the great @#*!&%#$^)!!$%, didn’t check the obvious.
The Phase I: Prepare output of normal encoding against the Phase I: Prepare output of “No Compression”. What have I found out ???
The Phase I: Prepare output of normal encoding produced 82 avs files (V01000000001001.AVS to V01008100003001.AVS)
while Phase I: Prepare output of “No Compression” produced 26 avs files (V01000000001001.AVS to V01002500003001.AVS)

These are the 56 more zero navpacks.

See the diffs for example of V01000000001001.AVS

V01000000001001.AVS of Phase I: Prepare output of normal encoding
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:01
#------------------
LoadPlugin("C:\Program Files\_MM\dgmpgdec1012a\DGDecode.dll")
mpeg2source("G:\_MOVIES_TEST\CONDOR\CONDOR_RB1_W_2004.02.10\D2VAVS\V01.D2V")
trim(0,2331)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())

V01000000001001.AVS of Phase I: Prepare output of “No Compression”
#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:01
#------------------
LoadPlugin("C:\Program Files\_MM\dgmpgdec1012a\DGDecode.dll")
mpeg2source("G:\_MOVIES_TEST\CONDOR\CONDOR_RB2_W_2004.02.10\D2VAVS\V01.D2V")
trim(0,9196)
ConvertToYUY2(interlaced=true)
AudioDub(BlankClip())

Sorry for not being enough accurate.
(Sometimes, I feel soooo angry at my stupidity….)

So the errors are not introduced by Phase III: Remuxing, but by Phase I: Demuxing.

Are we getting somewhere?
Is there any difference between normal Phase I and “No Compression” Phase I procedure ???

[gm901]

Back home, time for new experiments…

Extra info: In my previous post
0.72 Phase I: Prepare Mode 1 (CCE) was applied to Original (result 82 avs files)
0.72 Phase I: Prepare Mode 4 (100%) was applied to 0.72’s transcoded (result 26 avs files - OK)
But the input of each Phase was different.
Testing some more, I run
0.72 Phase I: Prepare Mode 4 (100%) to Original (result 82 avs files) !!!
0.72 Phase I: Prepare Mode 1 (CCE) to 0.72’s transcoded (result 26 avs files - OK) !!!

Therefore the Prepare Phase produced the same results according to the input.
So there should be no differences of preparing in mode 1 and 4.
Then the question is:

Why when the input is the original (Main Movie Shrinked I remind you – but checked and found navigational OK, both navpacks and viewing – 26 cells/zero time navpacks) the Phase I produces 82 avs, while when the input is the transcoded (with 82 zero time navpacks and freezing) it produces the correct 26 avs/zeros ???????

Now I’m completely lost…..

Please let me know what to check, what points exactly of the ifos, vobs the DVD-RB is analyzing as to create an avs file.
The ifos at both cases (orig. and transcoded) have the correct information concerning cells (26)

I’ve tested 0.75
Didn’t have the time to run a full reencoding, but it produced exactly the same results when Preparing, as 0.72 (82 avs to Orig. and 26 to transcoded). So I presume the final transcoded movie will also have 82 zero time navpacks = 56 freezes.

[jdobbs]

There are many, many good reasons why the number of AVS files (segments) don't match the number of cells. In fact you will find that it seldom does. For example, there are times when it is important that you have an I-Frame at a certain location, and the only way you can do that on some encoders (e.g. CCE Basic) is to start a segment there -- the cell count will be correct (based on the original) upon rebuild.

But you may be onto something here, and I'll follow up.

When you say "zero navpack" -- exactly what to you mean? From earlier e-mails -- you're counting the number of navpacks that have no value in the PCI_GI (BCD) at offset 0x45 in the navpack? The reason I ask is that zero is an illegal value in that field -- and you are saying the original had 26 of them. (two bits are used to show the frame_rate as part of the framecount portion and 00 is an illegal frame rate)

There are also lots of reasons for why there could be more navpacks -- it is reauthored. That does look like a large difference, though. I'll check on that too.

[gm901]

When you say "zero navpack"….

When offset 0x45, Zero Cell Elapsed Time as named by VobEdit, has value 0x40 as BCD (or 00.00.00,00 as time)

[gm901]

I don’t know if it may help you, but since I don’t know lots of things …
When checking, having no knowledge of vob structure, I’ve tried to locate within vob, the spots where the freezes happened. Then I copied VobEdit’s screen to Excel, and I ascii compared the specific data of the error movie vob against the mode 4 (100%) produced OK.
The first thing I noticed (and understood) was the offset 0x45.

But the total differences were:

Offset VobEdit’s description
-------- -----------------------------------------------------
(navigation pack where 1st freeze happens)
[0004] SCR (System clock reference)
[0045] Cell elapsed time (BCD)
[0407] system clock reference
[040f] VOBU end address - relative
[0413] VOBU first reference frame end block
[0417] VOBU second reference frame end block
[0423] Cell elapsed time (BCD)
[0599] offset to audio packet for AudioStrem1

and at the next navigation pack there are 2 more (plus the above):
[002d] this->lba
[040b] this->lba

Can’t evaluate if it means anything…
If you need the values, let me know.

[jdobbs]

Ok. That makes more sense. VOBEDIT only displays the interpreted value and removes the two bits showing frame rate -- it just puts a "/" followed by the framerate (e.g. "25" or "30")

It appears from what you are saying that (perhaps) each segment may be resetting that value to zero (which, of course, it shouldn't do -- as it only goes back to zero for each cell). Hmm... you may be onto something -- I'll check it out and give you some feedback.

This could also be the root of some previously reported display clock goofiness. (Don't you love the way I use strict scientific terms)

Good debugging, by the way, you're a helluva beta tester! I can only imagine how much work this must have been to find!

[jdobbs]

@gm901

Yep. You nailed it. I wasn't keeping the cell elapsed time current between segments. The fix will be in version 0.76.

Thanks, dude!

[gm901]

I thank you for your passion & dedication.
You must be in love with this project

[jptheripper]

You both rock!! congrats

[XMEN3]

Originally posted by gm901
Trying to figure out why some standalone players may not play a DVD-RB movie (freezes etc) I found out the following.

Original Movie (in fact Main Movie from Shrink)
Number of Video Packs=2267323
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=7243
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26

Transcoded Movie (DVD-RB 0.69 + 0.72, CCE)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=82 <------

Transcoded of transcoded Movie (DVD-RB 0.72 "No Compression (100% Video)" – to correct any errors)
Number of Video Packs=2077204
Number of Audio Packs=187090
Number of Subpicture Packs=4268
Number of Nav Packs=14084
Number of Cells=26
Number of Nav Packs with Zero Cell Elapsed Time (BCD 0x40)=26 <------ (now corrected)


Checking (viewing) the (82-26=)56 Nav Packs with Zero Cell Elapsed Time (BCD 0x40), there were the freezes.

Is that eventually the problem?

Any comments please…


---------------------------------
Edited according to next 2 posts.

HOW DO I FIND THESE VALUE?

[Trahald]

Originally posted by XMEN3
HOW DO I FIND THESE VALUE?
answer--
Originally posted by gm901
And, I know, there isn’t an easy way. I used Vobedit, copy to excel to ascii compare …
Until I modified a free program + source I’ve found so as to auto check all nav packs.
basically means a lot of work.

[XMEN3]

ok...so...demuxing e rebuilding the movie again with dvd-rb 0.76 will adjust everithing?:rolleyes:

[jdobbs]

Yes. Actually demuxing and rebuilding using the "No Compression" option of any version would work. Or just use v0.76 which corrects it from the start.

The odd thing is that this would have an effect on playback. I always thought the BCD fields in the NAVPACK were only used for display of playback times -- apparently some players use it for more.

[XMEN3]

again...the bug is present on dvd-rb from the beginning? first beta version?

[gm901]

Hi,

Tried the new 0.76. Done a full reencoding…
Well, didn’t had the chance to “real test” it (I visit the touchy LG every weekend) but the “simulated” results, using PowerDVD @32X, are the same !!!

There is another thing that bothers me, but I can’t be sure yet. Have to rescan all the dvds as to have a more concrete view.

But as a hint…
Up to know I’ve found 2 dvds that during Preparing, more .avs files were produced than the amount of cells (chapters). Both of them freeze the simulation (and the first, the famous Condor, has also failed real testing).
Condor produced 82 segments / 26 Cells. As you’ve explained, avs’ might be more than real cells. OK.
But the 2nd, Zatoichi - The Blind Swordsman, produced 367 seg / 13 Cells, and to make it more clear
Here are the Cells
Cell Frame
1 0
2 9256
3 29809
4 51142
5 77064
6 88738
7 104000
8 106743
9 111930
10 142883
11 150397
12 160888
13 165503

the segments that were created were according to the cells up to the 12th

Count LBA NavPack
1 0 1
2 138841 783
3 422964 2503
4 714252 4295
5 1068611 6459
6 1223595 7444
7 1447481 8729
8 1488782 8959
9 1565329 9393
10 1996645 11987
11 2104410 12619
12 2266295 13498
And the rest 355, were created from LBA 2266327 to 2277568, and from NavPack 13499 to13907. Almost every navigation pack was for a new segment !!!
That definitely shouldn’t have happened…

Usually, all my (PAL) movies are Main Movie Shrinked and stripped off other audios (but for the original) + subtitles (but for my language – which is not En).
Some of them are also 70% start and end (titles) compressed (by Shrink).
Condor was not, but Zatoichi was. But then I’ve checked other movies that were also title-compressed, and there were no extra segments or nav error.
Therefore I can’t say that the Shrink process added some bug. Just mentioning it…

And yet another observation.
Opening just the .vob, not as a dvd structure, but as a simple file (without the ifos…) the simulation runs OK !!!
Don’t know how a player works, but that’s seems strange. And I moved elsewhere the ifos/bups just to be sure.

Let’s go back to Condor.
As I’ve already posted, apart from [0045]_CellElapsedTime, there were other parts of navpacks that were different, but I cannot evaluate their significance. I’ll give you some numbers to judge for yourself.
First of all notation:
RB072.CCE_ERROR means full reencoding using v0.72, Mode 1 (CCE) and result…
RB072.CCE_x_RB072.100_OK means full reencoding using v0.72, Mode 1, CCE and the result as input to v0.72, Mode 4 (NoCompression).

So the specimens are

A&nbsp;&nbsp;&nbsp; RB072.CCE_ERROR
B&nbsp;&nbsp;&nbsp; RB072.CCE_x_RB072.100_OK
C&nbsp;&nbsp;&nbsp; RB075.CCE_ERROR
D&nbsp;&nbsp;&nbsp; RB075.CCE_x_RB075.100_OK
E&nbsp;&nbsp;&nbsp; RB076_CCE_ERROR
F&nbsp;&nbsp;&nbsp; RB076.CCE_x_RB076.100_OK
G&nbsp;&nbsp;&nbsp; RB075.CCE_x_RB076.100_OK
H&nbsp;&nbsp;&nbsp; RB076.CCE_x_RB076.100-REDONE _OK (<- !! just to be sure !!)

Scanning the Vobs…
Originl A B C D E F G H
Number of Video Packs 2267323 2077204 2077204 2077112 2077112 2077112 2077112 2077112 2077112
Number of Audio Packs 187090 187090 187090 187090 187090 187090 187090 187090 187090
Number of Subpicture Packs 4268 4268 4268 4268 4268 4268 4268 4268 4268
Number of Navigation Packs 7243 14084 14084 14084 14084 14084 14084 14084 14084
Number of Padding Packs 0 0 0 0 0 0 0 0 0
Number of Unknown Packs 0 0 0 0 0 0 0 0 0
Number of Cells 26 26 26 26 26 26 26 26 26
Number of 00:00:00,00 82 82 26 82 26 26 26 26 26

[offset]_Description A vs B C vs D E vs F B vs D D vs F B vs F A vs C C vs E A vs E F vs G F vs H
Amount_Of_Different_NavPacks 13214 10821 13214 8802 7579 5022 13170 13173 9445 7579 0
NavPack_Count 0 0 0 0 0 0 0 0 0 0 0
[002d]_LBA 5732 1465 5732 5039 24 5021 7579 6510 5021 24 0
[041f]_Vob-ID 0 0 0 0 0 0 0 0 0 0 0
[0422]_Cell-ID 0 0 0 0 0 0 0 0 0 0 0
[0045]_CellElapsedTime 8055 8055 0 0 0 0 0 8055 8055 0 0
[0039]_VobuStartPT 0 0 0 0 0 0 0 0 0 0 0
[003d_VobuEndPT 0 1 1 1 0 1 1 0 1 0 0
[0407]_SCR 13153 7624 13153 4432 4432 1 13169 13169 0 4432 0
[040f]_Vobu_End_Addr_Rel 1302 731 1302 52 48 4 1862 1859 4 48 0
[0413]_VOBU_1st_ref_FEB 3868 2067 3867 372 369 3 4256 4254 3 369 0
[0417]_VOBU_2nd_ref_FEB 4698 2816 4696 479 471 16 5127 5125 4 471 0
[041b]_VOBU_3rd_ref_FEB 4195 2555 4195 526 519 21 4408 4405 4 519 0
[0599]_Offset__audiop_AS1 11555 7581 11555 5499 5496 5 10983 10983 2 5496 0
[0423]_CellElapsedTime 8055 8055 0 0 0 0 0 8055 8055 0 0

Somewhere there are huge diffs, somewhere no
(tricky the table thing... so I attach a zipped xls)
Thanks

[XMEN3]

so version 0.76 is still buggy?
You wrote :
E RB076_CCE_ERROR

but in the table i can see 26 cells and 26 Number of 00:00:00,00

And why so many difference from:
Number of Video Packs 2267323 ---->2077112
Number of Navigation Packs 7243 ---->14084

I was thinking....
how these Nav Packs with Zero Cell Elapsed Time can cause freezes....
Anyway at the beginnin of each cells there's a 00 and this does not cause freeze...or not?

[jdobbs]

That definitely shouldn’t have happened… Not necessarily

I appreciate your testing -- but the question is: It's fixed. So what are we debugging? Am I missing something?

Let me give you an example on segments... if you had a narrative section that showed a lot of stills (say 300 of them) you would get 300 segments, because the still needs an I-Frame.

@xmen

There are supposed to be 26 00000 entries for 26 cells.

Video packs can never match -- they are determined by the encoder.

NAVPACKs depends upon authoring technique -- especially when related to stills.

As for how BCD values can cause freezing -- I don't know. Why a player would use BCD values to make determinations when there is a System Clock Reference only a few bytes away is beyond me.

[XMEN3]

Originally posted by jdobbs
.... So what are we debugging? Am I missing something?


I THINK gm901 found something...
bu the problem with him is (maybe) his Lg drive (not a very good dvd unit as I know)
freezing and skeeping is quite frequent using mastered dvds (mine skeeps even more with pressed dvd)

I think the problems are only media used and drive lens at this point....:confused: :confused:

[gm901]

Tried the new 0.76. Done a full reencoding… Well, didn’t had the chance to “real test” it (I visit the touchy LG every weekend) but the “simulated” results, using PowerDVD @32X, are the same !!!

By saying "are the same" I meant failed as previously.

Next weekend, I shall know the LG's attitude.

[gm901]

Couldn’t wait. The LG is home

No more debugging, just plain testing

A 0.67 to 0.75 [RB full encoding / Mode 1 - CCE]
B 0.76 [RB full encoding / Mode 1 - CCE]
C All versions [RB full encoding / Mode 1 - CCE] -> [RB Mode 4 - No Compression 100%]

Normal Play Fast Forward Backward
A B C A B C A B C
Standalones
Pioneer DV-360 ok ok ok ERR ERR ok ERR ERR ok
LG DV8600 ERR ERR ok ERR ERR ok ERR ERR ok

PC - Players
PowerDVD ok ok ok ERR ERR ok ERR ERR ok
Nero ShowTime ok ok ok ERR ERR ok ERR ERR ok
Notes:
All Players: ERR means freezing AND skipping.
PC Players: Forward speeds are 4x – 32X, Backward 1x – 32x. For some reason backward is more sensitive. Does that mean anything??
Nero escapes very fast the freezing when FF (you have to watch the timer), but when FB not only if freeze the image, but it freezes itself as a program!!

As you see the results are quite eloquent as far as 0.76 is concerned. I’m glad I’ve helped to locate an error that might cause trouble to others’ clock-timers, but unfortunately the fix doesn’t affect the malfunction I’m referring to.
by xmen
...bu the problem with him is (maybe) his Lg drive (not a very good dvd unit as I know)...
...I think the problems are only media used and drive lens at this point...@xmen
The LG has played flawlessly a large number of DV origin authored dvds + transcoded/reencoded movies. It plays perfectly as long as the source is perfect (which makes it a very good choice for a developer though).
I don’t know about other media, but I choose very carefully mine, and most of the time I double-check the burnt (Nero + DVDinfo or Binary Compare). It’s not the media.
Besides, errors that can be reproduced in 2 standalones and 2 sw players could not be specific case/configuration errors.


The vob value @offset [0045] (and [0423]) that is corrected @0.76,might be either informative, deriving from some other part of the Vob where lies the essential data, the data that the players really take into account, or it is indeed itself essential but must be in accordance with something else, for example the ifos (or another value within vob)
And what changes when the players run Fast Forward or Backward, all of them, even the Pioneer, what values are they “looking”. These values might be the problem.
And, don’t forget that Opening just the .vob, not as a dvd structure, but as a simple file (without the ifos…) the simulation runs OK !!!
…And I moved elsewhere the ifos/bups just to be sure.Every vob, doesn’t matter if it’s error, fixed, normal play, FF, FB, whichever speed, plays perfectly.
What a player “looks” when there is only a .vob file and what when there is a full dvd-structure. This is The Question

Maybe someone who has the knowledge to phrase the right question, could post something to a GNU SW (whichever)Player Forum/Net and get the right answer.

I’m not an expert, just a bit above complete ignorance, therefore this is as far as I can get. Maybe even what I’ve just said looks ludicrous to the eyes of a guru.

The only things I know for sure are the above test results.

I guess then, till further notice, I have to stick to the 1½ click mode (or 4 steps, or RBxRB)

Thanks for your patience.

[jdobbs]

I'll take a look at it. There's a table in the NAVPACK specifically used for FF/RW.

[gm901]

Think I’ve got it…

The navpacks with freezing problems have @ VOBU Search Information (VOBU_SRI)
Offset [04f1] to [0541] (next section) values [3fffffff]
while the RB X RB fixed has normal numbers.

Many others navpacks, have also [3fffffff] at offset [0545] to [0595] (previous section)

Is that it ???

[jdobbs]

You may be right, I'll have to see. Those values are legal -- but what I need to assure is that they weren't improperly placed based upon the segmenting. Are you having any trouble in the main movie, or is this just in extras? Extras would make more sense, as most movies would only break at cells in most situations (except where there was null packs inserted by DVD Decrypter because of copy protection - or partial cell references in the IFO).

[gm901]

I do only Main Movies, never extras.
I'll give you a pattern to understand more clear what I see

Offsets [04f1] ->>[0595]
next previous
NAVPACK_a001 F-----------------------
NAVPACK_a002 FF----------------------
NAVPACK_a003 FFF---------------------
NAVPACK_a004 FFFF--------------------
NAVPACK_a005 FFFFF-------------------
NAVPACK_a006 FFFFFF------------------
NAVPACK_a007 FFFFFFF-----------------
NAVPACK_a008 FFFFFFFF----------------
NAVPACK_a009 FFFFFFFFF---------------
NAVPACK_a010 FFFFFFFFFF--------------
NAVPACK_a011 FFFFFFFFFFF-------------
NAVPACK_a012 FFFFFFFFFFFF------------
NAVPACK_a013 ------------FFFFFFFFFFFF <----
NAVPACK_a014 -------------FFFFFFFFFFF
NAVPACK_a015 --------------FFFFFFFFFF
NAVPACK_a016 ---------------FFFFFFFFF
NAVPACK_a017 ----------------FFFFFFFF
NAVPACK_a018 -----------------FFFFFFF
NAVPACK_a019 ------------------FFFFFF
NAVPACK_a020 -------------------FFFFF
NAVPACK_a021 --------------------FFFF
NAVPACK_a022 ---------------------FFF
NAVPACK_a023 ----------------------FF
NAVPACK_a024 -----------------------F

Where
F = [3fffffff], and
- = any normal number


At NAVPACK_a013 is (or was, since v0.76 fixed it) the FALSE 00:00:00.00

it's like a new cell coming...

When you fixed the 00:00:00.00 did you figured out why it was produced? It seems that the same why produces pseudo cells patterns.

[EDIT] Added word FALSE for better sense

[gm901]

see attached xls for details

[jdobbs]

The pattern you are showing is correct for how the table is supposed to be constructed as long as it is within a VOBU. If you see that pattern in a segment that isn't a complete cell -- then I may have made a mistake in how I reconstruct the VOBU.

You don't need to spend any more time on it until I get a chance to look at it and tell you what I've found... I know what I'm looking for.

Again: thanks for the help.

[EDIT] Corrected terminology for clarity

[jdobbs]

Actually looking at the example you've given you say pack 13 has a zero elapsed time -- which implies it is a cell start -- so at least in that example the table is probably correctly constructed.

But I'm going to go through the routine anyway to be sure.

[jdobbs]

Ok, more confusion. The file you posted was done with v0.69... that doesn't help as that's not current and doesn't have the fix I put in 0.76. I'd need output from v0.76.

[jdobbs]

Originally posted by gm901
Think I’ve got it…

The navpacks with freezing problems have @ VOBU Search Information (VOBU_SRI)
Offset [04f1] to [0541] (next section) values [3fffffff]
while the RB X RB fixed has normal numbers.

Many others navpacks, have also [3fffffff] at offset [0545] to [0595] (previous section)

Is that it ??? I just looked at the code for inserting these and it appears to be correct as it is VOBU based and only updates on a per-VOBID basis. Can you elaborate on what you are saying here? The values are different if you run it through DVD-RB a second time with the no compression? Also -- please keep the discussion focused only on v0.76 ---> old information from obsolete versions has no value for me.

Thanks.

[Note]: The 3FFFFFFF is an indicator that there is no VOBU within the cell for the specified time unit in the appropriate direction.

[gm901]

Send you 2 xls.

1st the 076_CCE_ERROR and
2nd the RB_x_RB_OK
See them side by side, there are beautiful diffs (as for understanding what I'm talking about)

On each colored row there is a comment.

When I attach a file, I can't see it right away, but only after a few hours (!!). So I don't know if I sent it ...

Please let me know if you can dnld it

BTW, for all the extracts, a big thanks to the guy who not only has developed VobBlanker and PgcDemux (which I didn't had the chance to use as programs yet), but also has the courtesy to publish his source code (which I used as a basis to learn and to produce specific info results, since I didn't know a thing about IFOs/VOBs).
I didn't even knew that using VobEdit you have to check some checkboxes down there, in order to view more offsets. I found that out because trying to fix the error, in one of my tests, I used VobBlanker to cut a few LBAs and it produced a perfect result for that cell (fixing the subsequent navpacks). Then I looked at the code and I discovered that he putchared other offsets (VOBU SRI), significant but unknown to me.
And bear in mind that I'm not even a programmer.It's hell!!!

Hope that helps, If you need anything else let me know

[gm901]

And the 2nd RB_x_RB_OK

[jptheripper]

probably too little to late

but i came across this nav pack extractor program (from one of dvd remake's supporters)

might be useful

http://www.cdr-zone.com/forum/viewtopic.php?t=1025

[gm901]

probably too little to late
@jptheripper
Thank you, indeed, but now I got fully armed...

[jptheripper]

yeah i figured, thanx for all the great troubleshooting btw

[jdobbs]

I found what was causing this. I'll fix it and include it in v0.77.

@gm901

Again, great data collection and description of the problem.

[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.