Question: need help understading the dvd structure

Hi,

I am a novice when it comes to DVDs, I'm trying to understand how data is written on a DVD. I read that the sector size on dvd is 2064 B and that the ecc info is written for every 16 sectors. However, when i burn an all 00 file to a DVD image and examine it with hexeditor, I do not see any sector info added. the content of the file appear as if the DVD was written in RAW mode. I know that the raw mode is not possible on DVDs (atleast with normal buring programs). The file i have written is 80MB in size which I assume is big enough to cover 16 sectors. so why dont i see all this info ?.
The reason I am asking all this is, my dvd burner is not able to completely burn dvds, it "kind of" gets stuck in the middle of it and the LED on the burner keeps blinking. It is possible that my burning program (NERO 7) is producing a corrupt image that the buner is getting confused with or is it time to buy a new burner, even though it reads DVDs fine ?

any help would be appriciated,

Rgd:
Rahul

I think it is time to buy a new burner.

You don't see ECC because DVD burners handles and processes that internally. DVD burning & reading software can only process the data part - which is the 2048 bytes per sector.

I do not think Nero is creating a corrupt image, but my suggestion would be to try out the excellent ImgBurn, and if it does the same thing then it is your burner playing up.

Thanx for the reply, though I figured it out myself in the mean time. Actually, it was none of the two. it was a corrupt controller driver that had set the drive transfer mode to PIO. I didn't notice that the drive was reading slow aswell (I rarely watch movies on PC) I reinstalled the driver and it took care of the problem.


Just out of curiosity, does this imply that one would never see any ECC data on the disc if is examined with a hexeditor (in contrast to a CD image) and all of it is done on the fly. I am not trying to challange your knowledge however, I doubt it. coz I have a DVD-R(PC burnt) from a studio that was copy protected with bad sectors and in my thinking, if one never has any control over the ECC then bad sector protections would not have been possible, as the drive would create an ECC for the data you are trying to write on a percieved bad sector, which would essentially mean that there can never a bad sector on the disc in optimal conditions. May be I am looking DVD-thinking CD, can you please throw some light on it.

Yeah, I forgot about such thing, because that never happened to me before since I stick with Intel chipsets. The user _chef_ would have answered that correctly, hey, where were you this time, hehe?

Yes, you will not see ECC in the image because the standard readXX commands are also 2048 bytes per sector. Also, the standard MMC writeXX commands as used on all consumer DVD burners only support 2048 bytes per sector, so it is impossible with such unmodified burner.

I have seen some DVD-R video discs from a rental place that have extra large TOC of 4GB and ripping after halfway with ImgBurn, it gave lots of unreadable sectors and didn't finish after 10 hours. Upon closer inspection I noticed that the video portion is only 2GB! This method can be acheived by consumer burners, but it isn't to do with ECC, it is overburning large leadout.

If you really want to examine the ECC there are some DVD drives that does allow you to unconventionally read the full 2064 bytes per sector (also wii discs can be backed up with these drives):
- Hitachi LG GDR-8161b (IDE)
- Hitachi LG GDR-8162b (IDE)
- Hitachi LG GDR-8163b (IDE)
- Hitachi LG GDR-8164b (IDE)
- Hitachi LG GDR-H10NBLK (SATA)
- Plextor 755A (with my own tool)
- Plextor 760SA (with my own tool)
- LG GSA H22N (with my own tool)

---

Last edited by Truman; 01-10-2009 at 14:11.

There's a difference between burning a disc and buying a replicated disc. You can only send 2048 bytes per sector to a burner. In a factory, the discs are not burned but rather replicated. More than 2048 bytes can be used during the mastering and replication process. Because of this and other things, replicated discs can have deliberate errors.

RM

