Log in

View Full Version : Pack header SCR difference too little...


Pages : [1] 2

Sir Didymus
8th September 2004, 14:36
Using a couple of professional grade sw tools (i.e. Vobedit and Philips DVD Verifier) for the DVD analysis...

It seems that on many parts in the remuxed VOBs, the pack header SCR difference between a given navigation pack and the previous pack, (most time an audio pack) is too little...

For example, considering the pack I am looking at now with Vobedit, which is one of the initial nav pack in the VOB; in this pack the SCR difference respect to the previous audio pack is 45.126; in order to be compliant with the MPEG specifications, it must be at least 146.85 [27MHz ticks], given a mux rate of 10.08 Mbits/s.

In other terms, the difference of two succeeding Pack's SCRs should be at least:

(clk_freq * (pack length - 9 {=last byte of SCR})/byterate of previous pack) + (clk_freq * 9 {=last byte of SCR}/byterate of current pack))

Not sure it is relevant to know (hope it is ...),

Cheers,
SD

P.S. Also, please consider there is no STD_buffer_size initialization in the first packet of the video stream; in order to be MPEG compliant, the first packet of a video stream should specify the P-STD_buffer_size in the PES_packet extension part.

jdobbs
8th September 2004, 17:16
Actually that isn't between NAVPACKS, it is between all sectors. That value is based basically upon the spin-speed of the disc (along with buffering).

If you've found an instance where there is less than 146.85 it is definitely a problem (is that right -- I don't have the spec in front of me? Somewhere in the 146.2xx range sounds familiar, I'll check tonight when I get home). I've gone to great lengths to ensure each sector meets that standard. I will scan some DVDs tonight just to be sure -- but my guess is that a DVD not meeting this standard would fail completely.

Be very careful, however, when using VOBEDIT. It has a bug in which sometimes when you click on a sector (when going in a reverse direction) you don't get the sector you thought. I always click behind the sector I need and then click forward. You can get incorrect results.

You never know -- I may have fat-fingered an error into one of the previously good sections of code. If so I will certainly find it.

Sir Didymus
8th September 2004, 17:30
Afraid for my English,
sometimes I am not as clear as I would...

1) The troubles I found (there are many in a given VOB) are between two consecutive packs, one is audio, and the next is a navpack. It is easily found looking at the navpacks, and checking (if a previous audio pack exist) its SCR.

2) It's not Vobedit, believe me.

3) Good luck...

SD

jdobbs
8th September 2004, 17:42
I'll check tonight. I have a specific line of code when multiplexing the original audio into the stream that checks the difference to ensure it meets the minimum (which I just found, by the way -- it is 146.286). I'll check it tonight and see if it has been mangled.

You aren't talking about "greater than" 146.286 are you? Because that is very common.

Also -- has any package other than DVD-RB been used on the stream. I'm just being careful -- there are a lot of "butchering" third party software packages out there.

Also -- just to be sure, go to the NAVPACK, click 3 sectors back and then forward to the packet just prior to the NAVPACK. I can guarantee you that the error I mentioned in VOBEDIT is there. If you click on the NAVPACK and then click on the prior packet -- you will get bad data as often as you will get good... try it.

Sir Didymus
8th September 2004, 18:12
No, no, I am not talking about "greater than" 146.286. I know this is normal. I am talking about "less than" 50.000. It is an anomalous situation which is easy to verify, because it is FREQUENT.

Maybe some other kind people could check this, just for you in order not to rely on the test of a single person (I would appreciate if somebody else could perform a cross verify, in order to confirm the problem)... It is there...

No other sw used after DVD-RB. This is also fundamental. I know.

Thank you for the warnings about the results of Vobedit. To say the thruth I tried a lot, but I am now not actually able to get scrambled data from it. But I remind I got some bad values other times, so I share your position. In any case, from now on I will be much more careful in taking the reliability of Vobedit as ensured...

Nevertheless I am sure and I say again: before posting I double checked the presence of the trouble.

I verified and deeply checked the situation. Even without Vobedit.

Cheers
SD

jdobbs
8th September 2004, 20:06
Well, like the man says "With all this horsesh*t lying around, there must be a pony in here somewhere."

I'll run some tests. If it can be consistently repeated and I find a fix, I'll be indebted to you -- but also embarrassed because I should have caught something this obvious myself.

jdobbs
8th September 2004, 23:46
I found this. I couldn't get it to repeat as often as "Frequent" but it did appear at least once in each disc I checked. It only happened on an audio packet that followed the last video packet of each given cell -- and then only when the last video packet was flushed in a certain way (with a small amount of data).

I have a suspicion this might be at least a part of the cause of reported audio dropouts (that only happen on some players) or the Sony problems I thought had been fixed. It could certainly confuse the clock on an unforgiving system.

jdobbs
9th September 2004, 02:03
Fix is posted in v0.58

Trahald
9th September 2004, 02:43
Great investigative job, Sir Didymus

Sir Didymus
9th September 2004, 08:59
@Trahald
Thanks for the compliment, I am pleased to receive it from a master like you...

