Snip out some bad sectors from a vob

[ukb008]

Hi

I just bought a few old DVDs in discount. They're mostly ok, but a few show read errors in my computer. Nero, of course, wouldn't copy those DVDs. I put one thru an old Decrypter, and it shows, for the first vob of the movie-title: 'Failed to read Sector 301904 - No Seek Complete' ... and it's still going on, through Sector 310451. Other files have been decrypted nicely, indicationg their readability.

MY impulse is to stop at the point where the file begins to become unreadable, and blindly go a little forward in the file and resume ripping. Of course, my old Decrypter doesn't have any such facility. That is just what I did with my VCDs with VCDCutter. The VCDCutter gives a review window and a sliding control to place cut-points.

ChopperXP allows something like that for vobs, but I don't know how to use the resulting two vobs with the other vobs in my DVD-movie with my current ifo. And I suspect Nero wouldn't want to have anything to do with a home-doctored vob such as ChopperXP would produce. Once I had used ChopperXP to exclude a few seconds of the beginning credits of a movie, and fed the vobs to Nero Recode, and Nero promptly declared 'Analysis of DVD-Movie failed'.

Can you PROs please throw some pointers as to what I should do about a few thousand bad sectors in the middle of a vob?

Regards.

[kumi]

I had that problem with an old copy of a DVD, the main movie PGC had a couple thousand bad sectors. I set DVD Decrypter to "ignore read errors" (Tools | Settings | I/O) and got a working rip, playable on 2 standalones.

...actually this was after processing the rip through FixVTS, and remultiplexing the main movie in MuxMan, for safety's-sake.

[setarip_old]

@ukb008

Hi!
You have, of course, first tried cleaning the DVDs, haven't you?

You might find the information in the following thread useful:

http://forum.doom9.org/showthread.php?t=114815

[ukb008]

Hi. kumi

I set DVD Decrypter to "ignore read errors" (Tools | Settings | I/O) and got a working rip

Yes, I did exactly that; it is now into its third hour of ripping. Let's see how much it can do overnight.

Hi, setarip_old

Yes indeed, I did clean the surface. Thanks for the link to IsoPuzzle 1.2. I'll try that and see.

By the way, if we knew the cells corresponding to those bad sectors, then we could rip the files without them in SmartRipper, couldn't we? How does one relate cells and sectors?

Regards.

[setarip_old]

I set DVD Decrypter to "ignore read errors" (Tools | Settings | I/O) and got a working rip
Yes, I did exactly that; it is now into its third hour of ripping. Let's see how much it can do overnight.To save time, you should also set DVD Decrypter to -0- retries for read errors ;>} (Using SmartRipper shouldn't be any faster)

[ukb008]

Yes, -0- retries for read errors it is. Decrypter running overnight, 13673 errors and still going, recovery percentage is 50% now, rising from 48% last night.

This 3% of a 1-GB vob that has been recovered painfully - I have a hunch the video will be distorted, jerky, snappy and generally quite unwatchable. But I am hoping to cross the bad areas, hit the good patch beyond, and finish the file. Question is, what do I do about those 30/40 bad MBs ? How do I get rid of them and redo my DVD?

Regards.

[setarip_old]

How do I get rid of them and redo my DVD?You can't get rid of them. They will exist as blank sectors that certainly may result in an unwatchable video. That's why I provided you with the link to the thread about "IsoPuzzle 1.2, which attempts to recover the actual data in those sectors.

Have you tried it yet?

[r0lZ]

Hum, it should be possible to cut the damaged part with VobBlanker. However, I'm not sure VB will accept the corrupted VOB file.

[blutach]

There is a possible way. Find out which sectors are corrupted and build a PSL file. Rip with DVD Decrypter, which will insert dummy sectors.

The output may look crappy (and it might take a while to determine which LBAs are bad - and of course there is no guarantee the good ones will stay good), but if this process completes, you'll have a compliant DVD.

Regards

[r0lZ]

IMO, even w/o PSL, DVD Decrypter replaces the damaged sectors by null ones. It takes longer, but the result should be identical.

Anyway, you will probably have to cut the damaged parts, as the null sectors inserted by DVD Decrypter are not valid. They don't hurt in never played cells (like in ARccOS protection), but here the video is played.
Maybe FixVTS is sufficient to replace the illegal null sectors by legal stuffing packs, but again I'm not sure.

