CUETools versions 1.9.5 through 2.1.4 (current), AccurateRip support & more Options

[Gregory S. Chudo...]

Please welcome, CUETools v2.1.4. (CUETools download page) or direct link: http://www.cuetools.net/install/CUETools_2.1.4.rar

16.04.2012: CUETools 2.1.4:
* CTDB 2.0: now ignoring pregap in parity calculations
* CTDB 2.0: popular CDs can have twice larger correction files
* CTDB 2.0: confidence values no longer include AccurateRip data
* CTDB 2.0: simplified (per-track) verification log
* CTDB 2.0: faster verification process with less network traffic
* CUERipper: support for some older drives, like PLEXTOR W1210A
* CUERipper: support for cover art
* CUERipper: main window resizable
* CUERipper: real test&copy mode
* CUERipper: options dialog
* Tagging: support for release date, release country, disc subtitle, label, catalog number, comment
* Local DB: can now refresh folder, removing missing files from database and adding new files.
* Codecs: LAME encoder updated to use libmp3lame.dll, which is now included in CUETools download (version 3.98.4)
* Various bug fixes

14.06.2011: CUETools 2.1.2:
* AccurateRip v2 support (without cross-pressing verification)
* EAC CTDB plugin
* CTDB now supports musicbrainz Next Generation Schema (NGS) metadata. Old musicbrainz library removed. New musicbrainz NGS metadata can now be used in filename templates, including %discname%, %label%, %releasedate%, %country%, %releasedateandlabel%, %discnumberandname%
* CTDB submissions are now based on the same data that was used when verifying, so 'submit' script was removed, and data is submitted after verification, after showing confirmation dialog
* CTDB verification is now much faster
* Local DB: option to purge records
* Local DB: now shown in the same window as folder browser
* metadata editing window size is now saved in settings
* CUERipper now sends CD barcode and rip quality when submitting
* support for wierd CDs with two data tracks before audio

IMPORTANT: .NET Framework 2.0 (SP2) required. If you get a "could not load file or assembly" error message for CUETools.Codecs.TTA/APE/WavPack/FLAC, make sure the recent version of Visual C++ 2008 runtime files (x86,x64) is installed.

You can always download the latest source code from project's SVN repository at SourceForge.
Instructions for svn access can be found here.

This post has been edited by Gregory S. Chudov: Apr 17 2012, 03:55

[Fandango]

WAV output is greyed out<edit>
Ah I didn't see the "embed cue sheet" was selected! But still, if the configuration file of the 1.9.1 version had WAV output, 1.9.2 will still output a WAV file... the greyed out radio button is selected 1.9.2 needs at least an error box before conversion begins or automatically change to FLAC or (best solution IMHO) default to "Single File + CUE" if is was "Single File" in 1.9.1.
</edit>when I want to add a cue sheet via drag & drop into the "Input:" box, the cue sheet is not added.

But apart from that... embed cue sheet, add AR CRC tags, and so on... great job!

The status report is a nice feature, too. Make it so that the log can be written to the output dir (using the name scheme) for each conversion, would be useful for batch conversion.
<edit>...I'm going blind I guess.</edit>

This post has been edited by Fandango: Oct 3 2008, 17:35

[foorious]

Hi, Gregory sent me to this thread from this one : http://www.hydrogenaudio.org/forums/index....showtopic=56531

What I don't understand is that my need is to be able to analyze a whole album made of single-track files in lossless form (FLAC, etc.) put inside the same album folder. I may be blind too Fandango , but I don't see CUETools doing that yet. Am I wrong ?

This functionality is mandatory for me since I have thousands of single-FLAC files and not a single cuesheet.

This post has been edited by foorious: Oct 3 2008, 18:21

[Gregory S. Chudo...]

WAV output is greyed out<edit>
Ah I didn't see the "embed cue sheet" was selected! But still, if the configuration file of the 1.9.1 version had WAV output, 1.9.2 will still output a WAV file... the greyed out radio button is selected 1.9.2 needs at least an error box before conversion begins or automatically change to FLAC or (best solution IMHO) default to "Single File + CUE" if is was "Single File" in 1.9.1.
</edit>when I want to add a cue sheet via drag & drop into the "Input:" box, the cue sheet is not added.

