New anti-ARccOS plugin for PgcEdit

[blutach]

See here (http://forum.digital-digest.com/showthread.php?t=56078). Written by The Mad Monk.

A little plugin for PgcEdit which analyse the IFOs of ARccOS protected DVDs, and guides you through making a PSL2 automatically and then helps cleanup the cell structure afterwards.

Works like a charm.

Regards

[Mug Funky]

on a slight tangent here, but have you encountered any arccos discs downunder? it's a while since i actually sat down and watched a DVD (i've bought a few lately - they're all still shrink-wrapped), but i haven't found any yet.

[blutach]

Just a couple, Hitch and Closer (I think). As it turns out, they used the scheme which DVD Decrypter decrypted easily.

Obviously, this plugin is for those ARccOS disks released after development of DVD Decrypter ceased.

Regards

[setarip_old]

This looks promising.

Is this plugin an "intelligent" program, able to cope with any new .IFO coding, applying thusfar unused .IFO commands that SONY may choose to use or, is it "hardwired" to specifically deal only with those commands that have been used thusfar (up to and including the protection used on "Lords of Dogtown")?


Obviously, this plugin is for those ARccOS disks released after development of DVD Decrypter ceased.
Are you saying that it cannot handle the older ARccOS protection schemes?

[blutach]

It handes before and after.

The plugin is commented so you can see exactly how it works.

Nothing can predict the future way in which companies try to manipulate their IFOs. The way it works it to follow the various jumps in the cells commands from the entry point of the title (usually cell 1 but it doesn't have to be). The various cell commands are analysed and eventually you get to a cell that that plays on. This way the ARccOS cells can be identified. PSL2 is made accordingly.

Regards

[jeanl]

I thought the arccos cells were actually unreferenced at all (i.e., never referenced in any of the PGC cells)! If that's the case the plugin wouldn't need to follow the navigation. But I suppose sony perfected it so the cell appears to be reference, but by a PGC cell that actually never ever plays... Is that the case?
jeanl

[setarip_old]

Nothing can predict the future way in which companies try to manipulate their IFOs.

So it's "hardwired" to handle specific protection schemes. I guess that would explain the v.1.4 changes to address two specific DVDs ("Layer Cake" and "Lords of Dogtown")...

[jeanl]

no, I think these were merely fixes for bugs that were revealed by the specific DVDs. The technique should work with any arccos protected DVD, as long as the same protection technique is used (very primitive indeed). The plugin only helps you create the PSL2 file...
jeanl

[blutach]

Gents,

First, I am not the author. The plugin is commented. Follow it through.

@jeanl - the cells are referenced but don't play. Pick an ARccOS disk in your collection and trace through the structure. What happens is you enter the title (always at cell 1 so far, but it doesn't have to be of course), play that cell (a legit 10 framer), follow a cell command which usually looks something stupid like:

if gprm(3) == gprm(3) LinkCN ##then play the next cell (always a legit 1/2 second blank) and go on like this for a while until the title is actually played (no further cell commands).

The plugin is intelligent enough to figure out what cells are the ARccOS ones from there and then builds a PSL2 using recent development work carried on around the place.

Afterwards, you get rid of the ARccOS cells from the cell table (Remove Crap) and you are left with a DVD that looks and plays precisely like they all did a year or so ago.

Regards

[cynthia_old]

The Lord of Dogtowns is a new ARccOS version. It works different than the older ARccOS released DVDs.

During the creation/beta testing of this tools - Closer was used. But as the above title needed a new approach - there where the need for an update of the plugin.

[r0lZ]

I have just analyzed the code. Seems the plugin is able to deal with all cell commands you may encounter in future ARccOS versions. But IMO, there are still some gaps in the way it handles some things. To be able to cope with all future protections, there are still some things to do. But I don't want to explain them here. Sony may be interested, too!

[CoNS]

But you could discuss those things with The Mad Monk, r0lZ?

[r0lZ]

Not sure who he is, though I have an idea.

[blutach]

@CoNS - my strong understanding is that if new things come out, the plugin will be updated. Already in a week there have been 4 enhancements.

And yes, there are some areas that are not quite 100% but really only in cases not yet seen.

The idea to get a very quick and easy way to make a PSL2 file. So far, it works. In effect, we are the Beta testers for it. Get your ARccOS disks out and test it. Report back any problems. I'm sure TMM will read them.

Regards

[Wheelie4]

I'm totally lost. You use a ripped dvd in pgcedit. Why the need for the PSL2 if it's already ripped? :)