[kumi]

Here's what I did:

Source: DVD w/ bad sectors (amounting to about 20 short video glitches interspersed throughout the main movie)
Rip w/ DVD Decrypter in File Mode, ignore read errors.
Process files w/ FixVTS.
Demultiplex the problem PGC w/ PgcDemux.
Remultiplex the assets w/ MuxMan.
Replace old PGC w/ VobBlanker.

I half-expected MuxMan to complain, but everything went smoothly... go figure.

[r0lZ]

And the glitches are magically repaired, with no A/V synchronization problem?

[kumi]

In my case, although the glitches remain (obviously), A/V sync is preserved throughout the entire movie.

That's what I meant by "everything went smoothly" ;)

[ukb008]

Hi, setarip_old

you wrote:

You can't get rid of them (i.e., the bad sectors). They will exist as blank sectors that certainly may result in an unwatchable video. That's why I provided you with the link to the thread about "IsoPuzzle 1.2, which attempts to recover the actual data in those sectors.

Have you tried it yet?

Yes, I have. I have finished my rip, both in the now-extinct Decrypter and in IsoPuzzle 1.2. IsoPuzzle provided an ISO file of the DVD, from which I extracted my offending vob with IsoBuster. I attempted to play the files in BSPlayer, vlcPlayer and PowerDVD. Here are the results:

Decrypter-extraction:

1. BSPlayer - freeze-frame at timestamp 00:11:34, a mixed half-half frame in between, and another quick full-frame, finally resuming play at 00:11:37, audio synch maintained. I am pleased - only 3 seconds lost. Then I remember that Decrypter failed to read sector 301904 through 329888 - and it went through them in nearly 16 hours.

2. vlcPlayer - bad spell started at 0:06:33 (same frame as in BSPlayer before - note the widely different timestamp - maybe vlc's slider-control can't synchronize with the time-display?) - bad spell continued till 0:07:20 through severely pixalated garbled display in which a scene of the hero shooting someone could be sensed. When the video stabilized finally, it was at the same frame that BSPlayer also steadied. By vlc's own timestamps, the interim period was 47 seconds.

3. PowerDVD - Bad spell started at 00:11:20, went through a number of spliced & mixed frames (around 10) and stabilized at 00:12:18 - the shootout was much clearer than vlc but nowhere near reasonably comprehensible. Movie played on without loss of synch. Bad spell was 57 seconds.

IsoPuzzle 1.2-extraction:

1. BSPlayer - video stops at the first bad frame at 00:11:19 and don't start. Audio, however switches from next frame to what's there in the first good frame after the bad spell. Audio plays on, but video does not play.

2. vlcPlayer - same timestamps as in case of the other file in the same player above, but freeze-frames and pixalations continue longer. No resulting audio asynch. It took longer to resume normal play.

3. PowerDVD - shows four bad frames starting at 00:11:20 and ending at 00:11:57 and smartly goes on to the good spell and continue. Bad spell period: 37 seconds.

I conclude from all this:

1. I don't know the duration of bad video
2. I have a fair guess as to when the bad spell starts, but not when it ends.
3. Although there's yet insufficient evidence to Dump the old Decrypter in favor of IsoPuzzle 1.2, still it is an option worthwhile to remember.
4. Data that were lost by corruption are truly lost forever in that particular DVD of mine. There's no way I can get that back.

Thank you, and regards.

[setarip_old]

Attempting to salvage a severely damaged DVD is always quite challenging - but a positive learning experience as well ;>}

[kumi]

http://pioneer.jp/crdl/tech/dvd/4-4-e.html :

"a VOBU is not required to contain any data other than the NV_PCK."

Reading that makes me wonder if there's a way to rip a DVD using "smart" padding of bad sectors (in .VOB files)... i.e. creating dummy VOBUs containing just navigational packs. Instead of "dumb" padding with 0s.

[r0lZ]

I don't think so, as a VOBU must have a minimum duration of about 1/2 second. If you use too many nav packs to pad the bad sectors, you will lengthen the cell duration too much.
But there are also valid padding packs (or stuffing packs), which can be used without problems to fill the gaps between the standard nav packs. They will be simply ignored by the player.

