Skip to main content
Topic: One track cannot be verified, differs in 46 samples @04:07:54 (Read 705 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

One track cannot be verified, differs in 46 samples @04:07:54

Hello,

I've got this log https://pastebin.com/XbNh4knE and I'm not quite sure how to interpret it.
It says that the track can't be verified and also differs in 46 samples @04:07:54 but supposed track quality is still 99.9 %,
so I am wondering if it's accurate or would I need to repair it and how would I do that?

Cheers!

Re: One track cannot be verified, differs in 46 samples @04:07:54

Reply #1
Code: [Select]
Track 14
 
     Filename C:\EAC Rips\Jang Hye Jin (장혜진) - Golden Best - 1997 (CD - FLAC - Lossless)\14 - 열정.wav
 
     Peak level 100.0 %
     Extraction speed 3.1 X
     Track quality 99.9 %
     Test CRC 97134DB6
     Copy CRC C756CB48
     Cannot be verified as accurate (confidence 2)  [EF3B68BD], AccurateRip returned [EECA57F0]  (AR v2)
     Copy OK

---

[CTDB TOCID: eVTcldSGf4ytZ8fEdVCT6iCFXoQ-] found
Submit result: insufficient quality
Track | CTDB Status
[...]
 14   | (4/4) Differs in 46 samples @04:07:54
[...]
If you are sure that your rip contains errors, you can use CUETools to repair it.
Track 14
Track quality is less than 100%. That means there were re-reads.  As re-reads increase the Track quality is lowered.
No errors so the re-reads did yield consistent data.
... but Test & Copy CRC's don't match.
AccurateRip: No match (confidence 2). There are at least 2 rips that matched each other in the database for Track 14 but didn't match yours. All other tracks from your rip did match the database (confidence 2).
CTDB: No match (Differs in 46 samples (confidence 4/4)). 4 of 4 rips match each other in the database for Track 14 but didn't match yours. All other tracks from your rip did match the database (confidence 4/4).

The CD could be dirty or damaged. It is possible that the CD has a flaw that allows the data in that area to be read with more than one consistent result. It is also possible that you have a different pressing not yet in the database(s). I would try repairing the rip.

I suggest the EAC log file be in the same folder as the audio files. This isn't required for this rip but may be helpful when processing other rips.
The instructions below are for this rip and may need adjustment for other situations.
If you use CUETools often it may be beneficial to create a 'repair' profile to save any alternate settings.

Action: Encode
change the script from 'default' to 'repair'
Mode: Tracks (to match your rip type)
remove check from 'Edit Tags' to keep original tags without a popup window.
Audio Output: Lossless, Audio file format: flac, Encoder: libFLAC, Slider: 8 (to closely match your rip).
CUE Paths (suggestions)
Input: Folder Browser
Output: Use template
Template: [%directoryname%\]new[%unique%]\%filename%.cue
 or
[%directoryname%\]repaired[%unique%]\%filename%.cue
You may also want to check the box: Audio Filenames - Keep original filenames or change the Track format: to %tracknumber% - %title% to match your rip.

Find the rip in the folder browser (left window) expanding folders as needed. Expand the rip folder and select the CUE (if exists) or the grouped flac files (same icon as 'Audio file format'). Press Go.
CUETools will verify the rip then retrieve the recovery record. Respond to any pop-ups. CUETools will encode a new copy of the rip using the recovery record in a sub-folder named 'new' (or 'repaired').

The result shown in the log window is a projected result. The new copy doesn't get verified. You can verify if you wish. Collapse the rip folder in the folder browser then expand it again. There should be a folder named 'new' (or 'repaired'). Expand that folder and select the CUE. Change to Action: Verify. Press Go.
korth

Re: One track cannot be verified, differs in 46 samples @04:07:54

Reply #2
First of all, thank you for the very comprehensive and helpful reply!
I've now used CUETools to repair the rip and got this new log: https://pastebin.com/eW5Et9KQ
So I assume that the rip has now been successfully repaired, since it matches with the two pre-existing results.
Thanks again.

 
SimplePortal 1.0.0 RC1 © 2008-2019