Verify Output Sample Count

[joshstoik1]

Describe the bug When a track rip immediately fails, fre:ac will sometimes mistakenly believe the rip was accurate and remove it from the job list.

To Reproduce I believe this only occurs when no audio data is read/written, i.e. the first sector returns an SCSI read error.

Expected behavior fre:ac should double-check the sample count of the output actually matches the expected track length (from e.g. the table of contents), and report the rip as invalid if there's a mismatch.

Screenshots Here is an example snipped from a rip log:

00:01:51.505     Ripping: device://cdda:0/8
00:01:51.505          to: Nirvana_-_Nevermind/08_-_Nirvana_-_Sappy.flac
00:01:51.505         Decoder: CDIO Ripper Component v2.1.0
00:01:51.505 
00:02:00.982     Successfully verified input track: device://cdda:0/8
00:02:00.982         Track has been accurately ripped:
00:02:00.982             Checksum (AccurateRip v1): 00000000, Confidence: 0
00:02:00.982             Checksum (AccurateRip v2): 00000000, Confidence: 0
00:02:00.982 
00:02:00.984     Finished ripping: device://cdda:0/8
00:02:00.984         CRC checksum: 00000000
00:02:00.984         Duration: 00:09.479 (0.0x speed)
00:02:00.984 
00:02:00.986     Verifying: 08_-_Nirvana_-_Sappy.flac
00:02:00.986 
00:02:00.987     Successfully verified output file: 08_-_Nirvana_-_Sappy.flac
00:02:00.987         MD5 hash: d41d8cd98f00b204e9800998ecf8427e
00:02:00.987         Duration: 00:00.001 (0.0x speed)

System (please complete the following information)

• OS: Ubuntu Lunar
• CPU: Intel® Core™ i7-10610U
• RAM: 16.0 GiB

Additional context I was using a Pioneer drive set to "Perfect Mode", which causes the drive to return hard SCSI errors for unreadable sectors rather than interpolating them. (Honesty is the best policy!)

Also, I had Paranoia disabled.