Cdrecord TAO burn glitch - two extra sectors

Please post any bugs you have found
Post Reply
Message
Author
kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

Cdrecord TAO burn glitch - two extra sectors

#1 Post by kethd »

Puppy seems not capable of burning a perfect CD from ISO!

Burniso2cd and Graveman use cdrecord to burn in TAO mode. In this mode, two extra phantom null run-out sectors of padding are added at the end. These do not seem to affect most normal uses. But they make readcd think the CD is two sectors longer than it actually is, in terms of the real data-contents. So if you read the CD back into an ISO file, it will be too long, and the md5sum will not be correct. In addition, on some drives, readcd will generate errors when trying to read the two extra trailing sectors. The workaround is to use isoinfo to find out the real size, and then use the sectors=0-isosize parameter in readcd to get a good read into an iso file of the right size. This is not user friendly -- maybe someone could do a little script for Puppy?

But DAO mode, which would burn perfect CDs from ISO, does not work in Puppy. Using the -dao switch in cdrecord generates "WARNING: Drive returns wrong startsec - using -150" weird message, and the burn fail soon after starting -- another coaster.

These problems are not specific to Puppy. TAO vs. DAO extra-trailing-sectors is a general issue. Using -dao is a general problem with cdrecord. However, it is possible to use cdrecord successfully to make a perfect CD in DAO mode. K3b in Knoppix 4.0.2CD does it. Presumably it is a matter of using the right version of cdrecord with the right Linux kernel (during the right phase of the moon?)

The other way to get a perfect burn would be to use Windows (Nero)...

It would be an improvement if Graveman showed the cdrecord command line it uses, and the messages generated -- or at least told you where to look for messages when there is an error. It is odd that Graveman offers DAO mode when creating a data CD, but not when burning a CD from ISO file (Duplicate CD). I don't know if cdrdao would help, but it does not seem to be included in Puppy. I suspect that Puppy Graveman cannot currently do any DAO burning properly.

Problem observed in Puppy 1.0.5, 1.0.7, 1.0.8r1, with both CD-RW and DVD-RW drives.

Sample commands:
# mkdir /extra
# mount tmpfs /extra -t tmpfs -o size=950m
# cd /extra
# isoinfo -d -i /dev/hdc
# readcd -v dev=ATAPI:/dev/hdc f=cd.iso retries=3
# md5sum cd.iso
# cdrecord -data -dummy -v -dao speed=4 dev=ATAPI:/dev/hdc cd.iso

The best introduction to this issue:
http://www.troubleshooters.com/linux/coasterless.htm
http://memebeam.org/toys/WritingCdromsRight
http://cdrecord.berlios.de/old/private/ ... EADME.copy

People discussing the problem:
http://lists.debian.org/cdwrite/2005/05/msg00107.html
http://lists.debian.org/debian-cd/2004/11/msg00026.html
http://www.ussg.iu.edu/hypermail/linux/ ... /0231.html
https://www.redhat.com/archives/shrike- ... 00666.html

The manual pages:
http://linuxcommand.org/man_pages/isoinfo8.html
http://linuxcommand.org/man_pages/readcd1.html
http://linuxcommand.org/man_pages/cdrecord1.html
http://linuxcommand.org/man_pages/cdrdao1.html
http://linuxcommand.org/man_pages/isosize8.html

The sources:
http://cdrecord.berlios.de/old/private/cdrecord.html
http://freshmeat.net/projects/cdrecord/
Maybe there is an ongoing war between cdrecord author and Linux kernel?

After days of studying this, I have found no powerful tool for looking at a CD TOC etc and telling you everything about what is there -- both the real size, the total extended capacity size, etc. Is there such a utility? What about isobuster?

See also:
http://www.murga.org/%7Epuppy/viewtopic.php?t=6796
How to make iso file from CD with readcd

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

cdrdao, yes, there is an unleashed cdrdao package, but it isn't in the live-cd.

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#3 Post by kethd »

Perfect, simple self-reproduction is a target core competency for LiveCDs such as Puppy... Could future versions please include cdrdao? Then maybe burniso2cd and graveman could use it?

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#4 Post by GuestToo »

burniso2cd always seems to work for me ... i always check the md5sum of the cd after burning it, to see if it matches the md5sum of the iso ... i've found that most of the time, the simple method of checking the md5sum of the cd seems to work:

md5sum /dev/hdc

this does not always work, because of padding bytes or the read-ahead-bug ... if the simple method doesn't work, using dd to read the exact number of bytes from the cd that were in the iso file usually seems to work ... the programs i wrote to check the md5sums of Puppy cds to see if they had burned correctly, use the dd method (it's on the coasterless webpage)

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#5 Post by kethd »

