is this digital solution a way to replace cd/dvd player

[markjia]

I realize that CD-Rom are not fragmented. What I'm saying is that given a hard drive's higher seek rate, fragmentation is not a problem. I'm using digital video as proof that fragmentation will not have an impact. I'm not saying that a drive that is horribly chopped up will still produce great sound, but so long as it is maintained every now and then and not used excessively, will playback audio just fine. 24bit 44.1kHz sound is only 150KB/s, insignificant for a hard drive (mine can do 200-300 times this amount).

Jitter is not at all related to a hard drives access time. They are entirely different matters. You pointed out yourself the huge difference in magnitude. They are seperate matters, and produce entirely different results. The effect of fragmentation is choppy playback, not at all the same as jitter.

An ethernet based playback system is really little different from a computer. They still use hard drives, and if you delete files, will result in fragmentation as well. It is kinda just like another bus. Instead of transfer data over SCSI or IDE, it uses 10/100. Ethernet is actually even slower than using a hard drive, and if your network is not well designed and/or overly congested, you can end up with a lot of collision and lag. SCSI or IDE over PCI will be faster and more reliable. Ethernet based drives are mostly for convience and muiltiple users.

 

[dvw]

Like I said, I have no disagreement with you. I am just touting the benefit of Ethernet based system.

Ethernet based system is the same as a computer playback system, except it uses Ethernet as a transport. The transfer rate of digital audio is about 3.5 Mbit/s with a 10/100 system there is plenty of bandwidth. Transfer speed is not an issue here SCSI is plenty fast enough. However, SCSI transfer at large block and have no retransmit capability.

Ethernet system acts pretty much as a computer. It takes the data and encapsulated into Ethernet packet with TCP/IP protocol (assuming you set it as such). This process have buffering in the computer (much larger than the drive buffer) and eliminate the effect of fragmentation and jitter from the HD.

This packet is then transmit the the receiving DAC. The DAC then un-encapsulate it and turn it into digital audio again (this process retime the Ethernet signal). If there is an error on the data transport, the DAC (using TCP/IP), will ask for a retransmit. The error detection is very robust in Ethernet, it only has one undetected error every 10 billion years.

With 100Mbit/s bandwidth, you can have a lot of retransmission in case of a noisy enviroment.

The only problem with this scene is that there aren't too many Ethernet based DAC out there.

My only point here is that HD based system aren't very good for real time transport (such as SPDIF). Regardless how fast it is, the data are taken out of the HD at 3 Mbit/s. A good seek time will help fragmented file. But a highly fragmented HD will still have problem.

 

[MirandaX]

