Talk:Optical disc drive

From ArchWiki
(Redirected from Talk:DVD Burning)
Jump to: navigation, search

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

Unfortunate re-introduction of cdrtools war aspects

I am unhappy with changes

03:52, 22 December 2013 Fleetwood

04:04, 22 December 2013 Fleetwood

which add "mkisofs" to explanations which apply to all three compatible programs and not specifically to mkisofs.

Firstly, this unnecessarily refers to unpleasant discussions about who is right with optical drives and software licenses.

Secondly, if "or mkisofs" gets sprinkled all over the text, then i would feel discriminated, if it would not become "or mkisofs or xorrisofs". (I am the developer of the latter.)

How should i proceed ? Is there a way to contact Fleetwood about this issue ? We seem to have technical interests in common.

Scdbackup (talk) 16:39, 28 December 2013 (UTC)

You can try to send him an email, but I think you should see this report first: ArchWiki_talk:Reports#cdrtools_page.
I'm not acquainted with any of these tools, but I have the impression that the previous wording was better - especially with regard to the example commands.
-- Lahwaacz (talk) 17:50, 28 December 2013 (UTC)
Ahum ... so my gut feeling was right: Beginning quarrel. The next traditional step of escalation would be hostile editing, accusation, counter-accusation, and finally mutual declaration of being clueless.
Reading the diff since my last visit:
i would say that the larger changes are not better or worse than what was stated before. No false claims. Just more words.
But i uphold my warning that the two mentioned changesets begin to revert my efforts of last summer. See above:
Was Fleetwood already contacted about this issue ?
Scdbackup (talk) 19:08, 28 December 2013 (UTC)
I did not try to contact him except for several posts on talk pages. And don't worry, your effort will certainly not come in vain ;)
Perhaps this "war" thing is the reason why his edits were not accepted on Wikipedia? This quarrel you described might have happened there before, and their approach might be the best (relative to maintenance).
One more thing: the original questionable edits by Fleetwood (see [1]) were amended by Fengchao and Kynikos ([2], [3], [4] and [5]), but they were style changes only and are irrelevant to the real problem (perfect style is useless without good content).
-- Lahwaacz (talk) 20:41, 28 December 2013 (UTC)
I wrote a mail meanwhile, asking for consent to remove the newly introduced explicit mentionings of mkisofs.
The war thing is based on a longstanding feud between Joerg Schilling on one side and Linux kernel developers plus distro packers on the other side. Since then, discussions about optical drive burning and ISO 9660 production are synonyms for "flame war".
In 2006 it resulted in forking of Debian's cdrkit from Joerg's cdrtools. At the same time, i joined the libburnia project to beef up libburn to a competitive level. My main motivation is to free the topics from the eternal quarrel. (Still working on that :))
My plan for correcting the changes is to just remove the surplus occurences of mkisofs. I am not a native speaker of english, and also somewhat too much involved in the technical entrails. So Fleetwood's other changes might well be appropriate, language-wise. As said: technically they are not wrong.
Scdbackup (talk) 20:58, 28 December 2013 (UTC)
(Just adding that Fleetwood seems active on his User page, maybe a message in User talk:Fleetwood could be effective.) -- Kynikos (talk) 03:43, 29 December 2013 (UTC)
I now posted an offer for cooperation there. Fleetwood obviously explores all kinds of optical disc software. A special bias for cdrtools is not to detect.
Scdbackup (talk) 11:02, 29 December 2013 (UTC)
The surplus mentionings of "mkisofs" are removed now. See
As a general rule of thumb, i propose to mention "genisoimage" where any of the compatible programs would work. The existence of these programs is explained already at the begginning of the article.
Scdbackup (talk) 09:09, 29 January 2014 (UTC)

Closing: cdrkit will be dropped.[6] Lonaowna (talk) 11:14, 22 January 2017 (UTC)

k3b troubleshooting

is the k3b troubleshooting section still valid? the bbs entry is from 2007, additionally the default character set is UTF-8 for quite some time. --Soloturn (talk) 20:53, 4 January 2017 (UTC)

Likely not, I've deleted it. Lonaowna (talk) 11:12, 22 January 2017 (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)