dvd replication problems

[redguy]

hi
i have authored a dvd9 with scenarist. it runs perfectly from the files in my computer. when i burn it (using nero) i have mixed results. it runs ok in 99% of the computers, but in very few standalone dvd players. in these devices, reproduction stops or the image garbles when i try to access one of the menus.
i thought it was something with the disc itself, so i sent it to the replication plant. they checked it and they saw it was ok. however, after they made the copies of the disc this problem continued to appear, even in the copies.
i checked time after time my authoring and it seems ok, it is pretty simple.

later, it was checked with eclipsesuite. it reported there was an error and explained that these kind of errors arise when the dvd-r is made from another master disc, instead of the files stored in the computer's hard drive. When a master disc is built there is some kind of addressing of data stored in a table, this data apparently is lost or invalid if the dvd is copied.

it is very strange, since i did make the master from the files on my computer. what could be wrong, aside from the coding?

[redguy]

i received another email from the plant, they say that the vts_nn_0.ifo are not at the addresses pointed by video_ts.ifo :confused:

i never had this kind of error. i burned the disc right after the flies were built, i didn't mess with them.

the question is: how could this error be avoided?
more important: how can i check this error for myself?
most important: how to correct it?

all my hope is set on you guys :scared:

[Cheesus]

Firstly I don't really why you are having these problems but I have some suggestions for things to try to hopefully remedy your situation.
Are you writing the image to DLT when sending it off for replication? I assume you must be as far as I am aware dual layer burnable discs are far from reliable. As is Nero for burning dual layer discs. You can use DVD decrypter to burn DL recordable discs, which is a lot better. Load the .dvd file into decrypter (or right click on it and there should be a 'burn with Decrypter' option) and burn.
If you are laying out to DLT, create all the sets of files in one go i.e DVD video files, image and then write to DLT all at the same time. I was told this is the most reliable way of completing this process by a very experienced guy, instead of splitting the process up.
If you have the very latest version of Scenarist (3.1) I believe it supports dual layer burners, although I haven't used it.
If you use IFO edit to look at your new and old ifo files you should be able to see if this error is continuing.
Good luck!

[redguy]

well, it seems there is actually an error with the ifo files.
after i posted these msgs, i checked them with ifoedit (well, i understand very little of this program, so 'check' is too large a word) and pressed the 'get vts' button; thus ifoedit found and corrected some inconsistencies among the ifo files.
the replication plant told me this kind of error appears when a dvd is reauthored, and the tables are not corrected.
damn! i am authoring, not reauthoring, i don't know how this error could have happened, it seems scenarist screwed up the files, so next time i author anything i will have to double-triple-...-check it with ifoedit...

@cheesus
thank you man, i will take your advices ;) . as for the dlt tapes, they say at the plant they prefer dvd-dl because they cannot check the dvd when it is on tape.

so i'll burn another one and post the results :angry:

[redguy]

oh, and another thing
how can it be possible that this dvd can be played well in computers and not in standalone players? this beats me

[mpucoder]

oh, and another thing
how can it be possible that this dvd can be played well in computers and not in standalone players? this beats me
This question has come up many times in the past - computers and DVD players access the data differently. Mainly PCs use the file system and ignore the sector pointers in the ifo, while DVD players do the opposite.

[redguy]

ok, so...
i wonder if there's any pc-based player that can replicate the way standalone players work

[DaRat]

You might want to get a H+ mpeg card (sells for like $20 on ebay) it pretty much emulates standalone behaviour, tough I'm not really sure if it access the disc via the sector-method, but it spotted quite a few errors for me so far.

Also for your problem, before the final build you should clean the muxdir, there might be some stuff that screws up builds, happened to me once or twice.

[redguy]

hmm, cleaning the muxdir... interest thing, it has sense, never came to me
maybe that's the cause :sly:

ok thanks daRat!!!! :) :thanks:

[redguy]

it is a bit weird, now i check every project i do in scenarist with ifoedit and it seems ifoedit has always something to correct when i push the 'get vts' button (even the simplest projects). is this normal?

[mpucoder]

Yes, because IfoEdit and Scenarist allocate space differently. Scenarist uses the recommended 32K gap between VIDEO_TS.IFO and VIDEO_TS.BUP when VIDEO_TS.VOB is less than 32K or absent. PGCEdit is a better tool to check the allocation.

[redguy]

thanks for the reply.
this is surely an over-simplistic conclusion but judging the result, the way ifoedit allocates space works and the way scenarist allocates space doesn´t. at least to me.
i have corrected the tables using ifoedit, burned the dvd9 and it seems to work on standalone players on the very parts the old version failed...

btw mpucoder, where can i learn about this
Yes, because IfoEdit and Scenarist allocate space differently. Scenarist uses the recommended 32K gap between VIDEO_TS.IFO and VIDEO_TS.BUP when VIDEO_TS.VOB is less than 32K or absent. PGCEdit is a better tool to check the allocation.

damn, there´s too much i don´t know :p

[mpucoder]

IfoEdit may well be correcting an error, but due to the different allocation schemes it can also make changes that are not necessary or indicative of any problem.
There is a long thread about the 32K gap in the ifo/vob editors section.