[ukb008]

...a VOBU must have a minimum duration of about 1/2 second. If you use too many nav packs to pad the bad sectors, you will lengthen the cell duration too much.
But there are also valid padding packs (or stuffing packs), which can be used without problems to fill the gaps between the standard nav packs. They will be simply ignored by the player.

Perhaps you may care to explain in somewhat more details the portion of your quote in Times New Roman?

Regards.

[r0lZ]

Difficult! I don't know exactly what they are, but I know that they exist.
The problem with the dummy (null) sectors inserted by DVD Decrypter when it encounters a read error is that they are filled with null bytes, including their headers. That's illegal. Most soft players will simply ignore them, but a standalone player may hang.
In the other hand, the stuffing packs are also null sectors, but with a correct header, exactly like for any other stream. The ID is different of the video, audio or subpic streams, of course. Therefore, the players will treat them as a stream they don't need, and skip them.
Of course, replacing the null sectors by stuffing packs is probably not enough to fix all problems, as the nav packs (which are essential for a correct navigation) will still be missing. So, IMO, the correct way to repair a damaged VOB file is to rebuild the nav packs chain, and to fill the remaining null packs with stuffing packs.
I'm sure jeanl, jsoto or mpucoder can elaborate. I'm not a specialist of VOBs and multiplexing.

[ukb008]

Great. Provides a glimmer of hope. I wonder how, for a damaged vob-file, one can rebuild the nav packs chain, and fill the remaining null packs with stuffing packs? I mean what procedures one can adopt and whether there are softwares available for the purpose, that sort of thing. I imagine a program that can cogently deal with a damaged vob without too much pain will be really appreciated by many.

Regards.

[kumi]

I've always operated under the blind assumption that a combined demux/remux operation will "smooth" out invalid packs. It'd be great if one of the experts would chime in on whether this is a valid approach, or just plain useless ;)

[r0lZ]

ukb008, IMO, FixVTS is a good starting point. If I an right, it can replace the null packs with stuffing packs. But it will not rebuild the nav packs, as it is extremely difficult to guess what should be make.

Currently, IMO, the best solution is to cut the damaged part with VobBlanker.

@kumi: I really don't know. But if something is really odd in the original streams, a good muxer should at least warn you.

[jsoto]

Currently, VobBlanker (in keep mode) ignore and skip the null packs, so the output VOB will not have any null pack.

I can easily change the code to output a padding pack instead of skipping the null ones, but to reconstruct the navs is not so easy... I can know where the first one should be (looking the VOBU lenght in the last nav) but you cannot know how many navs you need to recreate... may be in a second pass...

In any case a VOB with a group of padding packs probably will work fine, if the first pack after the padding ones is a nav again.

So, the patch could be:
- Read the input VOBU pack by pack
- Keep in memory how long has to be the current VOBU
- Fill with padding packs up the the end of the current VOBU if a null pack appears.
- Do not output any additional pack until a new nav
- In a second pass, fix the pointers and also fix the elapsed time along all the navs

I think I could add this to VobBlanker...

jsoto.

EDIT: Mmmm, PTSs and SCRs will have a discontinuity after this...May be it wion't work fine

[BigCondor]

Have you tried to join the two vobs cut by chopperxp with vobmerge and replace the original one? I had tried it before and fix it with FixVTS afterwards and it works.

[jsoto]

I've always operated under the blind assumption that a combined demux/remux operation will "smooth" out invalid packs. It'd be great if one of the experts would chime in on whether this is a valid approach, or just plain useless ;)
A mux/remux probably will take out the bad packs, but:
a) the demuxed tracks will have a brute cut in the middle (one pack does not contain an exact number of frames, except in LPCM and also DTS). So the demuxed video track and the Dolby digital audio will be "corrupted" . Audio track can be fixed with a tool (like delaycut or BeSweet). About Video, I really do not know.
b) Because you'll lose an indeterminated number of packs, the audio/video synchronization will be lost (however the difference should be minimum, not detectable) . If you do not demux the VOB, the audio/video delay relation is still in the PTSs, so it can be (theoreticaly) recovered by the player.

So, to have a "perfect" cut you should split the cell into two cells and make the join non-seamless.

jsoto