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
- If I've understood you
1 hour 34 min ago - Pierre-Luc is correct
1 hour 48 min ago - $100? Thats all you have?
23 hours 7 min ago - When setting Next PGC, most
2 days 10 hours ago - PLAYER ISSUE
2 days 14 hours ago - Hello,
Sorry to hear you're
1 week 13 hours ago - GOP-Sequenz could be true
1 week 1 day ago - I can't believe it! I've
1 week 2 days ago - The code is unfinished
1 week 2 days ago - That would be interesting for me, too.
1 week 4 days ago
Active forum topics
Resources
Syndicate
Macrovision RipGuard Issues
Thu, 2008-05-08 06:19 — justin
Hi All,
I have recently been made aware of a potential issue with AE and the latest version of RipGuard and I was hoping for some help.
I supplied a project for replication that was flagged for CSS and Macrovision Type 2 - RipGuard to be added at the factory.
The replicator contacted me saying there was a problem and that RipGuard could not be applied.
I have spoken to Macrovision, who've analyzed the DLTs and they say there's a corruption of the Anchor Volume Descriptor (AVD) that is causing the problem.
I made a new version of the project and resupplied the DLTs - same issue.
I am running Scenarist 3.2 which macrovision say is rock solid with regards to ripguard so they attribute blame to AE as it is the "unknown" element in my work flow.
Has anyone had a similar incident or is there anyway around this? Can I test the AVD myself prior to sending out DLTs?
Thanks in advance,
Justin
New Download
Hi Larry,
I'll download and install the new version when I hit the office tomorrow morning. I won't be able to test it properly until my next ripguard project goes out the door (and comes back clean) but I'll keep you all posted.
Thanks for all your help: having such a responsive software provider is very much appreciated.
Cheers for your valuable contributions, Trai.
Best,
Justin
Justin, please try our latest release
Hi Justin,
We have released DVDAfterEdit Mastering Edition 3.0.5d3, which fixes the incorrect location of the 2nd Anchor Volume Descriptor Pointer when outputting DDP for CSS. You will find it in the download section, under licensed releases.
Regards,
Larry
It is our bug after all
Hi all,
Apologies, there was was an error in the last AVDP that we put out if there is CSS. We will fix it and make a new release.
Regards,
Larry
It is apparently an Eclipse bug
Thanks, Trai
I ran a CSS project and finally see the reported error. But I also see the AVDP with a Hex Editor.
So I sent a report to Eclipse documenting the error that you found, and copying you on the email.
Regards,
Larry
Try with CSS applied
Ok Larry,
The problem is found with CSS applied. Try it you'll see.
I just formatted a couple of Tape Images without CSS, and indeed, the warning doesn't appear, and Eclipse reports that both AVDP's have been found - and gives their sector number.
Thanks for clearing that up; I feel better now :-)
But there's still Justin and others to worry about on this question.
Luckily, Eclipse is quite adamant that this warning does not affect playback. Basically the second Anchor Volume Descriptor Pointer is a backup to the first one; kinda like the .BUP's are to the IFO's. Justin is the first person I've heard of run into any problems with it because of the Arcsoft implementation - which is applied to CSS projects; and because of the structural changes it makes to the DVD at the plant, it has to know precisely where everything is. If it doesn't find that second AVDP, I could see how they could call it 'corruption'.
It couldn't be too much more than a tweak to fix, could it?
Thanks again,
Trai
Trai Forrester
TFDVD Research Labs
DVDVerification.com
Eclipse 5.1 verifies without errors or warnings
I updated to Eclipse 5.1, made sure UDF checking was on, and there are no errors or warnings.
Regards,
Larry
Yes, Eclipse 5.1, shipping version
Hi Larry,
I get the same results with any DDP 2.0 Image on the hard drive, and when they come back to me as check discs, of course; using Eclipse Image Analysis 5.0, 5.1, and Beta 6.
Thanks for sending the UDF reader. It says my last AVDP on the above Image in question is located at sector 534104 (when I click on "N") - not quite what Eclipse was 'expecting'.
I've sent you the screenshot as well as a text file with all of the "N" sector's contents, and also the Eclipse IA 5.1 report for the Image (DDP 2.0 with encryption flags set). Also, here's the Eclipse report on the Image in html:
http://www.DVDVerification.com/MM51image.html
Thanks,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
I guessed wrong on the typo
Hi Trai,
I assumed the larger number was the end of the disc, and that the typo was the missing N - 256. But actually, 532543 is the end of the disc, and N - 256 = 532287. Are you running Eclipse 5.0, and not the beta?
I will email you my UDFReader and you can open the image, and you will find an AVDP at the end of the disc, labelled N. If you click on it you will see the AVDP. Please take a screen dump and email it back to me.
Regards,
Larry
Yes, Larry, the second
Yes, Larry, the second number was a typo (can't copy from an Eclipse screen! :-), thanks.
It should read:
"Anchor Volume Descriptor Pointer expected at Logical Sector.... DVD-ROM: at 532287 or 532543"
"Less than 2 Anchor Volume Descriptor Pointers....UDF: Expected at LSN (LBA) 256, 532287 or 532543, Found: 1 AVDP"
I've spent quite a bit of time over the last couple of years player bank testing various DVDAfterEdit projects on this question, and I'm satisfied this UDF anomaly does not affect playback in players. Looks like you won't be able to apply Ripguard with it though - Scenarist and DVD Studio Pro do not have this 'intermittent' (?) UDF issue.
Could it be your above calculation of "532287 - 256 = 531775" is incorrect? Eclipse is looking for the second AVDP at "532287 or 532543" - not the "531775" from your equation. But now, if you add (not subtract like you did) 256 to 532287 you get the correct number Eclipse is looking for... 532543.
Maybe the issue is as simple as that?
Thanks,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
Odd, I have never seen that error
Hi Trai,
I just ran two tests, one a dual-layer DDP I just created, and another single-layer test created some time ago, with Eclipse 5.0. No errors, no significant warnings, the UDF tab doesn't mention AVDP.
Your message above lists 256, 532287, and 53254. Perhaps that last number is a typo. 256 and 532287 would be legal, but the third one would be 532287 - 256 = 531775.
My preferences are at defaults.
My UDF reader utility shows both AVDP's.
Regards,
Larry
Less than 2, it says
Hi Larry,
When I run Eclipse 5/6 the error I get on all DVDAfterEdit generated DDP file sets are similar to the below (3 warnings):
"Anchor Volume Descriptor Pointer expected at Logical Sector.... DVD-ROM: at 532287 or 53254"
"Less than 2 Anchor Volume Descriptor Pointers....ECMA167: Found: 1 AVDP"
"Less than 2 Anchor Volume Descriptor Pointers....UDF: Expected at LSN (LBA) 256, 532287 or 53254, Found: 1 AVDP"
The above was on a short 15 minute video without menus, going to replication - and no ROM data, other than the empty AUDIO_TS folder.
I emailed you about these UDF errors a couple of years ago (when Eclipse IA beta 5 came out), remember?
Thanks,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
That is not correct
Hi Trai,
The UDF 1.02 spec states that there must be at least two anchor volume descriptor pointers (AVDP's), of the three possible. The possible locations are: sector 256, the last sector of the disc, and the last sector of the disc minus 256 sectors (N - 256). We do not put out the AVDP at N - 256.
We have checked the output of DVDAfterEdit with both Eclipse 5 and the Phillips UDF verifier, and it passes both. We routinely run these verifiers plus our own UDFReader in-house utility on our DDP and CMF output.
We did add the N - 256 AVDP to the output of HDAfterEdit, which makes more sense with UDF 2.5 for HD & BD, because there is always a copy of the disc directory at the end of the disc (the Metafile directory), in addition to the normal one at the beginning, and it falls naturally after that directory.
Regards,
Larry
Corrupt Anchor Volume Descriptor Files
Hi Justin,
Macrovision is correct; DVDAE's formatting does not output the correct number of Anchor Volume Descriptor Pointers in the UDF structure, according to Eclipse Image Analysis 5.0 - earlier versions of Eclipse IA did not verify the UDF's contents, just that it was there.
This warning returned by Eclipse could be what the issue is, or all it can return due to the mentioned AVD corruption.
Take care,
Trai
--
Trai Forrester
TFDVD Research Labs
DVDVerification.com
DVDAfterEdit images may not match Scenarist
Hi Justin,
Each premastering application is free to use its own algorithm to ensure that .BUP files do not occur in the same ECC block as their .IFO file. This means that you cannot guarantee that DVDAE will produce the same result as Scenarist would do. We do always produce legal Anchor Volume Descriptor pointers, and many hundreds if not thousands of our titles have been passed by Eclipse Image Analysis.
I don't know how RipGuard works, it was invented after we completed our premastering software. But I am not surprised that it might expect something other than the exact disc image layout that we produce. One thing you might check for is an empty VTS domain, such as no VMG video or no menu video for a VTS. If so, you might try adding dummy black video to ensure that the BUP is is at least 32 sectors past the end of the corresponding IFO file.
Regards,
Larry
Post new comment