[jeanl]

The IFOs are used, and they're not encrypted. The plugin does not use the VOBs (which couldn't be decrypted)... EDIT: sorry, I meant "couldn't be ripped"
jeanl

[Wheelie4]

Ahhhhh, I gotcha. I just briefly reviewed the guide and DANG thats a long guide. :)

[setarip_old]

does not use the VOBs (which couldn't be decrypted)...

That's not quite an accurate description.

In fact, (as I described in another thread) using Region 1 "Lords of Dogtown - EC" as the example, with DVD Decrypter v.3.5.4 (In "File" mode, set to "ALL files") set to -0- "Software read retries" and a checkmark next to "Ignore read errors" - after about 5 hours of of "grinding it out", you'll have a perfectly usable DVD "package".of .IFOs, .BUPs, and .VOBs. This "package" is accepted for input by both DVD Shrink and DVD95Copy (DVD2One complains about "improper" .IFOs) - and does NOT require creation of a PSL2 file or having to rip the DVD a second time with a PSL2 file...

[r0lZ]

That's true. But 5 hours (and it may takes upto 12 hours with some drives, and Sony may even increase the number of read errors), to finally have a non-standard VOB, that's not what I call a successful rip. Hence the utility of the PSL file, and of the plugin.

[setarip_old]

to finally have a non-standard VOB

Please be good enough to enlighten me - What would be "non-standard" about the .VOBs as ripped by DVD Decrypter in the manner I've described?

[r0lZ]

Well, the VOB should be exactly the same as the one produced by the plugin. But the bad cells in the VOB are still referenced in the IFOs, and therefore they must be readable if you want to process the DVD with, say, VobBlannker or DVDShrink. That's not the case with the ARccOS cells, replaced by dummy, empty sectors.

However, it should be possible to apply the post processing of the plugin anyway, to remove the references to the bad cells in the IFOs. But you need the plugin, or you must be experienced enough to do it manually with PgcEdit, IfoEdit or DRM.

[setarip_old]

@r0lZ

But the bad cells in the VOB are still referenced in the IFOs, and therefore they must be readable if you want to process the DVD with, say, VobBlannker or DVDShrink.

But as I said, using the "grind it out" method I described, the resultant DVD "package" WAS accepted by DVD Shrink (and DVD95Copy) for input and processing.

I guess I'm not fully understanding you, for which I apologize, but I'd really like to understand. Other than the obvious toll constant "grinding it out" (Not the case presently. Perhaps one out of 10 DVDs I've purchased in the past year have had any version of ARccOS protection) would take on my DVD-ROM, what is it I'm missing?

One other question, if I may. By using DVD Decrypter set to skip the bad sectors, what is the final condition of those sectors when DVD Decrypter (in "File" mode) writes the ripped DVD to my hard drive?

My speculation is that they are simply unwritten and, therefore, interpreted as being "bad sectors" - which would conform with the information "SONY" has placed in the .IFO.

Is this correct, or is it something else?

Thanks for providing your insight ;>}

[r0lZ]

DVSShrink may accept some of them. But there are cases where it won't. I don't know why. I have never tried DVDShrink on an ARccOS protected DVD, simply because I have never seen such DVD. I have only tried to understand how the plugin works with the Closer IFOs provided by Cynthia at Digital Video Forum.

The plugin is made for the new protection type, with cells referenced in the IFOs. I think (but, as I said, I'm not an ARccOS expert) that the first protection did not reference them. Have you tested your method with the newer protection (for example with Closer) ?

My understanding is that a good program must fail when it encounter a referenced ARccOS cell which has been replaced by zeroed sectors by DVDD. Obviously, such a cell is illegal, and may, at least, confuse the program. On the other hand, if the cell is unreferenced, the program may simply ignore it. Seems it's the way DVDShrink works, but not all programs are so smart.

I don't know how DVDD works when it encounter some bad cells that are referenced in the IFOs, without a PSL file to explain what to do with those cells. With the PSL2 file generated by the plugin, it will remap them to an existing valid cell, if the remap option was used, of course.
Maybe with your method it is able to remap them automatically? You may verify that. Have a look at the cell table after the rip. If the ARccOS cells are all identical, then DVDD is very smart. Also, the original ARccOS cell should appear in the "unreferenced material" secton of DVDShrink.

In File mode, a cell is never skipped by DVDD. It may replace the references in the IFOs to reference another, valid cell, but it will not remove it. It's only feasible in IFO mode. So, I think DVDD produces always illegal VOBs, though if the illegal cells are not referenced, it's probably not very important.

Anyway, it is better to remove completely (or replace by valid blank cells) the ARccOS cells with VobBlanker, even if they are not referenced anymore. The easiest way to do it is to use the plugin to remove them from the IFOs after the rip, and process the title domain with VobBlanker. This way, you don't have to worry. The DVD will be reabable with all applications. You may even use a software DVD player to display the contents of the VOB file, or reencode them, w/o the IFOs. If you don't remove physically the bad cells, it's probably not possible.
Removing the bad cells with VB has also the obvious advantage to free up some room for a better compression.

[setarip_old]

@r0lZ

Thanks for taking the extra time to explain further ;>}


Have you tested your method with the newer protection (for example with Closer) ?

Yes. I tested it with the LATEST version of "ARccOS" copy protection - on the Region 1 versions of "Lords of Dogtown - Extended Cut".

The resultant files were accepted for input and processing by DVD Shrink (and DVD95Copy) but not DVD2One (Complained about .IFOs).

Thanks again for your very informative postings...

[r0lZ]

Could you post a dump of the "Lords of Dogtown" cell table (after the rip)? I wonder how DVDD has made this magic.

[setarip_old]

Could you post a dump of the "Lords of Dogtown" cell table (after the rip)?

Sure - If you'll explain how to do this (I've little experience in this aspect of DVD analysis) ;>}