Dudes, this argument is pointless. A reasonable-sized cache in the media player/DAC can compensate perfectly for latency/delay in the transport (whether it's a hard drive or ethernet or whatever), as well as for decoding time by the CPU. None of this is an issue.

Even jitter across the bus from the CPU to the sound card/DAC is not an issue. Even cheap hardware will have a small on-board buffer to accomodate bus latency.

The only source of jitter in a reasonable computer setup comes from the clock inside the sound card/DAC.

 

[markjia]

MirandaX, exactly. That is what I've been trying to say. Any computer setup will not cause jitter due to hard drive speed/access time. The same applies to ethernet based systems. They are both sufficient (though HD based setups are better than ethernet, but both are sufficient).

As you said, jitter is caused mostly by the DAC.

 

[kelly]

I don't seem to have any problems with music files over ethernet. I think the key is to use a 100mbit switched network.

 

[dvw]

Ethernet system is still based on HD. You still need to get the data off the HD. Ethernet system is used as a data transport. The data is cached by the Ethernet controller. With this system, the jitter is only generated by the DAC.
In addition to caching, Ethernet also have better error detection than SPDIF.

If caching is available in the DAC, of course, latency and jitter in the transmission will become moot. Toslink in this type of system will not be factor at all. Error detection will be the most important aspect.

Regarding jitter, there are many different type of jitter. The PLL generated jitter in the DAC are the electrical jitter. There is also data jitter. Data jitter is the difference in arrival time of the data. It is not important if you are dealing with data (non-real time), but with real time data it makes a diifference. For example, network have to use QoS (quality of service) function to deal with real time voice jitter.

SPDIF is a real time interconnect while Ethernet is not.

If I misled you on Ethernet, I appologized. I am talking about a Ethernet interconnect vs a digital SPDIF/Toslink interconnect.

 

[MirandaX]

Quote:

Originally posted by dvw SPDIF is a real time interconnect while Ethernet is not.

True, but your analogy to real time voice is not valid. Voice cannot be easily buffered -- if you tried to maintain a five-second buffer with voice you'd have unnatural pauses between when one person said something and the other person heard it; this would make conversation impossible. Data transmission over S/PDIF is one-way. It's trivial to add a small (say, a half of a second) buffer in the transmitter on the sound card. This is why even the cheapest one-chip transmitters have buffers. Problem solved. The only jitter comes from the transmitter's clock.

 

[dvw]

I am not disputing the fact if you have buffer the problem is solve. If you have NO buffer, then you have a problem (same as voice).

In PCDP, they use buffer for anti-skip. They also have some buffering (not a lot, but there's caching in the computer memory) in sound card. The question is does commercial DAC with SPDIF have buffer built into them. If they do then, there should not be any problem with jitter and nobody would need any retiming device or low jitter cable.

 

[aos]

Don't confuse buffering with jitter. Receiver chips have buffers, and upsampling chips and digital filters have LARGE buffers. However most still use clock that is recovered from SPD/IF signal and therefore jitter on the transmitting side and added from cable does have influence.

Reclocking DACs - which use self-generated low jitter clock to feed at least the DAC chip - used to be very rare and reserved for extremely expensive exotic equipment but there seems to be more and more upsampling equipment that minimizes effects of jitter and even allows for easy addition of internal asynchronous clock for reading from its buffer so cheaper equipment (still expensive though) coming along.

 

[TimSchirmer]

Quote:

Originally posted by Joe Bloggs and digital EQ

bah!!

 

[dvw]

Buffering might be the wrong term. It's caching of data or store with the recovered clock and forward with the on board clock ( a large elastic store). I am not sure commercial DAC has this capability or not.

With the Ethernet connection, data are clocked by the on board clock only. There is no SPDIF clock at all. The data should be very clean. The Ethernet frame has 32 bit CRC vs 1 parity bit in SPDIF. Error detection is also more robust.

 

[markjia]

Aside from convience, there is no benefit to using ethernet. It's just a different bus. IDE, and especially SCSI, have there own very advanced error correction routines. Errors in data are really not a concern.

Really, the sound card, DAC, CD-Rom and extraction process are by far the more important parts of a computer based audio system. There is no way you can get around it by using a different bus.

 

[aos]

>>Buffering might be the wrong term. It's caching of data or store with the recovered clock and forward with the on board clock ( a large elastic store). I am not sure commercial DAC has this capability or not.

That's called elastic memory. As I mentioned so far only exotic and extremely expensive commercial DACs have done that, as it used to require REAL engineering skills, not just reading the datasheets. It's been done in DIY (by asynchronously reading from buffer in digital filter or by using custom FIFO memory and programmable logic array to control it) for much less money, though the total price is in thousands even in DIY. I have one sitting by my monitor right now... alas, only the board without power supply so I can't say how it sounds.

 

[MacDEF]

Quote:

Originally posted by markjia There is one program for mac (i don't remember its name) that I know of that will extract tracks bit-for-bit from CDs, but even then, I don't believe those tracks are in a format readable by any audio player.

I already pointed one: Toast Audio Extractor. And those files are readable by a CD player.

Quote:

I looked at toast's audio cd extraction process, and found that it is capable of verification...but I doubt that that is to the same extent as EAC. I can't be sure since Toast Audio Extractor's docementation regarding this is very limited, but my belief is that toast might make a few attempts at verification, but not with as much emphasis as EAC.

Wait... you can't find the documentation, so you just assume that it's not as good as EAC, and come up with "beliefs" that verification isn't as stringent as with EAC? Please explain.

FWIW, I talked directly to some of the people who wrote TAE a couple years ago, and was assured that it is just as "exact" as EAC.

 

[markjia]

MacDEF,

I don't see what's confusing...i explictly said that it is my BELIEF that TAE will not be as strick as EAC at audio extraction. I pointed out that my "docementation regarding this is very limited", so my these statements are just beliefs. Whether or not you agree is upto you. Since I have no formal proof either way, all i can do is draw conclusions. I do this based on a few facts.

First of all, TAE is not as focused on error correction (implying that the developers are not as focus on this aspect). Secondly, look at the market of the two programs. TAE is for people simply looking for a way to extract audio with little or no advanced options or features. EAC on the other hand takes a much more meticulous approach to perfection, geared at the real enthusiasts of 100% accurate CD extraction. EAC will make upto 82 attempts at extracting the correct data, it does not make sense for TAE to do so given that it would take excessively long, and most likely deter the average user from using TAE. It would not make sense for Adaptec to implement such a feature even if they could. Thirdly, EAC produces a substantially more detailed report of the extraction, while TAE gives virtually nothing. What this means is that if for some reason, the CD could not be extracted well (perhaps due to poor quality media), you could try with a different copy.

Your point that TAE does exact bit-to-bit extraction is false. All it does is extract audio tracks from audio CDs just like any other CD extraction program, the only difference from some other programs is that it does error correction. Proof of this is that the audio extracted from the CD is stored in Sound Designer II format (according to SoundApp). That's why the extracted files can be played by any program. What I'm talking about is a program that copies every single bit off a CD track, including errors, bad blocks and the like. Those tracks are not usable by any program, all you can do with them is write them back onto a new CD, exactly as it was originally (at least according the your CD reader). In order to play the audio, it has to be extracted again.

Think about it, if you're saying that TAE can extract a CD's track bit-for-bit and thereby creating 100% perfect extractions from CDs (assuming the media and drive are of sufficient quality), then don't you think there would be more talk of it, considering that no other program dares to make this claim (including EAC)?

Due to differences in CD-Roms, seldom will you find two extractions from different drives to be identical (even if using EAC). No program out there is going to allow a poor drive to extract all CDs better or as well as higher quality drives (under the same circumstances).

Don't get me wrong, I'm not saying that TAE is not capable of doing a good job in CD extraction. My belief that it is not as powerful as EAC, is not even too important. What I'm mainly saying is that no program is going to solve the problem with using poor CD-Rom drives for audio extraction. EAC even states that Plextor makes the best drives for audio extraction, and obviously SCSI is a more reliable and accurate bus (even though IDE has come a long way).