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: CUETools versions 1.9.5 through 2.1.6 (Read 1889446 times) previous topic - next topic
0 Members and 7 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #800
could someone help me understand exactly what the verification log means?  I've read this thread quite a bit but am still grasping at some understandings...

I understand my rip is accurate, but what is going on in the top three offset sets vs. the last one with CRC32s? 

The top three are comparing my ripped files against the accuraterip database, using some CRC method correct?  I understand the last set with the CRC32s is comparing something against what the EAC log says, and finding that it's a match, what does this tell me?

There is some difference between the accuraterip CRC/method (16bit crc maybe?) and this extraction CRC32 correct?

Code: [Select]
[Verification date: 2/21/2010 6:31:11 PM]
[Disc ID: 00112825-00585100-5c0e6606]
Track [ CRC    ] Status
 01 [fe725cc4] (06/28) Accurately ripped
 02 [edf0fbc5] (06/27) Accurately ripped
 03 [3047768c] (06/28) Accurately ripped
 04 [bf071050] (06/28) Accurately ripped
 05 [35c6773d] (06/27) Accurately ripped
 06 [fa729bd4] (06/28) Accurately ripped
Offsetted by -1:
 01 [056c411b] (19/28) Accurately ripped
 02 [9a6561a9] (18/27) Accurately ripped
 03 [e27a7b51] (19/28) Accurately ripped
 04 [7c319115] (19/28) Accurately ripped
 05 [e92ca0bb] (18/27) Accurately ripped
 06 [13ce74ed] (19/28) Accurately ripped
Offsetted by 1879:
 01 [48aad8bc] (03/28) Accurately ripped
 02 [8b82564a] (03/27) Accurately ripped
 03 [fc792bc7] (03/28) Accurately ripped
 04 [52c9ea84] (03/28) Accurately ripped
 05 [ec374054] (03/27) Partial match
 06 [d5221ec5] (03/28) Accurately ripped

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [3D39E78B] [AEA131F9]
 01 [77ECBEED] [5A1B52A0]   CRC32 
 02 [9F052884] [8DDB00AC]   CRC32 
 03 [51565210] [32CBA30D]   CRC32 
 04 [9D80235A] [0F30DA3B]   CRC32 
 05 [2DD451B6] [37B8BD91]   CRC32 
 06 [66365D54] [F71B52FE]   CRC32 

Thanks!


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #801
It tells you that the files don't deviate from what the log shows; no more, no less.  If they deviate it would either mean there was corruption of either the files, or the log wasn't generated from that set of files.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #802
Not a big issue, but I just fired up TripleFlac, and ... my, how much quicker it is at AccurateRip verification.
Which makes me curious whether CUETools
- has better features taking longer time?,
or
- has suboptimal algorithm?,
or
- is compiled inefficiently?




BTW: Thanx @ avanegmond

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #803
Verification became slower when i added CRC32 calculations.
Since then i found a way to do it faster, and 2.0.5 won't have this problem.

PS: And of course better features are to blame too. TripleFlac doesn't actually verify anything. It only finds an offset using offset CRC. The rip can still be inaccurate and you wouldn't know.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #804
Verification became slower when i added CRC32 calculations.
Since then i found a way to do it faster, and 2.0.5 won't have this problem.


Great news Gregory, I was wondering if Proxy Support can be added, so I can run cuetools from my machine !
Thanks a lot for the awesome work you have done, Cuetools is one awesome tool.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #806
My pleasure.

Ok guys, this is not yet an official release, but it's been a long time since there have been one, so i thought i'd post a preview of a CUETools 2.0.5.

Practically none of the requested features are there yet  But there are some new features nonetheless.

Main feature of the new version is a CUETools own CD database. I'm still not completely sure if it's a good idea, but there's only way to find out.

AccurateRip is great at verifying rips, but what if it tells you that rip is inaccurate? That's where CUETools DB steps in. Basically, it works in the way similar to PAR2: for every CD it stores a tiny recovery record, which allows it to fix a broken rip, if amount of errors is very small. The problem is that if database had as many CDs as AccurateRip, it would be terabytes in size and probably unmanageable. Time will tell, let's test it and see how it goes. For now the database was seeded with CD collections of me and some of my friends, it only has about 1500 CDs. You can see the list here: http://db.cuetools.net/