[setarip_old]

@r0lZ

if you'd be good enough to post where I'd find the "cell table" and how to extract it, I'd be glad to post it...

[r0lZ]

Open the DVD in PgcEdit. Select the main (protected) title. Then go to Info -> PGC. The cell table is at the end of the output. Copy it, and paste it here between [ CODE ] tags (to use fixed width fonts.)

[setarip_old]

Chap. Prog. Cell Type Layer Res- Still Cell Playback End Entry First Last Last VOB Cell
(PTT) Flags Break tric- Time Cmd. Time Time VOBU ILVU VOBU VOBU ID ID
ted. sector End Start End

0 1 1 1 3 yes no 0 30 00:00:00.00 00:00:00.00 0 0 0 6 1 1
0 2 3 yes no 0 33 00:00:00.00 00:00:00.00 7 0 7 13 1 2
0 3 1 yes no 0 0 00:00:00.00 00:00:00.00 14 0 14 20 1 3
0 4 3 yes no 0 87 00:00:00.00 00:00:00.00 21 0 21 27 1 4
0 5 3 yes no 0 19 00:00:00.00 00:00:00.00 28 0 28 34 1 5
0 6 3 yes no 0 6 00:00:00.00 00:00:00.00 35 0 35 41 1 6
0 7 9 no no 0 71 00:00:00.08 00:00:00.08 42 0 42 48 1 7
0 8 9 no no 0 13 00:00:00.04 00:00:00.12 49 0 49 55 1 8
0 9 9 no no 0 12 00:00:00.06 00:00:00.18 56 0 56 62 1 9
0 10 1 yes no 0 15 00:00:00.01 00:00:00.19 63 0 63 69 1 10
0 11 9 no no 0 44 00:00:00.07 00:00:00.26 70 0 1529 1649 1 11
0 12 1 yes no 0 51 00:00:00.02 00:00:00.28 1650 0 1895 2023 1 12
0 13 1 yes no 0 46 00:00:00.08 00:00:01.06 2024 0 4867 4899 1 13
0 14 9 no no 0 20 00:00:00.02 00:00:01.08 4900 0 5059 5171 1 14
0 15 1 yes no 0 17 00:00:00.03 00:00:01.11 5172 0 8433 8472 1 15
16 9 no no 0 44 00:00:00.05 00:00:01.16 8473 0 9807 9928 1 16
17 1 yes no 0 53 00:00:00.04 00:00:01.20 9929 0 11215 11313 1 17
18 9 no no 0 44 00:00:00.02 00:00:01.22 11314 0 14148 14280 1 18
19 1 yes no 0 25 00:00:00.04 00:00:01.26 14281 0 15193 15329 1 19
20 9 no no 0 0 00:00:00.06 00:00:02.02 15330 0 16561 16567 1 20
21 9 no no 0 0 00:00:00.04 00:00:02.06 16568 0 16568 16574 1 21
22 8 no no 0 0 00:00:00.14 00:00:02.20 16575 0 16575 16601 1 22
23 8 no no 0 0 00:03:56.13 00:03:59.03 16602 0 71262 71462 1 23
2 2 24 8 no no 0 0 00:04:25.15 00:08:24.18 71463 0 170051 170275 1 24
3 3 25 8 no no 0 0 00:05:19.06 00:13:43.24 170276 0 273093 273404 1 25
4 4 26 8 no no 0 0 00:02:15.22 00:15:59.16 273405 0 320316 320599 1 26
5 5 27 8 no no 0 0 00:04:23.08 00:20:22.24 320600 0 398141 398339 1 27
6 6 28 8 no no 0 0 00:05:01.13 00:25:24.07 398340 0 483972 484130 1 28
7 7 29 8 no no 0 0 00:06:07.16 00:31:31.23 484131 0 611792 611902 1 29
8 8 30 8 no no 0 0 00:03:16.16 00:34:48.09 611903 0 683653 683798 1 30
9 9 31 8 no no 0 0 00:03:36.09 00:38:24.18 683799 0 746260 746425 1 31
10 10 32 8 no no 0 0 00:04:08.16 00:42:33.04 746426 0 815358 815598 1 32
11 11 33 8 no no 0 0 00:04:20.14 00:46:53.18 815599 0 905266 905472 1 33
12 12 34 8 no no 0 0 00:03:02.21 00:49:56.09 905473 0 965516 965647 1 34
13 13 35 8 no no 0 0 00:04:20.05 00:54:16.14 965648 0 1033279 1033494 1 35
14 14 36 8 no no 0 0 00:04:13.23 00:58:30.07 1033495 0 1117057 1117250 1 36
15 15 37 8 no no 0 0 00:02:13.19 01:00:43.26 1117251 0 1156496 1156619 1 37
16 16 38 8 no no 0 0 00:05:00.08 01:05:44.04 1156620 0 1246712 1246834 1 38
17 17 39 8 no no 0 0 00:06:22.10 01:12:06.14 1246835 0 1352262 1352318 1 39
18 18 40 8 no no 0 0 00:03:55.17 01:16:02.01 1352319 0 1414513 1414712 1 40
19 19 41 8 no no 0 0 00:05:14.13 01:21:16.14 1414713 0 1508149 1508557 1 41
20 20 42 8 no no 0 0 00:03:16.06 01:24:32.20 1508558 0 1566956 1567213 1 42
21 21 43 8 no no 0 0 00:04:20.21 01:28:53.11 1567214 0 1643477 1643760 1 43
22 22 44 8 no no 0 0 00:03:22.11 01:32:15.22 1643761 0 1692355 1692552 1 44
23 23 45 8 no no 0 0 00:02:21.01 01:34:36.23 1692553 0 1735946 1736220 1 45
24 24 46 8 no no 0 0 00:02:08.06 01:36:44.29 1736221 0 1767615 1767824 1 46
25 25 47 8 no no 0 0 00:01:27.28 01:38:12.27 1767825 0 1791612 1791781 1 47
26 26 48 8 no no 0 0 00:02:24.19 01:40:37.16 1791782 0 1837488 1837666 1 48
27 27 49 8 no no 0 0 00:04:27.28 01:45:05.14 1837667 0 1923440 1923624 1 49
28 28 50 8 no no 0 0 00:05:10.06 01:50:15.20 1923625 0 1992321 1992358 1 50

