Jump to content

Read speed and related issues


kxkvi

Recommended Posts

Hi folks. I'm back to cause yet more trouble.

 

Yesterday, I was creating some ISO images from various discs. What caught my eye

at the time was that read speed settings existed on the dialog. In the past, I had

simply run with the defaults and largely ignored that option.

 

When I started thinking about the way this option was displayed, it didn't make much

sense to me. A read spead on the left, then what looks like a division sign (/), then

another read speed on the right. I just couldn't wrap my mind around it. I started

poking around in the guides, and finally found the answer.

 

It seems to me that if the dialog were simply labeled data on the left, and audio on the

right, it would make the reason for the separate settings more readily apparent.

 

Also, I read this statement in the guide:

 

"The reason for the default '8x' for 'Audio' as source, is that there's no error correction

on Audio tracks, so the slower the better really."

 

This has me a little bafflled. Is this setting in reference to audio CDs? The way I've

always understood audio CD theory, as outlined in great detail in Ken Pohlman's

excellent "Principles of Digital Audio", was that error correction is used extensively

on audio CDs. Specifically, cross-interleave Reed-Solomon Code, I seem to recall

that this was part of the Red Book standard as well. As such, I'm left a little mystified

by this statement, and why ImgBurn would not be unable to access that error-correction

information.. I suspect that the answer may well be way over my head, but I thought

I'd throw it on the table nevertheless.

 

Thanks again for a great app. Enjoy the day.

Link to comment
Share on other sites

The reason it doesn't say 'Data' and 'Audio' is simply because there isn't enough room for it to! Don't forget to take into account the varying lenghts of translations when thinking about it :)

 

Sectors on a disc are 2352 bytes in size, plus 96 for subchannel. Audio uses all 2352 bytes, data typically uses 2048. So whilst there's room in the 2352 for data to have extra error correction, there isn't any room for CDDA to have it.

 

Lke you said though, there's some sort of error correction on all discs, even CDDA. You get C1 and C2 error correction and some drives can report back the number of C2 errors to an application - but ImgBurn doesn't enquire about that info. You'd want to use something like EAC for stuff like that.

Link to comment
Share on other sites

Sectors on a disc are 2352 bytes in size, plus 96 for subchannel. Audio uses all 2352 bytes, data typically uses 2048. So whilst there's room in the 2352 for data to have extra error correction, there isn't any room for CDDA to have it.

 

Lke you said though, there's some sort of error correction on all discs, even CDDA. You get C1 and C2 error correction and some drives can report back the number of C2 errors to an application - but ImgBurn doesn't enquire about that info.

Hi Lightning.

 

Wow.. thanks for sharing that insight. While I don't claim to comprehend it all at this point,

I think I see what you're getting at. It sounds to me like you're referring to a whole different

layer involved in the process of moving that data around. Error-correction is there, but not

accessible or meaningful at the layer that your process needs to deal with. It's embedded within

the 2352 byte blocks of audio data, and as such, you have no need or way to access it.

Interesting stuff. We see a lot of similar situations in the telecom/datacom world as well. It'll

give me something to think about and study over the next few days.

 

Thanks again.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.