Are we moving towards a transport-less future ?

sivat schrieb:

One Clarification - I never doubted EAC. I believe, it does what it has to do.

eehh?

Then what have we been arguing about?

Please continue the discussion about transports, spdif, etc... its very educative for me

P.S. A quick doubt - are commercial transports connected to dacs thru spdif as well? If so, then where do the differences in sound between transports and sound cards arise? So the transports do some digital filtering?

zhopudey schrieb:

sivat schrieb: One Clarification - I never doubted EAC. I believe, it does what it has to do. eehh? Then what have we been arguing about?

The "mechanics" of the transport and "electronics" also have been to fine-tuned to minimize the jitter error at the reading-stage. This is the reason why we have so many fancy and expensive transports, after-market clocks, after-market PSU, etc.,

The EAC can do its job but the rest of chain has to good. Namely the transport and the associated electronics with it. Or you will end up with a file which is bit perfect but with timing errors. Am I right ?

Does this mean that a bit perfect file can have timing errors ?

Granted there can be timing errors since obviously the transport in a dvd rom/writer is not great... but what is the probability of a timing error occuring at a particular bit everytime if the same bit is being read ten times? Virtually zero... so I don't get what the fuss is all about

The basic difference essentially is that the so called high end transport reads a bit just once when playing while when extracting data from a cheap DVD drive, the same bit is read multiple times to ascertain whether what was read is correct. So the process is entirely different and the typical articles relating to jitter that you are referring to do not apply in this case.

A question....

In what way can a bit perfect file have timing errors ? If so then can the file be called bit perfect ?

The term "bit perfect" would mean perfect in data and time info. No ?

Manek

Manek schrieb:

A question.... In what way can a bit perfect file have timing errors ? If so then can the file be called bit perfect ? The term "bit perfect" would mean perfect in data and time info. No ? Manek

Err there is no timing information in a sound file other than the sampling rate. All are the following tag and then the data:

WORD wFormatTag;
WORD nChannels;
DWORD nSamplesPerSec;
DWORD nAvgBytesPerSec;
WORD nBlockAlign;
WORD wBitsPerSample;
WORD cbSize;

WORD refers to 16 bits and DWORD refers to 32 bits. Format tag is typically PCM, channels either 2/5/7, Samples per second is generally 44100 or 48000 or 96000 depending on sampling rate. block alignment is Bit/sample*No of channels. Bytes per second is block alignment*samples per second. Bits per sample is 16 or 24. cbSize is additional information.

After this is the actual data which essentially is a list of amplitude values of the audio which must be read based upon the above structure. The number of elements depends on the number of channels and also the length of the sound clip.

Thats all there is to a wave file or any other form of uncompressed digital audio and this is all the information that a DAC needs to convert the digital signal into music.

reignofchaos schrieb:

Manek schrieb: A question.... In what way can a bit perfect file have timing errors ? If so then can the file be called bit perfect ? The term "bit perfect" would mean perfect in data and time info. No ? Manek Err there is no timing information in a sound file other than the sampling rate. All are the following tag and then the data: WORD wFormatTag; WORD nChannels; DWORD nSamplesPerSec; DWORD nAvgBytesPerSec; WORD nBlockAlign; WORD wBitsPerSample; WORD cbSize; WORD refers to 16 bits and DWORD refers to 32 bits. Format tag is typically PCM, channels either 2/5/7, Samples per second is generally 44100 or 48000 or 96000 depending on sampling rate. block alignment is Bit/sample*No of channels. Bytes per second is block alignment*samples per second. Bits per sample is 16 or 24. cbSize is additional information. After this is the actual data which essentially is a list of amplitude values of the audio which must be read based upon the above structure. The number of elements depends on the number of channels and also the length of the sound clip. Thats all there is to a wave file or any other form of uncompressed digital audio and this is all the information that a DAC needs to convert the digital signal into music.

This is for WAV File ..and not for PCM.

Reading a WAV files falls under "CD*ROM" (Yellow Book)
...there will be not be any jitter problem due to the nature of the format.

I wasn't talking about PCM at all. Manek was asking about bit perfect file formats for digital storage.

Audio on CD is much simpler. It has frames of six 16 bit samples, nine error correction bytes in cross interleaved reed-solomon encoding and a subchannel code. This is the basic problem with CDs as this form of encoding interpolates unreadable errors. Also this interpolation and reading is completely transport dependent and hence there's no way to know if what was read is correct or not. This again is compounded by the fact that CDs don't have block accurate addressing and hence jitter creeps in.

Reign, thanks for the format structure. Had never read the redbook or the yellowbook formats in depth till date but now I will.
My query came from reading a previous post which hints at lossless files being bit perfect and not timing perfect.

Manek

reignofchaos schrieb:

Also this interpolation and reading is completely transport dependent and hence there's no way to know if what was read is correct or not. This again is compounded by the fact that CDs don't have block accurate addressing and hence jitter creeps in.

Ah !!

Manek schrieb:

Reign, thanks for the format structure. Had never read the redbook or the yellowbook formats in depth till date but now I will. My query came from reading a previous post which hints at lossless files being bit perfect and not timing perfect. Manek

Manek,

The answer is there for you in the stereophile article...it clearly illustrates it. Please take some time to read it.

Siva.

This discussion on AA is also worth reading..although it is more related to Trnaports and how they read...and there are vested interests at work here so its quite easy to get swayed either way !

http://www.audioasylum.com/cgi/vt.mpl?f=digital&m=131391


I guess the jury is still out on this one and this thread should be very interesting learning !

i am very interested in the conversion of Redbook to Yellowbook and what it takes to do that. i guess that is what we are talking off here.

Siva, that sterephile link is really good on first read..need to read it slowely to digest it !

http://www.stahltek.com/vekian_da.htm

Another DAC..that seems intresting. Not heard it though. The interview with the designer is quite good. I really like this kind of "no-nonsense" marketing...which educates the customers without trying to fool them with exaggerated statements.

I like the part ..where the designer explains about the output stage...my experience with DACs has been the same.

You can also use an USB for a audio stream, which is very easy to integrate with traditional DAC. I do not think a LAN interface will be any better tha a USB...unless you are hooking up the DAC direct to an internet/intranet audio stream.

shouldnt the Lan be better than an USB ? I believe the USB interface utilises a lot of CPU time, thus making it very Jitter prone ? the LAN on the other had is isolated due to the inherent interface standard and not really prone to jitter.