[easy2Bcheesy]

For what it's worth, I've successfully mastered using DVD+R DL. Although recording image files to DLT tape seems to be the standard way of mastering a dual layer project I always feel uneasy about sending away a master that I cannot test on a consumer DVD player. I prefer to be able to test the actual disk on a player before it is duplicated - call it peace of mind.

As dual layer production requires creating expensive glass masters, any errors can prove to be rather costly as I suspect the OP has discovered.

[Cheesus]

Why wouldn't you create a test DVD+R DL to test on a consumer DVD player and then output to DLT when you're happy with it?
DLT is a far more reliable method of converying bit for bit accuracy than a burnt DVD+R DL (or any burnt DVD). Not that I am trying to bad mouth your methods. I just would've thought, for peace of mind, a DLT is a better option and you can test the image beforehand. And peace of mind is all important with DVD production because, as you say,you don't want to be hit with a massive scary bill.

[mpucoder]

DLT is a far more reliable method of converying bit for bit accuracy than a burnt DVD+R DL (or any burnt DVD).
This sounds like the start of a new urban myth, that the soft errors present in writable DVD's, and reported by several scanning programs, affects the recovered data. It does not. All recording devices have soft errors, and all recording devices have methods of recovering the data. It is the hard (unrecoverable) error rate you need to worry about. DVD has a much lower unrecoverable error rate than DLT, even lower than CD, and almost as low as hard drives.

[Cheesus]

So a DVD is more reliable for recovering data than a DLT?

[mpucoder]

I would think so. Magnetic vs optical for one (ever wrinkle a tape or get it near a motor?). And DVD has several layers of error detection and correction. There's a good section on the subject in DVD Demystified.

[Cheesus]

OK, no system is perfect, I just assumed a tape format would be safer, all round. A DLT certainly looks more robust than a DVD. I am surprised that DVD has superior error correction than a DLT. So why is DLT the de facto way of supplying images to duplicating houses?
I've come across tape creases on domestic and professional video formats but with professional systems it's so occasional to be almost irrelevent. I've never come across it on DLT, although I'm sure it happens. Using verification would show this up though anyway. Plus DLT's are used to backup computer and network systems all the time, so they would have to be very solid format to be responsible for these types of operation. I've heard that DVD's are also used for backing up systems but got the impression again that DLT is the de facto system.
I do know that you can scratch a DVD very easily (which may or may not cause error correction to fail), get rogue stock, problems that wouldn't effect a DLT.
Hope I don't come across as spoiling for an argument, I'm just very intrigued and interested by this issue (and I don't want to be responsible for starting a new urban myth ;) ).

[int 21h]

DLT was chosen because of its ability to handle large files, transfer the files in a relatively short amount of time, and its ability to handle CSS. Since there are relatively few DVD drives that will write CSS (none will write to DVD-R General discs, although some, like the DVR-S201 will write CSS to DVD-R Author type discs), that throws a kink into sending most movie content to a replicator.

I know of many plants that are accepting DVD recordable content now as well, but the majority of work coming out of production houses is still DLT primarily because of the CSS issue. Lots and lots of PC content is sent via DVDs though.

[mpucoder]

Besides what Int 21 said, DLT was there before the first stamped DVD. You have to use something to begin the industry.
Because DVD is an exposed media likely to be handled carelessly the designers went to great lengths to provide a very robust error recovery system.
But what prompted my remark was the growing interest in the error rates of recordable DVDs in many other threads, not just this one. And these error rates certainly are worth noting as far as manufacturing quality goes, but very seldom cause data corruption. One post even suggested that the video quality didn't suffer due to mpeg's resilience, when in reality it is the error recovery of the DVD that turns all those soft errors into good data.

edit: Just a somewhat silly side note - DVD's will survive an EMP. Don't try that with hard drives, DLT, or even IC's.

[Cheesus]

Thankyou guys. I'm assuming there will never be a dual layer burnable DVD format that supports CSS like DVD-R for Authoring, so DLT's are here to stay. I wonder if the new HD DVD formats are taking a different road?

[DaRat]

IMHO the new road will be the FTP road (aka PlantDirect), its just so fast and convenient. Make the tape image and you're done, in about 20 mins the replication plant has your stuff (assuming dvd9, 100mbit on both ends fully used) and that's just unbeatable. You cut the cost of the dlt, the cost of the courrier (ok, network's cost is a bit higher than usual :D) and most importantly you can save days in the process and that's priceless sometimes.

On the dlt vs dvd issue: dlt is slooooooooow but we never got back any with problems with the master, on the other hand we had 2 faulty dvd-r masters.. :-/ To make really sure just rar your stuff into pieces (say, 20 megs or so) and pray that the staff in the plant can handle rar's.. (no kidding, we had a disc waiting for like 4 days before they got someone who could click-and-click because their usual dude was on vacation.. unbeliveable)

[dvdboy]

Well listening to the Sonic guys at IBC, Scenarist4HD currently supports DDP3.0 and you have the option to create an image file, send to the plant via network, or span your DDP Image across multiple discs - no mention of tape.