Bug 508371

Summary: Discs don't rip accurately anymore
Product: [Applications] Audex Reporter: Ludvig Liu Holtze <ldw.liu.holtze>
Component: GeneralAssignee: Carl Schwan <carl>
Status: REPORTED ---    
Severity: normal CC: null
Priority: NOR    
Version First Reported In: 25.08.0   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Log file of ripping between v24 and v25
24.12.3 Screenshot
25.08.2 Screenshot
24.12.3 *.cue file
24.12.3 *.log file
25.08.2 *.cue file
25.08.2 *.log file

Description Ludvig Liu Holtze 2025-08-17 06:57:05 UTC
SUMMARY
I can't get any of my rips to pass AccurateRip verification since upgrading to Audex 25.08.0. When I try to rerip discs ripped with previous versions of Audex – that previously verified correctly, with the same sample offset – all tracks now fail verification.

STEPS TO REPRODUCE
1. Rip a known good disc with Audex 25.08.0 and a previous version (using the correct offset for your drive)
2. Verify the rips through a third party program (ARver for example)

OBSERVED RESULT
Rips made with Audex 25.08.0 fail verification while <25.08.0 succeeds.

EXPECTED RESULT
Both rips verify correctly.

SOFTWARE/OS VERSIONS
OS: Fedora Linux 42
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1

ADDITIONAL INFORMATION
When I first launched 25.08.0, I noticed the sample offset in the settings menu had been reset to 0, so I set it back to the correct value. Did you change anything internally regarding the offset? Is it possible it isn't applied correctly?

I also noticed .cue files made by 25.08.0 no longer contain catalog/ISRC fields, even though they used to appear when ripping the same discs in earlier versions. Not sure if that's related though.

If you need more information, please let me know.
Comment 1 Unknown 2025-10-18 01:02:39 UTC
I came to check if Audex used AccurateRip or just Secure Mode. So it's good to find out it's Secure Mode and thanks to Ludvig I now know about Arver for verifying logs.

Onto the issue. My drive offset is +6. I'm ripping Rory Gallagher Live In Europe. I'm also on Fedora 42. I downgraded to Audex 24.12.3 and ripped. Running it against Arver it verified the rip was good. I then upgraded back to Audex 25.08.2 and ripped. Immediately I noted that Audex 25.08.2 was ripping much more quickly than 24.12.3. However, when I checked the rip there was a track length mismatch and I was told to re-run in permissive mode. Which I did. Verification of all tracks failed and it claims my disc pressing isn't in the MusicBrainz database (it is).

I also noted in Audex settings, under Device Settings, that 25.08.2 is now missing device information that is displayed in 24.12.3. Things such as the Vendor, Model, Revision, MCN, ISRC and whether or not C2 error correction is available.
Comment 2 Unknown 2025-10-18 01:04:46 UTC
Created attachment 185873 [details]
Log file of ripping between v24 and v25

This is the logs when running arver against the ripped files for both version 24.12.3 and 25.08.2.
Comment 3 Unknown 2025-10-18 01:06:07 UTC
Created attachment 185874 [details]
24.12.3 Screenshot

Screenshot of the device settings window showing information in 24.12.3
Comment 4 Unknown 2025-10-18 01:07:37 UTC
Created attachment 185875 [details]
25.08.2 Screenshot

Screenshot of the device settings window showing information in 25.08.2
Comment 5 Unknown 2025-10-21 06:17:44 UTC
Created attachment 185952 [details]
24.12.3 *.cue file

This is the cue file for 24.12.3 which ripped and verified successfully.
Comment 6 Unknown 2025-10-21 06:19:24 UTC
Created attachment 185953 [details]
24.12.3 *.log file

This is the log file for 24.12.3 which ripped and verified successfully.
Comment 7 Unknown 2025-10-21 06:27:11 UTC
Created attachment 185954 [details]
25.08.2 *.cue file

This is the cue file for 25.08.2 which ripped but failed verification.
Comment 8 Unknown 2025-10-21 06:28:04 UTC
Created attachment 185955 [details]
25.08.2 *.log file

This is the log file for 25.08.2 which ripped but failed verification.