Jump to content
ThomasB

Verifying all write tasks

Recommended Posts

Hello, I have just begun using CDBurnerXP.

If I understood correctly, verifying after a write process is not supported for all tasks. For example copying CDs, or burning audio CDs, do not have a verify feature. I see it is supported for burning ISO images.

It would be nice to be able to verify all write operations.

Can you list me all tasks which currently support verification after write?

Thanks.

Share this post


Link to post
Share on other sites

It is indeed not supported for all tasks. For audio discs verification is in fact not possible, doesn't make much sense from a technial perspective.

Share this post


Link to post
Share on other sites

Is it the same for video DVDs, that it doesn't make much sense technically?

What about copying discs (any format)? Is verification supported? (Have not tried yet.)

Thanks.

Share this post


Link to post
Share on other sites

Forgive my lack of comprehension, but why are audio discs not verifiable? If the data was known once to write, shouldn't it be known again to read? Even if the hardware performs some sort of algorithm on it, couldn't that be emulated/reversed?

I also would appreciate as much verification as possible. :)

Share this post


Link to post
Share on other sites

Audio data is written with much less error correction data than data discs, so it is in fact quite likely that the resulting disc cannot be read 100% accurately. But even if there are errors, it doesn't result in the audio data being corrupt, as opposed to usual data.

So since audio discs are not meant to ensure "data integrity", it doesn't make much sense to verify the data.

Share this post


Link to post
Share on other sites

This is a terrible decision.  It is an absolute stopper for me.  I used CDBurnerXP for a while some years ago, and stopped when it wouldn't verify audio.  I check back every few years to see if it got fixed.

Your observation that CD's have no CRC codes has nothing to do with whether the data written matches the data on the disk.  True, if a bit is wrong on a data disk, a program MIGHT crash, but it might work just fine, from the point of view of a user.  E.g. it might have a graphics file or rarely used data table the bit is in.  What you are saying in essence, is the output of us audio guys is SIMPLY LESS IMPORTANT!  What conceit!  A wrong bit MIGHT not be heard, but it can also result in a fairly loud audible pop!

floele writes:

Quote

Audio data is written with much less error correction data than data discs, so it is in fact quite likely that the resulting disc cannot be read 100% accurately.

THIS IS JUST NOT TRUE!  First off, on data CD's or DVD's, you have a CRC value.  To my knowledge, it corrects NOTHING!  It only is used to signal if there has been a data error.  How many data CD's have you had get a data error?  Probably more than a few, but also probably not most of the time.  There is nothing about the lack of a checksum that prevents audio CD's from being read just as reliably.  I have never heard that audio CD's tend to have a greater error rate when read than data CD's; although they will detect errors, unlike audio CD's.  If audio CD's did have frequent errors, you would get frequent pops and glitching when you played them.

If you own a recording studio, DO NOT USE CDBurnerXP to burn CD's, or your customer may find a pop or glitch caused by the burn, and it will go undetected.

ImgBurn does verify audio CD's as it should; but it insists on installing OpenCandy malware with no option to opt out (as of this date).  Nero verifies audio CD's.  There's no reason in the world why CDBurnerXP can't, except a choice by the developer(s).

Share this post


Link to post
Share on other sites
Quote

THIS IS JUST NOT TRUE!  First off, on data CD's or DVD's, you have a CRC value.  To my knowledge, it corrects NOTHING!

I don't think so. Please check the details at:
https://en.wikipedia.org/wiki/CD-ROM#CD-ROM_format

There is both error correction and detection data included (Mode 1).

Quote

ImgBurn does verify audio CD's as it should

You could in theory try to compare the original audio data with the audio data burned to the disc, but it may easily lead to detecting errors incorrectly because not all incorrectly read bytes necessarily result in a playback issue.

Just out of curiosity, I asked StarBurn about this (vendor of the burning library).

First of all,

Quote

There's no way to verify audio content. Neither with StarBurn nor with anything on Earth. There's no error correction codes embedded into raw CD sectors written. So grabbed tracks may be different from the ones you've recorded.

http://www.starburnsoftware.com/forum/starburn-sdk-f3/audio-burner-verify-t1272.html

So there is not "the developers" that decide it cannot be done, it's simply a technical limitation. So why can other applications do this? As far as they know, such applications compare characteristics of the burned audio file with the original audio ("does it sound the same, more or less?"), and do not attempt a bytewise comparison.

If you need a perfect copy of your audio data at all cost, you must burn your WAV files (or whatever source files you prefer) as data disc. Result of this is - of course - a lower disc capacity because of the additional error correction and detection data included.

Share this post


Link to post
Share on other sites
Quote

So there is not "the developers" that decide it cannot be done, it's simply a technical limitation.

That to me doesn't demonstrate a limitation.  Lack of error correction and crc data does not mean the data comes back garbled.  To make that case, you are saying if you rip a CD audio track, 10 times, it comes back 10 different ways.  Call me extremely skeptical of this.  if this were the case, we could hear garbage in our music.  After all, while some errors can't be heard, a single error might also make a loud pop, and we don't get that.  I just ripped a track using CDex three times, and used the command-line tool "FC" to compare the results.  They are all three the same.  I then wrote the track out again as three tracks to a blank disk and read them back in.  They were identical to the original.  My burner is a ASUS DRW-2014L1T.  it's pretty old, and not that high end.  If you can rip a track, you can compare it to original data.  This doesn't address subcodes, but then subcodes used these days are not audible anyway.  Also, if the issue is additional zero samples at the beginning, this could be synchronized too.

I know some CD burning software is capable of verifying audio CD's.  I can't say for sure that they are not simply reading the disk as opposed to comparing it to the original.  I am failing to see any reason why an audio CD can't be compared to its original data.  Optical drives today are not what they once were.  They are pretty reliable.  That may be their take on it, that grabbed tracks are different from those burned, but AT MOST, you might have extra samples/missing samples at the end or beginning - making it AT MOST a problem of synchronizing it.  Of course, jitter correction is probably the reason why they take that position.  I'm just sayin, I don't believe it.  It seems my drive, and I'm guessing MANY others, no longer exhibit the dreaded jitter that would mess this plan up.  Perhaps it could be turned off by default, and when someone enables the verify option, you could give a long explanation of why it might not work, but for those for whom it does, you could make sure their audio burn was without glitches.  This, as well as the recently added CD-TEXT feature (thx to whom it may concern, BTW ;), are probably the two most fundamental features us audio guys want in a burning app.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.