Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: after repair, verify & generate accurip report based on repaired audio #232

Open
mjb2010 opened this issue Nov 24, 2022 · 3 comments

Comments

@mjb2010
Copy link

mjb2010 commented Nov 24, 2022

Currently, if you do a Repair, CUETools generates a new .accurip file, but it's based on the unrepaired audio. It makes it seem like no repair has taken place, because unlike in a normal rip folder, the .accurip file does not reflect the current state of the files in that folder.

It would be nice to have the Repair script just go ahead and do another Verify step after the repair, so that it can generate a 2nd .accurip file, with "[ after repair]" appended to the name.

As it stands, I have to do the Verify separately, making sure to output to another folder, then move & rename the file and delete the other folder.

Regardless of whether the new .accurip file gets a special name, it would also be nice to have a message in the file like "CUETools DB: corrected 4849 errors", which is what the .accurip file used to contain after a repair (e.g. in CUETools 2.1.6).

@ha-korth
Copy link

A variation of this request is also on the HA Wishlist

@DarkVoyage
Copy link

DarkVoyage commented Jul 31, 2023

Here's the log after repair. It already contains exactly what you request.

[CUETools log; Date: 22.06.2023 23:44:05; Version: 2.2.4]
CUETools DB: corrected 6307 errors.
[AccurateRip ID: 002dff77-0249882f-04116911] found.
Track [ CRC | V2 ] Status
01 [e5e73e38|e57e7f4a] (0+0/3) No match
[...]
17 [68129515|0eca6063] (0+0/3) No match
Offsetted by 102:
01 [80cc7729] (3/3) Accurately ripped
[...]
17 [721cab7b] (3/3) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL]
-- 98,8 [C3A6F0FF] [4684AF85]
01 98,8 [3220BB7B] [C45B33A8]
[...]
17 64,0 [AC25FC53] [768B24AA]

@ha-korth
Copy link

DarkVoyage
That report is created before the repair is made using the info from the verify step of the damaged rip prior to repair and then altered by mathematically applying the repair. No verification is performed after the repair on the new file(s). This is why the OP says they verify the new file(s) after the repair to make sure the repair actually occurred.

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

No branches or pull requests

3 participants