So in CUETools 2.0.5 there's two new scripts you can choose from the combobox under selected action. In convert mode you can choose 'repair', and it will try to repair a broken rip using the database. This will of course only work if the CD is already in database, so your chances are slim yet  In verify mode you can choose 'submit', it will verify rip and send it to CUETools DB. In normal verification mode there's also a checkbox to enable/disable CUETools DB verification. You might want to uncheck it if you don't want to use the database, to make verification faster.

Amongst other changes:
* I tried to add proxy support - for now just a checkbox to use system proxy settings from IE, which is on by default. Please tell me if it helps.
* Verification should be much faster now (at least when CUETools DB support is turned off).
* When verifying CRC32 against EAC log file, it's now possible to verify it even after offset correction.
* Codec support libraries are now plugins, which means CUETools can function without them. You can delete unwanted plugins to save space. But if you delete all the plugin directories, CUETools will support only WAV.
* 'New' encoders added: libFlake is a pure managed (.NET) flac encoder/decoder, which probably compresses faster/better than libFLAC. FlaCuda is a FLAC encoder which utilizes the power of your NVIDIA GPU to compress fast. libALAC encodes/decodes Apple Lossless (m4a) files without iTunes. I posted all of them previously as separate command-line applications.
* There are no x86 and x64 versions of CUETools now, most of CUETools is processor independent .NET code. Processor dependent plugins are placed in "plugins (win32)" and "plugins (x64)" directories.
* I moved from Visual Studio 2005 to Visual Studio 2008, sorry folks, you might need to install yet another MS redistributable (most likely it's already installed): x86 version, x64 version. If you don't see libFLAC in the list of flac encoders, that means you need this redistributable. Although you can just use libFlake instead, which doesn't require it.
* You might want to check out the updated CUERipper, if it works for your CD Drive. As always, it comes with CUETools, look for CUERipper.exe in the same directory. I'd like to argue that it can provide more accurate rips than EAC, but of course we need much more testing to prove it.

CUETools 2.0.5: http://www.cuetools.net/install/CUETools_2.0.5.rar
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #807
Nice to see that the development is still going on! Are you able to comment on the points in my old post I made 1½ months ago? Especially the profile/settings system problems; have you done anything to those? Or do you have a full changelog available? Thanks a million.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #808
I didn't fix any of that yet, but i haven't forgotten about it.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #809
Hi!
Firstly, thanks for this topic!
It's useful.
I have a little more suggestion or question for this. I used to use it to check the lossless rip to the AR database. I want to write the log file to both "Convert" folder and the input folder. Can that be work?
And I also want to change the input folder's name according to the result of the AR check process. For example, the original folder's name is "AAA - 1990 - BBB". If the result of the check is "rip accurate", then turn the file name to "AAA - 1990 - BBB (AR)". If the other result, then change the folder's name accordingly?
Thanks!!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #810
great news, many interesting new features 

just a little question :
I suppose CTDB ID means CUETools DataBase ID
But what is the meaning of the numbers ?
Is it a hash sum for the whole rip ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #811
Yes, you are correct. CTDB ID is actually a CRC32 of the whole image (except for few sectors at the beginning and at the end, for the purposes of offset detection).

I've started writing some documentation here.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #812
I want to write the log file to both "Convert" folder and the input folder.
And I also want to change the input folder's name according to the result of the AR check process.

I can probably add this as an example of cuetools scripting feature.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #813
Thank you so much for this application! It helped me split some single image flac files and create new .cue file. Amazing! Regards

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #814
Hello Gregory!

Very good. =) Hopefully this will help me to fix some slightly scratched discs in the future.

BTW I added the currently most popular disc to your database. ;D (Radiohead - OK Computer)

Anyways I was wondering one thing since you're building a new database:

In the past I ripped many discs to .flac per track without keeping cuesheets.
A few months ago I began to convert them to single .wv files per disc using CUETools.
Even though they are perfectly accurate, pregap information for every track is missing as CUETools hat to create dummy cuesheets.
Do you think it would be possible and make sense allowing users to upload pregap information for every track?
I know they are basically useless but still ... that way we would be able to determine accurate gaps and restore them to cuesheets?

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #815
Thanks for submitting Radiohead, although i was very disappointed that Pink Floyd isn't the leader anymore  We'll see for how long will it remain #1.

