2

I have a hard time using Linux' built-in tools to rip an audio cd (sound juicer, rhythmbox). The reason likely being my drive, which vibrates a lot and cannot read the disk continuously. Playing the disk in any audio player results in short pauses and stutter-y playback. Ripping the CD results in noticeable artefacts. I would have thought there's some validation going on in those tools, say for example a buffer that's save to convert, but apparently that's not the case and data is converted as comes from the drive. This phenomenon occurred on several cds to different extent.

To work around the drive, I copied the .wav files over to disk (using thunar file browser). To double check if at least that worked, I found the location of the CD files, cd'd into that directory and used diff to compare the first file to the copied on in my music directory:

/run/user/1000/gvfs/cdda:host=sr0$ diff Track\ 1.wav ~/Music/Artist/Album/Track\ 1.wav 
Binary files Track 1.wav and /home/me/Music/Artist/Album/Track 1.wav differ

Ok, so they are different. Why is this the case? How can I copy the file correctly without getting a different one? Or is the problem with my verification? Is diff a valid way to to compare the two files?

Ideally, I'd love to just rip a CD to flac files renamed to match the track titles like sound juicer would do, but more reliably.

Improve this question

1 Answer 1

Reset to default
3

To rip an audio CD you should really use a tool such as cdparanoia.

This will handle jitter and error correction, will retry as necessary, and try to create a "perfect" datastream.

Typically you would use this to create the wav files, which can then be converted to FLAC format as necessary.

There are other tools, including some front end GUIs, that can talk to external databases like CDDB to automatically work out the album and track names, but for raw audio ripping cdparanoia is hard to beat.

Improve this answer
2
  • From cdparanoia -B I get a constant :-P Unreported loss of streaming in atomic read operation during the extraction process and the progressbar is filled with + Unreported loss of streaming/other error in read entirely, but it did created two files in the end that sound good. During the 3rd track, the drive becomes unavailable paranoia_read: CDROM drive unavailable, bailing. Then the drive rereads the disk again as if it was just inserted (the associated application for autoplay pops up. Is this a hardware problem? It looks like the drive is broken not working properly.
    – null
    Aug 27, 2016 at 17:51
  • Yes, that's a hardware problem :-) The machine lost communication with the drive in the middle, and then found it again so it thought it had been unplugged/plugged in.
    – Stephen Harris
    Aug 27, 2016 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .