Perfect Single-File FLAC: cdrdao vs. abcde

Topic: Perfect Single-File FLAC: cdrdao vs. abcde (Read 21049 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Perfect Single-File FLAC: cdrdao vs. abcde

2011-04-23 08:58:02

I'm attempting to rip a CD to a single file that can be used to produce a bit-perfect reproduction of the original CD (or as close as possible to bit-perfect -- at least something that CDDB will recognize). I'm compressing with FLAC to save space, and because of FLAC's wide compatibility. I also really like the "abcde -d file.flac" technique for encoding single-file FLAC albums to lossy separate tracks. I prefer to use linux native tools.

Question 1:
Will the file that results from

Code: [Select]

cdrdao read-cd --read-raw --driver generic-mmc-raw --with-cddb --datafile file.bin file.toc
toc2cue file.toc file.cue
flac --best --force-raw --sample-rate=44100 --channels=2 --bps=16 --endian=big --sign=signed --cuesheet=file.cue file.bin -o file.flac

be better for reconstructing the original CD than the file that results from

Code: [Select]

abcde -1 -M -o flac

Using abcde is appealing because of its simplicity, and I suspect it's faster than the first option. Can anyone suggest steps superior to either of these options (e.g. better/different switches on cdrdao and flac, or different tools altogether)?

Question 2:
I plan to reconstruct CD's (if necessary) by decoding the FLAC and writing with cdrdao.

Code: [Select]

flac --decode --force-raw --endian=big --sign=signed --output-name=file.bin file.flac
cdrdao write data.toc

As the "--with-cddb" option adds CD-text data to the cdrdao's toc file, does that mean the resulting toc cannot be used to reconstruct a bit-perfect reproduction of the original CD? Is it best not to use this option for that reason?

Question 3:
Has abcde (now in version 2.4.2) improved such that "abcde -1 -M -o flac" accomplishes the result desired by these tedious steps:

Quote from: Charles Steinkuehler on 2006-07-13 21:43:07

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

see also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389975

Question 4:
Regarding FLAC options, is it preferable to use "--endian=big" or "--endian=little"?

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #1 – 2011-04-24 02:09:06

Also, if "abcde -1 -M -o flac" is used to create a single FLAC from an album, how does one decode flac and burn a bit-perfect copy of the original disc? (Note that if, instead, the single FLAC file is just a compressed .bin created by cdrdao, it's easy to decode the FLAC to a .bin and use cdrdao to burn a disc.)

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #2 – 2011-04-24 03:29:58

Welcome to the forum. Now, let me disect your post bit by bit.

Quote from: soundman on 2011-04-23 08:58:02

I'm attempting to rip a CD to a single file

That's a bad practise, support for single file playback and handling is generally bad. You use abcde for splitting the tracks into sepereate files, but be aware that the ratio of programs being able to handle single file rips to multiple file rips is very unfavoring towards the single file solution.

Quote from: soundman on 2011-04-23 08:58:02

that can be used to produce a bit-perfect reproduction of the original CD (or as close as possible to bit-perfect -- at least something that CDDB will recognize).

That is a contradiction in itself. The only thing for CDDB to recognise a disc is the TOC (table of contents), the audio data is totally irrelevant, it can be zeros or random data, because it is never interpreted when creating the CDDB Id.

Then you say you want to have a bit-perfect copy of your CD. Well using cdrdao there is a high chance that you will not get a bit-perfect rip if your CD has physical errors. Even if there seems to be nothing wrong with your CD, no visible scratches, there can be simply pit defects that were introduced during the manufacturing. If you want to reliably get bit-perfect copies the only 100% safe way is to cross-check the checksums of your extracted audio data with the results of other people. You can achieve this by using a ripper that supports either AccurateRip or the new CueTools Database. (CTDB).

Oh and a so called secure ripper is a reasonable approximation towards bit-perfection if read errors are present, although it will never be 100% reliable. No ripping without cross-checking with a CRC database will ever be, because of the nature of the Audio CD format.

Quote from: soundman on 2011-04-23 08:58:02

I'm compressing with FLAC to save space, and because of FLAC's wide compatibility. I also really like the "abcde -d file.flac" technique for encoding single-file FLAC albums to lossy separate tracks. I prefer to use linux native tools.
Question 1:
Will the file that results from
Code: [Select]
cdrdao read-cd --read-raw --driver generic-mmc-raw --with-cddb --datafile file.bin file.toc
toc2cue file.toc file.cue
flac --best --force-raw --sample-rate=44100 --channels=2 --bps=16 --endian=big --sign=signed --cuesheet=file.cue file.bin -o file.flac
be better for reconstructing the original CD than the file that results from
Code: [Select]
abcde -1 -M -o flac
Using abcde is appealing because of its simplicity, and I suspect it's faster than the first option.

Makes no difference, it's both error prone. The bin/cue format of cdrdao is using the standard scheme of a single file rip, except that the audio format in the bin file is not WAVE, but raw PCM. Using

Code: [Select]

abcde -1 -M -o flac

has the advantage that you skip one flac command line. The results should be equally bad, i.e. insecure (=meaning there could be undetected read errors in your audio data).

Quote from: soundman on 2011-04-23 08:58:02

Can anyone suggest steps superior to either of these options (e.g. better/different switches on cdrdao and flac, or different tools altogether)?[/color]

Yes, I would recommend different tools, you should try CueRipper (needs Mono and may be buggy under Linux) or XLD. Use search to find them on the forum.

Quote from: soundman on 2011-04-23 08:58:02

Question 3:
Has abcde (now in version 2.4.2) improved such that "abcde -1 -M -o flac" accomplishes the result desired by these tedious steps:
Quote from: Charles Steinkuehler on 2006-07-13 21:43:07
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

see also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389975

That must be one of the most complicated and masochistic ways of ripping a CD I have ever seen. There are tools doing all that reliably (whereas your method seems unreliable due to manual error because of the many steps involved) with the click of a single button! Out of curiosity, did you come across a CD ripping guide from 1995 or something?

Quote from: soundman on 2011-04-23 08:58:02

Question 4:
Regarding FLAC options, is it preferable to use "--endian=big" or "--endian=little"?

Depends on whether the raw PCM data of the Audio CD format is either big endian or little endian, which I don't know and I don't give a damn about. Because that question would be irrelevant if you would simply use WAVE as the input format.

I hope I could help.

tl;dr cut all that crap and use XLD. but if you're feeling andventurous and daring try CUERipper of the very cool and practical CUETools program mini-suite.

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #3 – 2011-04-24 08:08:36

Quote from: Fandango on 2011-04-24 03:29:58

I hope I could help.

Yes, you have been helpful. Thank you for you suggestions, Fandango. Is XLD available natively for linux? Does anyone have experience setting up and using CUETools on linux? What is the best native-linux solution?

I used Rubyripper for a while, but grew weary of the endless re-ripping and audibly-imperfect results. Do all secure-ripping programs rip and re-rip a long time on most discs (i.e much slower than one pass with cdrdao)?

I'd like to continue ripping each album to a single file (something that's easy to split, encode to lossy, and automatically tag at a later date if desired).

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #4 – 2011-04-24 13:27:10

To add:

Quote from: soundman on 2011-04-23 08:58:02

Question 2:
I plan to reconstruct CD's (if necessary) by decoding the FLAC and writing with cdrdao.
Code: [Select]
flac --decode --force-raw --endian=big --sign=signed --output-name=file.bin file.flac
cdrdao write data.toc
As the "--with-cddb" option adds CD-text data to the cdrdao's toc file, does that mean the resulting toc cannot be used to reconstruct a bit-perfect reproduction of the original CD? Is it best not to use this option for that reason?

This depends in which context you use bit-perfect. Non-audio data such as CD-Text and ToC parameters certainly will not affect the audio portion of the disc, by their very nature. But if you add CD-Text to, and subsequently write to another CD, an image of a disc that didn’t have it beforehand, technically that introduces differences in the disc’s subchannel data.

Similar differences can be introduced in various ways if the subchannel data is reconstructed from elsewhere (ToC and additional information, e.g. from a cue-sheet) rather than being ripped and rewritten as-is. However! Subchannel data almost invariably matters so little, and indeed is so difficult to verify (or even obtain; I once had a drive that couldn’t read the same thing twice from this are), that I advise against worrying about it. Reconstructing the data should be perfectly adequate.

Plus, in this specific example, you would be adding potentially useful information, so it could be looked at as a win-win situation.

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #5 – 2011-04-26 09:04:49

Quote from: soundman on 2011-04-24 08:08:36

Is XLD available natively for linux?

Not having a Linux dekstop in ten years, I don't keep track of what's actually available for Linux. Hm, I was under the impression that XLD was already ported to Linux. But it actually wasn't! Bummer.

You can always try to use Windows software with Wine. If that is an option for you, I would suggest you try to use Exact Audio Copy via Wine at least once. It's the program that kind of set the standard. An alternative would be CUE Ripper using Mono, maybe it's suited even better.

Rubyripper would be the obvious native choice. Read what I've written further down about your issue with it.

Quote from: soundman on 2011-04-24 08:08:36

Does anyone have experience setting up and using CUETools on linux?

It does work with Mono, although it sometimes breaks after updates or because your Wine installation is not up to date. This is just a guess, but you would probably have to use your Linux distributions bleeding edge software repository for Mono and Wine to work with these programs.

Quote from: soundman on 2011-04-24 08:08:36

What is the best native-linux solution?

Bad news: AFAIK there is none. Read further down about CUE Tools purpose and main feature.

Quote from: soundman on 2011-04-24 08:08:36

I used Rubyripper for a while, but grew weary of the endless re-ripping and audibly-imperfect results. Do all secure-ripping programs rip and re-rip a long time on most discs (i.e much slower than one pass with cdrdao)?

Yes, that's one characteristic of traditional secure ripping. But nowadays it is not necessary anymore, since albums can be checked against the AccurateRip database and the even newer CTDB. I would strongly recommend a ripping software (the hassle of setting it up with Wine is worth it!), that checks a CD before ripping whether it's been included in one of those databases. If it is, no secure ripping method is needed, a simple burst rip / low paranoia level is sufficient. Re-reading sectors/tracks is then only performed if the software detects a CRC mismatch or if the CD is not yet in the databases the whole disc could/should be ripped with the slow secure method.

Now about Rubyripper. It does not support AccurateRip AFAIK, so if you want the assurance that your rips are ok, you will have to endure the slow ripping process. Hm, it seems there's actually no native Linux CD ripper with AR/CTDB support... weird.

Quote from: soundman on 2011-04-24 08:08:36

I'd like to continue ripping each album to a single file (something that's easy to split, encode to lossy, and automatically tag at a later date if desired).