But apart from that... embed cue sheet, add AR CRC tags, and so on... great job!

The status report is a nice feature, too. Make it so that the log can be written to the output dir (using the name scheme) for each conversion, would be useful for batch conversion.
<edit>...I'm going blind I guess.</edit>

Wierd, drag&drop works for me.

Hi, Gregory sent me to this thread from this one : http://www.hydrogenaudio.org/forums/index....showtopic=56531

What I don't understand is that my need is to be able to analyze a whole album made of single-track files in lossless form (FLAC, etc.) put inside the same album folder. I may be blind too Fandango , but I don't see CUETools doing that yet. Am I wrong ?

This functionality is mandatory for me since I have thousands of single-FLAC files and not a single cuesheet.

No, it's me who is blind, i didn't notice you didn't have cuesheets.
I'll think about automating the process, but for now i would recomend to write a script whch would create cuesheets for each directory. This would be very easy if your files have gaps appended. If they have gaps prepended or left out, there's nothing really that can be done - you have to know the size of gaps to be able to compare the disc to the database. Also if the first track had index 00, you're out of luck.

Here is a a template for your cuesheet:

CODE

PERFORMER "Performer"
TITLE "Title"
FILE "first_filename.flac" WAVE
  TRACK 01 AUDIO
    TITLE "title 01"
    INDEX 01 00:00:00
FILE "second_filename.flac" WAVE
  TRACK 02 AUDIO
    TITLE "title 02"
    INDEX 01 00:00:00
...

In fact, you don't even have to specify correct file names - you can use an option "Preprocess with filename corrector if unable to locate audio files".
You just have to have the correct number of tracks.
So you can create those dummy cuesheets by hand, and then just copy into each folder a .cue sheet which has the same number of tracks as this folder.

This post has been edited by Gregory S. Chudov: Oct 4 2008, 03:33

[Fandango]

Wierd, drag&drop works for me.

Oops, the path was longer than 255 characters, that's why nothing happened. My bad, that happens sometimes when I move folders. And when I used the "Browse" button I selected a different cue sheet, I guess.

[Gregory S. Chudo...]

I encountered some very strange logs:

CODE

[Disc ID: 00142b00-008fceac-900c3809]
Track    [ CRC    ] Status
01    [358a4c62] (30/77) Accurately ripped.
02    [247ccff4] (29/74) Accurately ripped.
03    [abe1dc48] (30/77) Accurately ripped.
04    [86712e7d] (30/77) Accurately ripped.
05    [8d5f2a58] (29/74) Accurately ripped.
06    [2ded3768] (23) Ripped with offset -2177
06    [96b9ba8c] (2) Ripped with offset -2765
06    [b9a8f9f6] (2) Ripped with offset -699
06    [a6dfa735] (30/77) Accurately ripped.
07    [83878257] (23) Ripped with offset -2177
07    [d68b4661] (2) Ripped with offset -699
07    [605c09ce] (30/73) Accurately ripped.
08    [539b885a] (23) Ripped with offset -2177
08    [7723b370] (2) Ripped with offset -699
08    [49ef8813] (29/72) Accurately ripped.
09    [fce59bb0] (22) Ripped with offset -2177
09    [d5e50132] (2) Ripped with offset -699
09    [20760a3b] (29/71) Accurately ripped.

What do you think about presenting them in such way:

CODE

