Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Help! How Do You Automate Verifying A Large FLAC Music Library? (Read 5781 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #25 –
Quote from: birdie on
My statement earlier about the need of hashing entire files and having PAR2 recovery for them holds true.
Building on what @Chibisteven said, if you store the audio MD5 then you can make sure the audio is untouched even across edits. Obviously that doesn't replace the need to store the file hash to check for bit-rot e.t.c.

I've never considered PAR before, is there any advantage of using it versus a standard hash check (assuming backups are in place), it seems like just more files to store and backup.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #26 –
Par2 doesn't just detect errors, it corrects them. You can set a target par2 size as a percentage of 5% say, then roughly speaking you can recover from a good chunk of data errors with recovery files that take up 1/20 the space of the originals. I keep par2 files on the same hardware as the original file as well as a copy of the par2 files on a USB stick (as well as redundancy but only for files I particularly care about).

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #27 –
Seems like a lot of extra work, would a BTRFS volume not simply do the trick since all files are checksummed by default?

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #28 –
Problem about par2 and friends, is that you want to alter tags.
There is a way to handle "text" tags (i.e. not pictures), assuming you do not alter filenames: foobar2000 with Case's foo_external_tags component. Export the tags to .tag files, and keep those versioned or backed up. Then you can keep the media files themselves unchaged.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #29 –
Quote from: MrRom92 on
Seems like a lot of extra work, would a BTRFS volume not simply do the trick since all files are checksummed by default?

BTRFS guarantees that what you read is what you save on it but
1) It cannot correct storage read errors, so if a bit flips, a related data block will be read as empty (if I remember correctly)
2) It cannot guarantee that your data hasn't changed after it's read off the disk (it can be altered by CPU, RAM and IO interfaces)
As a consequence of the second point: btrfs doesn't care (it can't know) what you're storing: imagine you're copying data from another partition or device to your btrfs volume. Any transmission errors will go unnoticed.

If you care about your data, hashsums are a must. Some sort of recovery is desirable unless you have multiple copies of your data stored in different geographical locations.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #30 –
I've been using Audio Tester to verify the integrity of the FLAC files in the library.  It works great because I can scan the entire FLAC library in one huge batch and get a report of any errors.

I also have some WAV files in this library.  Is there a program similar to Audio Tester that can be used to verify WAV file integrity?  I've searched but have not yet found anything workable.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #31 –
For .wav you can try my software (oldsCool).
https://hydrogenaud.io/index.php/topic,114816.msg1026786.html#msg1026786

Keep in mind that the .wav format itself is not as robust as flac if you want to check against corruption. Length truncation can be detected, but not corrupted audio data. This means a song with exactly 3 minutes can be replaced with exactly 3 minutes of garbage and remains undetected.

Apart from audio length, oldsCool also checks other things which can potentially go wrong with .wav, check the bundled ReadMe file for more details.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #32 –
Quote from: Lodum007 on
I've been using Audio Tester to verify the integrity of the FLAC files in the library.  It works great because I can scan the entire FLAC library in one huge batch and get a report of any errors.
It feels like you haven't read any of the replies to your original posting.

Quote from: Lodum007 on
I want the library to be perfect so that all audio is okay and the track names always match the audio they go with.
The only way to get anywhere near this is by starting with CUETools - assuming most of collection are rips from CDs.

If your original goals have changed and you now just want to weed out the obvious corruptions then carry on with AudioTester.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #33 –
Thanks,

My goals for this haven't changed, but I haven't had success with an automated approach yet.  I tried CUETools with the first album (the album I posted a corrupt file from).  The CD is common and released several times since 1986.  CUETools scans it and gives a message that it is not in the database.  I don't see that the program is going to be my full solution for this reason.   (Possibly that one album not showing up in the database is only an anomaly, but it's the album that started this search for a solution.)

I tried CUETools on other albums and it does find them in its database and do the scan, which is great.  I will use that tool as I am sure it will help and find album errors I would otherwise miss.

Foobar and MusicBrainz recognize the corrupt album (probably from the metadata) but they will not give me the feedback needed to determine if a track is misnamed another one, or if a file is truncated.

