[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Burning a Windows / DVD player compatible DVD


I'm really struggling with this whole compatible DVD thing.

For my amateur dramatics group, I have produced a DVD of our show,
including menus and all sorts of fun like that.  The DVD plays
perfectly with "xine dvd://video/dvd".

I have burned the DVD in many different ways, such as "growisofs
-dvd-compat -dvd-video -Z /dev/scd1 ." and most of the ways I burn it
will work perfectly on my panasonic DVD player.

However, when I distributed these DVD's to other people, I have
received reports that they don't work on Windows machines (they
apparently show up as a blank DVD), Mac's (similar I guess - but no
detail on that) or some DVD drives (which just refuse to read them).

I believe the DVD that was written that works on Linux and my DVD
player is using the UDF file system, but several real DVD's I have use

Well, if a disk gets mounted as iso9600, it doesn't mean that there is no UDF directory structure. What you're likely to see it bridge-formatted disk containing both ISO9600 and UDF directory structures, and ISO9600 gets mounted by default. For reference, mkisofs -dvd-video produces layouts just like that.

I tried burning it with iso9660 (actually using gnomebaker)
and that fails to play on my DVD player, but it is recognised and can
be played by a windows computer.

Right, real DVD players can and some actually do refuse to play ISO9660-only media. While Windows can simply not care about file system, it sees just a bunch of media files to be played.

What you're more likely to suffer from is incompatibility at media format level (see below), not file system or video content.

I'm currently using DVD-R disks, which I understood to be more likely
compatible with DVD players  (although I may have that wrong because
http://fy.chalmers.se/~appro/linux/DVD+RW/ suggests that DVD+R disks
are more compatible).

It doesn't really say it. It discusses DVD+ format merits, it discusses how to improve compatibility of recordings, but the choice is left to individual reader.

In case it is useful, I have pasted the output of dvd+rw-mediainfo for
one of the burned DVD's at http://pastebin.com/m7479a9c

For future I'd insist on including dvd+rw-mediainfo directly in message (as well as versioning information and even output produced during recording). On provided URL one can find:

INQUIRY:                [LITE-ON ][DVDRW LDW-451S  ][GSB6]
 Mounted Media:         11h, DVD-R Sequential
 Last border-out at:    2045*2KB=4188160
 Track Size:            2247216*2KB
READ CAPACITY:          2247216*2048=4602298368

For -dvd-compat/-video recording "last border-out," "track size" and "capacity" would normally be the same. Inconsistently low "last border-out" value is known to confuse some players rendering such media unplayable in this players. Question is why is it low? I used to account it to media defects in lead-in area. At least if advised to try different media or media brand in such situation, other users seem to confirm that failure is not reproducible. However! As I realize now they all reported value of 2045... Common media fault? Hardly... Common firmware deficiency? Can be... Common usage pattern, such as interference with auto-mounting facility? Can be... At least it's least likely recording program's fault, because last border-out position is pure firmware domain, i.e. recording program has nothing to say about it (not to mention that it's generally known to come out right, i.e. equal to last written block + 1).

Could anyone suggest how I should be burning these DVD's to ensure
they are compatible with both windows and more DVD players?

If you want to try DVD+R, then do make sure that you instruct your unit to burn it with so called DVD-ROM book-type with 'dvd+rw-booktype -dvd-rom -unit+r /dev/dvd'. Lite-on should allow you to do that. As for DVD-R. There was a case of malformed border-out position mentioned in http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html, look for BTC. If your firmware can't correctly handle incremental recording, then -use-the-force-luke=dao might be solution even for you. A.

Reply to: