CUETools 1.9.5, AccurateRip support & more Options

[Gregory S. Chudo...]

Please welcome, CUETools v2.0.4a.

08.08.2009: CUETools 2.0.4a:
 CUETools_2.0.4a_x86.rar ( 888.22K ) Number of downloads: 26191
 CUETools_2.0.4a_x64.rar ( 979.65K ) Number of downloads: 6128

If you are getting an error loading CUETools.Codecs.TTA, you need to install this update
* Another try to make a decent UI
* AccurateRip log made a bit more tidy (good offsets first, no 'as in pressing(s)' spam)
* Configurable log file and album art filename templates
* Experimental profiles system
24.06.2009: CUETools 2.0.3:
 CUETools_2.0.3_x86.rar ( 881.13K ) Number of downloads: 16427
 CUETools_2.0.3_x64.rar ( 968.9K ) Number of downloads: 1238

* File browser can now be turned off
* After the job is done, log is shown in the same window (in place of file browser).
* Improved templates for output path generation, using fb2k syntax
* Compression level selected in the main window
01.05.2009: CUETools 2.0.2a experimental:
 CUETools_2.0.2a_x86.rar ( 863.31K ) Number of downloads: 1921
 CUETools_2.0.2a_x64.rar ( 951.66K ) Number of downloads: 539

* Drag'n'dropping huge lists of files to FileSystem tree now works much faster.
* File formats/encoders are now a lot more configurable. New presets for popular command-line encoders.
* When 'Allow multiple instances' option is off, and CUETools is busy, attempting to run it again now produces a proper error message.
* 'Create CUE Sheet' action now not only creates dummy .cue sheets, but also extracts embedded .cue sheets
* Pressing F5 in filesystem tree now refreshes it
* Window size and position is now saved
* Filename corrector now can save results to a different file, and can change extensions without locating files.
* Correct AR tags are now written when converting with non-zero offset
* ACCURATERIPID tag no longer written when writeArTagsOnConvert option is off
* More options to configure tagging
* More options to configure AR log (log verbosity, log file extension, etc)
* Advanced users can slightly modify program's behavior using custom scripts (a-la plugins)
* 'fix offset' option is now an example of a custom script.

Current stable version: 1.9.5a
 CUETools_1.9.5a_x86.rar ( 753.12K ) Number of downloads: 4923
 CUETools_1.9.5a_x64.rar ( 842.15K ) Number of downloads: 894

* Pregap can now be read from log/freedb or set from interface
* ALAC decoding length mismatches fixed
* Problem with single-track albums fixed
* Added an option to disable assembler optimizations in flac
* Support for user-defined external commandline codecs with templates for tak/ogg/mp3
* Better support for zip archives, which previously worked only with flac/wav files
* More reliable tag handling, using taglib-sharp. Album art tags are now preserved.
* ALAC decoder bug fixed
* CRC comparison for older EAC logs is now supported
* Two verify modes: first is AccurateRip only and second is AccurateRip+EAC CRCs.

Version 1.9.4.a
 CUETools_1.9.4a_x86.rar ( 649.18K ) Number of downloads: 1262
 CUETools_1.9.4a_x64.rar ( 742.19K ) Number of downloads: 390

* %Y format character for output path - date of album release. For example, custom format "C:\Music\%D\%Y - %C\%D - %C.cue" produces the output like this: "C:\Music\Pink Floyd\1995 - Pulse\Pink Floyd - Pulse.cue"
* Fixed crash on source files that contain zero length tags
* Fixed a glitch in filename corrector - it sometimes didn't replace underscores with spaces.
* Fixed a bug when a broken cue sheet was created if artist, title or genre contained comma character.
* Added .zip archive support
* Added support for cue sheets which start with data track (mixed mode or "playstation type" cds)
* 'Convert and verify' mode is back.
* MusicBrainz/freedb lookup for missing tags
* .log file selection dialog, if it's filename doesn't match .cue file name
* option to extract EAC log tag to file
* added verification date to .accrip logs
* Better RAR archive support: .log files are extracted; filename corrector hopefuly works; if archive contains several .cue sheets, you can select one.
* TTA support
* German localization by tuxman
* option to overwrite CUE sheet tags (PERFORMER, TITLE), replacing them with audio file tags.
* More tags written to file-per-track images (GENRE, DATE, ALBUM, ALBUM ARTIST, TOTALTRACKS)
* CUETools now comes with CUERipper, very experimental but confirmed to work well on modern Pioneer drives. If you encounter ripping problems, please try CUETools.ConsoleRipper, which is a little more verbose, and send me it's console output.

Version: 1.9.3 update 1
 CUETools_x86.rar ( 433.1K ) Number of downloads: 2450
 CUETools_x64.rar ( 522.1K ) Number of downloads: 548

* LossyWAV support
* hdcd decoding to 16 bit lossyWAV
* hdcd detection, analyzis and decoding to 24 bit by Christopher Key
* ALAC (Apple Lossless .m4a) input supported
* RAR archive input supported
* input can be a directory with audio files and no cue sheet
* fixed PartialContent error when reading huge AccurateRip entries
* added an option to store md5 checksum in wavpack output (like wavpack -m)
* added an option to output m3u files when producing gaps appended output
* added an option to output cue file even when producing album image with embedded cuesheet
* added an option to automaticly detect and remove extra 4206 samples, added by some erroneous flac coders.
* added an option to reduce process priority to idle
* pause button becomes resume button when paused
* fixed bug in filename corrector - input files were sorted alphabeticaly, even if only file extension was changed.

Changes from 1.9.1 to 1.9.2 Update 8:
 CUETools_x86.rar ( 277.64K ) Number of downloads: 1218
 CUETools_x64.rar ( 317.57K ) Number of downloads: 381

* AccurateRip database support with automatic offset correction (with permission from Mr Spoon)
* Monkey's Audio (.ape) input/output support
* Embedded cue sheets support
* Tags are preserved
* Basic command line support
* CUE Sheet Creator option, which autogenerates cue sheets for folders with audio tracks.
* Better support for different cue sheet encodings
* Unicode filenames support
* x64 build
* Console version for AccurateRip verification: ArCueDotNet.exe
* russian localization
* Minor bug fixes and interface improvements



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++ 2005 SP1 runtime files 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: Aug 8 2009, 17:21

[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