[Disc ID: 00142b00-008fceac-900c3809]
Track    [ CRC    ] Status
01    [358a4c62] (30/77) Accurately ripped as in pressing(s) # 4.
02    [247ccff4] (29/74) Accurately ripped as in pressing(s) # 4.
03    [abe1dc48] (30/77) Accurately ripped as in pressing(s) # 4.
04    [86712e7d] (30/77) Accurately ripped as in pressing(s) # 4.
05    [8d5f2a58] (29/74) Accurately ripped as in pressing(s) # 4.
06    [a6dfa735] (30/77) Accurately ripped as in pressing(s) # 4.
07    [605c09ce] (30/73) Accurately ripped as in pressing(s) # 4.
08    [49ef8813] (29/72) Accurately ripped as in pressing(s) # 4.
09    [20760a3b] (29/71) Accurately ripped as in pressing(s) # 3.
Offsetted by -2765:
01    [212a0901] (00/77) No matches.
02    [211b1e34] (00/74) No matches.
03    [5327f804] (00/77) No matches.
04    [7d2a5066] (00/77) No matches.
05    [bbd0d4a3] (00/74) No matches.
06    [96b9ba8c] (02/77) Accurately ripped as in pressing(s) # 5.
07    [31a8a703] (00/73) No matches.
08    [6927016e] (00/72) No matches.
09    [56e4766c] (00/71) No matches.
Offsetted by -2177:
01    [c677f906] (00/77) No matches.
02    [ecba3a07] (00/74) No matches.
03    [eab127d7] (00/77) No matches.
04    [73a261ac] (00/77) No matches.
05    [04ac5287] (00/74) No matches.
06    [2ded3768] (23/77) Accurately ripped as in pressing(s) # 1.
07    [83878257] (23/73) Accurately ripped as in pressing(s) # 1.
08    [539b885a] (23/72) Accurately ripped as in pressing(s) # 1.
09    [fce59bb0] (22/71) Accurately ripped as in pressing(s) # 1.
Offsetted by -699:
01    [6fd92963] (00/77) No matches.
02    [9662fcde] (00/74) No matches.
03    [fdd54e7c] (00/77) No matches.
04    [1d2f85b5] (00/77) No matches.
05    [26ff0053] (00/74) No matches.
06    [b9a8f9f6] (02/77) Accurately ripped as in pressing(s) # 6.
07    [d68b4661] (02/73) Accurately ripped as in pressing(s) # 5.
08    [7723b370] (02/72) Accurately ripped as in pressing(s) # 5.
09    [d5e50132] (02/71) Accurately ripped as in pressing(s) # 5.

I know it's longer but at least it's more informative.

[No Fun]

Gregory S. Chudov

Thanks for nice new features! Great job!

It seems to me CUE Tools now reports "Track not present in database" instead of "Rip not accurate". Can you check it?

[Raiden]

This is a great tool! I'm using it to batch-verify my lossless rips with AccurateRip. The automatic offset correction comes in very handy.


It has a problem with tracks that just consist of digital silence:

CODE

Offset applied: 712
[Disc ID: 0036c6ce-03948928-580f7c17]
Track    [ CRC    ] Status
01    [7f530f41] (59/123) Accurately ripped.
02    [bb82c5b2] (60/123) Accurately ripped.
03    [92edbeee] (60/124) Accurately ripped.
04    [2817652f] (60/123) Accurately ripped.
05    [7cfe0dd2] (60/122) Accurately ripped.
06    [e1b26eb0] (61/125) Accurately ripped.
07    [55af72f8] (60/123) Accurately ripped.
08    [215a6ecc] (60/123) Accurately ripped.
09    [39088de6] (60/123) Accurately ripped.
10    [92039c5a] (60/124) Accurately ripped.
11    [e20d75bd] (60/123) Accurately ripped.
12    [5a23fc7f] (60/123) Accurately ripped.
13    [0d96722b] (60/123) Accurately ripped.
14    [90c958f1] (60/123) Accurately ripped.
15    [bbdf7fb2] (60/123) Accurately ripped.
16    [3e616b07] (59/121) Accurately ripped.
17    [12ecc1b9] (60/123) Accurately ripped.
18    [aed764a7] (60/124) Accurately ripped.
19    [a0aa9d2c] (57/121) Accurately ripped.
20    [7d64c179] (60/123) Accurately ripped.
21    [029d9079] (56/118) Accurately ripped.
22    [e21f8b62] (47) Ripped with offset -664
22    [015aba6e] (8) Ripped with offset -86
22    [66e88d76] (4) Ripped with offset -682
22    [f8b6ccf2] (56/118) Accurately ripped.
23    [00000000] (0) Ripped with offset -2939
23    [00000000] (0) Ripped with offset -2938
23    [00000000] (0) Ripped with offset -2937
23    [00000000] (0) Ripped with offset -2936
23    [00000000] (0) Ripped with offset -2935
23    [00000000] (0) Ripped with offset -2934
23    [00000000] (0) Ripped with offset -2933
23    [00000000] (0) Ripped with offset -2932
23    [00000000] (0) Ripped with offset -2931
23    [00000000] (0) Ripped with offset -2930
23    [00000000] (0) Ripped with offset -2929
23    [00000000] (0) Ripped with offset -2928
23    [00000000] (0) Ripped with offset -2927
23    [00000000] (0) Ripped with offset -2926
23    [00000000] (0) Ripped with offset -2925
23    [00000000] (0) Ripped with offset -2924
23    [00000000] (0) Ripped with offset -2923
23    [00000000] (0) Ripped with offset -2922
23    [00000000] (0) Ripped with offset -2921
23    [00000000] (0) Ripped with offset -2920
23    [00000000] (0) Ripped with offset -2919
23    [00000000] (0) Ripped with offset -2918
23    [00000000] (0) Ripped with offset -2917
23    [00000000] (0) Ripped with offset -2916
23    [00000000] (0) Ripped with offset -2915
23    [00000000] (0) Ripped with offset -2914
.
.
.
.
.
.
.
.