Well, EAC and CUERipper support this mode fully. CUE Tools' main purpose even was to handle these kind of rips to begin with. CUE Tools was created to losslessly convert a single file rip to a multi-file rip and vice versa, cue sheet included of course. It can also re-check already ripped rips and even correct ripping errors if that CD was already submitted to its CTDB by someone else.

I would definitely check both out using Mono (CUETools/CUERipper) and Wine (EAC). CUERipper is very easy to use, I'm sure you will like it.
But for real Linux support check out the corresponding threads and forums or use Hydrogenaudio forum search and check out the appropriate subforum here. Since I've never tried to get them to run on Linux I can't help you any further.

CUE Tools: http://www.hydrogenaudio.org/forums/index....showtopic=66233
Exact Audio Copy: http://www.digital-inn.de/forum271/

But maybe you will also find that there's a satisfying solution with native programs... you have to wait for a Linux user to post here, or try searching this forum. People with your exact same problem have come here since years. Or jsut try searching for "ripping linux" on google... then carefully look for results that mention secure ripping and AccurateRip and ignore the rest since those probably won't help you any further.

PS: Regarding what dv1989 said... yeah, CD audio extraction is not about also getting subchannel data... although the track indices like the pregap information is such data and is very tricky to retrieve even today. A total bit-perfect copy is VERY hard to achieve, you woul have to use software that was originally designed for 1:1 copies of copy-protected PC games. These tools are not secure by design as error correction would beat their purpose and are only available for Windows, too, probably never going to run via Wine, since they often need special low-level drivers. In a nutshell this is totally not what you want when ripping an audio CD. I personally think even pre-gaps and CD text which are both sub-channel information is not really needed. Your main concern should be the audio data and the TOC. Both can be extracted securely and sufficiently.

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #6 – 2011-05-01 07:19:56

