0 Items in Your cart
Shopping cart ![[]](/sites/all/modules/ecommerce/cart/images/cart_empty.png "View your cart items")
User login
Recent News
Poll
Recent comments
- Further research...
2 weeks 5 days ago - Blu-ray Graphics
2 weeks 5 days ago - About Blu Ray region codes,
2 weeks 6 days ago - DVDSP steals 8 of the 16 registers
3 weeks 10 hours ago - "DVDSP Errors"
3 weeks 21 hours ago - DVDSP Errors
3 weeks 1 day ago - BluRay Creation Software
4 weeks 2 days ago - There is a natural progression
4 weeks 2 days ago - What kind of a learning curve ?
4 weeks 2 days ago - If I've understood you
5 weeks 3 days ago
Active forum topics
Resources
Syndicate
VOBU length & number of sectors disagree
Mon, 2008-06-16 14:15 — Pierre-Luc
I just read 2 posts about this issue but I'm not sure if it's exactly what I got.
I got the Eclipse report saying this error with DSI higher than Actual value. I then ran a Compare of the DDP with the VIDEO_TS and Disc Image. Both tests failed with the same log error. Here is the last few lines:
File name VTS_02_1.VOB Offset 0261dc9f
0000: 0000 01ba 4406 df14 0cad 0189 c3f8 0000 01e0 07ec 8100 001f 3c5b 7365 2e2c b025 ....D...................<[se.,.%
0480: 5e44 2820 06ad 62cb a55b 0219 3be6 ea26 28a3 c7a0 e69a cdf3 2dba 6072 a1ed 9727 ^D( ..b..[..;..&(.......-.`r...'
0480: 5e44 2820 06ad 624a a55b 0219 3be6 ea64 28a3 c7a0 e69a cdb2 2dba 6072 a1ed 9725 ^D( ..bJ.[..;..d(.......-.`r...%
Format copy error detected in function Run at line 180 of file CInputComparatorThread.cp Note: Data compare error
Buffer types don't match: From type = None To type = Finished
Format copy error detected in function Run at line 109 of file CInputComparatorThread.cp Note: Buffer type mismatch
It looks like a problem with VTS#2. I tried just to redo the DDP, same error. I'm going to replace 2nd VOB to see what's wrong.
It looks like similar issues, the burned DVD-R from the disc image created from the DDP played fine all way through. Trai also mentionned it can probably be unreadable sectors due to submitting on DVD-R, but I've done this many times, without problem.
Still testing, thanks for your input.
Pierre
GOP-Sequenz could be true
even DVD SP should handle trimed MPEG correct, it is no good to to that. normally you better append the MPEG-streams.
I have seen different problems coming with it.
THIS could be the main problem with your stream.
danny
I can't believe it! I've
I can't believe it! I've rebuilt the entire project and Eclipse gave the same error, from new DLT's. The only thing I've done with DAE is replacing VMG menus with VTSM1 of the same project (can it be that?) and reauthored the project. Created the DDP (MacPro 10.4.11), transferred over the Mac (G4 10.4.11) with the DLT4000 drive attached and output on Sony DLTIV (used to be Maxell DLTIV).
Can it be from the encoding side ? 5 videos but the main feature is in 2 parts and I had to trim one of them so maybe a problem in the GOP sequence ?
I hate this kind of error you only know of when it's going to be replicated!
The code is unfinished
Hi,
Sorry, I was working on code to check the VOBUs, but was using a separate project and never finished integrating it into HDAfterEdit. And I have no time to pursue this now, though it is on my list of desirable things to do.
Regards,
Larry
That would be interesting for me, too.
One of my german coulegues have a similar problem, I wish I could give him a hand.
danny
Again
I got this same error message again for a new DVD-9 project submitted on DLT's. I'm rebuilding (muxing) the project from scratch since I had to replace some VTS's and it might be the problem. I also trashed the .plist of the project to make sure.
Larry, you said you had some code to verify this error with HDAfterEdit, could it be possible to have it so I can verify ? That would be great.
Thanks
Pierre
Well Trai, I think I'm
Well Trai, I think I'm convinced on that one. Although I always recommended DLT and check discs to verify the final product before the long run, I'll be more insitant to the clients and be much more aware of the potential alerts and will make clearly understandable by the client what are the risks of going the "cheap" way of DVD-R. Hard disk or USB stick is good idea as an alternative, but as you said, DLT is definitely more robust as an archive media.
And you're absolutely right about the low budget, don't want to spend much time to redo the job that doesn't pay alot at start :)
Go DLT Go!
Thanks!
Pierre
Go with DLT young Man
Hi Pierre,
The 'lower the budget', the more DLT makes sense.
Do you have anything left in that 'low budget' to take the time to mess with a botched submission on DVD-R? Or, worse than getting rejected by VOBU and sector mismatch errors is the replicator just going ahead and replicating with them on there. Do you have time factored into that low budget to deal with pulling the DVD from retail shelves and redoing the run, in that case?
Based on my replication troubleshooting experience over the last several years, I'd say about maybe about half the replicators out there (or most replicators about half the time?) don't even read the Eclipse reports, and are going to replicate what you send them - no matter what (all these Eclipse errors and warnings do not abort the transfer of the Image onto their server for mastering); you wouldn't believe the "doozies" that have come across my desk, which should never have been allowed to go out! (definitely alert your client to the need to verify the Image and/or replicators output, no matter what the Image is to be submitted on; that way you've moved to protect you and your client even if they decline).
And many replicators won't take the time to download from your FTP and/or verify your upload with a checksum program, etc. on their minimum run packages.
I've been encouraging DVD Image submissions for pre-mastering to me on 'microscopic' 10 - 15GB USB memory sticks - awesome; less expensive FedEx shipping rates than for big Fire Wire hard drives and they work well with all my verification software, Macs and PCs, and finally allow moving the Image nicely to DLT for submission to the plant. Maybe your replicator will accept these? Eclipse works well with these USB memory sticks.
Again, DVD-R has no place in DVD Image submissions --- unless of course you add dealing with its myriad potential issues 'to the budget' - and disclose to your client that they're in for a 'nice' game of roulette with you (not sure who 'pulls the trigger first' in that analogy :-).
Besides, DLT also gives everyone a more robust archive of the Image - and is still cheaper for DVD Image storage than a USB memory stick/flash drive (not by much).
Basically what I'm trying to say, Pierre; for all practical purposes and in all my years working on these things, I don't think I have even seen a 'low budget DVD'. Is this a setting I missed in the VMG, somewhere? :-)
Take care,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
Thanks Trai for this deep
Thanks Trai for this deep explanation. I read about it some time ago and I was kind of aware of the possible error, but since I never had problems at the plant going this way (and for clients that don't wanna pay for DLTs), I kept submitting on DVD-R for those who wanted to, though I always recommend DLT.
I also have a client (broker with replicators) that ask for DVD-R (DVD-Video) as a master. I let it for small projects, but for mass replication, forget it. He still claims that he never failed a job with DVD-Video. as long as the master is "perfect", but I tell him, you never know when it will step up into your face.
Well, concerning Plant Direct, is there any "safe server" that replicators usually use or I could use my own FTP to send the DDP ?
Unfortunately, we're always dealing with low-budget-people-DVD-R-is-fine.
Stay away from DVD-R
Hi Pierre,
This error is almost exclusively returned on Images submitted on DVD-R, and is Eclipse's way of saying that it couldn't read the Image data on one or more sections of disc. It is almost never an authoring system problem (I've only seen an authoring system output this error to hard drive/DLT once in 6 years). In fact, several times a month I get discs sent to me with this error at the plant and find the Images are perfect - yes, they were all submitted on DVD-R.
Here's the explanation of the error, as provided by the Eclipse ImageAnalysis program:
-------------------
"The calculated length of the VOBU and the length specified in the DSI field disagree.
The length of the VOBU is calculated using the address of the Navigational Pack and the length as specified in the DSI field (NV_PCK + VOBU_EA = LENGTH). During the analysis, the EclipseSuite tools read from the beginning of the VOBU until they reach the next NV_PCK, which indicates the end of the current VOBU and the beginning of the next. The EclipseSuite tools keep count of the number of sectors that make up the VOBU. If the number of sectors does not equal to the length specified in the VOBU_EA field then this error occurs.
In most cases, this problem has caused playability problems. It is for this reason that it is considered an error."
-----------------
So, if the replicators optical drive drops a sector during the read of your DVD-R, they'll get the error, even if the Image is fine.
And there is no way DVDAfterEdit, or any program for that matter, will ever be able to account for it, due to even a perfectly written DVD-R can have problems being read at times by various different optical drives.
The only defense is submitting on DLT or hard drive or FTP; keeping the DVD production process off of optical media all the way to the very end, when it finally becomes a stamped DVD-Video DVD-ROM.
But you knew that already, right?
Take care,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
VOBU Length
Hi Pierre,
I did some research on this error a few months ago, and have some code to check for it in the unreleased version of HDAfterEdit. It is definitely an authoring error, or corrupted data, and not something that DVDAE is ever aware of. There are major studio releases that have this error, but in harmless places, i.e. in video that is never played.
Regards,
Larry
Got it!
I finally had to rebuild the project on a diffrent hard drive on a different Mac (G4 to MacPro) with a different DVDSP version (4.0.3 to 4.1.2). DAE compare finally succeeded, but I found that you have to compare with the tape image as the Destination and not the Source, as it will failed at the end (often with a .DS_store offset). I later found a Ian's post here that confirmed that issue.
Is there any way we can verify the "VOBU length & number of sectors disagree" error with DAE ?
Post new comment