I think my best bet right now (although painfully slow) is:

1) Scan all files to make sure the audio integrity is okay.  I'll try OldsCool for the WAV files and continue to use Audio Tester for the FLAC files.

2) Scan the albums with CUETools.

3) I'll visually inspect the length of my tracks against some known standard - like Apple Music or Discogs.  An obvious difference in length will then give me a red flag for trouble.

I may still be missing something.  I didn't know about CUETools until I received answers on this thread and there may be some additional method of handling step 3 in an automated fashion that I haven't understood. 

Again, thanks to everyone for the advice and support.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #34 –
Quote from: Lodum007 on
I tried CUETools with the first album (the album I posted a corrupt file from).  The CD is common and released several times since 1986.  CUETools scans it and gives a message that it is not in the database.  I don't see that the program is going to be my full solution for this reason.   (Possibly that one album not showing up in the database is only an anomaly, but it's the album that started this search for a solution.)
The fact that the disc couldn't be found was an indicator that something is wrong. In this case the track was truncated so the disc layout (track timings) didn't match. It did its job!

Quote from: Lodum007 on
Foobar and MusicBrainz recognize the corrupt album (probably from the metadata) but they will not give me the feedback needed to determine if a track is misnamed another one, or if a file is truncated.
I don't know which album you're talking about, but foobar can only tell you if a file is corrupt or not, and in the joan_of_arc example it isn't, its just that it has an ID3 tag at the end. I'd have to see the MusicBraniz output to know what it's telling you, but I don't think Picard is particularly useful in a batch scenario like this.

What you should be doing is running CUETools against your entire collection and for every album that doesn't verify investigate separately. This will identify trucations, corruptions, incorrect track ordering e.t.c.
Foobar verifier, AudioTester and the WAV tester will only tell you about corruptions, they only see the individual files and have no understanding of an album/disc.

This assumes that your collection is from CD rips which you still haven't confirmed.

Why don't you create a new folder, place a handful of albums in there (including one that is corrupt) and run a CUETools pass against the entire folder. If you're happy you understand the results, then proceed with your entire collection and report back.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #35 –
Alright.
About 95% of my library is from CD.  The other albums are digital downloads.
I tried one folder with CUETools and that went fine.  Now I've started running CUETools on the whole library (and that will probably run for several days).

Can you explain how CUETools checks one's file against its database?  Does it look at metadata for the album or artist name that it scans?  Or is it some other information contained in the file?  Understanding this would help me understand why the corrupt song I uploaded wasn't found in the database.   I am not familiar with the theory behind this.

I can see so far on my scan of the full library that CUETools did not locate several other albums, such as the "Slumdog Millionaire" soundtrack, which doesn't make sense to me.  That is a common album and was taken from a CD.  Same with A Tribe Called Quest "Anthology". 

As a note, I can see that a few albums I added extra metadata to in the album name field show up correctly in the CUETools database when scanned.  I find it interesting because my album name metadata did not correctly match a standard, but the software found the albums in the database and compared my files to them.  Seems good so far.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #36 –
Quote from: Lodum007 on
I tried one folder with CUETools and that went fine.  Now I've started running CUETools on the whole library (and that will probably run for several days).
I would hope not. The last time I scanned ~30,000 tracks it took 3-4 hours.

Quote from: Lodum007 on
Can you explain how CUETools checks one's file against its database?  Does it look at metadata for the album or artist name that it scans?  Or is it some other information contained in the file?  Understanding this would help me understand why the corrupt song I uploaded wasn't found in the database.   I am not familiar with the theory behind this.
CUETools does use some metadata from your tags in order to identify a disc, and the order of the tracks within that disc. I'm guessing here, but I assume it uses AlbumArtist, Album, DiscNumber and TrackNumber.

For each identified disc a unique key is produced so that it can match with other rips from the database. The key includes - amongst other things - the number of tracks on the disc, and the length of each track.
The Full TOC from MusicBrainz is an example of such a key.

