Rocket Division Software

Greetings!

When I try to verify the data on the damaged CD (that has some scratches and therefore data cannot be read from this disc), verification function (StarBurn_CdvdBurnerGrabber_VerifyFile) fails with message 'CStarBurn_ScsiTransportASPI::ExecuteCDB(): Command failed' without reporting the bad blocks or read retries.
The only callbacks I receive are "CN_CDVD_VERIFY_BEGIN", some "CN_CDVD_VERIFY_PROGRESS" and then "CN_CDVD_VERIFY_END".

The same behavior shows the sample application VerifyFile.exe, so I decided to capture logs with this application.

I have an Idea that this is normal StarBurn behavior, is it true? Was it planned to work this way?
What should I do if I got the verification failure with the LB number? Restart verification from the specified block number or from the next one?

Should I provide log files to you?

Thanks a lot for your answers.

Yes we need to the logs. W/o them you make us guess...

I was not sure where to send them so I attach them here.
Was I supposed to send them on info at rocketdivision.com ?

Thanks a lot for a quick reply.

actually

Attached to the forum are also OK (if compressed of course).

VerifyFile:main(): StarBurn_CdvdBurnerGrabber_VerifyFile() failed at LBA 3030, e
xception 8, status 31, text 'CStarBurn_ScsiTransportASPI::ExecuteCDB(): Command
failed'

It tells you LBA 3030 fails. If you'll analyze CDB_FAILURE_INFORMATION you'll get ASC/ASCQ of 0x10/0x00 (CRC error). So both failed LBA and extended error message are present. What's actually missing you think?

Thanks a lot again for your rapid answer!

The problem, as I think, is that verification stops afer this.

I thought that I will receive the Callbacks CN_CDVD_READ_RETRY and CN_CDVD_READ_BAD_BLOCK_HIT
and verification process will continue until the burned data will finish or I will abort it manually...

So I was mistaken? Verification will work only until the first mistake in the burned data?

Yes. If we've hit bad block after recording we don't continue to scan whole media till the end of the written data.

Thanks a lot, now I've got the idea.
And the same situation with VerifyTree? (I haven't tested it yet)

And when do callbacks CN_CDVD_READ_RETRY and CN_CDVD_READ_BAD_BLOCK_HIT will be thrown? or they will not?

And, also, another (hope that last) question: if the data on CD and in ISO/tree differs, what will StarBurn do? will it throw exception or call specific callback?

Thanks a lot for your attention, you explained a lot for me.

1) VerifyTree works in the same way as VerifyFile

2) Bad block hit is used for ripping (grabbing) when you've set "ignore bad blocks" option

3) Retry callback will be called back (sic!) if you've set number of retries >1 for Verify(...)

Sorry for a long pause, I was trying to work with it. And that's why i've got some more questions. (sorry, they are not critical, but I would like to know, if you could help.)

1) I can specify the number of retries only for Tree Verification, because for File there is no Ex function that would allow me to specify it. Am I right?

2) Is there a way to determine what file(s) are located on the specified logical block? For example, if I want to know which file I will deffinately not be able to read when verification failed.

3) Is there any way to continue verification after the first bad block? (e.g. start from the next block, use any other function, the ability to write my own verification that does so using some low-level functions...) Or I have to stop thinking about it in the context of StarBurn?

4) If I receive the "EN_SCSI_CDB_FAILED" Exception, can I suppose that this is a bad block hit or I have to analyze CDB_FAILURE_INFORMATION for an specific value to say so?

looks like that is all I would like to know now... Thanks a lot for your attention!

1) Partially. It was true up to few minutes ago. I've just added VerifyFileEx(...) API call to match the one for the tree.

2) Partially. You can lookup UDF file system structures with StarBurn_CdvdBurnerGrabber_UDFFileSystemLookup(...) and StarBurn_CdvdBurnerGrabber_UDFFileSystemLookupEx(...) API calls and later during scan process you can match failed LBA with the ones belonging to every particular file on the disc. We'll be adding the same set of calls for ISO9660 (and extensions) in the future as now we're re-working ISO9660 engine.

3) We may write down the code actually not stopping after first failed read. It does not make a lot of sense but it's not a big deal. Or you can hand-craft such a code yourself as it's probably 100 lines of code (I can send you VerifyFile(...) implementation from StarBurn.cpp as an example).

4) You need to analyze failure information to be 100% sure it's read (SCSI opcode 0x28) failed. also you'll have extended SCSI errors.

1) Thanks a lot! That would be an logical improvement!

2) The nice part is that it is possible I didn't get the idea, but I never tried working with UDF before. So, I think, I'll read about UDF and its possibilities and will understand how and when I can use it. And that fact that it will be possible in the future to get that information from an ISO/Joilet is also very interesting for me.

3) As I don't have to hurry anywhere and I work with StarBurn only as a hobby, it would be great if you give me possibility to understand how it works below the curtains of Verify(...) call.

You don't have to wonder about the reasons of this feature request and, when no one else will need it, you can even don't implement it at all. I asked for this only because it was strange for me that the single reading mistake aborts the verification process at all.
I was thinking this way: what if the user knows that disc is damaged, for example, in the beginning, but he wants to burn some data there? If the verification will never check after the first damaged block, user will never be able to find out is the other data written correctly!
I understand that the best way to use such discs is to throw them to the trash can, but still...

4) Thanks a lot, looks like I’ve got the idea.
Is there any information about CDB_FAILURE_INFORMATION values (different Sense and CDB values) somewhere in the StarBurn SDK documentation? Or is it something well-known and I have to search for it through the internet?

Thanks again for your rapid reply!

1) I though the same

2) Well... a) You burn the disc b) You make StarBurn parse metadata content and find out where particular files are located on the recorded disc. Say file "foobar.txt" occupies logical blocks 1000 thru 2000. And so on... c) You run verification test thru StarBurn and you get f.e. StarBurn in unable to read logical block 1500. You match this value with the ones from UDF metadata parse and find out failed LBA belings to file "foobar.txt".

Pretty simple

3) Absolutely!

I don't know yet... Sounds like it's not a lot of work and also it does some flexibility. So... Let us release V12 first

4) Not really as we try to avoid making our users dive TOO deep into this stuff... Grab a copy of SCSI-2 spec draft and you'll get tons of ASC/ASCQ values.