IPB

Welcome Guest ( Log In | Register )

100 Pages V  « < 31 32 33 34 35 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
brycemc
post Feb 22 2010, 04:03
Post #801





Group: Members
Posts: 7
Joined: 27-January 10
Member No.: 77576



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
[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!

Go to the top of the page
+Quote Post
greynol
post Feb 22 2010, 05:24
Post #802





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Feb 22 2010, 05:25


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Porcus
post Feb 23 2010, 10:29
Post #803





Group: Members
Posts: 1789
Joined: 30-November 06
Member No.: 38207



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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 23 2010, 12:24
Post #804





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.

This post has been edited by Gregory S. Chudov: Feb 23 2010, 18:06


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
X0R
post Feb 24 2010, 01:29
Post #805





Group: Members
Posts: 15
Joined: 27-April 09
Member No.: 69323



QUOTE (Gregory S. Chudov @ Feb 23 2010, 12:24) *
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.

This post has been edited by X0R: Feb 24 2010, 01:29
Go to the top of the page
+Quote Post
Porcus
post Feb 24 2010, 21:12
Post #806





Group: Members
Posts: 1789
Joined: 30-November 06
Member No.: 38207



QUOTE (X0R @ Feb 24 2010, 01:29) *
Thanks a lot for the awesome work you have done, Cuetools is one awesome tool.

This is probably an inch away from bumping, but another bear hug for Gregory from me.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 28 2010, 23:10
Post #807





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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 smile.gif 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 smile.gif 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

This post has been edited by Gregory S. Chudov: Feb 28 2010, 23:24


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Akkurat
post Mar 1 2010, 00:21
Post #808


REACT Mod developer


Group: Developer
Posts: 929
Joined: 14-November 07
From: Finland
Member No.: 48750



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.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 1 2010, 00:23
Post #809





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



I didn't fix any of that yet, but i haven't forgotten about it.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
870421dy
post Mar 2 2010, 07:46
Post #810





Group: Members
Posts: 2
Joined: 2-March 10
Member No.: 78650



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!!
Go to the top of the page
+Quote Post
Bregalad
post Mar 2 2010, 21:08
Post #811





Group: Members
Posts: 18
Joined: 9-October 08
Member No.: 59840



great news, many interesting new features w00t.gif

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 ?
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 21:14
Post #812





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.

This post has been edited by Gregory S. Chudov: Mar 2 2010, 22:05


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 21:27
Post #813





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (870421dy @ Mar 2 2010, 09:46) *
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.4
Go to the top of the page
+Quote Post
punkrockdude
post Mar 2 2010, 21:53
Post #814





Group: Members
Posts: 243
Joined: 21-February 05
Member No.: 20022



Thank you so much for this application! It helped me split some single image flac files and create new .cue file. Amazing! Regards
Go to the top of the page
+Quote Post
SpaceAgeHero
post Mar 2 2010, 22:25
Post #815





Group: Members
Posts: 116
Joined: 23-August 08
From: Berlin
Member No.: 57417



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?
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 22:40
Post #816





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Thanks for submitting Radiohead, although i was very disappointed that Pink Floyd isn't the leader anymore smile.gif 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.

This post has been edited by Gregory S. Chudov: Mar 2 2010, 22:41


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
SpaceAgeHero
post Mar 2 2010, 22:53
Post #817





Group: Members
Posts: 116
Joined: 23-August 08
From: Berlin
Member No.: 57417



QUOTE (Gregory S. Chudov @ Mar 2 2010, 15:40) *
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.

QUOTE (Gregory S. Chudov @ Mar 2 2010, 15:40) *
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.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 23:02
Post #818





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.

This post has been edited by Gregory S. Chudov: Mar 2 2010, 23:08


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
SpaceAgeHero
post Mar 2 2010, 23:12
Post #819





Group: Members
Posts: 116
Joined: 23-August 08
From: Berlin
Member No.: 57417



QUOTE (Gregory S. Chudov @ Mar 2 2010, 16:02) *
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. smile.gif

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
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 23:14
Post #820





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Great!


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
870421dy
post Mar 3 2010, 06:38
Post #821





Group: Members
Posts: 2
Joined: 2-March 10
Member No.: 78650



QUOTE (Gregory S. Chudov @ Mar 2 2010, 22:27) *
QUOTE (870421dy @ Mar 2 2010, 09:46) *
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!
Go to the top of the page
+Quote Post
Porcus
post Mar 3 2010, 16:32
Post #822





Group: Members
Posts: 1789
Joined: 30-November 06
Member No.: 38207



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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 3 2010, 23:56
Post #823





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Thanks.

BTW, i just repaired my first real rip smile.gif

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.4
Go to the top of the page
+Quote Post
Fandango
post Mar 4 2010, 01:44
Post #824





Group: Members
Posts: 1546
Joined: 13-August 03
Member No.: 8353



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?
Go to the top of the page
+Quote Post
Porcus
post Mar 4 2010, 13:32
Post #825





Group: Members
Posts: 1789
Joined: 30-November 06
Member No.: 38207



QUOTE (Fandango @ Mar 4 2010, 01:44) *
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.

This post has been edited by Porcus: Mar 4 2010, 13:32


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post

100 Pages V  « < 31 32 33 34 35 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd April 2014 - 20:21