@Jdobbs
Hem... It seems that 0.58 is not fixing the problem...
The remux code of DVD-RB should be very complex, so maybe there is more than a single place where the problem is generated...

When I say "FREQUENT" I mean it is present in my tests a lot of time. If you want I can count how often it happens in a specific title (but it will take many hours to do this...). Maybe it is because I am in PAL land or it is depending on the specific title...

Cheers,
SD

jdobbs
9th September 2004, 10:45
Sorry, but I think there is something wrong in your analysis. I wrote a routine that goes through every single sector of the stream and compares the difference in SCR between every consecutive pack. I've run it against 8 DVD-RB authored discs now. The most I ever found was about 5, most had 1-2. Since the fix there have been none (except where they are supposed to be -- such as chapter breaks). I'll post a quick analysis program for you to run that outputs to a file tonight.

Sir Didymus
9th September 2004, 11:23
Thank you boss!

I will be happy of using your test program on my files...

By the way I am just now running another test (without using Vobedit at all). It will take at least a couple of hours to finish...

If you don't mind, as soon as I have more elements to provide to you I will post...

If no other people except than myself is observing the problem, I am necessairly forced to accept your doubts regarding my analysis...

Anyway, let me say I am very confident on my resources on the matter...


:)

Cheers,
SD

jdobbs
9th September 2004, 16:36
I'm looking forward to what you find. I'm especially interested in seeing what is different in what you are seeing and what I am seeing. The error I fixed only happened in about 1 out of 400,000 packets. I can't imagine how it could be different in PAL... that part of the muxing doesn't change between TV standards.

I did find one possibility as I was looking through the code in which a final audio packet might fall too close to the NAVPACK of the following VOBU -- but it would only occur if the new M2V files were larger than the originals...

Sir Didymus
9th September 2004, 18:02
Ok. Sorry for the late answer...
I was catched in some urgencies...

Following are some results of the tests carried out for counting the timing anomalie under discussion.

Let me just share some terms for the definition of the "timing anomalie".

We are discussing about the presence into the VOBs produced by DVD-RB of the following condition among two contiguous packs:

- first pack [audio pack] having an SCR of value "x", different from 0.000
- second pack [navigation pack] having an SCR of value "y", different from 0.000
- second pack is immediately following the first pack
- x < y
- y - x < 50.000 [it should be normally higher than 146.850, or some value like that,
and it could be much higher than that, in many normal situations]

Test.
- DVD-RB release 0.58
- CCE SP Trial Version 2.67.00.23
- EclCCE v1.81
- Avisynth 2.5.5
- Title: Open Range, PAL, R2, Italian version.
- Ripping: Using DvdDecrypter 3.5.1.0
- Preprocessing (unavoidable): Using VobBlanker 1.4.0.1, for cutting out unreferenced, protected material.
- Postprocessing: none.
- Source folder size 7.00 GB


1. After the decrypting and the preprocessing step, it was double checked that the source folder played well with two different sw players, for all of its contents.

2. Verified and double checked that in each one of the source VOBs VTS_01...VTS_07) of VTS01 the number of timing anomalies is 0.

3. Processed the title with DVD-RB. Little tuning of CCETargetSectors. 3 passes VBR. Stripped the second and the third of the audio tracks. The first is the Italian track [6 Ch, AC3] the second is the English track [6 Ch, AC3], the third is another English track [2 Ch, AC3, director comments]. DVD-RB processed just a single title set (VTS_01).

4. Output folder size 4.37GB, perfect. For the VTS01, five VOBs have been generated (VTS_01...VTS_05), so the size of the produced m2v is less than the original, for all of the encoded cells.

5. The play of the output folder with two different sw players was perfect.

6. Burned a DVD+RW and tested on my standalone. The result is perfect. I did never heard a single audio dropout.

7. Processed the output folder in order to check for the presence (and to count the number) of timing anomalies.

8. The tool adopted for the counting is an external application, different from Vobedit, for scanning the VOBS.

Here is the number of timing anomalies counted for each VOB (I used Vobedit just AFTER the counting, only as a double check for the verification of the results).

VTS01_1.VOB ---> 638
VTS01_2.VOB ---> 965 [total, i.e. including the ones of the previous VOB]
VTS01_3.VOB ---> 1349 [total]
VTS01_4.VOB ---> 1829 [total]
VTS01_5.VOB ---> 2027 [total, in the whole title set]

...if something wrong is happening in DVD-RB, it is not just at cell boundaries...

So, one of the following is true:

a) What I am looking at on my PC is just sh**t...
b) In some conditions (what are those ?) something inside DVD-RB is producing a lot of time anomalies...

As you may understand I am trying to do all my best in order to exclude a)...
even though I will be equally (maybe even more) happy if you will be able to exclude b)...

:)

All the best on my side,
SD

jdobbs
9th September 2004, 18:46
So you are saying this only looks as SCRs... it never looks at PTS or DTS values. I'm not sure how did you find these (Philips DVD Verifier?) and how you set the ruleset as to what defines the anomolies. Does the software already have a parameter to check for SCRs or did you have to put in a formula/location to look?