Thanks for your replies, everyone. One reason I liked cdrdao was that it can easily burn an exact copy of the original disc, after decoding the .flac disc image back into a .bin file. With EAC, decoding the .flac disc image results in a .wav file, correct. I assumed there might be more trouble producing an exact copy of the original disc using this file (e.g. difficult to get the same initial pregap as on the original disc, etc.). Which linux tools can take a .flac disc image produced by EAC and burn an exact copy of the original CD? Note that EAC under Wine sometimes has burning problems, so I'd like an alternate suggestion.

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #7 – 2011-05-11 02:13:42

RubyRipper was a promising tools last time I checked. Unfortunately still had some major blocking bugs. But once it is more than stable, it can replace EAC or another command line tool.

Perfect Single-File FLAC: cdrdao vs. abcde

Reply #8 – 2011-05-30 16:46:24

Hi all, this is a slightly old thread now, I realise, but since I was toying with all this over the weekend, I thought I'd add my notes, in case it's useful for anyone later.

Quote from: soundman on 2011-04-23 08:58:02

Will the file that results from

Code: [Select]

cdrdao read-cd --read-raw --driver generic-mmc-raw --with-cddb --datafile file.bin file.toc                      
toc2cue file.toc file.cue                                                                                              
flac --best --force-raw --sample-rate=44100 --channels=2 --bps=16 --endian=big --sign=signed --cuesheet=file.cue file.bin -o file.flac

