How to fix an old mistake (lots of old inaccurate rips)

[timwi]

I've got several hundred (~500-600) CDs ripped as FLAC. I ripped them with another tool (mediamonkey) and when I was doing it, I didn't really understand all of the reasons I could get bad rips, so other than retrying the rips a few times, I mostly just powered through. This leaves me with a lot of ripped albums that have scattered bad rips throughout. Other than re-ripping everything, is there any way or tool to re-verify existing tracks against the accurate rip DB? I'm better equipped now to attempt to get good rips of those tracks, but I have no way of finding them.

[simbun]

Re: How to fix an old mistake (lots of old inaccurate rips)

CUETools is the best tool for the job and in some instances can actually fix bad rips for you (depending on the nature of the problem).
Search 'captain rookie cuetools archive' for a guide. The guide takes you through verifying one rip, but just select the root folder and it'll scan everything under that folder and present you with a log window of the results.

CUETools is however only available on Windows (or through Wine on Linux); if you're on a mac the only thing I'm aware of is PerfectTunes.

[Spoon]

Re: How to fix an old mistake (lots of old inaccurate rips)

Use https://www.dbpoweramp.com/perfecttunes.htm and the AccurateRip component.

[timwi]

Re: How to fix an old mistake (lots of old inaccurate rips)

Lovely, this helps, at least some. I'm using PerfectTunes to start. Is there a way to browse the AccurateRip DB to try to see why so many of my albums are not found there? It's easily 2/3rds reporting as not found. I know I have some obscure stuff, but I don't know if that's excessive or not, or if I'm running into problems with idiosyncrasies in my tagging.

[timwi]

Re: How to fix an old mistake (lots of old inaccurate rips)

Amusingly, one of the albums it lists as not in the DB is Enya-Shepherd Moons, which is explicitly shown as an example album in the webpage for PerfectTunes.

Is the unregistered version limited in the number of thing it'll scan? No such limitation is mentioned.

[timwi]

Re: How to fix an old mistake (lots of old inaccurate rips)

And also interestingly, the album art tool recognizes all of the albums I've tried and suggests appropriate art. Any insight into how the tool matches up my albums to data in the AccurateRip DB? If it matters, my file layout is one directory per album and I've reversed artists names to "Last, First" where I can. Filenames end up like: "Music\E\Enya\Shepherd Moons\01-Shepherd Moons.flac", "Music\E\Enya\Shepherd Moons\02-Caribbean Blue.flac", or "Music\E\Emerson, Ken\Slack and Steel\01-Moana Chimes.flac".

In media monkey terms; "Music\<AlbumArtist:1>\<AlbumArtist>\<Album>\<Trac kNum:2>-<Title>"

[simbun]

Re: How to fix an old mistake (lots of old inaccurate rips)

I'm not certain about PerfectTunes as I use CUETools, but I believe it will be matching to AccurateRip on the table of contents of the CD (including the pregap), and then to check if it's correctly ripped it'll calculate the checksum of the audio data - in VERY simple terms :-) Given you've already ripped them it'll be using the lengths of the individual tracks, so if MediaMonkey wasn't ripping with gaps appended it likely won't match.
If you have more than one disc per folder it'll likely be using the DISCNUMBER tag to diffenciate between discs otherwise it'll be trying to match to a single CD that contains all the tracks of all the discs.

I'm guessing the album art tool will be using the tags (you could test that by changing the album tag).

The only limitations of the free version of PerfectTunes appears to be:
Album Art: displays possible matches, but will not save art
ID Tags: does not write ID Tags, but does allow browsing and shows recommendations
De-Dup: shows duplicates but does not enable deletion

[timwi]

Re: How to fix an old mistake (lots of old inaccurate rips)

