How are fake "100GB" DVDs made?

[Katie Boundary]

I've noticed that Paramount has a funny habit of making DVDs that are capable of tricking operating systems into seeing dozens of copies of the same files, effectively inflating the disc's apparent size to nearly 100GB and making the discs difficult to rip due to the "hall of mirrors" effect. Revenge of the Fallen, for example, appears to be 82.2 GB and has almost a hundred titles. How is this sorcery achieved?

[Ghitulescu]

There are not 100GB large, just that they employ a trick to make the OS think they are that big.

[Katie Boundary]

tricking operating systems into seeing dozens of copies of the same files, effectively inflating the disc's apparent size

There are not 100GB large, just that they employ a trick to make the OS think they are that big.

:rolleyes:

[Katie Boundary]

Oh, here's something weird: although Revenge of the Fallen and Dark of the Moon are scrambled this way, Age of Extinction is not.

[raffriff42]

Hard links, I betcha. It seems DVD uses Universal Disk Format (UDF) ,
https://www.google.com/search?q=dvd+file+system

and hard links are supported in UDF - at least in Windows
https://www.google.com/search?q=udf+hard+links


You might find them with fsutil.
https://technet.microsoft.com/en-us/library/cc788097.aspx

[Katie Boundary]

Hard links, I betcha. It seems DVD uses Universal Disk Format (UDF) ,
https://www.google.com/search?q=dvd+file+system

and hard links are supported in UDF - at least in Windows
https://www.google.com/search?q=udf+hard+links


You might find them with fsutil.
https://technet.microsoft.com/en-us/library/cc788097.aspx

Thanks!

For anyone else experiencing this same phenomenon, here's the short version: http://en.wikipedia.org/wiki/Hard_link

[qyot27]

Using hard links is one part of it, but it's not the *only* thing going on there. The really nasty part is that the chapter locations thread through the hard linked VOBs. That's why the extra program chains report all different durations even though the referenced VOBs are hard linked. The PGC for an individual VTS looks screwy to ripping software, but a normal DVD player (hard or soft) will just ignore it since they only worry about the actual navigation path.

The hard linking can even be verified; check the file hashes on the VOBs. Hard links are probably the only way to have all that seemingly invisible space being taken up while having exactly the same hashes.

I tested it with Thor - after decrypting and mounting the ISO, mpv was perfectly able to navigate and play the movie like it should, regardless of the hard links (and mpv can use --stream-dump to output the title as a single file, although I'm pretty sure you'd lose the chapter information; MediaInfo can get that from the .IFO, though...it only sucks if you want to re-author a disc backup with a not-royally-screwed-over file structure). Hell, I even deleted the duplicate hard-linked VOBs, replaced them with symbolic links, and it still didn't complain. Just deleting all the extra VTSes resulted in a lot of spammed messages from libdvdread upon playback, but still seemed to actually play the movie itself correctly.

You might find them with fsutil.
fsutil is an NTFS tool; it won't work with UDF.

[Katie Boundary]

Using hard links is one part of it, but it's not the *only* thing going on there. The really nasty part is that the chapter locations thread through the hard linked VOBs. That's why the extra program chains report all different durations even though the referenced VOBs are hard linked. The PGC for an individual VTS looks screwy to ripping software, but a normal DVD player (hard or soft) will just ignore it since they only worry about the actual navigation path.

You are literally the smartest, most helpful person on this whole damn forum :)

And actually, a lot of the program chains will report the same running times, at least when I'm using Smartripper without AnyDVD. When I use Smartripper WITH AnyDVD, then only the "correct" program chain will show any runtime at all, and all the rest will have a runtime of 00:00:00.