On Fri, 2005-12-30 at 09:15 +0100, Svante Signell wrote: > You are probably right. I did try to burn a 4.4GB image with dvdrecord > to a DVD-R with a corrupt disk as result.
Again, 4.7GB = 4.35GiB. You probably ran out of room if it's 4.4GiB (which most OS/utilities report as 4.4GB, but GB = 2^30, not 10^9). > DRV+R does not work, right? Understand there is more than just the formats. DVD Consortium (Pioneer, Matsushita, Toshiba, etc...) firmware designs are different than DVD+RW Consortium (Sony, Philips, HP, etc...). It's a very, very long and drawn out story. Although most DVD Consortium drives also do DVD+R/RW today, and most DVD +RW drives do DVD-R/RW today, the firmware/command sets are _different_. CDRecord was designed around the existing, "byte-by-byte" (character) record mechanism, which DVDRecord (CDRecord 1.x), CDRecord-ProDVD (CDRecord 2.0) and CDRecord+DVDpatch (CDRecord 2.0) are all based on. CD-R can work that way. DVD-R can work that way. DVD+R can_not_. Now Jorg has added limited block writing to CDRecord-ProDVD as of 2.0. This is DVD+R/+RW drive support for _only_ when using DVD-R (and "record" emulated DVD-RW) media. With 2.0a11, he has added experimental support for DVD+R (and DVD+RW) on Ricoh firmware DVD+R/RW drives. Pretty much _all_ drives today are supported with block writing at the kernel level. CDRecord design is not designed for such. I'd really have to go back into the history of CD/DVD drives, as well as the Linux kernel development. Long story short, until about 2003/2004, most "player" devices didn't have the "brains" to read arbitrary media formats, track/sessions and filesystems. And prior to about 1999, most recorder devices didn't either. Once block write (again, circa 1999+) and player block reading/media virtualization (again, circa 2003+) became commonplace, then block writes could be done, and read by players. I still prefer CDRecord in Disc-at-Once (DaO) or Session-at-Once (SaO) modes, with burnproof _off_, with CD-R and DVD-R because it produces the most universally compatible and longest lasting recordings. But I agree, for common use, it's overkill as of 2004+. > I've seen on the web that some burners don't work well in placed on a > slave position. ATA DMA modes were _never_ designed to have more than 1 device on a channel. The master/slave design is a legacy EIDE approach that ATA drives only support for backward compatibility. Unless both devices are in PIO mode, expect to have DMA performance and other compatibility issues -- especially if they are not the exact same vendor, let alone model sometimes. > Furthermore, the image I tried to write was on the same > IDE drive. Obviously problems can occur with DMA transfers, reducing the > speed greatly. In any case, the resulting DVD-image should not be > corrupt, would it? Yes, it can be if there is a bus timeout -- which exponentially increases if you have 2 different ATA DMA devices on the same bus. > On the problematic burner, I even tried an audio CD. > The result was that the CD was unplayable, extreme lagging, multiple > songs at once, etc. The burner has now been returned, using the two year > warranty from MSI. Recording to CD-RW or DVD-RW in emulated CD-R or DVD-R modes, respectively, can reduce both recorder and player lifetime. And don't get me started on using standard CLV CD-RW media in Sony/Philips CAV CD-RW (what I retroactively call CD+RW ;-). I've seen people utterly destroy their drives in no time doing such. At least with DVD-RW and DVD+RW, you _know_ they are CLV and CLV-Z, respectively. With CD-RW, you can really cause some damage if you use CLV media in a CAV mode. -- Bryan J. Smith mailto:[EMAIL PROTECTED] http://thebs413.blogspot.com ------------------------------------------ Some things (or athletes) money can't buy. For everything else there's "ManningCard." _______________________________________________ Dvdrtools-users mailing list Dvdrtools-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/dvdrtools-users
