Difference between revisions of "Talk:Optical disc drive"

From ArchWiki
Jump to navigation Jump to search
 
(76 intermediate revisions by 13 users not shown)
Line 1: Line 1:
==Command line order==
+
== Verifying the burnt ISO image ==
I don't know what ArchLinux is about, but this page was a very nice reference for growisofs. However, according to the man page for growisofs, all options for growisofs should come before the <code>-[Z|M] /dev/dvd-device</code>. The synopsis is:
 
growisofs <span style="color:green">[-dry-run] [-dvd-compat] [-overburn] [-speed=1] -[Z|M] /dev/dvd</span> <span style="color:blue"><mkisofs-options></span>
 
so this line:
 
growisofs <span style="color:green">-Z /dev/cdrw</span> <span style="color:blue">-v -l</span> <span style="color:green">-dry-run</span> <span style="color:blue">-iso-level 3 -R -J</span> <span style="color:green">-speed=2</span> <span style="color:blue">-joliet-long -graft-points /Magazines/=/home/citral/books/mags/</span>
 
should rather be:
 
growisofs <span style="color:green">-dry-run -speed=2 -Z /dev/cdrw</span> <span style="color:blue">-v -l -iso-level 3 -R -J -joliet-long -graft-points /Magazines/=/home/citral/books/mags/</span>
 
since <code>-dry-run</code> and <code>-speed=N</code> are options for growisofs and not mkisofs. I'm guessing growisofs figures that out for itself though, but for the sake of consistency, I feel the order should be changed... - ([[User:Reep|Reep]] 15:24, 4 April 2006 (EDT))
 
: Sounds very logical to me. Since it is your discovery, would you mind updating the page yourself?  --[[User:Citral|citral]] 14:24, 16 July 2006 (PDT)
 
  
==DVD Ripping - mplayer -dumpstream==
+
Although the part with getting the md5sum of the previously created ISO image is quite obvious, the part with verifying the actual contents of the burnt disc seems to be somewhat inaccurate.
hey,
 
I normaly just do
 
mplayer -dumpstream
 
  
and write it to a .vob file.
+
As soon as you have an alias like '''alias ls='ls-hF --color=auto'''' in your .profile, which could come in handy, the mentioned method for getting the block count is wrong:
  
So the actual command could look like:
+
  $ blocks=$(expr $(ls -l isoimage.iso | awk '{print $5}') / 2048)
  mplayer dvd://1 -v -dumpstream -dumpfile film.vob
 
  
Of course I get really big files this way. (3-8 gigabyte)
+
To make sure the calculated block count is valid for various user defined environments I would recommend the use of '''du -b''':
But I think it's definitely the best quality, isn't it?
 
