whipper-team
Figure out why morituri compares the cdrdao fast-toc against the slow-toc
As title: Figure out why morituri compares the cdrdao fast-toc against the slow-toc, and understand if/why we need the slow toc.
Glad you made this, I had wondered about this myself before and did some preliminary investigation before, but was focused on answering the pre-emphasis flag origins question and never finished. First step is to investigate what cdrdao does differently when the --fast-toc flag is applied to read-toc.
This may have been some kind of paranoid mode, which unfortunately breaks whipper with some drives and costs a lot of time. AccurateRip should be good enough to verify the correctness. Whipper's Musicbrainz lookup already happens to use the result of cdrdao read-toc --fast-toc.
Now that getFastToc() isn't faster than getTable() anymore (since #345 I think), it seems obvious that getFastToc() was previously meant to speed up two things:
- Getting to the point where MusicBrainz can get queried.
- Using the table cache to avoid having to obtain the regular TOC more than once.
I don't think 1. and 2. were the main reason for getFastToc. Or rather, let me rephrase: why do we not always use fast-toc?
The manual says this:
--fast-toc
Only used for command read-toc. This option suppresses the pre-gap length and index mark extraction which speeds up the read-toc
process. Standard 2 second pre-gaps (but no silence!) will be placed into the toc-file. The resulting CD will sound like the
source CD. Only the CD player's display will behave slightly different in the transition area between two tracks.
This option might help, too, if read-toc fails with your drive otherwise.
I've done some tests and I found that the results are often the same. So maybe most CDs have 2s pregaps already. I've done about 200,000 rips with just --fast-toc and never using the slow toc -- because it takes way too long. That's what this issue was about.