(The problem is not that there is something "really" wrong with the CDs being burned. The problem is that there are "issues", which are so complex they took me days of research/struggle to understand -- and which most people would never bother to go to so much trouble over. They would just assume there was something wrong with Puppy, or their hardware, or Linux...)

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

What a pleasant surprise...

#6 Post by irlandes »

I have been working several days on this exact problem. But, my findings are different.

I have a Dell Inspiron 2650 with TEAC writer. I was using Windows/Roxio to burn iso cd's for a long time because Mandriva LE 2005 would not write them without the input/output error on md5sum, though the live cd's would actually work fine.

Then, I discovered Puppy 1.06 and it worked fine for iso's

So, when Puppy 2.0x was announced, I thought, hey great!

Alas, puppy 2.00 also produced the same identical input/output error.

I googled again, and this time someone suggested it had to be dao mode, and someone else said, no, it had to be tao mode. Hee, hee.

Well, I looked in Mandriva, and discovered K3B write mode was auto, and it used TAO, which didn't work. As soon as I changed it to dao mode it burned perfect iso cd's.

I looked in burniso2cd script file, and discovered there was no call-out for dao or tao, and the cdrecord thus defaulted to tao, which caused cd's to be input/output error. I opened up burniso2cd script file, and played with it. I learned that if I added -dao after each cdrecord call, it would then come up with perfect cd, and perfect md5sum for /dev/hdc (not /dev/cdrom as usual.)

I thought, hey, I will remaster, using remasterpup2.

OOOPS!!!!!!!!!

remasterpup2 also calls out cdrecord, and big as punch it has -tao in it. I suppose I can remaster if I find a machine which will write correctly in tao, but don't know where here in the Third World to find another machine.

Here is the rub, and I will be looking for answers. I cannot modify and save remasterpup2 because it is in initrd.gz which is read-only.

If I mount the iso as loopback file, it is still read-only, and I have been unable to get it mounted as rw mode.

I can copy initrd.gz in another folder, and can thus extract it, but I have not wasted my time mounting it as loop since there is at this time no way to put the modified file back in the iso that is read-only. (Note that while the cd is running live, the basic file system is changeable, and writable with geany, but some stuff is in initrd.gz which is not writable.)

After considerable work, including taking burniso2cd and cdrecord from 1.06 and putting it in 2.01 (where it also fails), and from 2.01 and putting it in 1.06 (where it also works) I have concluded that cdrecord project manager Schillig is correct, and that the 2.6 kernel does not support cdrecord on some brands of writers. In one case here, someone could not get it to work on dao, and for me it works fine on my TEAC on dao.

I have downloaded the latest alpha cdrtools, and will try them tomorrow.

I don't like to make suggestions when I can't do the programming. But, it looks to me like puppy needs to be changed very slightly, until a cdrecord is found that will work on puppy's kernel, so that any of the utilities that run cdrecord add a BUTTON TO SELECT the different modes, tao, dao, etc, for those writers which fail in current default modes. There may be some writers which will fail both ways, but so far haven't seen one.

I can change it on burniso2cd, and could remaster it thus, but on my machine, remasterpup2 calls out tao, and I can't access initrd.gz both ways to change it. And, I don't plan on editing each time, and a bad cd is simply not something I will tolerate.

I will try to keep posted if I have any luck.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

Fixes posted on other forum...

#7 Post by irlandes »

http://www.puppyos.com/nfphpbb/viewtopi ... =1675#1675

Works on my writer, simple changes to make to burniso2cd and to remasterpup2, based on reading may work on a large number of writers. Now produces perfect md5sum iso's

I will look at Graveman next. Busy building a house here in the Third World. I think it will be easy enough to fix, but I had sources for 0.3.12 and it won't compile on my OS's. So, I just downloaded 0.3.8 same as puppy 2.0x.

Since I am not a real programmer, it might take a bit of time to sort it out for Graveman.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

To OP...

#8 Post by irlandes »

Kethd, You can look at the development of the Graveman command line. Get the correct sources, extract them, go to, I think it's the sources folder. Look in cdrecord, and open cdrecord.c with a editor, geany works fine. This is not cdrecord, but the program which Graveman uses to send the command line to cdrecord.

if you do an editor search for the word cdrecord in cdrecord.c, there will be a number of hits. if you study them, there are at least two places where a command line is built, might be Lcommand line or something like that. The French might slow you up, but should not stop you. There is a standard C print line, with %/ or a symbol something like that, for each following thing to be printed and there are many of them. Each item printed, or most of them have conditions set whether to print or not.

this might help. In C, this is a standard condition statement:

EXPR1 ? EXPR 2 EXPR3

I hope I got that right. :) If EXPR1 is true, value is set to EXPR2. If Expr 1 is zero, value is set to expr 3. Most of the command line I mentioned has expr 2 the word to be sent, and expr3 is "" that is null string.

