kxkvi Posted November 13, 2012 Posted November 13, 2012 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.
LIGHTNING UK! Posted November 13, 2012 Posted November 13, 2012 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.
kxkvi Posted November 14, 2012 Author Posted November 14, 2012 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.
Recommended Posts