Even more unusual authoring in ARccOS DVD

[blutach]

I cam across an ARccOS DVD the other day, which had an interesting situation:

A cell commands that said "If gprm(2) & gprm(2) Link Cell 10" (which does not exist)

When you play it, gprm(2) =0 so the condition is false (even though it looks true) and the title plays normally.

However, if you play the same title again immediately, gprm(2) is non-zero when the cell command is reached, making the player want to skip to the non-existent cell.

Is this just SONY being too clever by half? Or is this legal and the DVD will play the last legal cell in the PGC?

Regards

[r0lZ]

IMO, it's a bug in ARcc0$! :)

[setarip_old]

Hi!

Won't you be good enough to share the Title and Region of this DVD?

[blutach]

Indeed - it is MirrorMask R2.

I also think it is an ARccOS bug.

Regards

[setarip_old]

Based on the action you've described (That it plays properly the first time), it certainly doesn't appear to be part of any protection scheme.

My Region 1 version of "MirrorMask" doesn't contain "ARccOS" copy protection, just CSS and "standard" Macrovision.

I've seen no postings anywhere of this being an "ARccOS" copy protected DVD (No questions about how to rip it and no postings providing PSL2 files) - and it was released several months ago.

Are you certain your Region 2 version contains "ARccOS" copy protection, or was it just a presumption based on the fact that it's a SONY release?

[bourtzovlakas]

I can confirm that Mirrormask Region 2 Greek has this new protection scheme/bug...
Also, the Swedish version appears to be identical...

[blutach]

@setarip - it plays correctly the first time because the gprm(2) = 0. If you play it again immeidately, it is non-zero and the condition is true, leading the player to a non-existent cell.

And the DVD is absolutely riddled with ARccOS. Just cos R1 was unprotected means nothing for the R2 version.

Regards

[setarip_old]

@bourtzovlakas

Hi!

Other than this apparent anomaly (which appears to be a "bug" and not copy protection), were you able to use DVD Decrypter v.3.5.4 directly or DVD Shrink directly to successfully rip this DVD?

[r0lZ]

(which appears to be a "bug" and not copy protection)
It's obviously a bug in the ARcc0$ protection!

[bourtzovlakas]

This title is ARccOS protected...
...and has the bug that Blutach described, in details...

[setarip_old]

@bourtzovlakas

Thank you for confirming this...

[blutach]

Update - apparently, on some players (the cheaper ones, naturally), the title plays (once) and the second time, rather than stop, seems to find the last cell and returns to the menu.

Verrrrry strange.

What I wonder about is what the poor Europeans did to deserve this intentional defects in their DVDs?

Regards

[bourtzovlakas]

Region 2 seems to be the test bench for the U.S. releases...

[r0lZ]

What I wonder about is what the poor Europeans did to deserve this intentional defects in their DVDs?
IMO, it's not intentional. I see no reason to do it this way, since the protection is not more efficient, and it fails on compliant players!
I hope this bug will incite the companies to abandon those stupid and dangerous protections!

[jm1647]

Region 2 seems to be the test bench for the U.S. releases...

I don't think R1 sees half the protected DVD's that R2 does I'm :D we don't get and :( you guys do. But then R2 has all the fun doing them hard to do backups that are a challenge.

[cynthia_old]

The RC2 Swedish is also ARccOS - but that extra material can be played in Nero Showtime several times without that stop. I haven't burned it and played it in my standalone player yet. Will do that. :)

The swedish version of this DVD was released this week.

[blutach]

Perhaps mpucoder can give us the definitive answer on this - it seems it is illegal but in practical terms it might play.

Regards

[mpucoder]

If anyone with an R2 version would run it through a verifier we would know, at least, what the verifer thinks. Since no authoring program I know of will let you jump, link, or call a non-existant location I doubt it is either permitted or intentional. More likely the result of a bug in the "protection" software (which, afaik, is post-authoring since a modified script containing this error would be rejected by Scenarist and others).
btw, it is not very hard to get through most of RipGuard crap when demuxing. I already had some code to skip the pad sectors used by DVR. These are used to fill up the last ECC block when recording and have a strange, but detectable, structure (stc == vobu_s_ptm, ie 0 multiplex delay!). So adding a check for pack header was simple enough. The other two gotchas are audio desync caused by cells with no audio preceeding the real cells (also not difficult to detect) and now navigation errors (well, if you demux and remux those go away).