Skip to content

Add --tracks to rip only selected tracks - #716

Open
mkoester wants to merge 4 commits into
whipper-team:developfrom
mkoester:feature/rip-selected-tracks
Open

mkoester wants to merge 4 commits into
whipper-team:developfrom
mkoester:feature/rip-selected-tracks

Conversation

@mkoester

Copy link
Copy Markdown

Fixes #578.

Depends on #694, which is the first commit here: without it, writing the log crashes on every track that is not ripped. Please review the last three commits; I'll rebase once #694 is merged.

whipper cd rip -t/--tracks 3,5 or --tracks 3-7,10-13 rips only the given tracks. The main use is retrying a track that failed on an earlier rip, without reading the rest of the disc again. It is an include list, as suggested in the review of #260.

Behaviour

  • The selection is validated up front: 0, numbers above the track count, 7-3, and malformed items give a one-line error without a traceback. Syntax errors are caught before the TOC is read; the track count is checked once it is known.
  • Tracks that are not selected are not ripped, verified or touched, even if a file from an earlier rip exists. They keep their cue entries and are marked skipped with a new not_selected flag.
    • The log shows them as Track not ripped (not selected).
    • The health status says Only selected tracks were ripped.
    • The AccurateRip report shows not ripped (not selected).
    • They do not cause exit code 5, which still means that a selected track failed.
  • Hidden Track One Audio is ripped only when track 1 is selected.
  • Ripping into a finished rip of the same disc is allowed with --tracks (without it, it is still refused).
    • A selected track whose file exists is ripped again. The new file replaces the old one only on success, so a failed retry keeps it.
    • The existing .log is kept, and this run's log is written as <disc> (tracks 24).log. The .cue and .m3u are rewritten; the m3u lists every track whose file exists.
    • AccurateRip then verifies every file in the folder.
  • The table of contents an earlier rip saved (<disc>.toc) is reused with --tracks, instead of running cdrdao read-toc again. That read scans the whole disc and takes minutes on a damaged one.
    • It is used only when its CDDB and MusicBrainz disc ids match the inserted disc; otherwise the TOC is read as before.
    • --reread-toc forces reading it.

Also in here, because every partial rip triggers it: a track without a file (skipped or not selected) no longer logs two could not calculate AccurateRip checksum errors, only the existing warning. A track that failed with -k is reported as not ripped (skipped) instead of unknown (error). The errors remain for a file that exists but cannot be checksummed.

Tests

  • New unit tests cover the selection parser and formatter, the log wording, the AccurateRip report lines and logging, and loading the saved TOC. Those tests check that a matching TOC is used without reading the disc, and that a missing, unparsable or other disc's TOC falls back to reading it.
  • The rip loop has no test harness, so it was verified with real rips of two damaged discs.
    • -t 19-24 into an existing rip left tracks 1–17 untouched and verified all present files against AccurateRip.
    • -t 24 -r 0 reused the saved TOC, recovered a track that had failed in two earlier runs, and verified it as accurate.

This touches the same rip loop in cd.py as #702 and #711, so one of them will need a rebase.

🤖 Generated with Claude Code

Mirko Köster and others added 4 commits July 20, 2026 17:19
A track that fails every rip attempt is marked skipped and never gets a
peak level, leaving trackResult.peak as None. writeLog() -> trackLog()
then did an unconditional `trackResult.peak / 32768.0`, raising
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'`
and aborting the whole run *after* every other track had ripped fine, so
no log or cue file was written.

This is easy to hit on enhanced/CD-Extra discs: the last audio track
(right before the trailing data track) often fails to read, gets skipped
with -k, and then takes the log-writer down.

Guard the peak line so the "Peak level" entry is simply omitted for a
track without a peak, matching cd.py which already avoids the same
division for skipped tracks. Add a regression test covering a rip that
contains a skipped track.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Mirko Köster <git@mirkokoester.de>
Accepts track numbers and ranges (3,5 or 3-7,10-13). Unselected tracks are left alone and logged as not selected. With --tracks, a finished rip of the disc can be ripped into: its log is kept and this run logs to '<disc> (tracks N).log'. Fixes whipper-team#578.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Mirko Köster <git@mirkokoester.de>
Reading the full TOC scans the whole disc, which takes minutes on a damaged one. With --tracks, the .toc an earlier rip saved is loaded instead when its disc ids match the inserted disc; --reread-toc forces reading it again.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Mirko Köster <git@mirkokoester.de>
A track that was skipped or not selected has no file; that is expected. Log it once as a warning instead of two checksum errors, and report a skipped track as 'not ripped (skipped)' instead of an error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Mirko Köster <git@mirkokoester.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add ability to rip just particular tracks from a CD

1 participant