The final accurip file was 1268 KB

[Gregory S. Chudo...]

This is a great tool! I'm using it to batch-verify my lossless rips with AccurateRip. The automatic offset correction comes in very handy.


It has a problem with tracks that just consist of digital silence:

The final accurip file was 1268 KB

Thanks. Tried to fix it. Can you please test an updated version?

[Raiden]

It now says (excerpt):

CODE

  19    [8c2ca83c] (04/121) Accurately ripped as in pressing(s) #4.
20    [cb6b08af] (04/123) Accurately ripped as in pressing(s) #4.
21    [9a6cb1db] (04/118) Accurately ripped as in pressing(s) #4.
22    [66e88d76] (04/118) Accurately ripped as in pressing(s) #4.
23    [00000000] (00/00) No matches.

Also the new formatting is much more intuitive and better readable. Thanks!

[foorious]

No, it's me who is blind, i didn't notice you didn't have cuesheets.
I'll think about automating the process, but for now i would recomend to write a script whch would create cuesheets for each directory. This would be very easy if your files have gaps appended. If they have gaps prepended or left out, there's nothing really that can be done - you have to know the size of gaps to be able to compare the disc to the database. Also if the first track had index 00, you're out of luck.

Well, I believe there must already be some utility that can batch-create cuesheets from single-track files. I'm talking about simply selecting a start folder, and then the utility would scan all the subfolders, find all tracks within a given subfolder, then create a cuesheet from them. Am I wrong ?

I am not a programmer, but I guess if such utility doesn't exist yet, it should be quite easy to create, and also to implement in CUETools. So Gregory, I hope you'll have the time to automate such process in the future. Thank you.

So you can create those dummy cuesheets by hand, and then just copy into each folder a .cue sheet which has the same number of tracks as this folder.

Um, yes, sure, but I have several thousand folders, so by hand is not a solution...

[No Fun]

Strange...
Can it be that CUE Tools cannot find right offset for a set of FLACs linked up with a dummy cuesheet?
In my case it gives only "(00/01) No matches.", while TripleFlac! easily found offset to be -1501 (with "LeadIn: 0") and verification in CT with that value showed "Accurately ripped as in pressing(s) #1". Also when I converted "tracks + dummy cuesheet" to WAV "Single File + CUE", ARcue found -1501 as well.
At the same time with another rip (in the form of "flac-image + cuesheet") verification, as it should, showed two results: one without offset correction ("No matches") and another, "offsetted".

