"My Understanding is that in case of a HDD based transport, the File is converted into an Async format (Lossless) . This is then played via a PC/Mac and when given out as digital out, the clock that is synched to is the machines own clock (Am I right ?)"
The output from the PC, whether it is USB, Firewire or S/PDIF from a soundcard or Mac has the clock embedded. The clock is generated by the computer clock or by a local clock on the sound card.
The only time that the soundcard clock frequency can be influenced is if it has a word-clock input that synchronizes the soundcard clock. This does not reduce jitter however.
Lossless format is optional. There are many formats that can be stored on the computer hard drive or flash drive. They are all converted to the correct format for transmission on the interface, S/PDIF format for this interface, USB format for this interface etc.. The playback software, such as iTunes or Foobar does this transparently. If you have .wav, AIFF and FLAC files of the same track on the disc and you play them one after another, they will all be converted to the same identical data and format for transmission or transport.
The transport formats are different than the stored formats. Transmission of digital data is specific to each interface, USB, Firewire or S/PDIF. Once these are received, they are all eventually converted to either S/PDIF and then I2S or directly to I2S bus.
a) does this impact jitter of the Lossless file in anyway ? also what would the difference between an I2S and an USB interface be in this case as the clock is not really the original clock ?
Jitter is independent usually of the format that the data is stored.
As for the transport format, such as USB, the clock is embedded in the data and must be recovered at the receiving device if it uses Synchronous Adaptive mode. This usually requires a PLL.
I2S is not a native interface for a PC or Mac, so it must be generated from another interface, such as USB, Firewire or S/PDIF. I2S is the native interface for the D/A chip, so all interfaces must end-up converted to I2S.
I2S is not the original clock in the PC, but is synchronous to the original clock.
b) Can the original information without any timing errors be reconstructed from this using an external reclocker like the empirical audio device OR Monarchy ?
Reclockers like the Pace-Car 2 can generate a totally new clock which is synchronous or tracking to the original clock, but with lower jitter.
The original information is only data, not timing. The timing is only implied by the standard frequency that is used at recording time, when the analog data was converted to digital. If the A/D clock had jitter, then the record timing will be innacurate. This cannot be fixed once the data is stored as a digital recording. If the D/A clock has jitter, then the playback timing will be innacurate. This jitter can be minimized with reclockers, upsamplers etc..
c) If the clock is not present will an external DAC just assume the input to be as per its own clock. (If the rip were done by CDROM using the same clock freq as a DAc give any added benefit)
DAC's dont have clocks in general. The only clocks in typical DAC's are for upsampling. DAC's rely on the clock embedded in the incoming datastream, whether it is S/PDIF, AES, Toslink. DAC's recover the clock(s) using hardware. If the interface to the DAC is I2S, then the clocks are discrete so they drive the D/A directly without needing clock recovery.
Ripping has nothing to do with the timing accuracy of a data file. It is simply data. There is data and then there is the timing of when the data is presented to the D/A chip. This timing is not stored on the disk. Only the data is stored on the disk. The timing is recreated at playback time. No relationship to the music timing or beat.
Steve N.
Empirical Audio
The output from the PC, whether it is USB, Firewire or S/PDIF from a soundcard or Mac has the clock embedded. The clock is generated by the computer clock or by a local clock on the sound card.
The only time that the soundcard clock frequency can be influenced is if it has a word-clock input that synchronizes the soundcard clock. This does not reduce jitter however.
Lossless format is optional. There are many formats that can be stored on the computer hard drive or flash drive. They are all converted to the correct format for transmission on the interface, S/PDIF format for this interface, USB format for this interface etc.. The playback software, such as iTunes or Foobar does this transparently. If you have .wav, AIFF and FLAC files of the same track on the disc and you play them one after another, they will all be converted to the same identical data and format for transmission or transport.
The transport formats are different than the stored formats. Transmission of digital data is specific to each interface, USB, Firewire or S/PDIF. Once these are received, they are all eventually converted to either S/PDIF and then I2S or directly to I2S bus.
a) does this impact jitter of the Lossless file in anyway ? also what would the difference between an I2S and an USB interface be in this case as the clock is not really the original clock ?
Jitter is independent usually of the format that the data is stored.
As for the transport format, such as USB, the clock is embedded in the data and must be recovered at the receiving device if it uses Synchronous Adaptive mode. This usually requires a PLL.
I2S is not a native interface for a PC or Mac, so it must be generated from another interface, such as USB, Firewire or S/PDIF. I2S is the native interface for the D/A chip, so all interfaces must end-up converted to I2S.
I2S is not the original clock in the PC, but is synchronous to the original clock.
b) Can the original information without any timing errors be reconstructed from this using an external reclocker like the empirical audio device OR Monarchy ?
Reclockers like the Pace-Car 2 can generate a totally new clock which is synchronous or tracking to the original clock, but with lower jitter.
The original information is only data, not timing. The timing is only implied by the standard frequency that is used at recording time, when the analog data was converted to digital. If the A/D clock had jitter, then the record timing will be innacurate. This cannot be fixed once the data is stored as a digital recording. If the D/A clock has jitter, then the playback timing will be innacurate. This jitter can be minimized with reclockers, upsamplers etc..
c) If the clock is not present will an external DAC just assume the input to be as per its own clock. (If the rip were done by CDROM using the same clock freq as a DAc give any added benefit)
DAC's dont have clocks in general. The only clocks in typical DAC's are for upsampling. DAC's rely on the clock embedded in the incoming datastream, whether it is S/PDIF, AES, Toslink. DAC's recover the clock(s) using hardware. If the interface to the DAC is I2S, then the clocks are discrete so they drive the D/A directly without needing clock recovery.
Ripping has nothing to do with the timing accuracy of a data file. It is simply data. There is data and then there is the timing of when the data is presented to the D/A chip. This timing is not stored on the disk. Only the data is stored on the disk. The timing is recreated at playback time. No relationship to the music timing or beat.
Steve N.
Empirical Audio