AccurateRip failing on every disc for every track after the first with fre:ac v1.1.6

[ciphersimian]

I'm on Ubuntu 20.04.4 using the AppImage version.

I have an ASUS DRW-24B1ST j 1.01 drive which was detected with an offset of 6 (and that is also what is shown for this drive at http://www.accuraterip.com/driveoffsets.htm).

I never had any issues with fre:ac v1.1.4 which is the last version I was using before updating to v1.1.6 (I guess I skipped over v1.1.5).

One difference is that I'm now trying to use the "meh! multi encoder hub" to create FLAC and MP3's at the same time.

I get this error (with different hashes obviously) for every track after the first on every disc I've tried:

00:00:04.789     Ripping: device://cdda:0/2
00:00:04.789          to: Eminem - The Eminem Show/02. White America.[FILETYPE]
00:00:04.789         Decoder: CDIO Ripper Component v2.1.0
00:00:04.789 
00:00:20.478     Failed to verify input track: device://cdda:0/2
00:00:20.478         Track could not be verified as accurate:
00:00:20.479             Checksum (AccurateRip v1): 2da35daa
00:00:20.479             Checksum (AccurateRip v2): 93cc7aff
00:00:20.479 
00:00:21.203     Finished ripping: device://cdda:0/2
00:00:21.203         CRC checksum: b10df948
00:00:21.203         Duration: 00:16.414 (19.8x speed)

EDIT: I originally thought I didn't have this problem if I use the FLAC encoder directly; only when using meh or the MP3 encoder, but further testing has shown that it happens most of the time with just the FLAC encoder as well. The one instance where I didn't see it must have been a fluke.

I also noticed looking closer at the logs while comparing these that it never seems to happen on the first track, only on each subsequent track. I attached some logs showing the issue on 1.1.6 and the same disk, same drive, etc. on 1.1.4. Looking at the logs now it seems there are no indications of AccurateRip in 1.1.4 so perhaps that was added and I'm misremembering it being supported in earlier versions? I was formerly an Exact Audio Copy user but fre:ac works better on Linux so I switched. Maybe I'm remembering EAC's AccurateRip support though.

I included logs from both no read offset (default, presumably 0?) and with it set to 6 on each version. AccurateRip fails on the first track as well when the offset is not set which makes some sense since the offset for this drive is +6 samples.

The no_offset versions have matching CRCs and the 6_offset versions have different matching CRCs. This also makes sense. But neither matches the AccurateRip checksums (including the one that says it was successful). Also odd that the listing of tracks and offsets that fre:ac prints shows the exact same offsets in every log; I suppose these are the actual disk offsets or something, not affected by the drive read offset? I guess I was expecting the offsets to be shifted in that track listing.

I'm hoping something here gives you an idea or an avenue for me to provide additional debug info!

no_offset-1.1.6-20220618_162821_Conversion_1_-_20_tracks.log 6_offset-1.1.4-20220618_161702_Conversion_2_-_20_tracks.log no_offset-1.1.4-20220618_160242_Conversion_1_-_20_tracks.log 6_offset-1.1.6-20220618_151339_Conversion_2_-_20_tracks.log

[ciphersimian]

I just got a brand new PLEXTOR PXL-910S WP3M and it has the exact same issue... this seems like it must be an issue with the fre:ac AccurateRip implementation.

[zsoldosp]

I had the same issue on fre:ac v1.1.6

I got it resolved by going to Options - Configure AccurateRip, and clicked the Detect offset now button. The drive db had the offset at 6, but detected 0. Using the detected offset resulted in no-error verification after ripping

HTH

[limsim]

Ah! this solved my problem. Why isn't this done automatically?

[rambo919]

I did this to fix the same problem and now it freezes during rip. EDIT: ok turns out this is now due to parallel processing, if I disable that the rip completes but now most files are still failing. The weird thing is each time I do the same disc rip different tracks pass but most fail.