Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: cdrdao/cdparanoia+toc questions (Read 6119 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

cdrdao/cdparanoia+toc questions

I'm trying to find a way to do the following, from the unix commandline (so probably either with cdparanoia or cdrdao, or a combination of both):
- rip the full CD to seperate files, one for each track
- perform error correction
- create a TOC file (similar to CUE) for the CD that works with the extracted files

cdparanoia does the multi-track thing but seems unable to generate a TOC (unless I'm missing something), while cdrdao appears to insist on dumping the entire disc contents to a single large file and basing the TOC on that.

The reason that I prefer seperate files is that I would like to be able to easily generate .ogg's out of them, which I'd naturally want to be seperate files too. If there's an easy and fully accurate way to later split a single big file into seperate .wav's based on the TOC file that would be acceptable too.

As a side question, are there any other reasons (such as ripping quality) to use one of cdparanoia/cdrdao and not the other? Note that my ripping drive is a Plextor PX-755A, and this drive is my only concern right now.


cdrdao/cdparanoia+toc questions

Reply #2
You may like jack: http://manpages.debian.net/cgi-bin/display...60&format=plain
It can rip to separate oggs from a single image file using the toc.

As to ripping quality: cdrdao uses code from cdparanoia for ripping,

Have to go... enjoy


Thanks for the tip, Jack indeed seems to be able to do what I need.

One small problem though, it seems completely unable to do anything with CD's that have a track 1 pregap, not from an image+toc and not directly from the original CD either. I'm assuming this is a bug and I'm going to try to hunt it down, but if anyone knows some kind of clever workaround for this problem I'd greatly appreciate it.

cdrdao/cdparanoia+toc questions

Reply #3
on the same subject I was also going to post a similar question
is there a script or something wich allows one to just pop a cd in the drive, rip it a
and to edit the meta-data later, preferably something wich creates stores individual files, otherwise some kind of iso wich can then be read by normal cd-ripping frontends like grip (btw slightly off topic how secure is rubyripper? I intend to backup all my cd collection as flac files once and for all but I no longer have a cacheless drive and I'm planning on buying a plextor-230a to do the ripping , and the current state of cdparanoias lack of cache disable support makes me hesitate on this), but otherwise I would be looking for something similar to the original posters question, rip first tag later and with an almost automated ripping , and wich created a toc so that upon decoding from multiple flac files the original cds could be rebuilt bit perfect
how are my chances?

cdrdao/cdparanoia+toc questions

Reply #4
Thanks for the tip, Jack indeed seems to be able to do what I need.

One small problem though, it seems completely unable to do anything with CD's that have a track 1 pregap, not from an image+toc and not directly from the original CD either. I'm assuming this is a bug and I'm going to try to hunt it down, but if anyone knows some kind of clever workaround for this problem I'd greatly appreciate it.


Hmm...jack seems to happily rip my "problem" CD with a track 1 pregap (The Police/Synchronicity, catalog#: 0082839373524).

cdrdao/cdparanoia+toc questions

Reply #5
I'm trying to find a way to do the following, from the unix commandline (so probably either with cdparanoia or cdrdao, or a combination of both):
- rip the full CD to seperate files, one for each track
- perform error correction
- create a TOC file (similar to CUE) for the CD that works with the extracted files

cdparanoia does the multi-track thing but seems unable to generate a TOC (unless I'm missing something), while cdrdao appears to insist on dumping the entire disc contents to a single large file and basing the TOC on that.

The reason that I prefer seperate files is that I would like to be able to easily generate .ogg's out of them, which I'd naturally want to be seperate files too. If there's an easy and fully accurate way to later split a single big file into seperate .wav's based on the TOC file that would be acceptable too.


I would suggest ripping to a single file...if you have tracks with lead-in, you could easily wind up with parts of a song split between two different files on disk.  I'm trying to rip to a single flac file (with embedded cue file) and have had various problems.  I'm currently using abcde (from debian-unstable) as a front-end, but the problems seem inherent to the back-end tools used (ie: cdparanoia & cdrdao).  What I've encountered:

cdparanoia: Won't rip lead-in by default...you have to specify a start of track zero for disks with lead-in (instead of track 1).  Alternately, you can specify a zero offset (ie: [00:00:00.00] ) which seems to work for all disks (regardless of lead-in/pre-gap).  Also, there is no way to get a cue file out of cdparanoia...it would be possible to massage the output of a query, but there is no sub-code decoding done to provide lead-in for any but the first track.

cdrdao: Will examine the sub-code channels to provide proper track lead-in information in the toc file (which can be converted to a cue file), but doesn't seem to rip the lead-in area (it puts a "silence" entry in the TOC, which is converted into a PREGAP entry when running toc2cue).  The big problem with this (assuming the data from the CD actually *IS* silence, so cdrdao isn't throwing away real data) is it prevents proper discid generation from the resulting cue file.  With a <leadin> sector offset on all tracks, typically the track-length hash (the most-significant byte of the 32-bit discid) is incorrect, and the track start offsets provided in an extended cddb query are also wrong.

If you *REALLY* want to use linux (I do, too, but I'm getting less sure about this), the best I've come up with given the existing tools is:

1) Rip the whole disk using cdparanoia with a zero sector start position (ie: cdparanoia [00:00:00.00]- )

2) Generate a TOC file using cdrdao read-toc

3) Convert the toc file to a cue file with toc2cue

4) "Massage" the cue file, adding any pre-gap to the track index positions

...or you could just run EAC and let it do everything for you.

NOTES: 
The latest abcde will happily rip from the resulting flac file (with embedded cue sheet) once the audio is ripped (via EAC, linux, or whatever).

If you don't care about the subcode information, you can pretty easily use cdparanoia to rip the entire cd, and convert the discid information into a cue file.  The resulting flac/cue file will generate a discid/cddb query identical to the physical CD, but you'll have lost any track lead-in information embedded in the subcode channels, which may cause problems when ripping individual tracks later.

If you want subcode details, you have to use cdrdao, but it won't rip any track 1 leadin/pregap, and you'll have to mung your cue file to get a clean discid/cddb query from the resulting cue file.

As a side question, are there any other reasons (such as ripping quality) to use one of cdparanoia/cdrdao and not the other? Note that my ripping drive is a Plextor PX-755A, and this drive is my only concern right now.


AFIAK, cdrdao uses the cdparanoia library for ripping audio data, so there should be no major difference in regards to rip quality.

Charles Steinkuehler

cdrdao/cdparanoia+toc questions

Reply #6
Wow, many thanks for the extensive information!