[Jolida302]

The problem is the "ripping" process which is made on nasty CDROM
computer drives, at high speed, which may induce a lot of problems.

It's like high speed burn (on audiophiles burners) Vs X1 speed burn.
The difference is huge!!

 

[Currawong]

Considering that software CDs purely wont work with uncorrectable errors, I'd be rather surprised if clean, new audio cds had uncorrectable errors on them, despite the different format.

 

[emmodad]

Quote:

Originally Posted by StanleyB1 /img/forum/go_quote.gif Every time I read any such statement on the net I cringe. CD audio is riddled with errors on the discs. If it wasn't for Solomon-Reed we would have a serious problem. So imagine ripping a CD that has been 'error corrected' by the hardware. Is the rip a true copy of the original data, or a reflection of the eroor corrected data? But wait, there is more! Not all audio data on a CD is what you imagine it to be. Put for instance a Nora Jones's CD in your PC and then go to File Manager (or Directory Opus in my case). Is that a .dll that I see??? Surely my CD player cannot read driver software? So what is my PC ripping exactly? Individual bits directly off the disc, or information stored in a database of some sort? And what is a video file doing on my Katie Melua CD? My CDP doesn't play it, but my PC does. So is my CD player bit accurate, or my PC 'seeing' data that my CDP can't see? So this whole bit accurate ripping yarn doesn't quite add up. If what I can play on a CDP off a disc is different in content to what I can play off the same disc on a PC, there is an obvious method in existance to prevent us from ripping a disc bit accurate.

my, but the above is interesting...


having been involved in development of hardware for professional digital audio recording, storage and processing since the 1970s; and more than a bit of digital comms transmission technology, I am simply fascinated: StanleyB1, could you please explain what it is about this Solomon-Reed of which you speak that provides less-capable error correction than the Reed-Solomon based Cross-Interleaved Reed-Solomon code (CIRC) utilized in authoring CDs?

CIRC provides perfect data reconstruction (hence, perhaps, the term "error correction") of random errors, and burst errors up through something like 3000-3500 bits in length (you know, width of a good-sized scratch or pinhole), and beyond that of course does provide interpolation capability to approximate correct data for burst errors perhaps 3x or 4x larger.....

(for those of you -- ie perhaps not as experienced as StanleyB1 -- who don't have technical knowledge about error-correction methods used in CDs, Google is your friend, here's one not-too-mind-numbing description: Reed-Solomon Codes and CD Encoding )

ok, let's see...

- original audio data is C2 encoded, interleaved, C1 encoded, interleaved again; subcode (control info) is added; then EFM (8to14 modulation) encoding; time sync data is added;

- THEN this resulting "pre-processed" data is (burned / stored / whatever term you want) to CD.

- perhaps the evil "burning" process corrupts some data.....