be better for reconstructing the original CD than the file that results from

Code: [Select]

abcde -1 -M -o flac

Well, abcde uses mkcue rather than cdrdao to extract the disc's TOC, and mkcue does not do the fancy sub-channel reading that cdrdao does. You will miss out on pregaps, ISRC-codes and such. More importantly (because this actually affects the audio), I don't think mkcue handles the PRE_EMPHASIS flag at all.

As for your own set of steps above: don't rely on the toc that "cdrdao read-cd" produces. The problem, I believe, is that "read-cd", having been written around some version of cdparanoia, does not do linear reading. When you do the sort of jumping around that cdparanoia does, most drives return sub-channel information that is not from the exact current position. You can see this if you repeatedly make toc files through "cd-read": the pregap numbers are all over the place. (I think the author of EAC knows this, too: EAC always reads the pre-gaps in a separate go, iirc?)

So you want to do a separate run of "cdrdao read-toc" (for bonus points, I like to compare with and without the --fast-toc switch: the slow option reads the sub-channel, the fast one reads the on-disc TOC, and sometimes one contains ISRC codes and the other doesn't, or they differ... all good fun).

However... "read-toc" does something different than "read-cd" on discs that have track 1 starting at an offset ("hidden track one audio"). It seems to assume you can't read that part of the disc, and inserts a SILENCE statement, rather an offset START. I'm not sure if it's a bug or a feature, I only came across a disc like that for the first time yesterday - let's see what the cdrdao devs think. For now, that means you may want to merge both those toc files using something like vimdiff... (and Fandango thought _this_ was masochistic already )

Quote

I plan to reconstruct CD's (if necessary) by decoding the FLAC and writing with cdrdao.
Code: [Select]
flac --decode --force-raw --endian=big --sign=signed --output-name=file.bin file.flac
cdrdao write data.toc
As the "--with-cddb" option adds CD-text data to the cdrdao's toc file, does that mean the resulting toc cannot be used to reconstruct a bit-perfect reproduction of the original CD? Is it best not to use this option for that reason?

As dv1989 said - it's probably ok to change the metadata But in any case, --with-cddb will replace any CD-TEXT that came from the actual disc. If that bothers you, why not keep both the original toc file and the version with cddb data?It's only a few bytes extra. Just do "cdrdao read-toc" first, then copy the toc file, then run "cdrdao read-cddb" on the copied file (by the way, to keep your directories uncluttered, you can append both these files as flac comments using metaflac).

Quote

Has abcde (now in version 2.4.2) improved such that "abcde -1 -M -o flac" accomplishes the result desired by these tedious steps:
Quote from: Charles Steinkuehler on 2006-07-13 21:43:07
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

see also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389975

Interesting... it's 5 years later now, and as far as I can tell abcde still doesn't declare a dependency on cdrdao, so... if you really care about the pregaps, then no.

As for toc2cue: there's a more comprehensive converter called cueconvert, which is part of cuetools (which is not the same as CUETools...). It's available in the Debian/Ubuntu repo's. (but again, I just hold on to cdrdao's toc file as well, and stick it in a flac comment).