Yeah, I was beginning to suspect something like that. Oddly, it's not consistent to a given time stretch, nor a given hardware set. That is, recognized and unrecognized ripped albums are intermingled from the same ripping hardware at roughly the same time. I was guessing it's something to do with the way media monkey encodes (it's aimed at ease of use, not fidelity).

Sigh. I suspect I'm going to have to re-rip with something a bit more concerned about such things. Recently, I've been using Exact Audio Copy, largely because it was literally the next FLAC encoder I found after Media Monkey.

That said, is there a way for me to browse TOC data from AccurateRip for various pressings of a given Album? I'd like to look for a pattern of error so I can understand what has gone wrong to make absolutely sure I don't repeat the error.

[timwi]

Re: How to fix an old mistake (lots of old inaccurate rips)

Yup, that missing gap would seem to be the answer. Looking at MusicBrainz and Enya-Shepherd Moons, for example, my rips don't quite match any of the TOCs there. The closest is a TOC that I'm short by 1 second on 3 or 4 tracks. I presume I'm short by less than 1 second on most/all of the tracks, but it only shows up at the granularity of 1 second when the difference crosses an integral second count.

So, any ideas on how to save the work I've already done? I'm a bit fuzzy on just what that < 1s of data is, or if it would affect the CRCs for the tracks. Normally, it would seem obvious that it would, but CUETOols, for instance, in verify mode shows [ CRC32 ] and [W/O NULL], so I wonder if there would be a way to pad the FLAC files to get the TOC to line up. Sounds tedious and painful, even if possible, but reripping several hundred albums sounds even more tedious and painful.

[simbun]

Re: How to fix an old mistake (lots of old inaccurate rips)

Yeah, I was beginning to suspect something like that. Oddly, it's not consistent to a given time stretch, nor a given hardware set. That is, recognized and unrecognized ripped albums are intermingled from the same ripping hardware at roughly the same time. I was guessing it's something to do with the way media monkey encodes (it's aimed at ease of use, not fidelity).

I've never used MediaMonkey to rip, and I've never actually heard of anyone using it, but that's not to say it's not any good, but if it doesn't check against the AccurateRip or CUETools database then you can have no confidence in the rip.

Sigh. I suspect I'm going to have to re-rip with something a bit more concerned about such things. Recently, I've been using Exact Audio Copy, largely because it was literally the next FLAC encoder I found after Media Monkey.

That said, is there a way for me to browse TOC data from AccurateRip for various pressings of a given Album? I'd like to look for a pattern of error so I can understand what has gone wrong to make absolutely sure I don't repeat the error.

Both EAC and dBpoweramp are great. The advantage of dbPoweramp is that it'll be able to handle most of your tag requirements too, and so should make your workflow a bit simpler.

I don't think you can search the AccurateRip or CUETools database manually, but what I've used in the past is MusicBrainz. If you find your CD release on the website and go to the track listing page, towards the top theres a Disc IDs tab which will list all the CD pressings associated with the release, clicking on them will show their table of contents.

For one of the CDs that PerfectTunes doesn't verify, try and run it through CUETools as it'll give you a log with more detailed information. In CUETools, if you go to Settings and set [Advanced > Misc: 'Create TOC files'] to True, it'll output a toc (table of contents) file when you perform a verify (useful for comparing to MusicBrainz). Whilst you're there, you should also change 'CTDB: Detailed log' to True, as this will output pre-gap information in the log too.
As I've said before, depending on the type of error CUETools might be able to fix a rip, so keep an eye on the CTDB matches at the top of the log for possible corrections.

[simbun]

Re: How to fix an old mistake (lots of old inaccurate rips)

I was writing that post as you sent another, and it looks like you already know about MusicBrainz :-)

I'm not aware of being able to pad the files after the event. I assume if it's wholly because of the missing gap then I guess it would be possible, but I've never considered it.

I might try a quick rip with MediaMonkey and see what it outputs.

[GBrown]

Re: How to fix an old mistake (lots of old inaccurate rips)

I don't know how to fix this after the fact. But it sounds like the pre-gap spacing between tracks has been trimmed. Whatever software was used for the initial rips, maybe there is a setting there to do this? Unfortunately I think the only way to correct for that is to truly rip those discs again. :(

[simbun]

Re: How to fix an old mistake (lots of old inaccurate rips)

I performed a 'Jitter-corrected read' but couldn't verify the rip with MediaMonkey as that's a paid for feature. I also didn't apply 'Level Track Volume' as I assumed that would modify the actual audio data rather than add replaygain tags.

MediaMonkey discarded the pre-gap information so AccurateRip couldn't verify it, but CUETools with the log level set to Detailed verified it and highlighted the missing pre-gap

[CUETools log; Date: 04/04/2022 20:28:52; Version: 2.2.0]
[CTDB TOCID: dUVjU4rL2kTGgWa3Kg1q9mgai58-] found.
        [ CTDBID ] Status
        [28ca9763] (80/91) Has pregap length 00:00:33, Accurately ripped
        [38505e73] (01/91) Differs in 218 samples @32:16:70,32:17:73,32:25:47,32:26:03,37:28:46,37:28:62,37:30:10,37:31:01,37:32:07,42:31:56-42:31:57,42:32:50-42:32:51,58:16:67,58:17:31,58:17:50,58:17:69-58:17:70
        [e425ab20] (01/91) Has pregap length 00:00:33, No match
        [6eaf2ae0] (01/91) Has pregap length 00:00:33, No match
        ....

If you set a pre-gap of 00:00:33 in CUETools, or create a CUE with the pre-gap in it the log would look like:

[CUETools log; Date: 04/04/2022 20:33:59; Version: 2.2.0]
Pregap length 00:00:33.
[CTDB TOCID: dUVjU4rL2kTGgWa3Kg1q9mgai58-] found.
        [ CTDBID ] Status
        [28ca9763] (80/91) Accurately ripped
        [38505e73] (01/91) Has pregap length 00:00:00, Differs in 218 samples @32:17:28,32:18:31,32:26:05,32:26:36,37:29:04,37:29:20,37:30:43,37:31:34,37:32:40,42:32:14-42:32:15,42:33:08-42:33:09,58:17:25,58:17:64,58:18:08,58:18:27-58:18:28
        [e425ab20] (01/91) No match
        [6eaf2ae0] (01/91) No match
        ....

I also couldn't see anywhere to add (or have it detect) my drive offset, so when I added the pre-gap information to CUETools the rip did verify against AccurateRip but with an offset of 6.

So MediaMonkey can produce mostly accurate rips in 'Jitter-corrected read' mode (so will be able to in 'Secure' mode too), but without a paid version it doesn't do any checking.

Obviously this is all based on today's version, but it doesn't explain why you're getting some rips that do verify and some that don't unfortunately (assuming you're checking now in CUETools). It could obviously be the drive, but that doesn't help you now.