Hi Glassman,
Just a couple questions for you.
1. What form do you think the data is in before it's processed?
2. How are you comparing the data output on the spdif outputs?
CDROM drives appear to be less expensive than CD drives now. The Phiips may be another story, but they want to get away from Philips. Spares are compatible between different sources, so is the form factor. So replacements down the road are not a problem.
-Chris
Just a couple questions for you.
1. What form do you think the data is in before it's processed?
2. How are you comparing the data output on the spdif outputs?
CDROM drives appear to be less expensive than CD drives now. The Phiips may be another story, but they want to get away from Philips. Spares are compatible between different sources, so is the form factor. So replacements down the road are not a problem.
-Chris
1. I know, but we're interested in the resulting decoded data as that's what counts..
2. recording them into computer and then comparing in editor - align them and subtract, then see if there's any residue - usually there isn't any..
when I say regular mechanisms are way cheaper, I mean the wholesale pricing, which is order of magnitude lower than what you can get as an individual.. unlike computer stuff where end user prices are not far from wholesale..
2. recording them into computer and then comparing in editor - align them and subtract, then see if there's any residue - usually there isn't any..
when I say regular mechanisms are way cheaper, I mean the wholesale pricing, which is order of magnitude lower than what you can get as an individual.. unlike computer stuff where end user prices are not far from wholesale..
Hi all,
The argument for the cd-rom reading sectors multiple times is irrelevant. When it play audio normally, it just act as a standard cd-player, at 1x speed. If there are any errors, the same algorithms goes to hide it (repeat, mute, interpolate, etc).
In order to have a cd-rom drive read multiple times a sector, you have to control it by ide interface, fetch the data by ide interface, buffer it and output it following a fixed clock. By doing so, you'll have a no error reading as long as the cd is not badly damaged, and jitter performance is virtually excellent, depending on how the buffer is used (and transmission protocol, of course! )
However, I agree to say that a cd-rom player can get as accurate reading, even in real time, as a good dedicated cd drive.
The argument for the cd-rom reading sectors multiple times is irrelevant. When it play audio normally, it just act as a standard cd-player, at 1x speed. If there are any errors, the same algorithms goes to hide it (repeat, mute, interpolate, etc).
In order to have a cd-rom drive read multiple times a sector, you have to control it by ide interface, fetch the data by ide interface, buffer it and output it following a fixed clock. By doing so, you'll have a no error reading as long as the cd is not badly damaged, and jitter performance is virtually excellent, depending on how the buffer is used (and transmission protocol, of course! )
However, I agree to say that a cd-rom player can get as accurate reading, even in real time, as a good dedicated cd drive.
Hi Glassman,
My point has been that it's the quality of the RF waveform that the data depends on. Starting with a poor one puts you behind the eight ball.
Cool way of comparing the output data! Good thinking. Of course you will only ever see uncorrectable errors as a difference. A defective disk may show more differences, you would have to check. I can see them just by monitoring the flags.
Hi apolon34,
Companies using CDROM drives normally read the data in at a higher rate to give time to re-read bad sections. They use it as a specialized computer program might. That is why I commented that they are actually copying the data, because that is what they are doing. Whether we send the information to a DAC section or other media is a moot point as far as copy protection is concerned.
-Chris
My point has been that it's the quality of the RF waveform that the data depends on. Starting with a poor one puts you behind the eight ball.
Cool way of comparing the output data! Good thinking. Of course you will only ever see uncorrectable errors as a difference. A defective disk may show more differences, you would have to check. I can see them just by monitoring the flags.
Hi apolon34,
Companies using CDROM drives normally read the data in at a higher rate to give time to re-read bad sections. They use it as a specialized computer program might. That is why I commented that they are actually copying the data, because that is what they are doing. Whether we send the information to a DAC section or other media is a moot point as far as copy protection is concerned.
-Chris
We'll just have to agree not to agree 
From what I can find most of the copy unprotection schemes mess up the TOC or session info on the disc. Its done to confuse the software controlling the drive, not the drive itself.
ie Windows and CD/MP3 players are looking for a valid filesystem full of MP3 files as well as a CD full of CD audio. It reads the TOC and gets garbage so refuses to play the disc as it thinks its faulty.
From what I can find most of the copy unprotection schemes mess up the TOC or session info on the disc. Its done to confuse the software controlling the drive, not the drive itself.
ie Windows and CD/MP3 players are looking for a valid filesystem full of MP3 files as well as a CD full of CD audio. It reads the TOC and gets garbage so refuses to play the disc as it thinks its faulty.
sure thing, the better RF picture, the better chances of avoiding errors..
and uncorrectable / C2 errors are the only ones potencially affecting the sound, though I even doubt a few C2 errors during the whole playtime can seriously affect the perceived overall sound quality..
the flags are signaling just C2 errors as far as I know, or do you know of some chipset actually reporting even C1 errors? I could see C1 errors using KProbe paired with LiteOn DVD drive.. about thousand of them on the whole disc and it was spinning >24x.. needless to say, there was not a single C2..
I would expect them to use the CD-ROM drives in a proper was as described above, otherwise I don't see the point, but that's just me..
and uncorrectable / C2 errors are the only ones potencially affecting the sound, though I even doubt a few C2 errors during the whole playtime can seriously affect the perceived overall sound quality..
the flags are signaling just C2 errors as far as I know, or do you know of some chipset actually reporting even C1 errors? I could see C1 errors using KProbe paired with LiteOn DVD drive.. about thousand of them on the whole disc and it was spinning >24x.. needless to say, there was not a single C2..
I would expect them to use the CD-ROM drives in a proper was as described above, otherwise I don't see the point, but that's just me..
In my opinion, no C2 errors during a disc play = Perfect drive, you can't discuss that.
For the cd-rom commercial implantation, I doubt many of them does the read & reread, buffer, extract, etc...
Most of them just send the play command by ide interface and wait for the data on i2s or worse, spdif bus and just send it to a dac.
This just need a $10 uC and is simple to program, so is low cost.
For the other method, you need a good dsp, at something like 400Mhz to control the cd-rom drive and get the data by ide interface (at 2.xxxx Mhz rate, that's quick) and read it at more than real time to have the time to correct.
However, that's not the interesting feature, since even a bad cd-rom drive can read a cd accurately (no C2 errors). The important point is that you can dramastically reduce jitter by buffering.
For the cd-rom commercial implantation, I doubt many of them does the read & reread, buffer, extract, etc...
Most of them just send the play command by ide interface and wait for the data on i2s or worse, spdif bus and just send it to a dac.
This just need a $10 uC and is simple to program, so is low cost.
For the other method, you need a good dsp, at something like 400Mhz to control the cd-rom drive and get the data by ide interface (at 2.xxxx Mhz rate, that's quick) and read it at more than real time to have the time to correct.
However, that's not the interesting feature, since even a bad cd-rom drive can read a cd accurately (no C2 errors). The important point is that you can dramastically reduce jitter by buffering.
Hi apolon34,
Okay we disagree in the perfect world. In the real world where discs are not perfect, you will have more errors. The C2 flag may even be tied low for that matter, or data repeated.
If you start bad, it can only degrade from there. I think my point has been brought forth enough. If you wish to accept poor performance, that's okay too. Soon MP3 might be the good format.
-Chris
Okay we disagree in the perfect world. In the real world where discs are not perfect, you will have more errors. The C2 flag may even be tied low for that matter, or data repeated.
If you start bad, it can only degrade from there. I think my point has been brought forth enough. If you wish to accept poor performance, that's okay too. Soon MP3 might be the good format.
-Chris
There are obviously very view guys, which have investigate CD rom drives very thoroughly. An additional reason could be, that detailled schematic diagrams are very hard to find (in opposite to the most audio cd player devices).
For this reason any derogatory comments to the CD ROM are not professionally and therefore not helpful.
BTW - not only Meridian, but also Plinius uses a CD-ROM drive by their model CD-101 about
http://www.pliniusaudio.nzld.com/documents/downloads/plinius_cd101brochure.pdf
the ASUS CD-S520
ASUS CD S520 - CD-ROM drive - IDE - CD Drives - CNET Archive
For this reason any derogatory comments to the CD ROM are not professionally and therefore not helpful.
BTW - not only Meridian, but also Plinius uses a CD-ROM drive by their model CD-101 about
http://www.pliniusaudio.nzld.com/documents/downloads/plinius_cd101brochure.pdf
the ASUS CD-S520
ASUS CD S520 - CD-ROM drive - IDE - CD Drives - CNET Archive
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.