1. In my test I didn't just check cases where an audio pack was followed by a navigation pack -- I looked at every individual pack that existed in the DVD. As I read the pack I extracted the SCR and subtracted the previous SCR -- and at least on all the DVD-RB titles I created there was not a single value found less than 146.28x.

2. Why is preprocessing with VOBBlanker unavoidable? That is a difference, as I don't use VOBBlanker and don't actually even know what it does (I assume it blanks out cells).

Maybe you could pull out an offending cell and send it to me for analysis.

It would seem odd that you could have 2,000+ timing anomalies on a single disc and it would play alright...

robot1
9th September 2004, 19:10
Originally posted by jdobbs
2. Why is preprocessing with VOBBlanker unavoidable? That is a difference, as I don't use VOBBlanker and don't actually even know what it does (I assume it blanks out cells).Open Range (R2 italian verison) has a protection: there is a blank vob, never used in normal play, which result damaged. It's done on purpose to avoid full ripping of a dvd and a 1:1 copy on a DL. As it's unreferenced material, VOBBlanker simply ignore those unreferenced vobs, and (coupled to anydvd), copies all the other vobs intact. This form of preprocessing shouldn't affect the film's Vob, so should be safe.

jsoto
9th September 2004, 19:32
As it's unreferenced material, VOBBlanker simply ignore those unreferenced vobs, and (coupled to anydvd), copies all the other vobs intact. True, but inexact. VobBlanker can change the distribution of the cells inside the Vobs, because it follows the IFO PGC order when "coping" cells.
In any case I cannot see anything which can disturb DVD-RB when blanking PGCs, but the cutting function (I hope you are not using it) can affect the SCR sequence and probably can confuse DVD-RB... I believe cutting is only safe when used to delete the last part of a PGC (i.e credits).

jsoto.

Sir Didymus
9th September 2004, 19:41
@Jdobbs.

Sorry boss. It is now very late here in Italy...
Going sleeping, tomorrow, in the morning, I will answer to all of your very kind questions...

Just one option: you have already some material which is suspected to be affected by audio dropouts (if I remind, dvd maniac have sent to you some)...

Why don't you get a look to these cell(s) [at least for the moment] ?

@Robot1.

Yea!!!
That right what you say, and I specifyed it: I double cheched the source files, after the stripping of the unreferenced material, and they are totally free from the timing anomalie. I am just referring to this title since it is just the last one I ripped, just in order to eliminate the doubts, tomorrow I will do a completely "clean" DVD-RB session...

By the way, since you are participating to the thread, can I ask you to perform the very simple test I suggested to another gentleman in the Audio Droput Thread, in order to know if someone else is seeing this timing issue ? The only tool which is needed is Vobedit, and it is very simple to perform...

Grazie 1000 se puoi...

Ciao!!!
and Cheers!!!
SD

Sir Didymus
9th September 2004, 19:47
@Jsoto.

No, just a simple, plain processing with VobBlanker.

By the way compliments!!! Beautiful application!!!

By the way (second way...) if you could perform the same test I have just asked to robot1, I will be obliged to you...

Cheers,
SD

jdobbs
9th September 2004, 20:07
Originally posted by Sir Didymus
Just one option: you have already some material which is suspected to be affected by audio dropouts (if I remind, dvd maniac have sent to you some)... Well, yes, I have some that was supposed to have audio dropouts... but that doesn't necessarily imply it would have SCR problems. I'll test it (if I can find it).

Truthfully I hope this turns into something... at least if I can find a consistency I can fix it. I still can't understand why my DVDs aren't showing any of the problems, though, if it as prevalent as you've indicated.

robot1
9th September 2004, 21:18
Originally posted by Sir Didymus
By the way, since you are participating to the thread, can I ask you to perform the very simple test I suggested to another gentleman in the Audio Droput Thread, in order to know if someone else is seeing this timing issue ? The only tool which is needed is Vobedit, and it is very simple to perform...Rebuilding now a project. Tomorrow I'll test it with VobEdit, and report to the forum.

jdobbs
9th September 2004, 22:36
Ok. I'm at a loss. I just did 5 more discs that were created by DVD-RB and have yet to have see a single instance (beyond that fixed in 0.58). I'm going to check out the code and see if there is any way I may have missed something, but since there are over 2 million SCR entries in a DVD-5, and I've just scanned 300 million of them without an occurance I just don't know what to say. You'd think I get at least one example.

Can anyone suggest how this could be specific to PAL discs (I can't think of a reason at all)? All mine are NTSC.

jsoto
10th September 2004, 00:23
I highly recommend to wait the test results and see what happens without VobBlanker.

BTW, I found other potential problem of using VobBlanker previously to DVD-RB. If the DVD has an ILV cell, VobBlanker de-interleave them, so the DVD is now accepted by DVD-RB. But this de-interleave process is experimental, and SCR is not modified, so sure it is not correct.

I've a DVD-RB (v055b) backup of Alien (which is originally interleaved) and the backup shows "frecuent" timing anomalies..., but plays in my settop like a charm!!. Sorry, I do not have more DVD-RB backups, (I do not use it).

jsoto

PS: Doing other encoding, so I cannot do any other test for the moment.

EDIT: I'm testing the timing anomalies with this (http://www.posunplugged.com/jsoto/temp/scr.zip) It's a console app. Just execute scr.exe <vobfile>

Sir Didymus
10th September 2004, 07:22
Originally posted by jdobbs
...

Truthfully I hope this turns into something... at least if I can find a consistency I can fix it. I still can't understand why my DVDs aren't showing any of the problems, though, if it as prevalent as you've indicated.

Well, I hope too...

If I would discover to have put you into the situation of loosing a lot of time into an irrelevant issue, the only option I will have will be to find another sector of this galaxy where to move...

:)