Command line parameters is the feature I missed so much! Very nice verification mode & awesome new log!
Now I wish only CT could directly handle a set of FLAC files (or folder containing them) - I'd throw away TripleFlac!
As for usability I can suggest hotkeys (Alt+letter) and Write Offset box right in the main window (yeah, it was there already some time ago, and IMHO so it were much more convenient). Also an option to set up filename for AccurateRip report would be nice to have. And to be completely a bore… maybe you can remove those points at the end of almost every line of AR report to save a few bytes on HDD?

[Gregory S. Chudo...]

Strange...
Can it be that CUE Tools cannot find right offset for a set of FLACs linked up with a dummy cuesheet?
In my case it gives only "(00/01) No matches.", while TripleFlac! easily found offset to be -1501 (with "LeadIn: 0") and verification in CT with that value showed "Accurately ripped as in pressing(s) #1". Also when I converted "tracks + dummy cuesheet" to WAV "Single File + CUE", ARcue found -1501 as well.
At the same time with another rip (in the form of "flac-image + cuesheet") verification, as it should, showed two results: one without offset correction ("No matches") and another, "offsetted".

Command line parameters is the feature I missed so much! Very nice verification mode & awesome new log!
Now I wish only CT could directly handle a set of FLAC files (or folder containing them) - I'd throw away TripleFlac!
As for usability I can suggest hotkeys (Alt+letter) and Write Offset box right in the main window (yeah, it was there already some time ago, and IMHO so it were much more convenient). Also an option to set up filename for AccurateRip report would be nice to have. And to be completely a bore… maybe you can remove those points at the end of almost every line of AR report to save a few bytes on HDD?

Can i see that dummy cuesheet? Is the accuraterip discId identical in those logs? Did you use CUETools to convert "tracks + dummy cuesheet" to WAV "Single File + CUE", or something else was involved in that process?

[No Fun]

Can i see that dummy cuesheet? Is the accuraterip discId identical in those logs? Did you use CUETools to convert "tracks + dummy cuesheet" to WAV "Single File + CUE", or something else was involved in that process?

Of cause you can, although I can't even imagine what can be wrong there

CODE

FILE "01.flac" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "02.flac" WAVE
  TRACK 02 AUDIO
    INDEX 01 00:00:00
FILE "03.flac" WAVE
  TRACK 03 AUDIO
    INDEX 01 00:00:00
FILE "04.flac" WAVE
  TRACK 04 AUDIO
    INDEX 01 00:00:00
FILE "05.flac" WAVE
  TRACK 05 AUDIO
    INDEX 01 00:00:00
FILE "06.flac" WAVE
  TRACK 06 AUDIO
    INDEX 01 00:00:00
FILE "07.flac" WAVE
  TRACK 07 AUDIO
    INDEX 01 00:00:00
FILE "08.flac" WAVE
  TRACK 08 AUDIO
    INDEX 01 00:00:00
FILE "09.flac" WAVE
  TRACK 09 AUDIO
    INDEX 01 00:00:00
FILE "10.flac" WAVE
  TRACK 10 AUDIO
    INDEX 01 00:00:00
FILE "11.flac" WAVE
  TRACK 11 AUDIO
    INDEX 01 00:00:00
FILE "12.flac" WAVE
  TRACK 12 AUDIO
    INDEX 01 00:00:00
FILE "13.flac" WAVE
  TRACK 13 AUDIO
    INDEX 01 00:00:00

Here's CUE Tools verify log:

CODE

[Disc ID: 001a219e-01121231-9e0ea70d]
Track    [ CRC    ] Status
01    [3b855413] (00/01) No matches.
02    [a94794c5] (00/01) No matches.
03    [10defeda] (00/01) No matches.
04    [2bf1fba0] (00/01) No matches.
05    [9005ab87] (00/01) No matches.
06    [3cddaad7] (00/01) No matches.
07    [21d37bf7] (00/01) No matches.
08    [fe595914] (00/01) No matches.
09    [2e4d4e4d] (00/01) No matches.
10    [31fd9da0] (00/01) No matches.
11    [32eecc56] (00/01) No matches.
12    [0d96ef91] (00/01) No matches.
13    [93bb2533] (00/01) No matches.

Here's TripleFlac screenshot:


As you can see DiscIDs are the same.