[r0lZ]

Well, obviously, the ARccOS protected cells are still referenced in the IFO. Have a look at the Entry VOBU Sector and Last VOBU End values of the first cells (upto cell 22.) The VOBU sectors numbers are contiguous.
Also, all playback times of those cells are too short. (It is illegal, theorically, to have a cell PB time less than approx 0:00:00.12.) But that timing problem is not so important. Seems all players are able to use those cells w/o problems.

I'm still wondering how DVDShrink handles the zeroed cells when they are referenced. Anyway, my conclusion has not changed: it is better to remove them.

[setarip_old]

@r0lZ

Thanks for the interpretation of the cell table.

I guess the reason this rip works will remain a mystery...

Does your analysis of this table tell you how DVD Decrypter handled the actual bad sectors?

[r0lZ]

No. DVDD has not remapped the bad cells, and I think it is unable to recreate from scratch a new valid cell when the original is not readable. Therefore, I suppose there are still zeroed cells in the VOBs (and those cells are still referenced in the IFOs.)

Note that you can see them in DVDShrink: the time slider should jump rapidly to the next cell when a zeroed cell is skipped by the preview. (In the ARccOS example DVD I have tested now, those cells were remapped, and the zeroed ones are therefore in the unreferenced material section.)

[setarip_old]