SD

Sir Didymus
10th September 2004, 07:23
Originally posted by robot1
Rebuilding now a project. Tomorrow I'll test it with VobEdit, and report to the forum.

Thanks, Robot1!!!
SD

Sir Didymus
10th September 2004, 07:40
Originally posted by jsoto
I highly recommend to wait the test results and see what happens without VobBlanker.

BTW, I found other potential problem of using VobBlanker previously to DVD-RB. If the DVD has an ILV cell, VobBlanker de-interleave them, so the DVD is now accepted by DVD-RB. But this de-interleave process is experimental, and SCR is not modified, so sure it is not correct.

I've a DVD-RB (v055b) backup of Alien (which is originally interleaved) and the backup shows "frecuent" timing anomalies..., but plays in my settop like a charm!!. Sorry, I do not have more DVD-RB backups, (I do not use it).

jsoto

PS: Doing other encoding, so I cannot do any other test for the moment.

EDIT: I'm testing the timing anomalies with this (http://www.posunplugged.com/jsoto/scr.zip) It's a console app. Just execute scr.exe <vobfile>

Jsoto, BIG THANKS. I am obliged with you, and I don't know how I can thank you for your support.

1) First of all I will follow your suggestion of redoing other tests without using VobBlanker at all.

2) I do not think that the usage of your excellent application have any relationship with the timing anomalie.

3) Here you can find the output of your test program (just the first 30 lines); it is reporting more than 300 anomalies in VTS_01_1.VOB. Clearily it is reporting much less than the 638 I have find with the Philips DVD Verifier, due to the limit you put into the code of 50.000.

4) The results of your program match perfectly with what I can see using VobEdit.

Thanks again,
and muchas gracias.

------------------------------------------------------
ERROR 0001: lba=87 diff=46 scr=43200 oldscr=43154
ERROR 0002: lba=161 diff=30 scr=86400 oldscr=86370
ERROR 0003: lba=263 diff=35 scr=172800 oldscr=172765
ERROR 0004: lba=421 diff=44 scr=345600 oldscr=345556
ERROR 0005: lba=601 diff=32 scr=475200 oldscr=475168
ERROR 0006: lba=706 diff=46 scr=604800 oldscr=604754
ERROR 0007: lba=810 diff=35 scr=734400 oldscr=734365
ERROR 0008: lba=1037 diff=3 scr=820800 oldscr=820797
ERROR 0009: lba=2208 diff=30 scr=1209600 oldscr=1209570
ERROR 0010: lba=2706 diff=3 scr=1382400 oldscr=1382397
ERROR 0011: lba=2963 diff=44 scr=1468800 oldscr=1468756
ERROR 0012: lba=3350 diff=32 scr=1598400 oldscr=1598368
ERROR 0013: lba=3736 diff=46 scr=1728000 oldscr=1727954
ERROR 0014: lba=3861 diff=30 scr=1771200 oldscr=1771170
ERROR 0015: lba=4646 diff=7 scr=2030400 oldscr=2030393
ERROR 0016: lba=5050 diff=32 scr=2160000 oldscr=2159968
ERROR 0017: lba=5465 diff=46 scr=2289600 oldscr=2289554
ERROR 0018: lba=6187 diff=3 scr=2505600 oldscr=2505597
ERROR 0019: lba=7154 diff=32 scr=2908800 oldscr=2908768
ERROR 0020: lba=7450 diff=46 scr=3038400 oldscr=3038354
ERROR 0021: lba=7547 diff=30 scr=3081600 oldscr=3081570
ERROR 0022: lba=7755 diff=35 scr=3168000 oldscr=3167965
ERROR 0023: lba=7965 diff=3 scr=3254400 oldscr=3254397
ERROR 0024: lba=8186 diff=7 scr=3340800 oldscr=3340793
ERROR 0025: lba=8548 diff=32 scr=3470400 oldscr=3470368
ERROR 0026: lba=8916 diff=46 scr=3600000 oldscr=3599954
ERROR 0027: lba=9034 diff=30 scr=3643200 oldscr=3643170
ERROR 0028: lba=9506 diff=3 scr=3816000 oldscr=3815997
ERROR 0029: lba=15697 diff=35 scr=5788800 oldscr=5788765
ERROR 0030: lba=15951 diff=48 scr=5860800 oldscr=5860752
... skip the other 270 error lines ...
----------------------------------------------------------

Cheers,
SD