And here's ARcue++ log (yes, "tracks + dummy cuesheet" converted to WAV "Single File + CUE" using CUE Tools):

CODE

VAO.fake.cue:

Checking AccurateRip database

Track   Ripping Status          [Disc ID: 001a219e-9e0ea70d]

1      ** Rip offset: -1501 **   (confidence 1)     [f4412e2c]
2      ** Rip offset: -1501 **   (confidence 1)     [c73179c8]
3      ** Rip offset: -1501 **   (confidence 1)     [34a31f66]
4      ** Rip offset: -1501 **   (confidence 1)     [869a31b8]
5      ** Rip offset: -1501 **   (confidence 1)     [c02a617d]
6      ** Rip offset: -1501 **   (confidence 1)     [a0f3d5c0]
7      ** Rip offset: -1501 **   (confidence 1)     [0ef8470f]
8      ** Rip offset: -1501 **   (confidence 1)     [48c15f65]
9      ** Rip offset: -1501 **   (confidence 1)     [59c30bc1]
10     ** Rip offset: -1501 **   (confidence 1)     [695a2514]
11     ** Rip offset: -1501 **   (confidence 1)     [f2dbd886]
12     ** Rip offset: -1501 **   (confidence 1)     [0bd99066]
13     ** Rip offset: -1501 **   (confidence 1)     [c55bb653]

_______________________

Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 0 ****
Track(s) Not in Database: 0

So why CUE Tools didn't find that -1501 offset?

[greynol]

Maybe 1501 is beyond the window being used. The AR dll uses a window of 3527 samples (-1763...0...1763). The larger you make the window, the longer determining the offset will take.

[Moitah]

It should be able to find offsets within +/- 2939. I tried to reproduce this (same offset, generic cuesheet) but it worked fine for me, at least on the CD I tried. I wonder if it has a problem calculating the checksum when it has to read into the previous/next track, but I didn't notice this because my files had enough silence in between (just a guess).

Also, I tested the bugfix for the silent track issue, it works fine (although it reports no matches for that track, but that appears to be a limitation of AccurateRip rather than a bug in this code).

By the way, I modified the latest code a bit to make the AccurateRip part work on CDs with data tracks. I sent it to Gregory so maybe he'll post a new version soon. I accomplished this by looking for a line in the cuesheet such as:

REM DATATRACKLENGTH 07:42:49

If anyone has a better idea, let me know.

This post has been edited by Moitah: Oct 7 2008, 05:49

[No Fun]

Maybe 1501 is beyond the window being used. The AR dll uses a window of 3527 samples (-1763...0...1763). The larger you make the window, the longer determining the offset will take.

I thought about that when I remembered about search range of 700 by default in previous version. So I applied +802 offset first to move audiodata at -699 samples from AR. But again CUE Tools didn't find that offset while TripleFlac did.

2Gregory S. Chudov
Why did you remove possibility to automatically verify output files after conversion?
Instead maybe we could render AccurateRip support in two checkboxes: "Verify" and "Fix offset"?
The first would depend on "Audio Output" selection: "None" - "Verify" will check source files, other options - "Verify" will check conversion result.
"Fix offset" must always turn on "Verify" and could be disabled if "Audio Output" set to "None".

This post has been edited by No Fun: Oct 7 2008, 08:52

[Gregory S. Chudo...]

The larger you make the window, the longer determining the offset will take.

It is no longer so My algorithm verifies 5878 offsets only twice slower than it takes to calculate single AR CRCs, so the window is constant now.

By the way, I modified the latest code a bit to make the AccurateRip part work on CDs with data tracks. I sent it to Gregory so maybe he'll post a new version soon. I accomplished this by looking for a line in the cuesheet such as:

REM DATATRACKLENGTH 07:42:49

If anyone has a better idea, let me know.

Thanks for the code, i'm playing around with it. Unfortunately embedded flac cue sheets can't have arbitary comments, so i'm probably going to add a flac tag also. And probably an input box in CUETools gui.

