I wonder if the CD rom controller is defective? I wonder if the noise also happens on the analog output from the CD rom? Do you have an analog output from the CD rom?
I dont think SPDIF sucks. I think the choice of DAC chip, choice of output stage, and choice of voltage regulation and grounding of the DAC board have a greater effect on the overall sound than the SPDIF protocol / interface.
The WM8804/5 reciever seems to do a very good job, and so does the DIR9001.
I wasnt too upset by the CS8414 and even managed to enjoy my time with the CS8412.
Does anyone know why SPDIF was chosen instead of using the EFM signal to transmit data outside of the player?
Last edited:
Usually WOW and flutter is not audible on a really good record player, and does not detract from the sound although the WOW and flutter is massive in comparison to the ns of jitter in a digital player.
Jitter is actually not on my top 10 reasons for "bad" digital sound. I'm more inclined to agree with albraxilito's theory that other factors such as common mode noise have a greater negative influence.
Last edited:
I agree, it works fine with multibit DACs.
All more significant concerns (subjectively) than S/PDIF related issues, IME.
EFM stands for eight-fourteen modulation. A modulation scheme is not a transmission format - for one reason it does not provide framing - its just suitable as a method for ensuring that the data has a minimum number of transitions and hence a clock can be extracted from it. The modulation scheme used in S/PDIF is simpler - biphase mark.
Ok, my understanding is foggy. Is this correct? - when getting the data from the laser to the decoder there is a laser eye pattern RF signal which contains the EFM coding.
Is there also another signal coming from the laser to idenify the framing and clock?
Its been many years since I studied this (a series of articles back in HFN&RR in the 80s) but I believe so. I can't recall how the framing is handled - perhaps its done through 'illegal' codes in the EFM scheme in which case I take back what I said earlier about no framing being provided. The decoding in EFM is more complex - it needs a look-up table so perhaps that reason is enough that it wasn't used as a modulation scheme in an 'external' transmission format.
Last edited:
Yes it needs the look up table for the reed solomon code to correct the data. So it seems to me that this is actually a better system of transmitting data than spdif?
Perhaps it is that the EFM signal uses the internal clock of the CD player and so to use EFM for external transmission would require a syncronised clock, basically a 2 wire system of data transmission.
Perhaps it is that the EFM signal uses the internal clock of the CD player and so to use EFM for external transmission would require a syncronised clock, basically a 2 wire system of data transmission.
Better? I can't think that it is better in terms of ease (complexity, power demands) of decoding - there's no need for the overhead of EFM and RS for S/PDIF, its not prone to errors as the optical disk is. Your mention of RS coding is pertinent in that given there's got to be a fairly substantial logic block to deal with that, the additional overhead of EFM's look-up table is fairly small. S/PDIF receivers though are decidedly more 'lean' - no need for considerable buffer memory either.
The speed of rotation of the disk gets locked to the crystal through extracting the clock and servoing the spindle motor to match that (on average) to the XTAL. So a transmission scheme could work a similar way but without the ability to vary the incoming data rate - a local PLL could be locked to the input rate.
The speed of rotation of the disk gets locked to the crystal through extracting the clock and servoing the spindle motor to match that (on average) to the XTAL. So a transmission scheme could work a similar way but without the ability to vary the incoming data rate - a local PLL could be locked to the input rate.
Better is debatable, but the advantage is that it has the error corection. Basically its just one chip that does all of this just like a SPDIF reciever chip. The chips themselves dont cost very much they are in every CD player. EFM in i2s out. Easy enough? I cant honestly say that I've ever heard any particular problems that I could equate to the EFM decoder chip inside a CD player.
Last edited:
Yes it has error correction. But the error rate over S/PDIF is vanishingly small so RS is overkill for that. Silicon area costs money and so the chip is not going to be designed bigger (and power hungrier) than it needs to be. If DIR9001s and WM8805s had to have buffer memory and logic on-chip they'd be significantly more expensive chips than they are now, not to mention higher power consumption.
By volume the EFM decoder chips must be cheaper than SPDIF recivers because they are in every CD player and CD/ DVD rom.
There are more EFM decoders in the world than SPDIF recivers.
I dont think the power hungryness of the EFM decoder has posed a sonic problem in any CD player I've heard.
I wasnt complaining about the error rate over SPDIF, but some people were complaining.
I was just discussing conceptually if we used EFM decoders instead of SPDIF recievers then people wouldnt have to worry about reflections in their cables because the error correction would sort it out for them.
I actually wouldnt be surprised if SPDIF was invented so that they could include the copy protection bit, which was not available in the EFM code.
There are more EFM decoders in the world than SPDIF recivers.
I dont think the power hungryness of the EFM decoder has posed a sonic problem in any CD player I've heard.
I wasnt complaining about the error rate over SPDIF, but some people were complaining.
I was just discussing conceptually if we used EFM decoders instead of SPDIF recievers then people wouldnt have to worry about reflections in their cables because the error correction would sort it out for them.
I actually wouldnt be surprised if SPDIF was invented so that they could include the copy protection bit, which was not available in the EFM code.
EFM decoders are not separate chips - its just one function amongst many in a player included on the silicon.
I don't believe the problems caused by reflections on S/PDIF cables were so severe to cause bit errors - rather they introduced more jitter (timing problems) than necessary. At least that was the argument I read. I rather suspect that jitter would be worse (rather than better) if EFM were used in place of biphase mark encoding.
I don't believe the problems caused by reflections on S/PDIF cables were so severe to cause bit errors - rather they introduced more jitter (timing problems) than necessary. At least that was the argument I read. I rather suspect that jitter would be worse (rather than better) if EFM were used in place of biphase mark encoding.
OK. I'll trust you on that. It was just something I had been wondering about lateley. I'll clear my mind of that idea now. Thanks.
I used the only player who has the play button on the front (without controller), but without success.
the sound from the headphone is, however continuous
there seems to be an incompatibility between the CD-Rom and the card with ESS9018
I noticed that even with the reader in stop or pause, the LED "lock" on the board of the DAC goes out with the same frequency
what is amazing is that after 10-15 min of intermittent reading the problem disappears, reappears after a jump of track or going fast forward
I checked with the oscilloscope and not noticed strange noise
An externally hosted image should be here but it was not working when we last tested it.
I do not know what to do
A weird issue indeed. What sample rate do your other SPDIF sources give? The Blu-ray and home theatre receiver might well be 48kHz. Maybe the DAC board is faulty and works at 48 but not 44.1.
Or maybe the CDROMs all have an inaccurate sample rate. IIRC for 44.1kHz sample rate, the bit rate of the SPDIF data stream should be 1.411200MHz.
I considered a project like this a while ago, but I ended up building a hard disk player and ripping my CDs to it.
Digital trivia: Early CD players apparently did use EFM as communication between the transport and an external DAC. The error correction in EFM is overkill for transmission over a short cable.
Any protocol that combines clock and data into a single signal requires clock recovery and so is susceptible to jitter.
The WM8804 does actually contain a buffer, part of Wolfson's "jitter scrubbing architecture"
Or maybe the CDROMs all have an inaccurate sample rate. IIRC for 44.1kHz sample rate, the bit rate of the SPDIF data stream should be 1.411200MHz.
I considered a project like this a while ago, but I ended up building a hard disk player and ripping my CDs to it.
Digital trivia: Early CD players apparently did use EFM as communication between the transport and an external DAC. The error correction in EFM is overkill for transmission over a short cable.
Any protocol that combines clock and data into a single signal requires clock recovery and so is susceptible to jitter.
The WM8804 does actually contain a buffer, part of Wolfson's "jitter scrubbing architecture"
Last edited:
Indeed it is strange
the DAC has the display and connecting the BlueRay containing a CD Audio, correctly displays 44.1kHz
and feel perfectly
connecting a CD-Rom displays equally 44.1kHz, but immediately has the problem
I tried to use the Toslink input putting the CD-Rom a 100ohm resistor and an LED, incredibly the defect is also present here
the DAC has the display and connecting the BlueRay containing a CD Audio, correctly displays 44.1kHz
and feel perfectly
connecting a CD-Rom displays equally 44.1kHz, but immediately has the problem
I tried to use the Toslink input putting the CD-Rom a 100ohm resistor and an LED, incredibly the defect is also present here
An externally hosted image should be here but it was not working when we last tested it.
Could you set your scope up to display an Eye pattern of the SPDIF signal and post the pic here? (Set persistence to infinite)
Do this for the CDROM and the Blu-ray playing an audio CD, and let's see if we can spot any difference. I suspect the sample rate of the CDROM is slightly out of spec or unstable, and the ESS9018 DAC is more picky about this than your soundcard.
Do this for the CDROM and the Blu-ray playing an audio CD, and let's see if we can spot any difference. I suspect the sample rate of the CDROM is slightly out of spec or unstable, and the ESS9018 DAC is more picky about this than your soundcard.
I purchased the oscilloscope recently, are still inexperienced;
viewing them as soon as we can
as suggested by scopeboy
probe 10X
BlueRay with CD-Audio connected to ESS9018, automatic persistence
BlueRay with CD-Audio connected to ESS9018, infinite persistence
CD-ROM with CD-Audio connected to ESS9018, automatic persistence
CD-ROM with CD-Audio connected to ESS9018, infinite persistence
probe 10X
BlueRay with CD-Audio connected to ESS9018, automatic persistence
BlueRay with CD-Audio connected to ESS9018, infinite persistence
CD-ROM with CD-Audio connected to ESS9018, automatic persistence
CD-ROM with CD-Audio connected to ESS9018, infinite persistence
I'm puzzled! If anything the digital output of the CDROM looks better than the Blu-ray. The Blu-ray has a slower rise time and bags of jitter.
Except that the CDROM seems to show one abnormally narrow pulse of about 50ns just to the left of the zero line. This falling edge must have been followed immediately by a rising one, or the scope should not have triggered it. Note that in the Blu-ray screenshot, there is one clear half cycle around the middle.
See if you can catch another one of these narrow pulses. If they are real, this is an illegal signal for SPDIF and might well freak the receiver out.
Except that the CDROM seems to show one abnormally narrow pulse of about 50ns just to the left of the zero line. This falling edge must have been followed immediately by a rising one, or the scope should not have triggered it. Note that in the Blu-ray screenshot, there is one clear half cycle around the middle.
See if you can catch another one of these narrow pulses. If they are real, this is an illegal signal for SPDIF and might well freak the receiver out.
- Status
- Not open for further replies.