And you can easily compress the vob-file anyway later if you want to.
 
  
I don't really have much knowledge about mplayer and video in general, so I didn't just write it in the article.
+
$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)
I only adopted it from [http://wiki.ubuntuusers.de/DVDs_manuell_rippen] (german language)
 
  
If anyone knows a better method (for example make mplayer read the dvd more carefully, if quality matters more than time) please write.
 
  
--[[User:Advocatusdiaboli|Advocatusdiaboli]] 15:40, 10 November 2009 (EST)
+
That's what I just stumbled upon while trying to verify my burnt image.
  
--
+
: I did not think of such aliases. My ~/.bashrc has: alias ls=ls
 +
: Your proposed du seems less prone to aliasing. Option -b is promised to be safe from pitfalls of sparse files. So i will put it into the wiki.
 +
: I wonder, though,  whether stat(1) would be ubiquitous enough in archlinux:
 +
: $ blocks=$(expr $(stat -c '%s' isoimage.iso) / 2048)
 +
: [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 15:42, 29 August 2013 (UTC)
 +
: General thoughts:
 +
: alias is an arbitrary nasty problem with shell commands, of course. One cannot avoid it by alias ls=ls in a sub shell. man 1 bash is merciless in that aspect. Inquiring alias manually, unaliasing, executing size determination, re-aliasing ... is much too complicated. Should we bet on the existence of /bin/ls or /bin/du ? Any other ideas to surely prevent alias evaluation in an interactive command ? [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 16:09, 29 August 2013 (UTC)
 +
:: Research:
 +
:: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/bin.html and http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard promise the existence of /bin/ls . du is not listed there. So /bin/ls is currently my best bet to prevent alias evaluation.
 +
:: I will wait a few days for objections or better ideas before changing the size command in the wiki page again. Please keep me from doing stupid things. [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 16:27, 29 August 2013 (UTC)
  
Maybe some of these links have useful info? [http://www.linux.com/archive/feature/140081] [http://www.linux.com/archive/feature/128105] [http://www.dedoimedo.com/computers/handbrake.html]
+
:::Of course there's no way to find a one-size-fits-all solution, maybe it's just worth to quickly mention the problem and propose the ls method as an alternative. I'd keep du as the main method because it's indeed less likely to be aliased. About its existence on all systems, this is the wiki for Arch Linux, whose basic, default installation includes {{Pkg|coreutils}}, where both ls and du are provided. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:55, 31 August 2013 (UTC)
  
==<s>CD Burning</s>==
+
::::du -b seems quite robust. I tried to fool it by alias definitions like du='du --human-readable'. But an explict option -b overrides it properly. I still get the byte count. (Sequence matters. du -b --human-readable would show e.g. "590M"). My doubts about availability are rather about stat(1). It would be more appealing than du, because du's main job is to report disk usage, not the addressable byte size.
 +
::::One of the problems i feared is demonstrated by :
 +
::::  dd if=/dev/zero bs=1 count=1 seek=10000000 of=/tmp/sparse_test ; ls -l /tmp/sparse_test ; du /tmp/sparse_test ; du -b /tmp/sparse_test
 +
::::On my machine i get a file of adressable 10000001 bytes which uses only 12 disk blocks of 1 KB. But du -b does it right. So for now i postpone my plan to change the size determination once again. [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 09:30, 31 August 2013 (UTC)
 +
:The current command for calculating the block size gives a syntax error because I have the following alias '''alias du=du -c -h'''' in my .zshrc. The '''-c''' results in another row of output and the expr fails, the following change to the command solves this issue. I'm not really sure if its worth including it in the wiki but I thought I'll leave a suggestion here.
 +
: $ blocks=$(expr $(du -b isoimage.iso | awk 'NR==1{print $1}') / 2048)
 +
:The '''NR==1''' makes sure that only the first row of output is used for the expression. --[[User:Saifazmi|Saifazmi]] ([[User talk:Saifazmi|talk]]) 13:54, 9 January 2018 (UTC)
  
I'm suggesting there should be a 'CD Burning' page where (1.) Commandline burning is explained and (2.) Burning with a GUI. CD Burning is a more unified title than this page. --[[User:Marco`]]
+
== restructure to read/play/write ==
 +
can we slightly restructure the article please into three paragraphs:
 +
* read / copy, includes mount, [[Optical_disc_drive#Reading_an_ISO_image_from_a_CD.2C_DVD.2C_or_BD| read an iso image]]
 +
* write / burn, includes creating iso9660 image
 +
* play
 +
the problem is that currently the paragraph to read an image is kind of hidden in a paragraph called "burning". i fell over this as i did not want to burn a dvd, but just copy one to disk and play to avoid scratching it. so i tried all the tools listed in ripping and none worked. it took a while to clue into the fact that one could just copy the iso off the disk and play it like one would do with an optical disk, no need to rip it. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 04:30, 5 January 2017 (UTC)
  
I have begun to merge this page into the [[CD Burning]] page --[[User:Marco`]]
+
:Copying an optical disk means reading one disk and writing it to another optical disk. As it involves both ''reading'' and ''burning'', it is too strict to split these topics. Also, [[Optical disc drive#Ripping|Ripping]] is a topic of its own as it implies time-consuming transcoding of the media into a different format, so I don't agree with [https://wiki.archlinux.org/index.php?title=Optical_disc_drive&oldid=461483#Copy_an_optical_disc_drive this organization]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:24, 5 January 2017 (UTC)
  
== special burning options ? ==
+
how do we solve it then, duplicate the info? ask somebody else what he thinks? --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:45, 5 January 2017 (UTC)
  
Have think about burning following CD :
+
== ISO 9660 and burning on-the-fly ==
-bootable CD
 
-contains audio track ( for CD player ) , any position is OK
 
  
Is such CD ( technically ) possible to burn ?
+
The command provided for burning a DVD on the fly is missing the '''-dvd-compat''' parameter.
  
== Burning files/directories throught genisoimage ==
+
$ growisofs -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso
  
make the .iso file:
+
I suggest that the command mentioned above changes to include the '''-dvd-compat''' parameter.
# genisoimage -r -J -o cd_image.iso /directory
 
  
 +
$ growisofs -dvd-compat -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso
  
The -r and -J ensures long file names work for Unix (using Rock Ridge) and Windows (using Joliet extensions) respectively.
+
As without it once the data has been written to the DVD it cannot be mounted using the '''mount''' command, resulting in the following error.
  
==<s>Merge multiple pages CD/DVD</s>==
+
$ sudo mount /dev/sr0 /mnt
 +
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error.
  
I've seen that there are a few Pages that describe CD / DVD burning tools. I ask myself "why?".  
+
The wiki already mentions the '''-dvd-compat''' parameter under the
 +
[[Optical disc drive#Burning an ISO image to CD, DVD, or BD|Burning an ISO image to CD, DVD, or BD]] section
 +
 +
$ growisofs -dvd-compat -Z /dev/sr0=isoimage.iso
  
*[[CD Burning]]
+
But it's somehow missing from the [[Optical disc drive#ISO 9660 and burning on-the-fly|ISO 9660 and burning on-the-fly]] section.
*[[DVD Burning]]
 
*[[DVD Playing]]
 
*[[DVD Ripping]]
 
*[[Video2dvdiso]] one page for a single script (????)
 
  
This pages describe "how to use" the same device. Nowadays there are only devices that burning them both cd/dvd.
+
--[[User:Saifazmi|Saifazmi]] ([[User talk:Saifazmi|talk]]) 18:15, 9 January 2018 (UTC)
I think we need to merge all the pages in a single.
 
In this way it is easier consultation by the users, because everyone would like to know how to exploit and operate your device to play, burning and ripping cd/dvd without having to navigate through multiple pages for a single device. Also the page of 'DVD burning' are not mentioned programs to burn, rightly cited the page burinig CD ..... this indicates that do not make sense multiple page for a single device, I want to know how to use my dvd burner? I have to navigate through multiple pages, if only to know what programs to use.[[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 08:18, 15 July 2013 (UTC)
 
  
:Ah well it sounds like a good plan to me :) It also sounds like a big job though: if you think you can do it, go for it! Just make sure to do many little edits (not just a few big ones) and document all of them using the edit summary. If you're not doing the merge, instead, you can request it by adding [[Template:Merge]] to those articles. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:52, 16 July 2013 (UTC)
+
== Suggestion for Verifying the burnt ISO image ==
  
::Yes ! It's a big job! mmm I can try to do a single page in my personal page, just to example, and add a template "merge" in all pages that link in this discussion. So all users will be made aware and can participate if they want, while I begin to do a draft.[[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 10:12, 17 July 2013 (UTC)
+
EDIT: I just realized that the {{ic|cat}} is totally unnecessary if you remove the second process substitution. Also cleaned up some grammar.
 +
[[User:Ksd|Ksd]] ([[User talk:Ksd|talk]]) 17:13, 21 May 2019 (UTC)
  
::: Well, i've created an example for this merging  in my personal page https://wiki.archlinux.org/index.php/User:Veleno77 . This merging consist in a few step.
+
I came up with a modified method for verifying the burnt ISO that eliminates the tedium and human error of having to eyeball two hashes but I wanted to run it past everyone first. It uses dd the same way as before but rather than use md5 it uses diff and process substitution (for those who don't know process substitution is basically a convenient way to use named pipes and is a feature common to all modern shells going as far back as ksh).
:::# Create a new page with title " Optical disc drive "
 
:::# In this page, simply merging [[CD Burning]] , [[DVD Burning]] , [[DVD Playing]] , [[DVD Ripping]] and related troubleshooting.
 
:::# In the section "See also" add a link to [[Convert any Movie to DVD Video]], because this is the real related page.
 
:::# The page [[Video2dvdiso]] is a page for a single script related to [[Convert any Movie to DVD Video]], and I think must be included in it.
 
:::Now I'm waiting for your views. [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 22:25, 17 July 2013 (UTC)
 
  
::::Good job, I like your draft, I'd just like to ask you to wait a few days before putting it into practice, let's say until this weekend, so we'll see if there are any users against the merge. That said, note the title of the page will have to be capitalized as per [[Help:Editing#Creating pages]] (I know it's a [[Help_talk:Style#Title_case|very hidden rule]]), and to make it a very good job you could try to perform the merge in multiple edits, not only a single big one, for example:
+
With this method you're reading every byte of the ISO and the drive (using the $block count) just as before but you're avoiding all the CPU intensive hashing and instead just comparing the bytes directly.
::::# Create [[Optical Disc Drive]]
 
::::# Merge [[CD Burning]] as it is (without changes)
 
::::# Adjust the section tree as in your draft
 
::::# Merge [[DVD Burning]] as it is (without changes)
 
::::# Adjust the section tree as in your draft
 
::::# Merge [[DVD Playing]] as it is (without changes)
 
::::# Adjust the section tree as in your draft
 
::::# Merge [[DVD Ripping]] as it is (without changes)
 
::::# Adjust the section tree as in your draft
 
::::# Merge the Troubleshooting sections
 
::::# Add any relevant links to the See also section
 
::::Then redirect the 4 merged articles to the correct sections in [[Optical Disc Drive]].
 
::::Finally yeah, I'd say [[Video2dvdiso]] can be merged into [[Convert any Movie to DVD Video]].
 
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:22, 18 July 2013 (UTC)
 
  
:::::Thank you for all your support and for your explanations. Unfortunately I am new to this method of "merging". I welcome all your suggestions and I hope to do things in a clear way, and not to make mistakes. I'll wait a few days and then I will get to work.[[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 21:43, 18 July 2013 (UTC)
+
Suggested method below:
  
::::::OK! All the changes have been done. I did well to create redirects to the sections? Or should I point them to the main page?[[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:14, 22 July 2013 (UTC)
+
You can verify the integrity of the burnt medium to make sure it contains no errors. Always eject the medium and reinsert it before verifying. It will guarantee that not any kernel cache will be used to read the data.
  
:::::::Very well done, thank you!! And thanks for making it easy to check all the edits by applying the changes step by step :) Redirecting to the proper sections was indeed the right thing to do, I've just redirected here the respective talk pages too, merging all the old discussions, like this very one.
+
First calculate the block count of the ISO file.
:::::::This discussion can be closed, as new comments can be added to [[#A big merge]].
+
Although some media types deliver exactly the same amount of data as have been submitted to the burn program, many others append trailing garbage when being read. So you should restrict reading to the size of the ISO image file.
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:59, 23 July 2013 (UTC)
 
  
== A big merge ==
+
$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)
  
This page is the result of the merger of pages:
+
Next perform a byte comparison between the ISO file and the ISO file system on the medium.
*[[CD Burning]]
 
*[[DVD Burning]]
 
*[[DVD Playing]]
 
*[[DVD Ripping]]
 
A one page to describe how to use an optical disc drive: CD burning;  burning, ripping and playing DVD, inherent troubleshooting.
 
  
'''For all wiki's translators:, simple read the "history" tab for how to merge all page in your language.'''
+
{{hc|1=$ diff <(dd if=/dev/sr0 bs=2048 count=$blocks) isoimage.iso|2=
For more detail see https://wiki.archlinux.org/index.php/Talk:CD_Burning [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 15:31, 22 July 2013 (UTC)
+
43992+0 records in
 +
43992+0 records out
 +
90095616 bytes (90 MB) copied, 0.359539 s, 251 MB/s
 +
}}
  
== How to contribute as upstream developer ? ==
+
There should be no message stating the Binary files differ. If there is one, you will probably also get an I/O error message from the {{ic|dd}} run. {{ic|dmesg}} might then tell about SCSI errors and block numbers, if you are interested.
 +
[[User:Ksd|Ksd]] ([[User talk:Ksd|talk]]) 00:49, 20 October 2018 (UTC)
  
Being the developer of libburn i see that you are consolidating
+
== {{ic|isosize}}, determine the size of the burnt image, and verification ==
the knowledge about CD, DVD, and BD.
 
Now i feel the urge to propose some corrections.
 
  
Would it be welcome if i make substantial changes, or would it
+
Am I right that most of the discussion here about verifying the burnt image, [[#Verifying the burnt ISO image]] and [[#Suggestion for Verifying the burnt ISO image]], revolves around the method to determine the burnt image size? In that case, was
be better to leave the wiki work to a person who is not involved
+
# isosize /dev/sr0
in the competing burn software for archlinux ?
+
mentioned? Doesn't it adequate for the task?
(I have no experience with this wiki software. Beware.)
 
  
What i would change:
+
[[User:Regid|Regid]] ([[User talk:Regid|talk]]) 22:55, 25 November 2019 (UTC)
# Clean out burn war rethorics (mainly cdrkit vs. cdrtools)
 
# Move ISO 9660 stuff before burning stuff
 
# Add my own packages libburn, libisofs, libisoburn to the list
 
# Unify the command names used in examples
 
# Clarify some technical facts
 
I have a more detailed list of change proposals. 150 lines.
 
Shall i post it here ?
 
[[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 12:48, 26 July 2013 (UTC)
 
 
 
: Do a bit of clarity between cdrkit and cdrtools would be a pleasant thing. As well as any technical clarifications. At present I see that your packages are only used by Xfburn front-end, and from Brasero as a alternative back-end (on Arch Linux). Mainly others use a combination cdrkit/dvd+rw-tools. I'm ignorant on the subject, but if you want to clarify everything, it must be done in a simple and explanatory. In practice: "there are three ways to burn cd/dvd on Arch linux, using packages cdrkit, cdrtools or libburnia." Explain the use of all in a comprehensive way (in the case should be reviewed throughout the page) but, consider that the main front-end using the packages described above. It is interesting to your proposal, but I do not have the technical means to be able to help in this regard.[[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 15:39, 26 July 2013 (UTC)
 
 
 
:: I take your answer as encouragement to post the long list of proposals.
 
 
 
:: (I am not doing well with wiki formatting here. Some experienced polishing seems needed.)
 
 
 
:: -------------------------------------------------------------------
 
 
 
:: '''Install CD-burning utilities'''
 
::* I would clean out the burn war rethorics, and rather list the known free programs and their packages in alphabetic order. Further i would put the description of dvd+rw-tools here and change the title to: "Install fundamental burning utilities for CD, DVD, and BD". I would explain that from the following lists one needs at least one program for creating ISO 9660 filesystem images and one program for burning data to the desired media type.
 
:: * The list of known free programs for ISO 9660 creation:
 
:: ''genisoimage'' from package ''cdrkit''
 
:: ''isomaster'' from package ''isomaster'' (with gtk2 GUI)
 
:: ''mkisofs'' from package ''cdrtools''
 
:: ''xorriso'' from package ''libisoburn''
 
:: ''xorrisofs'' from package ''libisoburn''
 
:: * The list of known free programs for CD, DVD, BD burning:
 
:: ''cdrdao'' from package ''cdrdao'' (CD only, .cue files only)
 
:: ''cdrecord'' from package ''cdrtools''
 
:: ''cdrskin'' from package ''libburn''
 
:: ''growisofs'' from package ''dvd+rw-tools'' (DVD and BD only)
 
:: ''wodim'' from package ''cdrkit'' (CD only, DVD deprecated)
 
:: ''xorriso'' from package ''libisoburn'' (no audio CD)
 
:: ''xorrecord'' from package ''libisoburn'' (no audio CD)
 
::* The free GUI programs for CD, DVD, BD burning depend on at least one of the above packages.
 
:: '''Modifying the CD-RW'''
 
::* I would mention that cdrecord, wodim, cdrskin all support the shown options for CD manipulation, wheras cdrdao has its own option set.
 
::* I would clean out the traces of cdrtools/cdrkit quarrel. If it is deemed necessary at all, then a general advise would be appropriate, to try one of the listed alternatives in case of trouble.
 
::* (One could open a new paragraph about multi-session. xorriso would look very good there. :))
 
:: '''Making an ISO image from an existing CD'''
 
:: This part should come before burning CDs (but after creating ISO images from disk files).
 
::* I would use {{ic|1= dd bs=2048}} rather than readcd or readom, which may or may not be good for reading non-data CD. (The statement that dd and cat "provide no error checking" is wrong, because you do get an i/o error if a block is unreadable or non-data. dd works nicely on auto-mounted CD. So the "Note:" box about umount can be shifted to the topic CD burning.)
 
:: '''Making an ISO image from existing files on hard disk'''
 
:: This part should come before burning CDs (and before extracting ISO images from CD).
 
::* I would mention that mkisofs, genisoimage, xorrisofs all support the shown options for ISO image creation. (The longish example with growisofs should be shown here.  Without the growisofs aspects.)
 
:: '''DVD burning'''
 
::* I would widen the chapter to "DVD and BD".
 
::* I would state that cdrdao and wodim are not suitable for DVD or BD. (Although wodim works with some DVD types, it is not worth the hassle.)
 
::* The packages cdrtools, dvd+rw-tools, and libburn+libisofs+libisoburn are suitable for DVD and BD burning. (Although i think that cdrecord does various DVD things wrong.)
 
::* The already mentioned programs for producing ISO 9660 filesystems are suitable for DVD and BD, too. The standards for video on DVD and BD demand UDF filesystems.  genisoimage and mkisofs can produce the format prescribed for DVD. (I am clueless about how to produce a UDF 2.50 for BD. Typically only the oldest players do not read plain ISO 9660. So possibly nobody cares about the specs.)
 
::* growisofs has a bug with BD-R. One can work around it by formatting the BD-R with dvd+rw-format before giving it to growisofs, or by using growisofs option  {{ic|1= -use-the-force-luke=spare:none}} if one does not want formatting and slow Defect Management.
 
::* ( archlinux should consider to repair the known growisofs BD-R bug by applying the single-line patch proposed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713016 )
 
::* I would remove the "Note:" about dvdrtools and completeness of cdrtools. (dvdrtools is not capable of all DVD types. I deem growisofs and libburn better suited for DVD than cdrecord. So there is reason to install one of these two.)
 
::* I would add program xfburn to the "Tip:" about k3b and brasero. (And maybe xorriso-tcltk.)
 
::* The first two growisofs examples run a mkisofs compatible helper program. Default is "mkisofs", but one can switch to other program names by executing before the growisofs run: {{ic|1= export MKISOFS="genisoimage"}} or {{ic|1= export MKISOFS="xorrisofs"}} . (xorrisofs cannot produce UDF images. UDF is not required by  the existing -dvd-video example, but possibly should be.)
 
::* For image extraction from DVD and BD, i would propose {{ic|1= dd bs=2048}}, rather than readcd or readom.
 
::* The explanation of mkisofs options with the fifth growisofs example should be merged with the paragraph "Making an ISO image from existing files on hard disk"
 
::* With growisofs one should state that nearly all mkisofs options may be used with a growisofs run. (-o is not allowed and -C should only be used if one wants to override the expert opinion of growisofs about the state of the DVD.)
 
::* cdrecord, cdrskin, and xorrecord burn DVD and BD with about the same options as with CD burning. xorriso has its own command set. I would translate the growisofs examples into additional examples for cdrecord and for xorriso. (Actually the {{ic|1= growisofs -M}} example should be expanded to a paragraph about multi-session.)
 
:: '''Re-writable DVDs'''
 
::* I would not mention explicit formatting for DVD+RW (or BD-RE), because all burn programs apply default formatting if needed.
 
::* I would rather mention that DVD-RW can be used unformatted which makes them very similar to DVD-R. But unformatted written DVD-RW need to be blanked before re-use. Fast blanking deprives them of their multi-session capability.
 
::* Full blanking lasts long. Better is to format DVD-RW, so that they behave much like DVD+RW: {{ic|1= dvd+rw-format -force /dev/cdrw}} or {{ic|1= cdrskin -v dev=/dev/cdrw blank=format_overwrite}} or {{ic|1=xorriso -outdev /dev/cdrw -format}} as_needed
 
:: '''BD Defect Management'''
 
::* This new paragraph would explain why BD-RE and formatted BD-R are written much slower than their nominal speed. It is due to checkreading and bad block replacement, which can be disabled to achieve full nominal speed.
 
:: [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 21:52, 26 July 2013 (UTC)
 

Latest revision as of 22:55, 25 November 2019

Verifying the burnt ISO image

Although the part with getting the md5sum of the previously created ISO image is quite obvious, the part with verifying the actual contents of the burnt disc seems to be somewhat inaccurate.

As soon as you have an alias like alias ls='ls-hF --color=auto' in your .profile, which could come in handy, the mentioned method for getting the block count is wrong:

$ blocks=$(expr $(ls -l isoimage.iso | awk '{print $5}') / 2048)

To make sure the calculated block count is valid for various user defined environments I would recommend the use of du -b:

$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)


That's what I just stumbled upon while trying to verify my burnt image.

I did not think of such aliases. My ~/.bashrc has: alias ls=ls
Your proposed du seems less prone to aliasing. Option -b is promised to be safe from pitfalls of sparse files. So i will put it into the wiki.
I wonder, though, whether stat(1) would be ubiquitous enough in archlinux:
$ blocks=$(expr $(stat -c '%s' isoimage.iso) / 2048)
Scdbackup (talk) 15:42, 29 August 2013 (UTC)
General thoughts:
alias is an arbitrary nasty problem with shell commands, of course. One cannot avoid it by alias ls=ls in a sub shell. man 1 bash is merciless in that aspect. Inquiring alias manually, unaliasing, executing size determination, re-aliasing ... is much too complicated. Should we bet on the existence of /bin/ls or /bin/du ? Any other ideas to surely prevent alias evaluation in an interactive command ? Scdbackup (talk) 16:09, 29 August 2013 (UTC)
Research:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/bin.html and http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard promise the existence of /bin/ls . du is not listed there. So /bin/ls is currently my best bet to prevent alias evaluation.
I will wait a few days for objections or better ideas before changing the size command in the wiki page again. Please keep me from doing stupid things. Scdbackup (talk) 16:27, 29 August 2013 (UTC)
Of course there's no way to find a one-size-fits-all solution, maybe it's just worth to quickly mention the problem and propose the ls method as an alternative. I'd keep du as the main method because it's indeed less likely to be aliased. About its existence on all systems, this is the wiki for Arch Linux, whose basic, default installation includes coreutils, where both ls and du are provided. -- Kynikos (talk) 03:55, 31 August 2013 (UTC)
du -b seems quite robust. I tried to fool it by alias definitions like du='du --human-readable'. But an explict option -b overrides it properly. I still get the byte count. (Sequence matters. du -b --human-readable would show e.g. "590M"). My doubts about availability are rather about stat(1). It would be more appealing than du, because du's main job is to report disk usage, not the addressable byte size.
One of the problems i feared is demonstrated by :
dd if=/dev/zero bs=1 count=1 seek=10000000 of=/tmp/sparse_test ; ls -l /tmp/sparse_test ; du /tmp/sparse_test ; du -b /tmp/sparse_test
On my machine i get a file of adressable 10000001 bytes which uses only 12 disk blocks of 1 KB. But du -b does it right. So for now i postpone my plan to change the size determination once again. Scdbackup (talk) 09:30, 31 August 2013 (UTC)
The current command for calculating the block size gives a syntax error because I have the following alias alias du=du -c -h' in my .zshrc. The -c results in another row of output and the expr fails, the following change to the command solves this issue. I'm not really sure if its worth including it in the wiki but I thought I'll leave a suggestion here.
$ blocks=$(expr $(du -b isoimage.iso | awk 'NR==1{print $1}') / 2048)
The NR==1 makes sure that only the first row of output is used for the expression. --Saifazmi (talk) 13:54, 9 January 2018 (UTC)

restructure to read/play/write

can we slightly restructure the article please into three paragraphs:

  • read / copy, includes mount, read an iso image
  • write / burn, includes creating iso9660 image
  • play

the problem is that currently the paragraph to read an image is kind of hidden in a paragraph called "burning". i fell over this as i did not want to burn a dvd, but just copy one to disk and play to avoid scratching it. so i tried all the tools listed in ripping and none worked. it took a while to clue into the fact that one could just copy the iso off the disk and play it like one would do with an optical disk, no need to rip it. --Soloturn (talk) 04:30, 5 January 2017 (UTC)

Copying an optical disk means reading one disk and writing it to another optical disk. As it involves both reading and burning, it is too strict to split these topics. Also, Ripping is a topic of its own as it implies time-consuming transcoding of the media into a different format, so I don't agree with this organization. -- Lahwaacz (talk) 09:24, 5 January 2017 (UTC)

how do we solve it then, duplicate the info? ask somebody else what he thinks? --Soloturn (talk) 19:45, 5 January 2017 (UTC)

ISO 9660 and burning on-the-fly

The command provided for burning a DVD on the fly is missing the -dvd-compat parameter.

$ growisofs -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso

I suggest that the command mentioned above changes to include the -dvd-compat parameter.

$ growisofs -dvd-compat -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso

As without it once the data has been written to the DVD it cannot be mounted using the mount command, resulting in the following error.

$ sudo mount /dev/sr0 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error.

The wiki already mentions the -dvd-compat parameter under the Burning an ISO image to CD, DVD, or BD section

$ growisofs -dvd-compat -Z /dev/sr0=isoimage.iso

But it's somehow missing from the ISO 9660 and burning on-the-fly section.

--Saifazmi (talk) 18:15, 9 January 2018 (UTC)

Suggestion for Verifying the burnt ISO image

EDIT: I just realized that the cat is totally unnecessary if you remove the second process substitution. Also cleaned up some grammar. Ksd (talk) 17:13, 21 May 2019 (UTC)

I came up with a modified method for verifying the burnt ISO that eliminates the tedium and human error of having to eyeball two hashes but I wanted to run it past everyone first. It uses dd the same way as before but rather than use md5 it uses diff and process substitution (for those who don't know process substitution is basically a convenient way to use named pipes and is a feature common to all modern shells going as far back as ksh).

With this method you're reading every byte of the ISO and the drive (using the $block count) just as before but you're avoiding all the CPU intensive hashing and instead just comparing the bytes directly.

Suggested method below:

You can verify the integrity of the burnt medium to make sure it contains no errors. Always eject the medium and reinsert it before verifying. It will guarantee that not any kernel cache will be used to read the data.

First calculate the block count of the ISO file. Although some media types deliver exactly the same amount of data as have been submitted to the burn program, many others append trailing garbage when being read. So you should restrict reading to the size of the ISO image file.

$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)

Next perform a byte comparison between the ISO file and the ISO file system on the medium.

$ diff <(dd if=/dev/sr0 bs=2048 count=$blocks) isoimage.iso
43992+0 records in
43992+0 records out
90095616 bytes (90 MB) copied, 0.359539 s, 251 MB/s

There should be no message stating the Binary files differ. If there is one, you will probably also get an I/O error message from the dd run. dmesg might then tell about SCSI errors and block numbers, if you are interested. Ksd (talk) 00:49, 20 October 2018 (UTC)

isosize, determine the size of the burnt image, and verification

Am I right that most of the discussion here about verifying the burnt image, #Verifying the burnt ISO image and #Suggestion for Verifying the burnt ISO image, revolves around the method to determine the burnt image size? In that case, was

# isosize /dev/sr0

mentioned? Doesn't it adequate for the task?

Regid (talk) 22:55, 25 November 2019 (UTC)