0

I have a CD transport and DAC which both take TOSlink connections. So, I can connect the transport to the DAC and that works fine.

However, in some cases I want to rip a CD so I can combine songs from different CDs to make a mix CD. So, in that case I need to move data from the transport to a file on a computer. However, the transport only has TOSlink which seems to only connect to other audio equipment, not computers. How can I use the transport to extract a file as oppose to move the data to another piece of sound equipment?

Tyler Durden
  • 2,186
  • 4
  • 34
  • 49

2 Answers2

1

You could get a sound card with toslink in.

However, doing this makes no sense since you would have to record the song at realtime speed. Get a CDROM if you want to rip CDs.

user1850479
  • 14,842
  • 1
  • 21
  • 43
  • My concern with CD-ROM players is that they might not be faithful to the data stream compared to a "CD transport". I assume that people pay big bucks for transports for a reason. If you could just use a $50 CD-ROM player to generate the data stream accurately there would be no need for transports. Justme's answer above suggests something along these lines, because he says that ripping programs do not just read data off the disk, they use a complex algorithm that does not have repeatable results and moreover may be very inaccurate. – Tyler Durden Dec 30 '21 at 13:43
  • @TylerDurden A CDROM using a secure mode ripping program will be more resilient than a stand alone CD player, especially with damaged or scratched disk. If this is a concern you should not be using toslink. The whole point of a standalone player is to stream in real-time, not stop and reread a damaged sector. – user1850479 Dec 30 '21 at 17:07
0

Audio tracks are not files on disc, so technically it is not easy or even possible with some equipment to accurately reconstruct them back into files.

They are just streams of data with some metadata that can be used to indicate to the player which track is playing at which time.

This metadata may come out with the S/PDIF stream or not, and even if it does, receiving it with a PC may require an advanced professional audio interface card, as standard sound cards usually don't receive this metadata and they may not even bit-accurately receive the audio if some internal resampling is done to sync the audio with the receiver master clock.

As copying tracks to audio files was not initially possible on early CD drives, on the drives it was possible it was usually highly inaccurate. The so-called CD ripping programs use algorithms to extract the audio by reading it multiple times in chunks of data that overlap and then they discard the identical parts and only add the new parts into a file, which may or may not produce an identical disc when the audio files are burned back again as an audio disc.

Justme
  • 127,425
  • 3
  • 97
  • 261
  • 2
    They are not "files", but they most definitely are fixed-format deterministic digital data with an error correcting code. And you can read that data in one go as-if you were playing audio, just many times faster. The whole rigmarole of overlapped reads and whatnot is an implementation detail and a historical malady with no real engineering reason for it. So this answer is mostly just a bunch of brouhaha. You can accurately make bit-identical image of CD's contents, recovering all metadata and whatnot. These days all you need is a USB microscope and an automated X-Y stage. No need for lasers :) – Kuba hasn't forgotten Monica Dec 30 '21 at 08:02
  • @Kubahasn'tforgottenMonica Unfortunately I have to disagree with you. CD was originally meant only for streaming audio like a digital LP record, not for exact random-accessing any given audio frame, so seeking is a very approximate operation. It only works for computer data, because for each audio timecode frame of 2352 bytes, 304 bytes is reserved for containing an exact data sector number and ECC data for the 2048 bytes of computer data. The audio timecode frames have much less protection and consist of 98 audio frames of 33 bytes with 24 bytes of user audio data. – Justme Dec 30 '21 at 09:03
  • So all players need to read and decode at least 98 concecutive 33-byte audio frames to even get enough bits for decoding PQ subchannel info to know which 2352-byte audio timecode frame is currently being read and to know the alignment of which 33-byte frames belong to which timecode frame to even show the playback track and timecode to user. So that is why demanding a CD drive to read a block of 16 audio sectors starting from timecode sector X is a big slow thing and not all drives implement it identically, some early drives were inaccurate or did not bother to implement reading audio data. – Justme Dec 30 '21 at 09:18