For example, -dummy only prints if a simul variable is set by a wdget library (i.e. user operated button or select in the Graveman window). You can see -speed even if you can't read the French word for velocity, and -driveropts=burnfree is also obvious. Etc.

both data and audio burns have a choice for dao or tao, but it does not have them for iso burn. Since my fixes let me burn with burniso2cd, I don't need it. But, at this point, I need to study some more to see if the data command line is the same one as used for iso burn.

In any case, if I can find exactly where to put the word -dao for iso burn, it will be a simple edit/compile and if necessary the cdrecord file produced can be transported separate from sources, it is only around 375KB and should work on all linux distros by plunking it in place of the current cdrecord.

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

great!

#9 Post by raffy »

Thanks very much for your attention, guys! CD burning is at the heart of Puppy and it's reassuring to know of your efforts to perfect it. :)

marksouth2000
Posts: 622
Joined: Wed 05 Apr 2006, 20:43

Re: Cdrecord TAO burn glitch - two extra sectors

#10 Post by marksouth2000 »

kethd wrote:Using the -dao switch in cdrecord generates "WARNING: Drive returns wrong startsec - using -150" weird message, and the burn fail soon after starting -- another coaster.
The "drive returns wrong startsec" warning is just that, a warning. CDrecord returns that for MOST drives, apparently. It does not automatically lead to a failed burn. I have an LG combo drive and a Samsung DVD burner that both get that warning and both produce perfect burns. So problem is elsewhere.
The other way to get a perfect burn would be to use Windows (Nero)...
Many of us are getting perfect burns within Linux. Problems are due to the combination of hardware and soaftware and bad luck, mostly.

BTW, if you do believe that only Nero will burn correctly, why not use Nero for Linux? It comes free with a lot of burners these days.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

As I said...

#11 Post by irlandes »

on the other forum, personal opinions by definition are subject to being wrong. But, at this time, my personal opinion is that this problem is related to model of cd writer, not just some sort of random luck factor.

And, of course, to the kernel. The kernal guys blame Schilling, and Schilling blames the kernel guys. If you read his comments on freshmeat, and in the cdrecord sources, he is not real nice about it. cdrecord worked perfectly in the 2.4 kernel, which is what we have been using so successfully in puppy until now.

I am betting on Schilling at this point.

Since some writers work fine, that tells me there is a fix ,or maybe a different system, but I am sure no writer producer is going to spend lots of money for essentially just puppy, since the big distros with K3b really don't have an insurmountable problem with this.

The problem is, if the kernel guys keep blaming him, they aren't going to fix this, now or on next version kernel. So, yeah, we might as well plan on not using cdrecord unless we have a great front-end like k3b, which is probably a bit builky for a minimalist distro.

I did get CD's from remasterpup2 which will accept added files using K3b/cdrao, in spite of technical definitions which seem to say this is not possible. But, I can't add files in Graveman. So, as I said on other forum, something has to give.

I will be trying the old kernel when I get time. I had planned on tweaking Graveman to run DAO in iso-burn, but though it doesn't look to be that hard, the bleak prognosis has decided me not to waste my time. I Have already said I got burniso2cd and remasterpup2 to burn verifiable and duplicable iso's, but it will still lack multisession.

Can you guys tell us which brand works and doesn't work for you? It may or may not give us any clues. Thanks.

marksouth2000
Posts: 622
Joined: Wed 05 Apr 2006, 20:43

Re: As I said...

#12 Post by marksouth2000 »

irlandes wrote:But, at this time, my personal opinion is that this problem is related to model of cd writer, not just some sort of random luck factor.
As I said in my post above yours, "Problems are due to the combination of hardware and soaftware and bad luck, mostly. "
And, of course, to the kernel. The kernal guys blame Schilling, and Schilling blames the kernel guys. If you read his comments on freshmeat, and in the cdrecord sources, he is not real nice about it. cdrecord worked perfectly in the 2.4 kernel, which is what we have been using so successfully in puppy until now.

I am betting on Schilling at this point.
Don't hold your breath. He's really only focusing on supporting Solaris these days. The dispute with the kernel guys is never going to be resolved. He's annoyed that they changed the kernel API. They state in the design docs that there are no guaranteed unchanging kernel APIs.

He didn't make things any better when he attempted to change the licence, and the mess about the key mechanism for dvdrecord has pretty well marginalised him - if he hates his user community, how can one hope that he'll make things work for them?

Incidentally, I met Schilling once about a decade ago, when my organisation and his were collaborating on a euro-project. He seemed far milder than one would imagine from his published polemics.

The best hope is that we can find a way to live without cdrecord, somehow.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

Oops!!

#13 Post by irlandes »

What I meant to say is that I think Schilling is probably right that the kernel guys screwed up. I absolutely agree that he will not spend one second to fix the problem for Linux. In fact, he makes that perfectly clear.

