Re: DVD+RW/+R for Linux update
On Monday 04 November 2002 13:49, Frank Hage wrote: On 2002.11.04, Joerg Schilling wrote: : But DVD-* media is cheaper and I see no advantage in using DVD+ media. One advantage I find is the ability to burn directly from NFS mounted partitions. It's slow but it works well. I've got gobs and gobs of data spread across many machines, many filled to capacity. It takes me less time and a lot less work to cross mount our aging workstations and burn directly than it does to copy and create iso files, and then burn. I thought burnfree was supported on DVD, assuming that the drive supports it of course. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From [EMAIL PROTECTED] Fri Nov 8 15:52:46 2002 High frequency wobbling does not help to make the DVD recording better in case of buffer underruns. You always use the pre-groove only to find the course place where to resume recording. The exact position is found by reading the already recorded data and switching from read to write. Well, explain following then. I can take *virgin* DVD+RW media, partially format it so that only lead-in gets written out as well as probably a small tail after it gets de-iced. This takes ~40 seconds. Then I can immediately seek to say 4GB, write some data and immediately eject the media. Another 10-20-30 seconds passed depending on how much I've chosen to write. I can flip the disc and note that media between lead-in and written data remained *virgin*. Now if exact positioning could be determined only by playing earlier written data how come it went so fast and surface in between remained virgin? If it weren't accurate enough how can they guarantee that I'll be able to squeeze 4GB in between lead-in and data written at 4GB offset? This seems to be contradicting the official developer information for the DVD+RW drives. It includes a state diagram that states that you need to detect an interrupted de-ice and continue it before the media becomes usable. On the other side: Pioneer introduced background formatting for DVD-RW about 2 weeks ago. Let us wait if there is a difference when the A05 is available. Call it ho you like, it _is_ some kind of packet writing. Well, yet the fact is that whatever we call it, the result is *indistinguishable* from whatever that might appear as TAO/SAO/DAO. If you did format a DVD-RW, then you have the same behavior as with DVD+RW. The fact that you may distinguish this from other write modes by looking at the media parameters, does not make it worse than DVD+RW. DVD+RW just does not support the other write modes. MMC specifications mention link data in DVD-R[W] context as well as border-in/-out in DVD-R incremental recording context. Does either hold true? If yes, what's role of border-in/-out? Most importantly. Is explicit support by DSP [performing the actual decoding of user data] required for playback of DVD-R[W] recorded in packet mode? I have to ask Pioneer. I have not yet been able to write a DVD-R in packet mode but the MntFuji mailing list tells me that it should work. Then I fail to understand why did you bring up packet writing at all? cdrecord[-ProDVD] doesn't support it so that those willing to perform say live NFS backups have to solely rely on buffer underrun protection, don't they? Is there reason to believe that recovery is so much more accurate than in CD [where it's off by default] that you're ready to bet your backup on it? Because it is the only write method that is supported by DVD+RW. Cdrecord-ProDVD will support multi border DVD-R writing if this is possible. What I currently know to do does not makes to be integrated into cdrecord-ProDVD because it does not help the users. As already mentioned. DVD+RW supports write of randomly addressed 2KB blocks even to *virgin* media (well, when you write 2KB, 32KB gets naturally written/de-iced], and naturally rewrite in random order at later occasion. Randomly written DVD+RW disc is *indistinguishable* from one written progressively/streamed. DVD+R media can be written ... because the drive does not support other write modes. progressively in 32KB ECC blocks, *but* uninterrupted streaming is not a requirement [you can even eject media between writes]. DVD+R media written progressively with interrupts is *indistinguishable* from one written streamed/in one single take. All this thanks to high [spatial] frequency wobbled [pre-]groove with addressing information modulated into it. As there is no good information from either DVD group, we may only guess :-( Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
On Sun, Nov 10, 2002 at 04:49:55PM +0100, Andy Polyakov wrote: The page in question was updated with following two paragraphs: Updated write-up is online and reads now as following: Snip Again. Even if DVD+RW is superior. What does it REALLY buy you? Excluding the 0.01% of the person that can actually use some or all of the benefits. There are 99.99% of the people that don't care and/or don't need such benefits. To take myself. I burn for about 6 years now. I have NEVER used CD-RW (Actually the DVD-Burner is my first burner that supports CD-RW and i would NEVER use my DVD burner to burn CD-R(W)) and i have NEVER used multisession or things like that (This includes packetwriting which is only other way to gain the (same/similar) effect that you can get with multisession). And i don't know any person in my surrounding that uses/needs such a feature. To say it simple: The price-tag and/or the availability will settle the DVD(+/-)R(W) war. (Or all manufractory will make drives like the announced drive from sony, that supports both formats. Then the price-tag of the media will settle the war) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From: Matthias Schniedermeyer [EMAIL PROTECTED] A few month ago i even read an articel in our Linux Magazin about the 2GB Barrier (The Topic was DVD-Recording). I felt like beeing warped back into the stoneage. :-) Well, this is Linux :-( Most OS did support large files in 1995. Linux ignored it for many years. OTOS, As MAC (OS X) systems do not support large files, DVD-video does not use files 2 GB and splits into smaller peeces. But back to the original problem: the 2 GB barrier never has been a problem for DVD writing via cdrecord+mkisofs. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From: Andy Polyakov [EMAIL PROTECTED] The write speed does not matter if you use BUrnProof or packet writing. Of course DVD+RW _only_ supports packet writing... The page in question was updated with following two paragraphs: What does plus stand for in DVD+RW/+R? The key feature of DVD+RW/+R media is high [spatial] frequency wobbled [pre-]groove with addressing information modulated into it. This makes it possible to resume interrupted [or delibirately suspended] burning process with accuracy high enough for DVD[-ROM] player not to notice anything at playback time. Recovery from buffer underrun condition in DVD-RW/-R case in turn is way less accurate procedure, and the problem is that the provided accuracy is very much what average player can tolerate. Now given that both provided and tolerated inaccuracies are proportional to respectively writing and reading velocities there basically no guarantee that DVD-RW/-R recording that suffered from buffer underrun will be universally playable. This is not correct. High frequency wobbling does not help to make the DVD recording better in case of buffer underruns. You always use the pre-groove only to find the course place where to resume recording. The exact position is found by reading the already recorded data and switching from read to write. It is not possible to get the needed precision only from information in the pree-goove. Fazit: a typical DVD+ marketing phrase :-( Sometimes DVD+RW/+R is erroneously compared with packet writing. Packet writing means that every chunk of actual user data gets surrounded by so called link, run-in and run-out sectors, which wastes some capacity, not to mention that it requires explicit support by player's DSP [Digital Signal Processor] performing the actual decoding of user data. Again thanks to high frequency wobble, no such things are needed for DVD+RW/+R. This is exactly why it's commonly referred to as designed from scratch for maximum compatibility with DVD-ROM specification. Call it ho you like, it _is_ some kind of packet writing. Of course, there is no run-in/run-out blocks as the DVD uses a different scheme for cross interleaved error correction. A real DVD sector is 32k. If you call this a packet, then you are excatly were we are with CD packet writing (except for the run-in/run-out blocks gaps). On A CD, there are two different types of packet writing: - write packets to a blank disk (no overwrite possible) - write random addressed packets to a pre-formatted disk (overwrite works). DVD- supports both modes, DVD+ only supports the second mode. In addition, DVD- supports a streamed de-facto uninterrupted write called SAO (Session At Once). Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
The only reason I'm answering is that I have reasons to believe that I indeed failed to find up-to-date or accurate enough information about DVD- formats. The only specification *publicly* available is 3.95GB DVD-R ECMA specification which describes certain Linking scheme that applies in Incremental Recording mode (a.k.a. packet writing, right?). Is this scheme applicable even to 4.7GB DVD-R and/or DVD-RW? The write speed does not matter if you use BUrnProof or packet writing. Of course DVD+RW _only_ supports packet writing... The page in question was updated with following two paragraphs: What does plus stand for in DVD+RW/+R? The key feature of DVD+RW/+R media is high [spatial] frequency wobbled [pre-]groove with addressing information modulated into it. This makes it possible to resume interrupted [or delibirately suspended] burning process with accuracy high enough for DVD[-ROM] player not to notice anything at playback time. Recovery from buffer underrun condition in DVD-RW/-R case in turn is way less accurate procedure, and the problem is that the provided accuracy is very much what average player can tolerate. Now given that both provided and tolerated inaccuracies are proportional to respectively writing and reading velocities there basically no guarantee that DVD-RW/-R recording that suffered from buffer underrun will be universally playable. This is not correct. High frequency wobbling does not help to make the DVD recording better in case of buffer underruns. You always use the pre-groove only to find the course place where to resume recording. The exact position is found by reading the already recorded data and switching from read to write. Well, explain following then. I can take *virgin* DVD+RW media, partially format it so that only lead-in gets written out as well as probably a small tail after it gets de-iced. This takes ~40 seconds. Then I can immediately seek to say 4GB, write some data and immediately eject the media. Another 10-20-30 seconds passed depending on how much I've chosen to write. I can flip the disc and note that media between lead-in and written data remained *virgin*. Now if exact positioning could be determined only by playing earlier written data how come it went so fast and surface in between remained virgin? If it weren't accurate enough how can they guarantee that I'll be able to squeeze 4GB in between lead-in and data written at 4GB offset? Sometimes DVD+RW/+R is erroneously compared with packet writing. Packet writing means that every chunk of actual user data gets surrounded by so called link, run-in and run-out sectors, which wastes some capacity, not to mention that it requires explicit support by player's DSP [Digital Signal Processor] performing the actual decoding of user data. Again thanks to high frequency wobble, no such things are needed for DVD+RW/+R. This is exactly why it's commonly referred to as designed from scratch for maximum compatibility with DVD-ROM specification. Call it ho you like, it _is_ some kind of packet writing. Well, yet the fact is that whatever we call it, the result is *indistinguishable* from whatever that might appear as TAO/SAO/DAO. Of course, there is no run-in/run-out blocks as the DVD uses a different scheme for cross interleaved error correction. Yes, I have to admit that I'm apparently wrong about these run-in/run-outs [they do belong in CD recording] and will correct the page as soon as I get clear picture of DVD-R[W]. MMC specifications mention link data in DVD-R[W] context as well as border-in/-out in DVD-R incremental recording context. Does either hold true? If yes, what's role of border-in/-out? Most importantly. Is explicit support by DSP [performing the actual decoding of user data] required for playback of DVD-R[W] recorded in packet mode? Then I fail to understand why did you bring up packet writing at all? cdrecord[-ProDVD] doesn't support it so that those willing to perform say live NFS backups have to solely rely on buffer underrun protection, don't they? Is there reason to believe that recovery is so much more accurate than in CD [where it's off by default] that you're ready to bet your backup on it? - write packets to a blank disk (no overwrite possible) - write random addressed packets to a pre-formatted disk (overwrite works). DVD- supports both modes, DVD+ only supports the second mode. In addition, DVD- supports a streamed de-facto uninterrupted write called SAO (Session At Once). As already mentioned. DVD+RW supports write of randomly addressed 2KB blocks even to *virgin* media (well, when you write 2KB, 32KB gets naturally written/de-iced], and naturally rewrite in random order at later occasion. Randomly written DVD+RW disc is *indistinguishable* from one written progressively/streamed. DVD+R media can be written progressively in 32KB ECC blocks, *but* uninterrupted streaming is not a requirement [you can even eject media
Re: DVD+RW/+R for Linux update
From: Frank Hage [EMAIL PROTECTED] : But DVD-* media is cheaper and I see no advantage in using DVD+ media. One advantage I find is the ability to burn directly from NFS mounted partitions. It's slow but it works well. I've got gobs and gobs of data spread across many machines, many filled to capacity. It takes me less time and a lot less work to cross mount our aging workstations and burn directly than it does to copy and create iso files, and then burn. I see no relation between DVD- vs. DVD+ and NFS. The write speed does not matter if you use BUrnProof or packet writing. Of course DVD+RW _only_ supports packet writing... Other advantages are the ability to completely fill the disks ( 4 GB iso files are a problem on 32 bit systems) and not needing free space for the disk images. It looks like you are confused. Although its possible to pipe mkisofs output to cdrecord and avoid producing an image, (which I usually do for CDR), buffer underruns are a problem when the files live across on a NFS partition. See above. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From: Matthias Schniedermeyer [EMAIL PROTECTED] : But DVD-* media is cheaper and I see no advantage in using DVD+ media. Other advantages are the ability to completely fill the disks ( 4 GB iso files are a problem on 32 bit systems) and not needing free space for the disk images. When you don't know what you are talking about. Shut up. :-) See above ;-).. You can't make a single file bigger than 2 GB in an ISO-Filesystem, corect. But that is a limitation in of the ISO-Filesystem itself. The OP did not talk about single files _inside_ an ISO FS but about ISO-FILES which usually is a file holding an ISO FS as content. When you have a problem creating the 4.5GB Image-File then your system isn't up to date. Update the system or use the split-option of mkisofs. I burn DVD-Rs for more than a year now and from day one on i had never problems with file-sizes (*1) (*2) This is true. *1: Except that i had to patch the ISO-driver in Linux (kernel 2.4.9) to recognize files bigger than 1 GB. But that patch made into normal Linux a few revisions later. A known old bug in the linux kernel *2: I don't count the 2GB Limitation of ISO-fs as a problem. As it is conceptual there is nothing you can do about it. Future versions of mkisofs will allow you to use 2 GB files in UDF filesystems. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
On Wed, Nov 06, 2002 at 02:26:21PM +0100, Joerg Schilling wrote: From: Matthias Schniedermeyer [EMAIL PROTECTED] : But DVD-* media is cheaper and I see no advantage in using DVD+ media. Other advantages are the ability to completely fill the disks ( 4 GB iso files are a problem on 32 bit systems) and not needing free space for the disk images. When you don't know what you are talking about. Shut up. :-) See above ;-).. I won't say what one of my teachers in school said about this topic. You can't make a single file bigger than 2 GB in an ISO-Filesystem, corect. But that is a limitation in of the ISO-Filesystem itself. The OP did not talk about single files _inside_ an ISO FS but about ISO-FILES which usually is a file holding an ISO FS as content. As i said below. That problem doesn't exist (anymore). :-) The 2GB problem is the only size-problem i know. So i included the rant about that limitation to make a (more or less) technically correct statement. Point. Future versions of mkisofs will allow you to use 2 GB files in UDF filesystems. You should rename the program. It doesn't feel correct anymore. OK currently you can't skip the ISO-FS. But AFAIR you once said that you will make it possibel to skip the ISO-FS from the image. mkufs mkimg mkhybrid :-) mk_image_suitable_for_burning_on_a_CD-R(W)_or_DVD(-/+)R(W)_(or_other_medium) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
On Wed, Nov 06, 2002 at 01:22:17PM -0700, Frank Hage wrote: On 2002.11.06, Joerg Schilling wrote: : : : From: Matthias Schniedermeyer [EMAIL PROTECTED] : : : But DVD-* media is cheaper and I see no advantage in using DVD+ media. : : Other advantages are the ability to completely fill the disks ( 4 GB : iso files are a problem on 32 bit systems) and not needing free space : for the disk images. : : When you don't know what you are talking about. Shut up. :-) : : See above ;-).. : : I burn DVD-Rs for more than a year now and from day one on i had never : problems with file-sizes (*1) (*2) : I'm sorry. I forgot that DVD +/- geeks were having a religious war. ;-) You say it. There is only one god. :-) Yes, you .de guys are right. Your Mileage Varies greatly from mine. A few month ago i even read an articel in our Linux Magazin about the 2GB Barrier (The Topic was DVD-Recording). I felt like beeing warped back into the stoneage. :-) However, perhaps you should look at it from my point of view. Often Confused and Ignorant, I go on trying to do my real job using computers my institution provides and supports. Stability is a big issue in my work, so we often run SEVERAL YEARS behind current releases on our computers. We do this on purpose, because they need to collect and process data 24/7, often for years at a time. I have limited options and little patience for chasing development/alpha software. Yes, DVD- works great for you after you patched, updated, split, etc... and then, what... diddled Joerg for a cdrecord key? Perhaps I don't have that option. For burning i only had to recompile mkisofs because the version from my distribution wasn't compiled right, it couldn't create an image 2GB. But besides that i didn't had to change anything else in my system. So i've never splitted my images, since the 2GB Barrier was gone since 2.4prewhatever and i used 2.4.4 or 2.4.9 the time i burned my first DVD-R. For reading files bigger 1GB the kernel had to be patched because otherwise the file would be shown as 16MB or something like that. No keys back then. The binary was the key, i got my own cdrecord. The keys came later. And another thing i never had problems with and where other people have a variing milage is firewire. Since day one i use the DVD-R connected via a IDE - Firewire enclosure. It took about 10 trys until i finally had my first DVD-R-coaster. :-) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From: Andy Polyakov [EMAIL PROTECTED] Slightly off-topic in this list context. http://fy.chalmers.se/~appro/linux/DVD+RW/ was updated this weekend. Major news are support for SONY DRU500 unit and improved compatibility control (see new Compatibility caveat lector paragraph on the page in question). From reports I got for Cdrecord-ProDVD, cdrecord does not need an update for the Sony drive, it just works Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
From reports I got for Cdrecord-ProDVD, cdrecord does not need an update for the Sony drive, it just works Not when it comes to burning DVD+RW/+R media. cdrecord-ProDVD works only with DVD-RW/-R media. A. But DVD-* media is cheaper and I see no advantage in using DVD+ media. I didn't post the announcement to be dragged into this discussion so I'm not going the comment on this. Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD+RW/+R for Linux update
On 2002.11.04, Joerg Schilling wrote: : : : But DVD-* media is cheaper and I see no advantage in using DVD+ media. One advantage I find is the ability to burn directly from NFS mounted partitions. It's slow but it works well. I've got gobs and gobs of data spread across many machines, many filled to capacity. It takes me less time and a lot less work to cross mount our aging workstations and burn directly than it does to copy and create iso files, and then burn. Other advantages are the ability to completely fill the disks ( 4 GB iso files are a problem on 32 bit systems) and not needing free space for the disk images. Although its possible to pipe mkisofs output to cdrecord and avoid producing an image, (which I usually do for CDR), buffer underruns are a problem when the files live across on a NFS partition. Of course, YMMV. -- Frank Hage [EMAIL PROTECTED] National Center for Atmospheric Research -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