The next stage is to hash the audio of each track and compare that to the matching rips in the database. A single incorrect bit will produce an inaccurate result.

Quote from: Lodum007 on
I can see so far on my scan of the full library that CUETools did not locate several other albums, such as the "Slumdog Millionaire" soundtrack, which doesn't make sense to me.  That is a common album and was taken from a CD.  Same with A Tribe Called Quest "Anthology".
In each folder will be a *.accurip file that gives you more detail. There could be any number of things wrong with it, including that it wasn't from a CD. Feel free to attach one for us to review.

Quote from: Lodum007 on
As a note, I can see that a few albums I added extra metadata to in the album name field show up correctly in the CUETools database when scanned.  I find it interesting because my album name metadata did not correctly match a standard, but the software found the albums in the database and compared my files to them.  Seems good so far.
As mentioned before, it only uses the metadata in order to be able to identify a disc, so you could have put anything into the album field (as long as it's the same for every track) and it would have correctly grouped them and then perfomed the matching on the key of that "disc".

Hope that makes some sense.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #38 –
I looked through the documentation on CUETools.
I want to make sure I'm doing this right.  Specifically, I want to make sure I understand the results of the tests.
(My understanding of technical matters is "basic geek", but not "deep geek", with all proper respect to geeks.
There may be technical points taken for granted as understood by the CUETools user which I don't know.)

I found the physical CD that had corruption earlier this week and re-ripped it into FLAC (and deleted the old corrupt version).
I then scanned the album using CUETools and the results are below.
Could you please interpret them for me?   Should I be concerned about the errors that show up?
If so, what would I do about them?
Why are there errors in CTDB but no errors in AccurateRip?
What is the significance of track peak when doing this test? 

I'm trying to get a feel of what I am looking for when interpreting these results so I deal with them correctly.
Thank you.

_____

Code: [Select]
[CUETools log; Date: 9/8/2023 3:06:40 PM; Version: 2.2.4]
[CTDB TOCID: DOgqiNs3rS.8lt8asau6gAcRtdI-] found.
Track | CTDB Status
  1   | (1285/1306) Accurately ripped
  2   | (1284/1306) Accurately ripped
  3   | (1285/1306) Accurately ripped
  4   | (1279/1306) Accurately ripped, or (2/1306) differs in 3 samples @03:50:22
  5   | (1289/1306) Accurately ripped
  6   | (1290/1306) Accurately ripped
  7   | (1285/1306) Accurately ripped
  8   | (1284/1306) Accurately ripped
  9   | (1280/1306) Accurately ripped, or (2/1306) differs in 8157 samples @03:37:37-03:37:48
[AccurateRip ID: 000ec885-006c383a-7509bc09] found.
Track   [  CRC   |   V2   ] Status
 01     [5e455c1e|95af0aec] (000+000/891) No match
 02     [a49e3e2c|d6d45532] (000+000/889) No match
 03     [402d8aac|b56b7eab] (000+000/893) No match
 04     [488026c5|ba30d47e] (000+000/887) No match
 05     [c6cf3964|efec44c4] (000+000/885) No match
 06     [49445bd9|889c677a] (000+000/889) No match
 07     [1b86347e|03a043f7] (000+000/882) No match
 08     [51570a91|3ea2c932] (000+000/882) No match
 09     [38edc633|591bc423] (000+000/883) No match
Offsetted by 667:
 01     [cc2152c3] (084/891) Accurately ripped
 02     [d6224535] (084/889) Accurately ripped
 03     [d972a5ef] (086/893) Accurately ripped
 04     [8dc44b7e] (085/887) Accurately ripped
 05     [3f8114ab] (084/885) Accurately ripped
 06     [e7e47505] (084/889) Accurately ripped
 07     [a1bfa5c4] (085/882) Accurately ripped
 08     [e71a55cc] (082/882) Accurately ripped
 09     [2e0c30c8] (084/883) Accurately ripped
Offsetted by 1141:
 01     [c6ead5c9] (049/891) Accurately ripped
 02     [e7e8bb21] (049/889) Accurately ripped
 03     [503cd390] (049/893) Accurately ripped
 04     [121a7b19] (049/887) Accurately ripped
 05     [102251c8] (049/885) Accurately ripped
 06     [e939cdeb] (049/889) Accurately ripped
 07     [6c6d718b] (048/882) Accurately ripped
 08     [33ed6b64] (049/882) Accurately ripped
 09     [2ec40f01] (047/883) Accurately ripped
Offsetted by 1334:
 01     [1779ed7a] (031/891) Accurately ripped
 02     [9fe319e5] (032/889) Accurately ripped
 03     [1767b0e2] (031/893) Accurately ripped
 04     [4990c60a] (031/887) Accurately ripped
 05     [bb197074] (031/885) Accurately ripped
 06     [3748a318] (031/889) Accurately ripped
 07     [21b61ea9] (031/882) Accurately ripped
 08     [b23091fb] (031/882) Accurately ripped
 09     [b6f052c3] (030/883) Accurately ripped
Offsetted by 1502:
 01     [28538dba] (082/891) Accurately ripped
 02     [fdf58129] (083/889) Accurately ripped
 03     [4289c855] (082/893) Accurately ripped
 04     [8955cb17] (081/887) Accurately ripped
 05     [21fb5cdd] (081/885) Accurately ripped
 06     [0de7cf11] (082/889) Accurately ripped
 07     [bb715a5e] (080/882) Accurately ripped
 08     [bd7af470] (081/882) Accurately ripped
 09     [89ed15e0] (079/883) Accurately ripped
Offsetted by 2001:
 01     [c273b9ee] (113/891) Accurately ripped
 02     [db341a4c] (112/889) Accurately ripped
 03     [8f052f1a] (112/893) Accurately ripped
 04     [a20f18ed] (111/887) Accurately ripped
 05     [12f9539f] (111/885) Accurately ripped
 06     [971d8866] (112/889) Accurately ripped
 07     [dcf73fcf] (109/882) Accurately ripped
 08     [7466b1d2] (111/882) Accurately ripped
 09     [d4b460bb] (112/883) Accurately ripped
Offsetted by 1436:
 01     [15b13591] (000/891) No match (V2 was not tested)
 02     [9dbcc837] (000/889) No match (V2 was not tested)
 03     [c221499f] (000/893) No match (V2 was not tested)
 04     [bef1e814] (000/887) No match (V2 was not tested)
 05     [029824be] (000/885) No match (V2 was not tested)
 06     [2e38727f] (000/889) No match (V2 was not tested)
 07     [4baaf8d8] (000/882) No match (V2 was not tested)
 08     [28f94f2f] (000/882) No match (V2 was not tested)
 09     [2dc78980] (000/883) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] 
 --   67.1 [759AC356] [1CC89E4E]           
 01   59.5 [10FDD893] [CEA1E7F4]           
 02   65.3 [843F58FB] [714E7D81]           
 03   35.3 [5B0078B4] [4B1A0519]           
 04   67.1 [FCE28D7C] [5D1C918F]           
 05   44.9 [AA7346BE] [F00B1AA4]           
 06   34.5 [F2317E6F] [D3CDE8C6]           
 07   32.8 [20DF2890] [ABFBD933]           
 08   32.2 [78F0BDEE] [B5E69D6F]           
 09   41.2 [2E24D7E2] [63A07730]          




MOD edit: moved log to code box

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #39 –
Quote
Why are there errors in CTDB but no errors in AccurateRip?
I see all 9 tracks 'Accurately ripped' with a minimum confidence of  (1279/1306)
korth

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #40 –
Here's another one, Jazz At The Pawnshop

Code: [Select]
[CUETools log; Date: 9/8/2023 3:30:00 PM; Version: 2.2.4]
[CTDB TOCID: NdAQSzWbfFSO.9VA7W_D0kfWC.E-] found.
Track | CTDB Status
  1   | (32/35) Accurately ripped, or (1/35) differs in 8 samples @06:00:46
  2   | (33/35) Accurately ripped
  3   | (34/35) Accurately ripped
  4   | (25/35) Differs in 18 samples @06:04:18, or (1/35) differs in 18 samples @06:04:18, or (1/35) differs in 18 samples @06:04:18
  5   | (25/35) Differs in 61 samples @03:54:40, or (1/35) differs in 64 samples @03:54:40,05:10:62, or (1/35) differs in 61 samples @03:54:40
  6   | (25/35) Differs in 59 samples @03:28:27, or (1/35) differs in 90 samples @01:31:15,02:43:34,03:28:27,03:44:19,03:51:51,04:01:49,04:59:09,05:35:60,06:13:32, or (1/35) differs in 59 samples @03:28:27
  7   | (25/35) Differs in 34 samples @00:33:03, or (1/35) differs in 82 samples @00:29:00,00:33:03,01:01:21,02:46:30,03:07:38-03:07:39,03:34:31-03:34:33,03:55:31,04:44:24,04:53:61-04:53:62,04:56:56, or (1/35) differs in 34 samples @00:33:03
  8   | (25/35) Differs in 13 samples, or (1/35) differs in 408 samples, or (1/35) differs in 50 samples
  9   | (26/35) Accurately ripped, or (1/35) differs in 355 samples, or (1/35) differs in 78 samples
[AccurateRip ID: 0018eb0e-00b3eecd-7c104809] found.
Track   [  CRC   |   V2   ] Status
 01     [2241f32a|5853a614] (0+0/1) No match
 02     [cd3bbe9d|92ff42b4] (0+0/1) No match
 03     [55026de8|fb2b3420] (0+0/1) No match
 04     [ae0819e3|b1d5d300] (0+0/1) No match
 05     [305ba6af|e4305d6f] (0+0/1) No match
 06     [ac11c05d|c46e8a8c] (0+0/1) No match
 07     [0e4320b6|570d0698] (0+0/1) No match
 08     [e5de5632|e16abcfd] (0+0/1) No match
 09     [640cffb7|5f3b241c] (0+0/1) No match
Offsetted by -1364:
 01     [fdf645dc] (1/1) Accurately ripped
 02     [f49e3c79] (1/1) Accurately ripped
 03     [6170b22b] (1/1) Accurately ripped
 04     [6cad41ab] (0/1) No match (V2 was not tested)
 05     [9195ecd2] (0/1) No match (V2 was not tested)
 06     [c3c20415] (0/1) No match (V2 was not tested)
 07     [deae19ed] (0/1) No match (V2 was not tested)
 08     [dd679a8c] (0/1) No match (V2 was not tested)
 09     [a7dedfa6] (1/1) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [8EA836AC] [4F3ED34B]           
 01   78.8 [ABA6B597] [5788EA0A]           
 02   74.0 [7FD094D9] [87D9DCE4]           
 03   89.8 [449C1759] [52BA85B7]           
 04   69.1 [170276F5] [4E835184]           
 05   69.1 [9C00A145] [627E6F8B]           
 06  100.0 [AC243CA1] [64DEEAEF]           
 07   69.0 [2A5BACC7] [0C662C84]           
 08   89.0 [46632C21] [705128C2]           
 09   59.9 [C803AC05] [2492F91F]          

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #41 –
Quote from: korth on
Quote
Why are there errors in CTDB but no errors in AccurateRip?
I see all 9 tracks 'Accurately ripped' with a minimum confidence of  (1279/1306)

I see. I don't think I understand the software.  What does 1279/1306 signify?

What is the significance of this result?
4   | (1279/1306) Accurately ripped, or (2/1306) differs in 3 samples @03:50:22

Thanks!

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #42 –
Quote
I see. I don't think I understand the software.  What does 1279/1306 signify?
1279 rips match out of 1306

Quote
Here's another one, Jazz At The Pawnshop
Tracks 4-8 are not accurate but RIP is repairable.



Edit: looks like SimBun is taking it from here. I'm tagged out.
korth

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #43 –
Code: [Select]
  4   | (1279/1306) Accurately ripped, or (2/1306) differs in 3 samples @03:50:22
This means that your rip of track 4 matched 1279 other users (from 1306 rips total) AND it differed by 3 samples from another 2 rips.

Code: [Select]
[AccurateRip ID: 000ec885-006c383a-7509bc09] found.
Track   [  CRC   |   V2   ] Status
 01     [5e455c1e|95af0aec] (000+000/891) No match
 02     [a49e3e2c|d6d45532] (000+000/889) No match
 03     [402d8aac|b56b7eab] (000+000/893) No match
 04     [488026c5|ba30d47e] (000+000/887) No match
 05     [c6cf3964|efec44c4] (000+000/885) No match
 06     [49445bd9|889c677a] (000+000/889) No match
 07     [1b86347e|03a043f7] (000+000/882) No match
 08     [51570a91|3ea2c932] (000+000/882) No match
 09     [38edc633|591bc423] (000+000/883) No match
This probably means that you haven't setup your ripping drive correctly. What software are you using? EAC for instance has sample offset correction that needs to be configured. Here's an old guide for EAC that might be of some use.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #44 –
Thank you both.

I typically use EAC but didn't with this specific CD.  I'll use it in the future to make sure future rips don't have this problem.

Why does CTDB show errors on tracks 4 and 9 but AccurateRip doesn't?   Why would that be and should I care?

On the Jazz At The Pawnshop, how would one repair tracks 4-8?

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #45 –
CUETools has a board on the forum:
https://hydrogenaud.io/index.php/board,74.0.html
It doesn't help anyone else asking program-specific questions on a different board.

Quote
Why does CTDB show errors on tracks 4 and 9 but AccurateRip doesn't?
Those aren't errors. It is showing you that another 'recovery record' exists from 2 rips that had slightly different audio than your rip did. Your rip was Accurately Ripped so those 2 rips are not significant.

A recovery record is a 180KB file (about twice that size for more popular CDs), which is stored separately in the database and accessed only when verifying a rip that differs or when repairing a rip.
korth

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #46 –
Quote from: Lodum007 on
On the Jazz At The Pawnshop, how would one repair tracks 4-8?
In the CUETools Action section, instead of using 'Verify' you'd choose 'Encode' (to create a new copy) and then select 'repair' in the dropdown.

Once you've hit Go you'll be prompted for which set of repairs to make (if there are multiple possibilities), just select the ones that result in the most matches (25/35).

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #47 –
Quote from: korth on
Quote
Why does CTDB show errors on tracks 4 and 9 but AccurateRip doesn't?
Those aren't errors. It is showing you that another 'recovery record' exists from 2 rips that had slightly different audio than your rip did. Your rip was Accurately Ripped so those 2 rips are not significant.

Now if the reverse were true and your rip matched the two
Code: [Select]
[CTDB TOCID: DOgqiNs3rS.8lt8asau6gAcRtdI-] found.
Track | CTDB Status
  1   | (1285/1306) Accurately ripped
  2   | (1284/1306) Accurately ripped
  3   | (1285/1306) Accurately ripped
  4   | (2/1306) Accurately ripped, or (1279/1306) differs in 3 samples @03:50:22
  5   | (1289/1306) Accurately ripped
  6   | (1290/1306) Accurately ripped
  7   | (1285/1306) Accurately ripped
  8   | (1284/1306) Accurately ripped
  9   | (2/1306) Accurately ripped, or (1280/1306) differs in 8157 samples @03:37:37-03:37:48
One might lean toward repairing the rip to match the higher confidence.

Note: Having a confidence of 2 doesn't mean the rip is less accurate. 2 vs 2000 is popularity not accuracy.
korth

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #48 –
Note that - if you are a bit careless - a confidence of 2-out-of-many might both be your own.

Re: Help! How Do You Automate Verifying A Large FLAC Music Library?

Reply #49 –
Thank you all for the helpful input.
I've been working with CUETools to scan the library as recommended.

I have various questions about the type of error messages coming up and what to do about them.
All the questions specifically relate to CUETools, so I've posted the next set of questions in a new CUETools thread.

https://hydrogenaud.io/index.php/topic,124732.0.html