Certainly kernel programmers can do whatever they wish. That is the whole idea of open source.

However, since it is obvious they knew what his design standards were, ignoring those standards means the kernel guys are at least logically responsible for failure of cdrecord with 2.6.

That is fine. The problem is too many people rely on cdrecord, including the whole puppy structure, thus ignoring his standards means the kernel guys have caused a lot of grief to a lot of people. We need to put cdrecord behind us since it is apparent there is no future for it in Linux, unless someone takes it over and fixes it.

If I had the capacity, I sure would, but my background incudes little programming as such. I started on microprocessors in 1974, but my specialty was taking the assembly listings for the embedded systems we worked on, and making sense out of them so we could fix our problems. That meant I became sort of mulitlingual on programs, but never actually wrote programs (except a couple minor ones, no more than two weeks on my biggest project which came after our programming team bid over $100,000 to do the job. i wish I had been paid $100,000 for that two weeks work.)

I realize there are always more ways than one to view things. That's why I often like to say this is my personal opinion, and am well aware personal opinion is just that. So, I am well aware intelligent people may have a completely different view of the Schilling controversy.

The question is what to do about it. I have changed my mind, after a good night's thinking it over, and I am going to see if I can rewrite remasterpup2 and burniso2cd for cdrdao. And, if I can make that work, which remains to be seen, (plus Barry may beat me to it since he has a lot more experience at it) then maybe I can bastardize Graveman to make it work in cdrdao as well. I woke up with an idea how to do that, though the Graveman team may need smelling salts. :)

In fact, I think that is the correct response to Schilling/kernel group conflict, learn to get along without cdrecord. Even K3b failed for me, and it was a year before I had a clue all I had to do was change to DAO, and that simply is not good for Linux.

One thing that will help is those whose writers work and don't work let us know so the smartest people can figure out what the extent of the problem is. Mine is TEAC W224-E and it doesn't work in puppy 2.0x but does work for iso's with my mods on burniso2cd and remasterpup2, except for multisession of course.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

Update...

#14 Post by irlandes »

I was digging a lot, to get stuff to work with when I go home later.

I found on Graveman page that starting with v. 3.9 Graveman uses cdrdao to make copies. Guess we know why. When I get home, I will try to build, and see if it really works. The catch for puppy is it needs cdrdao, which on my Mandriva is around 539K.

If this works, that's one down the tubes, and the hardest one at that. Will keep you posted.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#15 Post by BarryK »

I tested the latest Graveman last week, and posted a bug report to the developer.
Yes, it uses cdrdao, and I also installed the latest cdrdao. But, got a burn error.
I think I posted a report on this to my Developer News page.

irlandes
Posts: 13
Joined: Sun 25 Jun 2006, 01:07

I have had bad luck on Graveman...

#16 Post by irlandes »

I downloaded them all, tarballs, 0.3.9; 10; 11; and 12.5 (?). and set them up on my laptop with Mandriva because it has the required stuff to compile. I ran them on Mandriva.

3.9 compiled; ran okay, but md5sum on iso had input/output error.

3.10 would not install. I had to mkdir several directories to get a clean install, then it ran, but iso had input/output error.

3.11 as soon as I called it via terminal command, it started spitting out assertion failures, on that, um, g_hash_table_lookup or something like that, that they use to develop a lot of variables, and eventually crashed.

3.12.5 (?) compiled and installed okay, but when I tried to burn an iso, it wouldn't even give me a solid burn button.

I have not yet produced the latest cdrdao.

I am trying to verify if the remasterpup2 actually provides a open multisession or not. I sure can't get puppy to save on shutdown, and will continue to find out why.

One interesting thing, K3b uses an undocumented command when calling cdrdao, to burn from a iso file on HD, in multisession mode, --remote followed by a hashed file name in /tmp which seems to hold only basic file name and location --unless I missed it in man. I will try to get my hands on Mandrake source as well as google for it.

Well, maybe one of us will get lucky.

Um, also I made a number of cd's of remastered, with multisession, and Graveman would add to them more files in DAtaCD, if I put it in TAO mode, and do not fixate. So, that part works.

I just noticed that in remasterpup2, there is no --nofix so I need to look at that again.

Well, down but not out. :)

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#17 Post by miriam »

I've lately been having problems burning iso to CD. I thought those were well behind me, but I have a feeling my new computer's CD/DVD drive is the culprit. In the end I managed to burn the iso from the command line using:

Code: Select all

cdrecord -multi -data -eject -v speed=4 dev=ATAPI:/dev/sr0 "blah.iso"
I wonder what is going on...

I'll experiment more when I get back home tonight...
[color=blue]A life! Cool! Where can I download one of those from?[/color]

Post Reply