robot1
10th September 2004, 08:38
Using scr by jsoto (it's simpler then VobEdit...)
DVD: LOTR Two Towers, PAL R2 ITA
Full backup (no preprocessing)
CCE 2.50
One setting changed: gop15 (hope doesn't give problems...)
Result: 4.37GB (TargetSectors tweaked...)

scr.exe reports 285 anomalies in the first vob of the film.
here are the first 30:


ERROR 0001: lba=1296 diff=14 scr=1188000 oldscr=1187986
ERROR 0002: lba=1663 diff=32 scr=1620000 oldscr=1619968
ERROR 0003: lba=2915 diff=23 scr=3132000 oldscr=3131977
ERROR 0004: lba=3314 diff=42 scr=3564000 oldscr=3563958
ERROR 0005: lba=5670 diff=32 scr=5076000 oldscr=5075968
ERROR 0006: lba=8047 diff=5 scr=6156000 oldscr=6155995
ERROR 0007: lba=10142 diff=42 scr=7020000 oldscr=7019958
ERROR 0008: lba=13003 diff=14 scr=8100000 oldscr=8099986
ERROR 0009: lba=16645 diff=14 scr=9482400 oldscr=9482386
ERROR 0010: lba=18126 diff=42 scr=10015200 oldscr=10015158
ERROR 0011: lba=18772 diff=23 scr=10274400 oldscr=10274377
ERROR 0012: lba=19662 diff=42 scr=10706400 oldscr=10706358
ERROR 0013: lba=22326 diff=42 scr=11858400 oldscr=11858358
ERROR 0014: lba=25448 diff=32 scr=13370400 oldscr=13370368
ERROR 0015: lba=27303 diff=5 scr=14450400 oldscr=14450395
ERROR 0016: lba=30569 diff=14 scr=15703200 oldscr=15703186
ERROR 0017: lba=32254 diff=32 scr=16135200 oldscr=16135168
ERROR 0018: lba=33888 diff=14 scr=16624800 oldscr=16624786
ERROR 0019: lba=35658 diff=23 scr=17186400 oldscr=17186377
ERROR 0020: lba=37201 diff=42 scr=17618400 oldscr=17618358
ERROR 0021: lba=40125 diff=14 scr=18468000 oldscr=18467986
ERROR 0022: lba=40520 diff=23 scr=18568800 oldscr=18568777
ERROR 0023: lba=41095 diff=42 scr=19000800 oldscr=19000758
ERROR 0024: lba=43592 diff=32 scr=20052000 oldscr=20051968
ERROR 0025: lba=45920 diff=5 scr=21132000 oldscr=21131995
ERROR 0026: lba=47066 diff=14 scr=21693600 oldscr=21693586
ERROR 0027: lba=48449 diff=32 scr=22125600 oldscr=22125568
ERROR 0028: lba=52423 diff=32 scr=23508000 oldscr=23507968
ERROR 0029: lba=54628 diff=5 scr=24588000 oldscr=24587995
ERROR 0030: lba=55331 diff=23 scr=25020000 oldscr=25019977

Now burning on RW to test with standalone, and redoing another encode with original settings (gop=12).

jsoto
10th September 2004, 08:42
Jsoto, BIG THANKS. I am obliged with you, and I don't know how I can thank you for your support You're welcome. I'm interested in support VobBlanker as previous phase of DVD-RB or dvdshrink because many users like it. So thanks to you too.

Currently I'm at work, but this morning my encoding had finished and I started a new rebuild (v058) of a PAL-DVD without VobBlanker processing phase. IŽll report the results this night. (Unfortunately I cannot test Alien, because it is interleaved.)

jsoto

Sir Didymus
10th September 2004, 09:09
@Jdobbs
Hi, I am back testing...
Sorry for the late (and long) reply...

-----------------------------------------------------------------------------------
Quote:
a. So you are saying this only looks as SCRs... it never looks at PTS or DTS values.
b. I'm not sure how did you find these (Philips DVD Verifier?)
and how you set the ruleset as to what defines the anomolies.
c. Does the software already have a parameter to check for SCRs
or did you have to put in a formula/location to look?
-----------------------------------------------------------------------------------

a. No. I am just saying that the anomalie under discussion is concerning improper SCR values.
b. Yes. A colleague of mine have a friend whose brother have available the Philips DVD Verifyer...
So, since I did some favours to this colleague... sometimes I can freely use the Verifyer... :cool:
The rulesets of the Verifyer just define what errors it should display and what should be masked.
An MPEG error is an error because there is a standard. If the SCR difference among two
contiguous packs is less than 146.xxx, this is an error because the anomalie is not compliant
with the MPEG specifications. With the rules you can just decide not to show the error, if you want.
c. No. The MPEG and DVD standards rules are embedded in the Verifier and it is not possible to change
anything on definition of the compliancy rules.

-----------------------------------------------------------------------------------
Quote:
1. In my test I didn't just check cases where an audio pack was
followed by a navigation pack -- I looked at every individual
pack that existed in the DVD. As I read the pack I extracted
the SCR and subtracted the previous SCR -- and at least on all
the DVD-RB titles I created there was not a single value found
less than 146.28x.
-----------------------------------------------------------------------------------

What can I say ?
I am sure that in your test disks the anomalie is not present; it seems
that, if it happens, it is very frequent and easy to see; if it does
not happen there is nothing to do with it... I think I should try to
give more elements to you for understanding what are the overall
conditions that are generating it, but I do not know what to do, other
than redoing from the beginning my tests, in a very clean and descriptive way...
And without using any other tools except DVD-RB for rebuilding the disk...

Nevertheless, please consider that even if the timing anomalie is
present, the disk play perfectly both on sw players and on my standalone...


-----------------------------------------------------------------------------------
Quote:
2. Why is preprocessing with VOBBlanker unavoidable? That is a difference,
as I don't use VOBBlanker and don't actually even know what it does
(I assume it blanks out cells).
-----------------------------------------------------------------------------------

Kindly answered by Robot1.
On my next test disk "ALI", I will not use the excellent application of Jsoto.

-----------------------------------------------------------------------------------
Quote:
Maybe you could pull out an offending cell and send it to me for analysis.
-----------------------------------------------------------------------------------

I will be happy of sending one to you, but please consider I have at the moment not
available to me an ftp server where to place it, and sending these huge files via e-mail
should be troublesome (I think I have some size limitation in the attachments to cope with...)

-----------------------------------------------------------------------------------
Quote:
It would seem odd that you could have 2,000+ timing anomalies on a single
disc and it would play alright...
-----------------------------------------------------------------------------------

Agreed.
Nevertheless it happen.
More than 2000 timing anomalies and the disk play like a charm...

Sir Didymus
10th September 2004, 09:13
Originally posted by robot1
Using scr by jsoto (it's simpler then VobEdit...)
DVD: LOTR Two Towers, PAL R2 ITA
Full backup (no preprocessing)
CCE 2.50
One setting changed: gop15 (hope doesn't give problems...)
Result: 4.37GB (TargetSectors tweaked...)

scr.exe reports 285 anomalies in the first vob of the film.

... skip ...

Now burning on RW to test with standalone, and redoing another encode with original settings (gop=12).

Thanks a lot Robot1, I have a debt with you, since you are seeing is what I am seeing, so I am now a little bit more convinced that I am not chasing some shadows...

I guess that the disk will play flawless from the beginning to the end...

All the best,
SD

Sir Didymus
10th September 2004, 09:27
Originally posted by jsoto
You're welcome. I'm interested in support VobBlanker as previous phase of DVD-RB or dvdshrink because many users like it. So thanks to you too.

Currently I'm at work, but this morning my encoding had finished and I started a new rebuild (v058) of a PAL-DVD without VobBlanker processing phase. IŽll report the results this night. (Unfortunately I cannot test Alien, because it is interleaved.)

jsoto

Yeah, you may say by sure that many users like your application. I am among them.
It is a little bit OT to say this here, but I really like it, waiting daily for its improvements. I think that when you will include the support of the menu processing, it will be almost a perfect tool (complementary, but in my personal opinion even preferrable to others) for the general preprocessing and removal of unreferenced materials from DVDs.

By the way, many thanks again for your little BIG tool. Very good and appreciated also the inclusion of the source code in order to see what it does "inside".

Cheers,
SD

robot1
10th September 2004, 09:49
Originally posted by Sir Didymus
I guess that the disk will play flawless from the beginning to the end...
Just played 20 minutes, without problems.

robot1
10th September 2004, 14:27
Second test with scr.exe by jsoto.
Same DVD (LOTR Two Towers, PAL R2 ITA).
Full backup in "one click mode", no preprocessing.

scr.exe reports 220 anomalies in the first vob of the film.

If scr.exe works properly, there is a problem (not showed by the standalone, a Pioneer DV-360 unit).

Hope this helps.

jdobbs
10th September 2004, 15:10
@Sir Didymus

Check your PM.

BTW, thanks for all the hard work. There is obviously something different between the output you are getting with DVD-RB and what I am getting. All I can imagine is some difference between PAL and NTSC (although I'm baffled as to what it could be right now). If I get an example of the offending output, I'm sure I can find out where the bug is.

Sir Didymus
10th September 2004, 15:44
@Jdobbs

One user in the thread on Audio Dropout [gizzin] is an NTSC user, and it seems he found the anomalie in one of its VOB...

I will follow your kind instruction in order to send to you one of the offending cells.

I suppose you prefere one with a lot of anomalies [test of yesterday] right ?
If you prefere one with very few anomalies [test attached in the following], tell me, please.

It will take some time indeed, not before tomorrow evening in the best case, since you know,
my wife has allocated the whole day of tomorrow for a trip to see the "100 lakes natural resort",
a beautiful place in the small mountains [~2000 meters] between Emilia and Tuscany...


Ok. Let me post the results of my second full test.

- DVD-RB release 0.58
- CCE SP Trial Version 2.67.00.23
- EclCCE v1.81
- Avisynth 2.5.5
- Title: ALI, PAL, R2, Italian version.
- Ripping: Using DvdDecrypter 3.5.1.0
- Preprocessing: None.
- Postprocessing: None.
- Source folder size 7.43 GB


1. Verified and checked using the scr.exe application of Jsoto that in each one of the source VOBs [VTS_01...VTS_08] of VTS01 the number of timing anomalies is 0.

2. Processed the title with DVD-RB. CCETargetSectors=2263000 [grrr. forgot to delete this tuning from Rebuilder.ini...]. Removed second and the third of the audio tracks. The first is the Italian track [6 Ch, AC3] the second is the English track [6 Ch, AC3], the third is another Italian track [6 Ch, DTS]. DVD-RB processed just a single title set (VTS_01).

3. Hopefully the output folder size 4.37GB, perfect. For the VTS01, four VOBs have been generated (VTS_01...VTS_04).

4. The play of the output folder with two different sw players was perfect.

5. Did not burn a disk to test on my standalone.

6. Processed the output folder in order to check for the presence (and to count the number) of timing anomalies, both using the scr.exe application of Jsoto and the DVD-Video Verifier.

Here is the number of timing anomalies counted for each VOB by scr.


VTS01_1.VOB ---> 6
-------------------------------------------------------------------
ERROR 0001: lba=228749 diff=39 scr=86511600 oldscr=86511561
ERROR 0002: lba=292125 diff=39 scr=109407600 oldscr=109407561
ERROR 0003: lba=449264 diff=32 scr=167104800 oldscr=167104768
ERROR 0004: lba=488213 diff=39 scr=181335600 oldscr=181335561
ERROR 0005: lba=491708 diff=32 scr=182743200 oldscr=182743168
ERROR 0006: lba=507067 diff=7 scr=189536400 oldscr=189536393
-------------------------------------------------------------------

VTS01_2.VOB ---> 6
-------------------------------------------------------------------
ERROR 0001: lba=147630 diff=32 scr=248493600 oldscr=248493568
ERROR 0002: lba=176919 diff=39 scr=259138800 oldscr=259138761
ERROR 0003: lba=417714 diff=5 scr=62377200 oldscr=62377195
ERROR 0004: lba=418749 diff=5 scr=62766000 oldscr=62765995
ERROR 0005: lba=471154 diff=5 scr=85316400 oldscr=85316395
ERROR 0006: lba=489945 diff=5 scr=94345200 oldscr=94345195
-------------------------------------------------------------------

VTS01_3.VOB ---> 1
-------------------------------------------------------------------
ERROR 0001: lba=134779 diff=5 scr=172105200 oldscr=172105195
-------------------------------------------------------------------

VTS01_4.VOB ---> 0
-------------------------------------------------------------------
-------------------------------------------------------------------

Total of timing anomalies reported by scr in the title [referring to SCR differences less than 50.000] -----> 13

Total of timing anomalies reported by DVD-Video Verifyer [based on SCR differences less than 146.xxx] -----> 16

The surprising thing [at least for me] is the very low number of anomalies detected this time, respect to the very high number of the previous test... It should be dependent on the specific DVD...

Hope the test is of some help to find the cause of this issue...
If useful, I can post or send the Rebuilder and the DVD-Video Verifier session logs.

All the best, and enjoy your w/e !!!
SD

Trahald
10th September 2004, 16:37
Im NTSC and i tested a family guy disk and got 66 anomalies (using scr.exe) with 0.57a and exact same amount with a rebuild done with 0.58. verified it with vobedit. this was an unpreprocessed original (scr.exe found no anomalies on the original)

jdobbs
10th September 2004, 17:53
I've done 15 discs now. Not one found.

I'll download SCR.EXE and see if it gets the same results.

jsoto
10th September 2004, 20:22
Report of my test:
VTS01 (main movie). SCR.exe reported errors (diff less than 50)
3 errors in VTS_01_1.VOB
0 errors in VTS_01_2.VOB
204 errors in VTS_01_3.VOB
0 errors in VTS_01_4.VOB

There are also errors in the extra's VTSs.

I've updated scr.exe, just to print the packet type. Seems the wrong value of scr is always in a NAV pack (the first printed). May be this helps to find the problem.


F:\DVDRB\VIDEO_TS>scr VTS_01_3.VOB
ERROR 0001: lba=188258 diff=6 scr=465030406 oldscr=465030400; NAV SUB
ERROR 0002: lba=397357 diff=26 scr=43200 oldscr=43174; NAV AUD
ERROR 0003: lba=397659 diff=26 scr=172800 oldscr=172774; NAV AUD
ERROR 0004: lba=397979 diff=26 scr=302400 oldscr=302374; NAV AUD
ERROR 0005: lba=398285 diff=26 scr=432000 oldscr=431974; NAV AUD
ERROR 0006: lba=398488 diff=26 scr=518400 oldscr=518374; NAV AUD
ERROR 0007: lba=398798 diff=8 scr=648000 oldscr=647992; NAV AUD
ERROR 0008: lba=398917 diff=26 scr=691200 oldscr=691174; NAV AUD
ERROR 0009: lba=399240 diff=26 scr=820800 oldscr=820774; NAV AUD
ERROR 0010: lba=399553 diff=26 scr=950400 oldscr=950374; NAV AUD
ERROR 0011: lba=399857 diff=21 scr=1080000 oldscr=1079979; NAV AUD
ERROR 0012: lba=400163 diff=26 scr=1209600 oldscr=1209574; NAV AUD
ERROR 0013: lba=400467 diff=26 scr=1339200 oldscr=1339174; NAV AUD
ERROR 0014: lba=400786 diff=11 scr=1468800 oldscr=1468789; NAV AUD
ERROR 0015: lba=401096 diff=26 scr=1598400 oldscr=1598374; NAV AUD

jsoto

lamster
10th September 2004, 20:53
Results reported by SCR for Master Of Disguise, NTSC, QuENC 0.54

Rebuilder: 0.58 0.57b 0.57a 0.57a(*) 0.57
==== ===== ===== ===== =====
VTS_01_1.VOB 34 87 71 47 71
VTS_01_2.VOB 158 134 117 166 117
VTS_01_3.VOB 50 110 78 80 78
VTS_02_1.VOB 0 0 0 0 0
VTS_03_1.VOB 0 0 0 0 0
VTS_04_1.VOB 13 13 13 13 13
VTS_05_1.VOB 0 0 0 0 0
VTS_06_1.VOB 6 6 6 6 6
VTS_07_1.VOB 4 4 4 4 4
VTS_08_1.VOB 8 8 8 8 8
VTS_09_1.VOB 0 0 0 0 0
VTS_10_1.VOB 7 7 7 7 7
VTS_11_1.VOB 0 0 0 0 0
VTS_12_1.VOB 1 1 1 1 1
VTS_13_1.VOB 0 0 0 0 0

* The second 0.57a column was done with no languages being stripped; all the others had French stripped (DVD-Rebuilder options set to strip everything except English and Spanish).

A spot-check of other DVD's (all NTSC, U.S. releases) rebuilt using DVD-Rebuilder showed numerous SCR-reported errors on:

Annie
Lord Of The Rings - The Fellowship of the Ring
Lord Of The Rings - The Two Towers
Mary Poppins
SpiderMan
Spirited Away
Sponge Bob SquarePants - Nautical Nonsense
Springtime With Roo
The Matrix (16x9 letterbox N. America)
The One
Winnie The Pooh


(This is everything I've checked; I can check more when I get home tonight.)

jdobbs
11th September 2004, 00:00
Okay. The point is made. Give me some time to find out what is wrong.

lamster
11th September 2004, 00:05
Originally posted by jdobbs
Okay. The point is made. Give me some time to find out what is wrong.

My reason for posting all the titles was to try and find something we both have, so you could see the problem I'm seeing (since you said you didn't see it in the 15 titles you checked). I hope you didn't feel I was trying to bash the point home... :)

jdobbs
11th September 2004, 00:30
Nope. Nothing negative intended... actually I appreciate the input. I just ran scr.exe against my files and it flagged problems too. Now I have to find out why my scanning software didn't find it -- and since it uses the same library as DVD-RB, that may possibly lead me to why I'm getting the problem in the first place.

Sir Didymus
11th September 2004, 07:23
@Jdobbs

Just uploaded to your server a couple of cells and some additional info on the issue...

Hope the huge amount of time you are spending on the matter, and in general on your big and greatily appreciated coding work on DVD-RB will be compensated in some way in the future...

All the best on my side,
SD

P.S. Looking towards the mountains, this morning the horizon is very cloudy...
The only reason that could lead my wife to postpone a nice trip is the "VERY VERY VERY HIGH RISK" to take some rain on the top of her head...
With this little "manouver" I had the some more little time to invest for sending to you the data...
Anyway, the mountains are still there, so we can do the trip another time...
The only big drawback I see now for myself is the terrif perspective (or better the certainty) a very owful shopping day in downtown...

jdobbs
11th September 2004, 12:18
Ok. I just fixed this one and will post it in v0.59. The error was incredibly simple and I don't know how I could have missed it.

My library was working fine -- but my SCR scanning software had a stupid mistake in it.

In debugging this I found another smaller problem with timing of sound -- I'm working on that and will post when I get it fixed.

Thanks all -- especially Sir Didymus!

Redbacks
11th September 2004, 14:46
I'm licking my lips hear jdobbs.. I hope this is the little fix I need for all my problems to go away :)

Ta.....

jdobbs
11th September 2004, 22:24
@Sir Didymus,

Many thanks for the excellent detective work -- and the files you provided... They are incredibly useful!!! ;)

You'll see #1430 go away later today.

jdobbs

Sir Didymus
11th September 2004, 22:58
All my compliments to you, boss.

My English is not sufficient to express how happy I am from the understanding we have been helpful. I mean the fantastic guys who gave contributions, on this specific subject, like robot1, jsoto, gizzin, master Trahald, lamster and myself for the testing of you fantastic application... Hope didn't forget anybody...

Let me just say BIG COMPLIMENTS JDOBBS

Cheers,
SD

Trahald
12th September 2004, 06:24
Tested same disk.. 0 errors with scr.exe with .59

robot1
12th September 2004, 07:00
@ jdobbs
GREAT JOB!
Tested with scr.exe, 0.59 works well for me too (PAL DVD).

TuRiSOft
12th September 2004, 08:35
I only wish to thank you for the really great job.

Thank you jdobbs , and keep up this great tool!!!