Reply to this post | See parent post | Go Back

View Post [edit]

Poster:	festering leper	Date:	Jan 28, 2003 6:39am
Forum:	macromedia	Subject:	Re: proposal for CD-ROM archive - comments?

i'd just like to point out something about the bin/cue format... while it's a fairly useful format it's not without its problems.

while bin/cue images can consist of cooked sectors, the format is most versatile/useful when used as a collection of raw-mode sector reads (otherwise an iso could easily suffice).

since i can't explain it as well as some others, but have experienced _cdrom_generational_loss_ firsthand - stemming from raw-mode reads, here's a piece from the comp.periph.cdr faq from the section "can i make copies of copies?"

[quote-]
The heart of the problem is the way that that the data is read from the source device. When a program does "raw" sector reads, it gets the entire 2352-byte block, which includes the CD-ROM error correction data (ECC) for the sector. Instead of applying the ECC to the sector data, the drive just hands back the entire block, including any errors that couldn't be corrected by the first C1/C2 layer of error correction (see section (2-17)). When the block is written to the CD-R, the uncorrected errors are written along with it. This problem can be avoided by using "cooked" reads and writes. Rather than create an exact duplicate of the 2352-byte source sector, cooked reads pull off the error-corrected 2048-byte sector. The CD recorder regenerates the appropriate error correction when the data is written. Ideally SNAPSHOT[or other software - ed.] would be able to do the error correction in software when operating in "raw" mode, but apparently there's no readily available code that does this. It could also read each block twice, once in raw mode and once in cooked, but that would double the read time.
This begs the question, why not just use cooked writes all the time? First of all, some recorders (e.g. Philips CDD2000 and HP4020i) don't support cooked writes. (Some others will do cooked but can't do raw, e.g. the Pinnacle RCD-5040.) Second, not all discs use 2048-byte MODE-1 sectors. There is no true "cooked" mode for MODE-2 data tracks; even a block length of 2336 is considered raw, so using cooked reads won't prevent generation loss. It is important to emphasize that the error correction included in the data sector is a *second* layer of protection. A clean original disc may well have no uncorrectable errors, and will yield an exact duplicate even when copying in "raw" mode. After a few generations, though, the duplicates are likely to suffer some generation loss. The original version of this quote went on to comment that Plextor and Sony CD-ROM drives were not recommended for making copies of copies. The reason they were singled out is because they are the only drives that explicitly warned about this problem in their programming manuals.
It is possible that *all* CD-ROM drives behave the same way. (In fact, it is arguably the correct behavior... you want raw data, you get raw data.)
...
The final answer to this question is, you can safely make copies of copies, so long as the disc is a MODE-1 CD-ROM and you're using "cooked" writes. Copies made with "raw" writes may suffer generation loss because of uncorrected errors. Audio tracks don't have the second layer of ECC, and will be susceptible to the same generation loss as data discs duplicated in "raw" mode. Some drives may turn off some error-correcting features, such as dropped-sample interpolation, during digital audio extraction, or may only use them when extracting at 1x. If you want to find out what your drive is capable of, try extracting the same track from a CD several times at different speeds, then do a binary comparison on the results.
[-end quote]
whether or not the underlying technical details are accurate for today's hardware and software, i have experienced cd generational loss firsthand, i can vouch for the fact that using raw-mode reads can truly screw your copies over.

based on the above and on my own personal experience (been doing copies/extractions/burns for 9+ yrs) i would not recommend the bin/cue format unless great care was taken to ensure that cooked sectors were used where possible. not all software does this for you. extraction followed by testing of copies might be the only way to determine what mode (cooked/raw) will work.

festering leper (never been 'burned' by cooked mode track reads :) )