2Gregory S. Chudov
Why did you remove possibility to automatically verify output files after conversion?
Instead maybe we could render AccurateRip support in two checkboxes: "Verify" and "Fix offset"?
The first would depend on "Audio Output" selection: "None" - "Verify" will check source files, other options - "Verify" will check conversion result.
"Fix offset" must always turn on "Verify" and could be disabled if "Audio Output" set to "None".

My reasoning was that if you are converting audio files and verifying them with AccurateRip, you'd usually want to correct offset while you're at it. What's the point of verifying audio files after conversion, if you are most probably going to find out that offset wasn't correct and you have to convert them again? So you basicly either don't care about AccurateRip, or just want to verify existing files and don't want to rewrite them, or you want to convert them and fix offset. Thus 3 options. I wanted to keep it simple.

[Gregory S. Chudo...]

By the way, I modified the latest code a bit to make the AccurateRip part work on CDs with data tracks. I sent it to Gregory so maybe he'll post a new version soon. I accomplished this by looking for a line in the cuesheet such as:

REM DATATRACKLENGTH 07:42:49

If anyone has a better idea, let me know.

I'm starting to think we don't need to store so many tags - we already have ACCURATERIPID which is just what we need to get the right entry from the database. So we only need to specify DATATRACKLENGTH in source file or in the CUETools interface, but we should store only ACCURATERIPID and use ACCURATERIPID when it's available. In theory, that way we would be able to verify even a single track taken out of the album, if it has been verified and tagged before by someone - all we need is the ID of the album and the track number.

Also, if we have a decent EAC log in the same folder as a CUE sheet and with the same name, we can try to parse it and retrieve the data track length from there.

This post has been edited by Gregory S. Chudov: Oct 7 2008, 20:53

[Gregory S. Chudo...]

So why CUE Tools didn't find that -1501 offset?

Thanks a lot, looks like i fixed it!

CODE

[Disc ID: 001a219e-01121231-9e0ea70d]
Track    [ CRC    ] Status
01    [3b855413] (00/01) No matches.
02    [a94794c5] (00/01) No matches.
03    [10defeda] (00/01) No matches.
04    [2bf1fba0] (00/01) No matches.
05    [9005ab87] (00/01) No matches.
06    [3cddaad7] (00/01) No matches.
07    [21d37bf7] (00/01) No matches.
08    [fe595914] (00/01) No matches.
09    [2e4d4e4d] (00/01) No matches.
10    [31fd9da0] (00/01) No matches.
11    [32eecc56] (00/01) No matches.
12    [0d96ef91] (00/01) No matches.
13    [93bb2533] (00/01) No matches.
Offsetted by -1501:
01    [f4412e2c] (01/01) Accurately ripped as in pressing(s) #1.
02    [c73179c8] (01/01) Accurately ripped as in pressing(s) #1.
03    [34a31f66] (01/01) Accurately ripped as in pressing(s) #1.
04    [869a31b8] (01/01) Accurately ripped as in pressing(s) #1.
05    [c02a617d] (01/01) Accurately ripped as in pressing(s) #1.
06    [a0f3d5c0] (01/01) Accurately ripped as in pressing(s) #1.
07    [0ef8470f] (01/01) Accurately ripped as in pressing(s) #1.
08    [48c15f65] (01/01) Accurately ripped as in pressing(s) #1.
09    [59c30bc1] (01/01) Accurately ripped as in pressing(s) #1.
10    [695a2514] (01/01) Accurately ripped as in pressing(s) #1.
11    [f2dbd886] (01/01) Accurately ripped as in pressing(s) #1.
12    [0bd99066] (01/01) Accurately ripped as in pressing(s) #1.
13    [c55bb653] (01/01) Accurately ripped as in pressing(s) #1.

[No Fun]

Thanks a lot, looks like i fixed it!

Thanks to you! It really works. For this disc
But here's another strange one.

CUE Tools:

CODE

