Difference between revisions of "Talk:Optical disc drive"

From ArchWiki
Jump to navigation Jump to search
(Noting that this discussion thread is outdated and obsolete)
(Noting that this discussion thread is outdated resp. obsolete)
Line 52: Line 52:
The -r and -J ensures long file names work for Unix (using Rock Ridge) and Windows (using Joliet extensions) respectively.
The -r and -J ensures long file names work for Unix (using Rock Ridge) and Windows (using Joliet extensions) respectively.
: This has been taken into respect by the recent overhaul. - [[User:Scdbackup|Scdbackup]] ([[User talk:Scdbackup|talk]]) 11:55, 9 September 2013 (UTC)
== <s>A big merge</s> ==
== <s>A big merge</s> ==

Revision as of 11:55, 9 September 2013

Command line order

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 -[Z|M] /dev/dvd-device. The synopsis is:

growisofs [-dry-run] [-dvd-compat] [-overburn] [-speed=1] -[Z|M] /dev/dvd <mkisofs-options>

so this line:

growisofs -Z /dev/cdrw -v -l -dry-run -iso-level 3 -R -J -speed=2 -joliet-long -graft-points /Magazines/=/home/citral/books/mags/

should rather be:

growisofs -dry-run -speed=2 -Z /dev/cdrw -v -l -iso-level 3 -R -J -joliet-long -graft-points /Magazines/=/home/citral/books/mags/

since -dry-run and -speed=N 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... - (Reep 15:24, 4 April 2006 (EDT))

Sounds very logical to me. Since it is your discovery, would you mind updating the page yourself? --citral 14:24, 16 July 2006 (PDT)
The disputed growisofs command fell victim to the recent overhaul. The new growisofs command examples follow the sequence of man growisofs.
Nevertheless it has to be noted that the source code of growisofs does not indicate the need for putting -Z resp. -M between growisofs-specific options and mkisofs options. (See dvd+rw-tools-7.1, growisofs.c, line 2990 ff.)
Scdbackup (talk) 11:51, 9 September 2013 (UTC)

DVD Ripping - mplayer -dumpstream

hey, I normaly just do

mplayer -dumpstream

and write it to a .vob file.

So the actual command could look like:

mplayer dvd://1 -v -dumpstream -dumpfile film.vob

