Re: linux kernel error reading end of cd/dvd
What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I never claimed I have all the answers! I just tried to give most accurate definition and applied it to a particular case:-) I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. all files were readable, Once again. All files being readable is what basically counts. Yes, we have formal right to expect kernel to provide for direct access to /dev/cdrom as well, but only if it's free from technicalities specific to media manufacturing, recorder firmware implementation, player firmware implementation, etc. Bypassing the block buffer and finding sane block count is a way of telling to the system I'll take care of technicalities and I think that we should *just do* that. not necessarily all isoinfo -d blocks (last ones give read error). Then play with programs in mkisofs/diag, make one to print last significant block of file system to figure this one out... The media size can't then be smaller than the filesystem size, For mkisofs mastered images!!! But generally speaking there is nothing preventing you from putting value of 500MB to volume descriptor (value returned by df and isoinfo), having last significant block at 300MB and burn 400MB on the media. The media will be perfectly mountable, all 300MB worth files will be accesible, df will return 500MB and lead-out will be at 400MB... * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. DVD is completely different story. Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Who said it's wrong? The fact that it's not what you expect it to be in some particular situation doesn't necessarily mean it's wrong! OK, I have to admit that I might have mislead you people by calling it READ CAPACITY as it was a media capacity in respect to read operations, but the fact is that it's just a name of command reading a media capacity, not necessarily in respect to read operations. Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? Yes. There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Yes, and under some circumstances it's more or less intentional (e.g. random access DVD+RW), or hard to predict (e.g. CD player can't tell apart media recorded in DAO and TAO, while TAO media is guaranteed(?) to have unaccessible blocks before lead-out). But what makes us human geeks? Ability to adjust to situations! So bypass the block buffer and figure out sane block count in user land:-) Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Tue Oct 14 18:47:59 2003 If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. Not if this is e.g. a Solaris boot CD. Note that last part of the statement reads as for *mkisofs* *mastered* images. Is Solaris boot CD image mastered with mkisofs? I can't confirm it is, at least not Solaris 8 (strings reveal MakeDisc ver. 1.20). May be wrong for S 8 FCS, but who is talking about things outdated for a long time? Since January 2000, Solaris CDs are made with mkisofs. mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? Mkisofs is able to create a Sun disk partition table. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Interesting point! If you have a multi session disk, then bad things may happen if the OS reads more then 150 kB bejond a session end ad the read capacity command returns the end of the last session. If the OS fails because it tries to read more than 150 kB bejond an ardess that is listed as part of the used media, then it is broken. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. This may be true for single session disks, but for multi session disks either of both output may be nonsense. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A. 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? Mkisofs is able to create a Sun disk partition table. Did I say that mkisofs can't create Sun disk paritition table? Can anybody point at the sentence in my post which would say that? I did *not* say that, but rather opposite! I said that if SPARC bootable image is prepared with mkisofs, then SPARC boot block[s] (or partition[s] if you wish) appear *within* the value returned by isoinfo [even though they are not referenced to from ISO9660 directory structure]. And I implied that this is distinct from layout I've observed on original Sun media(*). All this means that I actually *tried* and *verified* that if I follow the instructions in README.sparcboot and get X sectors large bootable image, isoinfo *still* reports X sectors. Which in turn means that the original statement that isoinfo output can be used as sane block count for images mastered *with* *mkisofs* holds true *even* for SPARC bootable images. A. (*) On original Sun media the value reported by isoinfo is noticeably smaller than track size. But I do get almost the track size if I sum up the value returned by isoinfo and sizes of those UFS bootable partitions, which makes me conclude that UFS partitions were appended to ISO9660 image by means other than mkisofs -B command line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. But I maintain that *if* *I* *myself* prepare a SPARC bootable image with mkisofs -B on *my* system and just burn it, then I'll be prefectly able to use isoinfo output to copy such disk correctly. Can you really refute this statement? Can you really confirm that after *you* complete all the steps in README.sparcboot, value returned by isoinfo will differ from actual size of the image file? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: From: Andy Polyakov [EMAIL PROTECTED] [...] 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003 mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
Hi. I erased my dvd-rw (maxell, ver 1.1, bundled with the dvd burner): $ dvd+rw-format -blank /dev/scd0 * DVD±RW format utility by [EMAIL PROTECTED], version 4.7. * 4.7GB DVD-RW media in Sequential mode detected. * blanking | $ I ejected and inserted the media back (just to make sure), then: $ dvd+rw-mediainfo /dev/scd0 INQUIRY:[HL-DT-ST][DVDRAM GMA-4020B][A105] GET [CURRENT] CONFIGURATION: Mounted Media: 14h, DVD-RW Sequential READ DVD STRUCTURE[#0eh]: MediaID: MCC 00RW11N9 Current Write Speed: 1.0x1385=1385KB/s Write Speed #0:1.0x1385=1385KB/s READ DVD STRUCTURE[#0h]: Media Book Type: 32h, DVD-RW book [revision 2] Legacy lead-out at:2298481*2KB=4707289088 READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 2297888*2KB Track Size:2297888*2KB Again, I ejected and inserted the media back, then: $ growisofs -dvd-compat -Z /dev/scd0=dvd.iso Executing 'builtin_dd if=dvd.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: Current Write Speed is 1.0x1385KBps. :-[ LBA=0h, SENSE KEY=5h/ASC=30h/ASCQ=05h ] :-[ media is not formatted or unsupported ] :-( write failed: Input/output error $ I tried without dvd-compat and got the same error. So in this second attempt I added it to see if I could do it. Is this possible? Could it be the media, even being able to blank it successfully? As I told before, it is a maxell, bundled with the burner. Thanks a lot in advance! Best regards, djaba Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears to be prepared by mkisofs, *but* UFS partitions are clearly appended to iso-image by means *other than* mkisofs -B. Yes, mkisofs was used, but it was not the last program which generated the resulting image. The layout is therefore can't be classified as mastered *with mkisofs* and I still maintain that isoinfo can be used to retrieve sane block count for *any* image mastered with mkisofs. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
$ dvd+rw-format -blank /dev/scd0 ... $ growisofs -dvd-compat -Z /dev/scd0=dvd.iso Executing 'builtin_dd if=dvd.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: Current Write Speed is 1.0x1385KBps. :-[ LBA=0h, SENSE KEY=5h/ASC=30h/ASCQ=05h ] :-[ media is not formatted or unsupported ] :-( write failed: Input/output error Minimally blanked DVD-RW media can only be recorded in DAO mode (it's the way it is, period). growisofs does attempt to detect minimally blanked media and engages DAO in such case, but unfortunately there is no reliable way to tell apart minimally and fully blanked media and it might fail to engage DAO with some units. Your options are - try to growisofs -dvd-compat -dvd-compat, i.e. pass two -dvd-compat options, to manually engage DVD-RW DAO; - try to 'dvd+rw-format -force /dev/scd0' to format for Restricted Overwrite (I personally recommend Restricted Overwrite); - spend an hour on 'dvd+rw-format -blank=full /dev/scd0'; A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Extracting file system from an iso image
Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? I shall really appreciate your response. Thanks Ashish -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
Hi there! - try to growisofs -dvd-compat -dvd-compat, i.e. pass two -dvd-compat options, to manually engage DVD-RW DAO; It worked gracefully this way! Thanks a lot! I'm so curious now. I wanna really *know* things, how they *really* work, even physically. All the format specifications, recording modes, the physics behing the different media, even file systems format (iso, the udf structure). Could you please point me some sites where I can get some information like these? If I overlooked some of them in your page, sorry! Congratulations! I really couldn't write a single byte with this burner of mine with any other piece of software. I e-mailed LG and got no response. Your software is small, simple and efficient. And your page is very informative as well. Best regards, -- djaba Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extracting file system from an iso image
Thanks for the response. However, isodump seems to be an interactive utility and not something that you could just call from another script/executable running in background. If it can be, then I would like to know how? Thanks Ashish On Wed, 2003-10-15 at 18:05, Volker Kuhlmann wrote: Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? isodump (comes with cdrecord/mkisofs) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extracting file system from an iso image
On 16-Oct-2003 Ashish Rangole wrote: Thanks for the response. However, isodump seems to be an interactive utility and not something that you could just call from another script/executable running in background. If it can be, then I would like to know how? Hi, Ashish, why not mounting the iso image via loop device? Then you have access to any file operations and commands you need. In script mode too, sure! Joachim Backes -- Joachim Backes [EMAIL PROTECTED] University of Kaiserslautern,Computer Center, High Performance Computing Department, D-67653 Kaiserslautern, PO Box 3049, Germany -- Phone: +49-631-205-2438, FAX: +49-631-205-3056 http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html Regards Thanks Ashish On Wed, 2003-10-15 at 18:05, Volker Kuhlmann wrote: Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? isodump (comes with cdrecord/mkisofs) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I never claimed I have all the answers! I just tried to give most accurate definition and applied it to a particular case:-) I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. all files were readable, Once again. All files being readable is what basically counts. Yes, we have formal right to expect kernel to provide for direct access to /dev/cdrom as well, but only if it's free from technicalities specific to media manufacturing, recorder firmware implementation, player firmware implementation, etc. Bypassing the block buffer and finding sane block count is a way of telling to the system I'll take care of technicalities and I think that we should *just do* that. not necessarily all isoinfo -d blocks (last ones give read error). Then play with programs in mkisofs/diag, make one to print last significant block of file system to figure this one out... The media size can't then be smaller than the filesystem size, For mkisofs mastered images!!! But generally speaking there is nothing preventing you from putting value of 500MB to volume descriptor (value returned by df and isoinfo), having last significant block at 300MB and burn 400MB on the media. The media will be perfectly mountable, all 300MB worth files will be accesible, df will return 500MB and lead-out will be at 400MB... * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. DVD is completely different story. Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Who said it's wrong? The fact that it's not what you expect it to be in some particular situation doesn't necessarily mean it's wrong! OK, I have to admit that I might have mislead you people by calling it READ CAPACITY as it was a media capacity in respect to read operations, but the fact is that it's just a name of command reading a media capacity, not necessarily in respect to read operations. Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? Yes. There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Yes, and under some circumstances it's more or less intentional (e.g. random access DVD+RW), or hard to predict (e.g. CD player can't tell apart media recorded in DAO and TAO, while TAO media is guaranteed(?) to have unaccessible blocks before lead-out). But what makes us human geeks? Ability to adjust to situations! So bypass the block buffer and figure out sane block count in user land:-) Cheers. A.
Re: linux kernel error reading end of cd/dvd
* The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A.
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Interesting point! If you have a multi session disk, then bad things may happen if the OS reads more then 150 kB bejond a session end ad the read capacity command returns the end of the last session. If the OS fails because it tries to read more than 150 kB bejond an ardess that is listed as part of the used media, then it is broken. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A. 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? Mkisofs is able to create a Sun disk partition table. Did I say that mkisofs can't create Sun disk paritition table? Can anybody point at the sentence in my post which would say that? I did *not* say that, but rather opposite! I said that if SPARC bootable image is prepared with mkisofs, then SPARC boot block[s] (or partition[s] if you wish) appear *within* the value returned by isoinfo [even though they are not referenced to from ISO9660 directory structure]. And I implied that this is distinct from layout I've observed on original Sun media(*). All this means that I actually *tried* and *verified* that if I follow the instructions in README.sparcboot and get X sectors large bootable image, isoinfo *still* reports X sectors. Which in turn means that the original statement that isoinfo output can be used as sane block count for images mastered *with* *mkisofs* holds true *even* for SPARC bootable images. A. (*) On original Sun media the value reported by isoinfo is noticeably smaller than track size. But I do get almost the track size if I sum up the value returned by isoinfo and sizes of those UFS bootable partitions, which makes me conclude that UFS partitions were appended to ISO9660 image by means other than mkisofs -B command line.
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. But I maintain that *if* *I* *myself* prepare a SPARC bootable image with mkisofs -B on *my* system and just burn it, then I'll be prefectly able to use isoinfo output to copy such disk correctly. Can you really refute this statement? Can you really confirm that after *you* complete all the steps in README.sparcboot, value returned by isoinfo will differ from actual size of the image file? A.
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: From: Andy Polyakov [EMAIL PROTECTED] [...] 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003 mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. 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.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
Hi. I erased my dvd-rw (maxell, ver 1.1, bundled with the dvd burner): $ dvd+rw-format -blank /dev/scd0 * DVD±RW format utility by [EMAIL PROTECTED], version 4.7. * 4.7GB DVD-RW media in Sequential mode detected. * blanking | $ I ejected and inserted the media back (just to make sure), then: $ dvd+rw-mediainfo /dev/scd0 INQUIRY:[HL-DT-ST][DVDRAM GMA-4020B][A105] GET [CURRENT] CONFIGURATION: Mounted Media: 14h, DVD-RW Sequential READ DVD STRUCTURE[#0eh]: MediaID: MCC 00RW11N9 Current Write Speed: 1.0x1385=1385KB/s Write Speed #0:1.0x1385=1385KB/s READ DVD STRUCTURE[#0h]: Media Book Type: 32h, DVD-RW book [revision 2] Legacy lead-out at:2298481*2KB=4707289088 READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible incremental Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 2297888*2KB Track Size:2297888*2KB Again, I ejected and inserted the media back, then: $ growisofs -dvd-compat -Z /dev/scd0=dvd.iso Executing 'builtin_dd if=dvd.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: Current Write Speed is 1.0x1385KBps. :-[ LBA=0h, SENSE KEY=5h/ASC=30h/ASCQ=05h ] :-[ media is not formatted or unsupported ] :-( write failed: Input/output error $ I tried without dvd-compat and got the same error. So in this second attempt I added it to see if I could do it. Is this possible? Could it be the media, even being able to blank it successfully? As I told before, it is a maxell, bundled with the burner. Thanks a lot in advance! Best regards, djaba Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br
Re: linux kernel error reading end of cd/dvd
I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears to be prepared by mkisofs, *but* UFS partitions are clearly appended to iso-image by means *other than* mkisofs -B. Yes, mkisofs was used, but it was not the last program which generated the resulting image. The layout is therefore can't be classified as mastered *with mkisofs* and I still maintain that isoinfo can be used to retrieve sane block count for *any* image mastered with mkisofs. A.
Re: DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
$ dvd+rw-format -blank /dev/scd0 ... $ growisofs -dvd-compat -Z /dev/scd0=dvd.iso Executing 'builtin_dd if=dvd.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: Current Write Speed is 1.0x1385KBps. :-[ LBA=0h, SENSE KEY=5h/ASC=30h/ASCQ=05h ] :-[ media is not formatted or unsupported ] :-( write failed: Input/output error Minimally blanked DVD-RW media can only be recorded in DAO mode (it's the way it is, period). growisofs does attempt to detect minimally blanked media and engages DAO in such case, but unfortunately there is no reliable way to tell apart minimally and fully blanked media and it might fail to engage DAO with some units. Your options are - try to growisofs -dvd-compat -dvd-compat, i.e. pass two -dvd-compat options, to manually engage DVD-RW DAO; - try to 'dvd+rw-format -force /dev/scd0' to format for Restricted Overwrite (I personally recommend Restricted Overwrite); - spend an hour on 'dvd+rw-format -blank=full /dev/scd0'; A.
Extracting file system from an iso image
Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? I shall really appreciate your response. Thanks Ashish
Re: DVD-RW blanks fine but burning yields 'media unsupported'. Is it possible?
Hi there! - try to growisofs -dvd-compat -dvd-compat, i.e. pass two -dvd-compat options, to manually engage DVD-RW DAO; It worked gracefully this way! Thanks a lot! I'm so curious now. I wanna really *know* things, how they *really* work, even physically. All the format specifications, recording modes, the physics behing the different media, even file systems format (iso, the udf structure). Could you please point me some sites where I can get some information like these? If I overlooked some of them in your page, sorry! Congratulations! I really couldn't write a single byte with this burner of mine with any other piece of software. I e-mailed LG and got no response. Your software is small, simple and efficient. And your page is very informative as well. Best regards, -- djaba Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br
Re: Extracting file system from an iso image
Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? isodump (comes with cdrecord/mkisofs) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: Extracting file system from an iso image
Thanks for the response. However, isodump seems to be an interactive utility and not something that you could just call from another script/executable running in background. If it can be, then I would like to know how? Thanks Ashish On Wed, 2003-10-15 at 18:05, Volker Kuhlmann wrote: Once I have read an ISO9660 image with or without Joliet/Rockridge extns, is there a way to simply extract files, directory sturcture from it (analogous to tar extraction), without actually mounting the iso image? Is there a utility to do this? isodump (comes with cdrecord/mkisofs) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