@r0lZ

Forgive my lack of knowledge here but, I asked about "sectors" and you responded about "cells" - Are the terms "cells" and "sectors" synonymous?

[Video Dude]

A DVD sector is 2048 bytes of data.

A cell is a unit of playback (or a scene). It can be small (0.15 sec) or a couple minutes.

So the bigger the cell, the more sectors it takes up.

[r0lZ]

Sorry Video Dude, I haven't noticed your reply.

@stearip_old:
No. A sector is a block of 2048 bytes. A cell is made of several sectors.

The cell is the smallest "item" that can be referenced in the IFOs. So, for example, it there is a read error in a sector of a specific cell, that cell as a whole cannot be played, and must be remapped, zeroed, removed or whatever by DVD Decrypter. This is why I prefer to speak of cells rather than sectors.

[setarip_old]

@Video Dude

Thanks for the specifics

@r0lZ

Thanks for the supporting detail of your previous response. Based on what you've explained, I'm guessing that when used set to -0- software read error retries and "Ignore all read errors", DVD Decrypter is probably re-writing all bad sectors as sectors filled with zeros - which apparently (at least in the case of this specific Region 1 "Lords of Dogtown - Extended Cut", if not ALL "ARccOS"-protected DVDs) results in a perfectly usable DVD "package" - for either direct burning or compression by DVD Shrink, DVD95Copy, and perhaps other software.

Again, thanks very much for the technical analysis ;>}

[blutach]

My understanding is that with 0 software error retries it reproduces a bad cell - similar to how DVD Fab Decrypter operates (but fengtao is modifying this behaviour).

However, what happens is that in ARccOS disks, the bad cells are skipped. In your cell table setarip, you will notice the movie (which probably starts at cell 1) then stops to execute cell command 30, which takes it somewhere, skipping over the bad sectors and only playing good ones, till it finally reaches cell 23 where you can see there is some real video (3min 56 sec 13ff), after which it plays normally (no more cell commands).

This probably explains why it plays OK.

A number of transcoding packages seem to accept the rip while others don't. This does not mean that they will perform properly when transcoding comes (although AFAIK, most basically rebuild their IFOs, especially problematic time map tables).

The use of "After rip: remove crap" in The Mad Monk's plugin will assist greatly in producing compliant IFOs for programs to process.

Regards

[setarip_old]

My understanding is that with 0 software error retries it reproduces a bad cell

This seems illogical, for how could DVD Decrypter reproduce (duplicate) a cell it can't read?

I guess only the author knows for sure...