Of course I get really big files this way. (3-8 gigabyte) 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. I only adopted it from [1] (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.

--Advocatusdiaboli 15:40, 10 November 2009 (EST)


Maybe some of these links have useful info? [2] [3] [4]

special burning options ?

Have think about burning following CD :

-bootable CD 
-contains audio track ( for CD player ) , any position is OK

Is such CD ( technically ) possible to burn ?

Burning files/directories throught genisoimage

make the .iso file:

# genisoimage -r -J -o cd_image.iso /directory

The -r and -J ensures long file names work for Unix (using Rock Ridge) and Windows (using Joliet extensions) respectively.

This has been taken into respect by the recent overhaul. - Scdbackup (talk) 11:55, 9 September 2013 (UTC)

A big merge

This page is the result of the merger of pages:

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. For more detail see https://wiki.archlinux.org/index.php/Talk:CD_Burning Veleno (talk) 15:31, 22 July 2013 (UTC)

How to contribute as upstream developer ?

Being the developer of libburn i see that you are consolidating 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 be better to leave the wiki work to a person who is not involved in the competing burn software for archlinux ? (I have no experience with this wiki software. Beware.)

What i would change:

  1. Clean out burn war rethorics (mainly cdrkit vs. cdrtools)
  2. Move ISO 9660 stuff before burning stuff
  3. Add my own packages libburn, libisofs, libisoburn to the list
  4. Unify the command names used in examples
  5. Clarify some technical facts

I have a more detailed list of change proposals. 150 lines. Shall i post it here ? 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.Veleno (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 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 -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: export MKISOFS="genisoimage" or 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 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"
  • Rather than to "Note: growisofs is basically just a front-end to mkisofs" 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 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: dvd+rw-format -force /dev/cdrw or cdrskin -v dev=/dev/cdrw blank=format_overwrite or 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.
Scdbackup (talk) 21:52, 26 July 2013 (UTC)
As an example of how i would implement my proposals, i have now added an overview of available burn tools and a note about the workaround for the BD-R bug of growisofs. (Sorry for not giving an appropriate summary with the change of 09:46, 27 July 2013.) I hope not to have deleted any valuable information from that section. Please confirm that i shall go on. Scdbackup (talk) 09:59, 27 July 2013 (UTC)
Please do not make too many changes in the same post (except for corrections of form and syntax), this could possibly create problems for those who follow the message. This is a very big change! I can not say if everything is correct, but I can express my thoughts. I believe that greater clarity and cleanliness can be good, currently there are six main sections:
  1. CD burning
  2. DVD burning
  3. DVD playing
  4. Burning CD/DVD with a GUI
  5. DVD ripping
  6. Troubleshooting
This layout is derived from the combination of multiple pages (see discussion above), and there is no reason to improve their formatting. Now this page is aptly titled "Optical Disc Drive" because it contains generically any existing optical drive, past and future. (cd, dvd, bluray disc), then it is possible to recast the sections on the basis of this principle. But there is a feature to be taken into account, namely that the first part describes the tools you need and how to use the command line. An exception is the chapter "Burning CD/DVD with a GUI" as this comes from another page List of Applications/Multimedia, and I think it should remain the same (you can possibly change the title). . For example:
  • Create a new primary section Install burning utilities (which contains all the tools to burn CD/DVD/BD, merge #CD burning and #DVD burning)
  • Create a new secondary section ODD Playing (or similar), which includes all references to playing CD/DVD/BD (to replace #DVD playing)
  • Create a new thirdy section ODD ripping (or similar), which includes all references to ripping CD/DVD/BD (to replace #DVD ripping)
  • Preserve #Burning CD/DVD with a GUI (this must be a list of GUI), enventually changed the title in best ones, example Graphics Interface
  • Preserve #Troubleshooting, to include all trouble in a single sections.
These could be major changes sensible: E for everyone decide the content. Each operation must be done patiently, without changing everything at once. What do you think?Veleno (talk) 10:32, 27 July 2013 (UTC)
Sorry for the size of my proposal and the perky change of the wiki. The latter should be harmless because it just lists the known free programs and leads the user to those programs which are mentioned in the following sections.
It is desirable to unify the description of burning of CD, DVD, BD. The existing sections overlap by us other programmers intruding into the realm of growisofs. :))
Ripping of CD, DVD, and BD is mostly out of my scope. But i know that the challenges with CD differ significantly from those with DVD and BD.
I have no user experience with the GUI programs. Mostly i know them from troubleshooting their backend programs.
The troubleshooting section is currently totally missing my kind of trouble: write errors, speed problems, limitations of media types, ... Is there a bug database where to fish for such reports ?
On a side note: Why does the query https://www.archlinux.org/packages/?name=isomaster not find https://aur.archlinux.org/packages/isomaster/ ? How to create a link in the wiki ?
Scdbackup (talk) 12:00, 27 July 2013 (UTC)
Wow sorry for delaying my answer but it took me ages to go through all this thread :) Welcome to the ArchWiki! Let's begin:
>>Would it be welcome if i make substantial changes, or would it be better to leave the wiki work to a person who is not involved in the competing burn software for archlinux ?
Yes it would be more than welcome, as long as you split your changes in several edits, not only a single (nor just a few) big one. Each edit must be accompanied by a proper Edit Summary, see also Help:Style#Edit summary.
>>(I have no experience with this wiki software. Beware.)
I think you're doing well until now, wiki markup is designed to be easy to use; you may find some useful guidelines in Help:Editing and related.
Regarding the changes that you want to apply to this article, I think that overall they are going to be a huge improvement: you show a high degree of competence on the subject (obviously, being the developer of an optical media management library), so I think you can do a very good job. I can't really judge the correctness of the information you're going to add, but this is a wiki, so as long as you write in an objective, unbiased way, you can go and share your knowledge with the community, which will be thankful for that ;)
>>The troubleshooting section is currently totally missing my kind of trouble: write errors, speed problems, limitations of media types, ... Is there a bug database where to fish for such reports ?
Are you talking about upstream bugs? I don't think so because being a developer you know that they must be reported upstream ^^ If they're bugs specific to the Arch versions of the affected packages, you should use https://bugs.archlinux.org/ Otherwise if they are just issues that must be solved on a per-user basis, just use the Troubleshooting section of this article.
>>On a side note: Why does the query https://www.archlinux.org/packages/?name=isomaster not find https://aur.archlinux.org/packages/isomaster/ ? How to create a link in the wiki ?
That query doesn't work because isomasterAUR is a package in the AUR, not in the official repositories: if you're not familiar with the Arch Linux repository system, you can start reading those two articles. In order to link to packages, you should use Template:Pkg or Template:AUR (follow those links for usage guidelines), e.g. isomasterAUR. About links, see Help:Editing#Links.
-- Kynikos (talk) 05:42, 28 July 2013 (UTC)
hi, kinikos. The user has raised issues to improve the entire section on the creation of images and burning. This leads to a big change of the whole part for CD burnig and DVD burning, which no longer need to exist separated, and therefore is a complete review of all that section. It's a big change, and I do not have much technical expertise to check everything on Arch Linux system. I have now done via email to work on his page to a draft (https://wiki.archlinux.org/index.php/User_talk:Scdbackup#Burning), as the changes are radical. He is doing a magnificent job, the problem and how to apply it step by step in the wiki. As you know this type of job, extra-translation, i are not yet accustomed. If you need you can also contact me via email.Veleno (talk) 07:13, 28 July 2013 (UTC)
We are going to apply the changes discussed here. We will carry out a fusion of the first two chapters CD burning and DVD burning in one section called Burning (at maximum you could then rename it to ODD burning, you accept tips). Then the section Burning CD/DVD with a GUI will be included in the new section as a sub-section. Veleno (talk) 10:10, 30 July 2013 (UTC)
I have now transfered the first three sections. Please have a look at my Summary notes, whether they are ok. Ping me by email when i shall go on.
I plan to first transfer all new sections, overwriting those sections which match 1:1. The big section "DVD burning" will stay until all replacements are done. Then it will be obsolete and i will delete it.
Finally i want to re-arrange the new options to the sequence that is shown in my template.
Correct me if this plan is not good.
Scdbackup (talk) 11:35, 30 July 2013 (UTC)
Small change of plan: I will put the updated sections to the places where they finally shall end up. So the step about re-arranging them is not needed.
Scdbackup (talk) 12:59, 30 July 2013 (UTC)
As no opposition to this restructuring has been shown in this discussion since it was started, I'd say you can go on more liberally with your changes, without the need for introducing each of them here, as long as you keep accompanying your edits with proper edit Summaries (thank you for your diligence in doing it btw). -- Kynikos (talk) 15:16, 31 July 2013 (UTC)
I have now copied the new and updated sections into the wiki page.
Regrettably i messed up the change log at a few occasions:
  • 15:41, 31 July 2013 : I removed the wrong old section.
  • 15:52, 31 July 2013 : Removes the surviving old section of 15:41 but the summary should say "This should have been done *three* changes before"
  • 16:01, 31 July 2013 : Copied in the wrong new section.
  • 16:02, 31 July 2013 : Put the right new section to the wrong new place.
Is this bad enough to roll back and do it again ? Elsewise i would be done now.
Scdbackup (talk) 17:18, 31 July 2013 (UTC)
Eheh that's not bad at all, if only everybody documented all the changes like you've done... ;) -- Kynikos (talk) 13:51, 2 August 2013 (UTC)
About the upstream bugs: It is rare that a distro does not stockpile them in its own bug tracker. Me upstream usually googles to find them. (Of course package maintainers are invited to forward them.)
I want to thank you guys for the friendly and tolerant reception here. :))
Scdbackup (talk) 12:33, 30 July 2013 (UTC)
Arch Linux's official bug tracker is https://bugs.archlinux.org/
Thank you for choosing to contribute to our wiki: your work will not only be useful to Arch users, but very likely to many users of other distributions, just like I can assume you are ^^
-- Kynikos (talk) 15:16, 31 July 2013 (UTC)
I am using a very old installation of a german distro. But as upstream i take care to stay neutral. I took Veleno's effort as opportunity to clean out urban legends which annoy me at least once per month.
Although today i got a report that cdrecord burns 6x BD-R faster than cdrskin (only at 4x). If i don't find a plausible explanation soon, then a new legend is born.
Scdbackup (talk) 15:33, 31 July 2013 (UTC)
I merged Burning CD/DVD/BD with a GUI into main section Burning, because the programs listed are used to burning.You are welcome in the arch wiki system and thanks for your technical support. Now this page is more cleaned and comprehensible. Remember to follow the page to stay informed of any changes. More developers should take your example and participate in the drafting of the main wiki (Debian. gentoo, slackware and Arch). Users do what they can, but a contribution of the developer can be enlightening in many cases (my personal thought). Again, thank you for choosing the Arch wiki and especially for your objectivity in proposing changes. (this is what you need for a documentation). In the future, feel free to prepare minor changes to the page (also concerning the other sections if you want), while substantial changes can always discuss here. I think this discussion is now complete.Veleno (talk) 10:27, 1 August 2013 (UTC)
Well then: Good bye for now. My mail address is in my user profile. Just in case there is need to clarify my statements or to describe new technical aspects (holo disc is still only at the far horizon).
Scdbackup (talk) 12:08, 1 August 2013 (UTC)
Bye bye, good job Scdbackup and Veleno! Closed. -- Kynikos (talk) 13:51, 2 August 2013 (UTC)

May i remove the Accuracy tag from the article's start ?

I am biased, of course, as i provided new facts and proofreading of old ones.

Nevertheless, the discussion thread ended in consensus. So at least the tag should not point to that thread any more. (I would be interested to learn about any remaining objections or doubts.) Scdbackup (talk) 20:19, 28 August 2013 (UTC)

Yes please, just remove the Accuracy tag. User:Foxxx0 has made an interesting observation in #Verifying the burnt ISO image, you may want to reply him. -- Kynikos (talk) 13:42, 29 August 2013 (UTC)
Done now, after i changed the size determination command from ls to du. Please see my second reply to the aliasing problem. Maybe this needs more attention. Scdbackup (talk) 16:06, 29 August 2013 (UTC)

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)
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)