- the CD sits on a shelf, the dataset stored on the disc is fixed (ok conspiracy theorists, let's forget CD rot for now)

- and then, whether one is playing back in realtime, or ripping faster than realtime, the digital audio data is read/extracted from the CD, in any case undergoing CIRC decoding. which, in the absence of "large" physical errors on the disc, provides as decoded output the original data entered into the error-correction encoding process.

graphically:

audio >> error-correction encoding >> store to fixed CD >> read/extract from CD >> error-correction decoding

presuming the playback or ripping process is competent, ie a capable drive running at reasonable speed is able to correctly do digital audio extraction...

what, pray tell, would be the difference in resulting extracted audio? similar error correction for similar data coming off the disc...?

---

as for the comment wrt ripping, it appears that we will have to remind all the Digital Audio Extraction people who have designed drives and audio ripping software which specifically target only the audio datasets (from within the various datasets) on the different types of CDs, to be certain that their drives and audio ripping software specifically target only the audio datasets (from within the various datasets) on the different types of CDs. oh, wait.....

---

i'm perplexed as to the difference in aquired data you seem to imply in this and following posts, between "ripping a CD that has been 'error corrected' (sic) by the hardware" versus playing back (in realtime) a CD that has been error-corrected by the hardware: in the absence of egregious physical errors which overload CIRC burst-error correction capability and force attempted interpolation (ie signal approximation), what would be the difference between audio data sets sent in the two cases to a/ storage and b/ DAC?

---

related puzzlement: the seeming contradiction between your position in this thread, and your TC-7510 DAC homepage, which states regarding the product:

"The latest MK6/4 with MOD21 has been upgraded to accurately recreate the musicality, transparancy, detail, and dynamic range of music stored on Media hard drives, optical discs, and storage cards. Playback response is close to or equal to CD based music, when using high quality source material." (italics added)

your DAC is a standalone product which is supplied with an audio datastream. that datastream can be, ie:

a real-time-extracted datastream sourced in realtime from a transport spinning optical discs (ie real-time reading, extraction, error correction and immediate onward transmission via a digital interface to your DAC); or

a nonlinear (aka non-real-time, sourced from optical disc but stored) extracted datastream sourced from a transport spinning optical discs (ie real-time reading, extraction, error correction and placement in storage media, otherwise known as ripping; followed sometime later by delayed onward transmission out of storage media via a digital interface to your DAC).

given that the source is the same CD; presuming no egregious differences in transmission via digital interfaces; and presuming your DAC's digital receiver circuitry can competently handle whatever level of jitter you think is important or not important on the incoming signal: for the TC-7510 to provide from hard drives or storage media a "playback response... equal to CD-based music," wouldn't the two audio filesets -- realtime datastream or delayed-by-storage datastream -- have to be essentially identical?

just wondering....

 

[StanleyB1]

I must make a correction: it is Reed-Solomon, and not Solomon-Reed. My apologies for the confusion.

As for reference to whatever product or products I sell or my website: please note that my contribution to this topic is solely with regards to the topic. I am, in accordance with the rules under which head-fi operates, unable to give an answer to any question posed by another member in which any of my products or my site is mentioned. For those not satisfied with this, please consult Jude in Admin who would be more than willing to clarify the position. I am therefore unable to answer emmodad without facing the possibility of being banned or suspended. Sorry guys, but I have received notice of being under observation and don't wish to forfeit my logging on permission.

Stan

 

[japc]

Quote:

Originally Posted by StanleyB1 /img/forum/go_quote.gif Nope. I have been working in that industry on and off since 1982. That includes R&D for both Sony and Philips. So there is a background to my statements that doesn't rely on data gleamed from the internet.

I'll quote your statement again:

"So this whole bit accurate ripping yarn doesn't quite add up. If what I can play on a CDP off a disc is different in content to what I can play off the same disc on a PC, there is an obvious method in existance to prevent us from ripping a disc bit accurate."

because I find it utterly bizarre. It is the same as saying that if I sit on a CD and it doesn't spit out music then there is "an obvious method in existance to prevent us from ripping a disc bit accurate".

Except that in this example it may even be as I'm heavy and disks break.

 

[emmodad]

Quote:

Originally Posted by StanleyB1 /img/forum/go_quote.gif I am, in accordance with the rules under which head-fi operates, unable to give an answer to any question posed by another member in which any of my products or my site is mentioned...I am therefore unable to answer emmodad

and it was so interesting to think that head-fi could benefit from the sharing of perspective and knowledge gleaned from your many years of experience

(hmmm, maybe we should tell Elias to stop answering questions in the "Benchmark DAC-1 now available with USB" thread?)

 

[nick_charles]

Quote:

Originally Posted by emmodad /img/forum/go_quote.gif CIRC provides perfect data reconstruction (hence, perhaps, the term "error correction") of random errors, and burst errors up through something like 3000-3500 bits in length (you know, width of a good-sized scratch or pinhole), and beyond that of course does provide interpolation capability to approximate correct data for burst errors perhaps 3x or 4x larger..... - original audio data is C2 encoded, interleaved, C1 encoded, interleaved again; subcode (control info) is added; then EFM (8to14 modulation) encoding; time sync data is added; - and then, whether one is playing back in realtime, or ripping faster than realtime, the digital audio data is read/extracted from the CD, in any case undergoing CIRC decoding. which, in the absence of "large" physical errors on the disc, provides as decoded output the original data entered into the error-correction encoding process.

This is great stuff, thanks.

 

[nnotis]

I was recently disturbed when comparing a lossless ALAC rip to the the original CD playing in the computer's CD drive. I could hear only a very subtle difference, but the CD did sound better. My computer is a G5 from 2004. I've read that on slower computers, one could hear such a difference. After all, there is computation involved in uncompressing the lossless file. Is it not reasonable for that to have an impact on the final sound?

 

[japc]

Some impact. Most of the time not tangible impact.

 

[krmathis]

nnotis. Imo thats not reasonable, since todays computers are plenty fast to decode Apple Lossless on the fly. That goes for a G5 from 2004 as well.
There are a at least a couple of possible reasons though:
* Errors occurred during ripping, and hence they are not identical even before compressing to Apple Lossless.
* Some playback options are enabled for the Apple Lossless files, but not the CD. Like 'Sound Enhancer', 'Sound Check' or even some volume level.

This has been discussed to death several times already, and there still are some believers, some deniers, and some skeptics.

 

[joe_cool]

Quote:

Originally Posted by krmathis /img/forum/go_quote.gif This has been discussed to death several times already, and there still are some believers, some deniers, and some skeptics.

Good answer!

 

[Fidelity]

Quote:

Originally Posted by nnotis /img/forum/go_quote.gif I was recently disturbed when comparing a lossless ALAC rip to the the original CD playing in the computer's CD drive. I could hear only a very subtle difference, but the CD did sound better. My computer is a G5 from 2004. I've read that on slower computers, one could hear such a difference. After all, there is computation involved in uncompressing the lossless file. Is it not reasonable for that to have an impact on the final sound?

On the computer, was the CD audio output via DAE (Digital Audio Extraction) directly to the sound card (the software player has to support), or just via the old method where the CDROM drives analog output is connected to the sound card via a small cable?

If the latter, the difference is attributed to listening to the audio via the CDROM drives internal DAC, on the other hand the ALAC audio file played back on the same computer is passed through the sound cards own DAC.