First track pregap is part of the TOC, so it's already part of the database. But it's also part of DiscID (i shamelessly used the same was AccurateRip, although i'm starting to doubt i was right about this). So it's currently impossible to verify rips with lost pregap information, but it can be fixed by switching to a different DiscID which would only take actual audio tracks into account. This would also solve the problem with Enhanced CDs. Database would then be able even to 'repair' most of the lost pregap, provided it's short enough, which it usually is.

Other index/pregap information is really useless, like you said. Even fb2k ignores it. It is also unfortunately not consistent. Different EAC gap detection modes produce different results, other software often just ignores all index information, so imho there's not much sense in trying to collect it.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #816
Other index/pregap information is really useless, like you said. Even fb2k ignores it. It is also unfortunately not consistent. Different EAC gap detection modes produce different results, other software often just ignores all index information, so imho there's not much sense in trying to collect it.


Alright you convinced me here. :-) I almost forgot about the non-consistent problem.

First track pregap is part of the TOC, so it's already part of the database. But it's also part of DiscID (i shamelessly used the same was AccurateRip, although i'm starting to doubt i was right about this). So it's currently impossible to verify rips with lost pregap information, but it can be fixed by switching to a different DiscID which would only take actual audio tracks into account.


So what you're considering is storing an additional DiscID calculated from the actual audio data without track 1 pregap?
Wouldn't that absolutely solve the issue on rips with lost pregap information?
Another way I was thinking of is a bruteforce algorythm for CUETools, as it appears to me that pregaps are usally values like 32.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #817
DiscId should still be based on track lengths, not audio data, else we won't be able to lookup and repair rips with errors, and after all this is CTDB's main purpose. But only the length of actual audio tracks should be taken into account, so we don't have to worry about pregap and/or CD-Extra data tracks. I really don't understand why FreeDB, MusicBrainz and AccurateRip use pregaps/data tracks in their ID calculations.

I also think i should not be adding, but replacing the discid. The database keeps all the TOCs, so it can be converted to a new discid without any loss of data.

In theory, it's even possible to create a tool which would restore cue sheets for single file images. You only have to know e.g. the artist's name to lookup all possible discids for that artist and this disc length - there shouldn't be many of those, and then find the one which matches and use associated TOC to recreate a cue sheet.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #818
DiscId should still be based on track lengths, not audio data, else we won't be able to lookup and repair rips with errors, and after all this is CTDB's main purpose.


Yes of course. Sorry, I wasn't absolutely aware of this.

Personally I agree with all you said and I'm really excited to see how this will evolve. Good luck!
I'll scan my music directory and try to add 500+ discs to your database over night, if you don't mind. ;D

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #819
Great!
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #820
I want to write the log file to both "Convert" folder and the input folder.
And I also want to change the input folder's name according to the result of the AR check process.

I can probably add this as an example of cuetools scripting feature.


Thanks so much!
I'm looking forward for that!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #821
Once I have a couple of days vacant computertime, you'll have some 6000 discs from here, possibly improving the Pink Floyd to Radiohead ratio.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #822
Thanks.

BTW, i just repaired my first real rip

EAC rip had errors, so i reripped it with CUERipper - and this rip passed AccurateRip check!

But what's even more cool, it submitted it to CUETools DB, and i was able to repair my old EAC rip with CUETools.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #823
Verify is so fast now! Good job.

...but I have a problem, and not just now with 2.0.5 but also with 2.0.4a. I can't get batch mode to work anymore. When I add another cue sheet to the drag'n'drop area, it replaces the first cue sheet that is already there. When I add multiple files at once they will all be there. But I can't do that since every album is in its own directory and Windows won't allow me to drag'n'drop multiple files that do not reside in the same directory. I tried pressing the default modifier CTRL for those purposes, but it doesn't work (anymore). So how can I use batch mode without using the multiselect browser?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #824
So how can I use batch mode without using the multiselect browser?

Mark the folders -- not the files therein, but the folders themselves -- and drag + drop.

Edit: Tested 2.0.4a, not 2.0.5.