[Disc ID: 0017e7d1-00bf2bfa-950e510a]
Track    [ CRC    ] Status
01    [af1f932c] (00/01) No matches.
02    [34454baa] (00/01) No matches.
03    [def7ad1c] (00/01) No matches.
04    [354b67a6] (00/00) No matches.
05    [5c8a24af] (00/01) No matches.
06    [e2f5e9b4] (00/00) No matches.
07    [cc7d00b0] (00/01) No matches.
08    [6e2f3ab5] (00/01) No matches.
09    [6ec83640] (00/01) No matches.
10    [b0ecd7e9] (00/01) No matches.
Offsetted by 655:
01    [9259c6fc] (00/01) No matches.
02    [734ae878] (00/01) No matches.
03    [4498c239] (00/01) No matches.
04    [65f00e98] (00/00) No matches.
05    [1b940606] (00/01) No matches.
06    [f5661249] (00/00) No matches.
07    [15e1e83e] (00/01) No matches.
08    [43707c3b] (00/01) No matches.
09    [b610deb7] (01/01) Accurately ripped as in pressing(s) #1.
10    [6fee13fa] (00/01) No matches.

TripleFlac!:

[Gregory S. Chudo...]

Well, in this case there is no bug. Either your copy or the one in database is damaged in almost every track, there's only one submission to the database, so there's no way to find out which was the case.

My current guess is that Tripleflac compares partial CRCs, not of entire tracks, but of some small fragments. There is a mysterious unused alernate CRC for each track in AccurateRip database, and i suppose it's a CRC of some fragment of a track.

Tripleflac managed to guess the offset using bad copies - that's looks like a nice feature, and i would like to have it in CUETools too, though i think it's not very useful. Because if your copy is damaged, offset is the last thing you should worry about

[No Fun]

if your copy is damaged, offset is the last thing you should worry about

Agree, since I can verify rip without fixing offset at first I'm not worried about it at all Maybe that is why I haven't really tried "Fix offset" option yet and lack for autoverification after conversion. If AR knows about different pressing only but I'm sure the rip is offset corrected, I wouldn't adjust it to AR, only convert image to tracks (I like it that way) and verify result. Anyway I accept what you done with gratitude!

Creating .cue works fine! But I think there must be some remark about it's origin, maybe in filename or in REM or both.
And that "Browse for folders" dialog always starting at Desktop is really a pain in the ass IMHO drag'n'drop straight on those three buttons would be much more handy (accepting cuesheet(s), folder(s) and a set of files would be nice).
But it still wouldn't be as much handy as commandline switches to do whatever we want directly from favorite file manager

And could you please add hotkeys also for "Output" ("Fix offset" could be changed to "Fix offset"), "Manual" and "Create subdirectory"?

Let me know if I'm makin haste or distract you from more important things

This post has been edited by No Fun: Oct 8 2008, 09:00

[NachoMan77]

Hi Gregory !

thanks a lot for jumpstarting CUEtools dev. Moitah did a fantastic job to begin with, and I'm sure that with all these new features, CUETools will be one of the ebst tools for lossless,cue,AR management.

I have a request though...

I'm currently transcoding very old single ape+cue albums to FLAC. I basically decode to wav, verify AR and if OK (all tracks present & confidently ripped) I encode them to FLAC. If AR check is not OK, I move the album to a ToVerify folder for later on inspection.

Can you implement an "Encode if AR verify OK" mode ? You could even have a setting to specify the confidence level of an OK AR verification, say for example, 5 (i.e.: if confidence level is >=5, then flag it as OK). An album should be considered AR OK if all tracks verify with the same offset, over the previously specified treshold.

On the other hand, you could also have an option to log all the AR verification activity to a central file. This is really helpful for batch processing. Say for example you you can log all the AR fails, and later on it's just a matter to manually parse the log looking for full albums that are eligible for offset correction (i.e: same offset for all tracks), and apply it using batch mode.

Hope this makes sense...

thanks in advance,

n.

This post has been edited by NachoMan77: Oct 8 2008, 13:58

[foorious]

Creating .cue works fine! But I think there must be some remark about it's origin, maybe in filename or in REM or both.

I second that. Cuesheets created by CUETools should be immediately distinguishable from others. Why not directly in the filename ? E.g. : "Artist - Album [CUETools].cue" (REM would be good also as a complement)

This post has been edited by foorious: Oct 8 2008, 14:50