Quote from: Fandango on 2011-04-26 09:04:49

Quote from: soundman on 2011-04-24 08:08:36
Does anyone have experience setting up and using CUETools on linux?
It does work with Mono, although it sometimes breaks after updates or because your Wine installation is not up to date. This is just a guess, but you would probably have to use your Linux distributions bleeding edge software repository for Mono and Wine to work with these programs.

I think that's right. I had a brief go with the latest CUETools release (in the unpacked dir, just try "mono CUETools.exe"), but on my not-so-bleeding-edge Mono (just the one in Ubuntu 11.04), the GUI is a bit too broken to feel comfortable using it (you click stuff and never know if it did something ). More importantly, the flac module is not working, so all you can use is wav. What does work great though is ArCueDotNet.exe, the command-line utility that ships with CUETools to perform AccurateRip verification. The broken flac support means you'll have to decode first, but I think that's more than worth it because CUETools' AccurateRip implementation is famously offset-agnostic.

Quote

Now about Rubyripper. It does not support AccurateRip AFAIK, so if you want the assurance that your rips are ok, you will have to endure the slow ripping process. Hm, it seems there's actually no native Linux CD ripper with AR/CTDB support... weird.

There's morituri (also available in debian/ubuntu repositories). I'd say it's alpha-quality at the moment - it still crashes on stuff like unexpected musicbrainz data, and has some other rough edges, but I think it's worth testing it with a few disks, if only to give the developer some useful feedback. It looks like it will be pretty good in the future.

It doesn't quite do what's asked here though: it will always rip to separate files, with pre-gaps appended to the previous track (that is, the "non-compliant" cue-sheet option in EAC), and any hidden track-one audio will go in a separate file. Having said that, you can always recover the single file with something like "flac -d -c --force-raw-format *.flac > data.bin" (presuming that your track names start with track numbers so they're put out in the right order...).

(in fact, both RubyRipper and Morituri have a very strong focus on getting the pre-gaps and hidden track-one audio right. As such, they both build on cdrdao, but also, they've both cooked their own toc-to-cue conversion. They get all the indices and offsets right, which is quite a feature, but I don't think they're otherwise as complete as cueconvert yet)

Btw, I fully agree with Fandango that you don't want to miss out on AccurateRip support. I think CTDB is an even cooler feature, so let's try getting CUETools packaged for Linux.

Quote from: soundman on 2011-05-01 07:19:56

Thanks for your replies, everyone. One reason I liked cdrdao was that it can easily burn an exact copy of the original disc, after decoding the .flac disc image back into a .bin file. With EAC, decoding the .flac disc image results in a .wav file, correct. I assumed there might be more trouble producing an exact copy of the original disc using this file (e.g. difficult to get the same initial pregap as on the original disc, etc.). Which linux tools can take a .flac disc image produced by EAC and burn an exact copy of the original CD? Note that EAC under Wine sometimes has burning problems, so I'd like an alternate suggestion.

The flac decoder can give you a raw file, regardless whether you started with a wav file from EAC or a bin from cdrdao. Just use the switches you mentioned in your earlier post if you want a raw file (that is, force-raw, big endian etc etc). The thing is, pretty much the only difference between wav and cdrdao's bin files, is that wav contains a header describing what's inside the file, and the samples are stored small-endian. Flac is happy to output either. I think _the_ tool for burning is cdrdao.

Notice