I am sure you are right, i examined the dvd files w/ & w/o AnyDVD enabled. one of the files was showing fake size and many other fake VTSs also. I guess it makes sense aswell, if one would imagine a situation where the first sector the track2 falls between an ECC block of the track1(coz the TOC will indicate that there is more data on the track, while in reality it has ended) then the drive might start giving errors. I guess it can be acheived by little sector manipulation.

Not to sound Schizophrenic, I guess in that case only the first file should give errors while being copied individually, not the others if they are of the actual size. I am confused, I wonder if this guy is using some software coz what he has done would take lots of time and concentration to achieve manualy as you also have to keep the IFOs in mind.

*******
thanx for reply RM,
I understand that there is difference between replicated and burned DVDs and lots can be done at the glass mastering stage. The DVD i am refering to is a home burnt DVDR not a pressed one and that set me thinking how can this(bad sectors) acheived with a normal consumer DVD burner when one cannot access the whole 2064B of data or writing some data pattern that could trigger an EFM error. I am certaily not as learned as you are so im trying to collect information.

---

Last edited by rahul.dangi; 01-10-2009 at 21:03. Reason: Reply to the RM post

Sorry rahul.dangi, I completely overlooked the part of your post that described a DVD-R that you were having problems with.

I can think of one popular DVD copy protection (I'll just call it RG) that does not write 'bad sectors' during glass mastering. Instead they provide certain data patterns that when read back, can not be read without error. I'll try to explain.

Have you heard of Digital Sum Value (DSV)? Here is a link that tries to describe it:

http://www.music.psu.edu/Faculty%20P...C_Content.html


On a DVD, the transitions from a pit to a land or from a land to a pit indicate a change from a 0 to a 1 or from a 1 to a 0 (not respectively). If you have a bunch of long (in clock cycles) pits but only short lands then you develop a DC offset. In otherwords, the signal is ON more than it is OFF. The same is true for a bunch of long lands and only short pits where the signal is OFF more than it is ON. Ideally the signal will be ON and OFF for the same average amount of time keeping the DC offset (DSV) fairly constant.

The problem is that each byte of the 2048 bytes of user data must each be changed to a series of ON and OFF (pits and lands). Due to limitations in the DVD spec, it is possible to find user data patterns that will cause the DC offset (DSV) to climb high or fall low. This alone is not a problem. But, when the DSV has climbed real high or real low a new user data pattern can be recorded that will cause the complete opposite. If this change from high to low or low to high happens too rapidly, the read laser will lose focus. This will result in a read error.

Most of the above is true for CD as well.

To summarize, by providing a certain data pattern to the drive for burning you can, in the end, make certain sectors un-readable.

DVD video navigation can easily be authored to not even try to play such sectors. DVD-ROM (games etc...) can skip these as well. But, ripping tries to read every sector. Games can be designed to make sure that these certain sectors are unreadable before they will play. Video can be authored to do one thing if these un-readable sectors are bad but do something different if they are good.

I know the above is quite complicated but I hope you get the idea. I tried to explain things in terms that I can (almost) understand.

RM

I would also like to list the breakdown of a DVD sector of 2064 bytes.

Bytes 0-5 (ID/IEC)
Byte 0 contains info about this sector's layer, reflectivity, whether it belongs to program area/middle area/leadout etc...
Bytes 1-3 are the PSN (physical sector number) (layer 0 PSN user data starts at 0x030000).
Bytes 4-5 are IEC (ID error correction code for previous 4 bytes)

Bytes 6-11 (CPR-MAI)
These bytes hold the ETK (encrypted title key) if protected with CSS copy protection

Bytes 12-2059 (USER DATA)
These bytes contain the actual user data (movie, game, etc...)

Bytes 2060-2063 (EDC)
These bytes contain the EDC (error detection codes) for the previous bytes of the sector


An ECC block contains 16 of these 2064 byte sectors and then gets the PI/PO (parity inner/parity outer) error correction applied

When you read a sector from a DVD, the drive must read an ECC block (16 sectors) in order to give you the data you want for the one sector. If any of the other 15 sectors are bad, you will likely get a read error

The above are the basics and I tried to simplify them.


RM

Sorry to keep adding things... but, you can only send 2048 bytes per sector to the drive. The drive then takes 16 of those sectors and builds an ECC block by adding the PI and PO (parity data) (error correction codes) to them. You have absolutely no control over the PI/PO bytes so you can not make a sector (or ECC block) that is bad on the disc. You can only provide data (2048 bytes) that will cause errors when read back from the disc that you burn.

CD is the same way. You can only provide the burner with 2352 bytes per sector (2448 bytes if you want to provide the 96 bytes of subcode as well). The C1/C2 error correction is done by the drive. As with DVD you can not make a true bad sector on the actual disc. But you can put data on the disc that will confuse the CD reader during play back and cause an error. There are CD copy protections that use this technique.

RM

Thankyou, for the explanation and efforts girven. I read an article that almost uses the technique yuo have explained http://www.freepatentsonline.com/y2008/0127357.html

but as Truman suggested that the read errors were also generated if the TOC is modified i believe this is what the guy must be doing, 'coz i did find modified file sizes on the disc.

As I said in my prev post, I believe that with a little manipulation, a TOC might make the drive read through virtualy overlapping ECC blocks creating an error. for e.g. first sector tarckB falling the in a misrepresented ECC block of trackA. I have attached an image to show what in my understanding, could be happening when the drive reads as per the modified TOC.

Is is possible or am i just being whimsical?

I searched for more then 2 hrs but could not find a program that could help me modify a DVD TOC to check if this is possible.

Hi rahul.dangi,

I get confused on what you mean by TOC. For a CD the TOC means table of contents which is leadin. This shows where each track on the disc will start and is what CD Audio players use to find audio tracks. A DVD does not contain tracks and does not contain a TOC. It has only one track. It does have a leadin that describes the first sector and last sector of user data.

It seems to me you are referring to the UDF file system, which describes where individual files start and end. If this is the case then you need to find some software that will let you edit the file system pointers. This will let you modify the UDF file system so that no files 'overlap' and you can correct the actual size of the files present on the disc.

You could have a disc that says a file is 50GB (which is impossible for DVD) even though the file is only 10MB. If you know what you are doing you could modify the UDF to change the UDF pointers to correct this problem.

If you can not find software that will correct this problem, you can study the UDF specs and do it manually using a hex editor (if you can get an ISO/UDF, etc... image of the disc causing problems).

RM

Nice info Richman!

Hmm, I don't think it is to do with overlapping (In my opinion another impossible thing with consumer burners). Well I rented the DVD-R again and I think I can see the reason for that protection. It is definitely a single layer DVD-R, and on the burning side I can see that is it written just under halfway of the entire area - that means it should report as recorded under 2GB or so, but in ImgBurn the drive says it is recorded to 4GB. Nero also says the same thing, so it is not any software bug. It seems that the ripping tries to read the unrecorded area! Not only that, but as RichMan said, the ISO/UDF is taken advantage also, I cannot copy 2 .vob files using file explorer. I think those 2 files reference the unrecorded area.

I see, this could well be reason for you not being able to rip the DVD. I looked at my DVD again, but it has a valid 4.3 GB data although the explorer states that the DVD has 195GB data, which is obviously impossible.

I did some research and found that this is a kind of commercial DVD protection (fake VTS and extralarge TOC) called Xprotect which is generally found on german DVDs

Also when I examined the DVD with PGCEdit, I found that there are some fake cells in the PGC and cell commands have been used to skip these cells.

I think that he is using some bad sector trick right in middle of VOBs and this could be reason that I am not able to copy .VOBs from explorer aswell, who knows ?. What sill amazes me is the fact that this guy has been able to replicate a commercial DVD protection right from a home PC. 'Guess possibilities are endless when you know what you are doing. I would have to study the DVD and ISO/UDF structure deeply to nail this trick.